Date: Mon, 1 Dec 2025 11:47:29 -0600 From: "A. Wilcox" <AWilcox@Wilcox-Tech.com> To: Timothy Pearson <tpearson@raptorengineering.com> Cc: Piotr Kubaj <pkubaj@freebsd.org>, Al <al@datazap.net>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Minsoo Choo <minsoochoo0122@proton.me>, Warner Losh <imp@bsdimp.com>, "freebsd-arch@freebsd.org" <arch@freebsd.org>, freebsd-ppc <freebsd-ppc@freebsd.org> Subject: Re: What's the plan for powerpc64 in FreeBSD 16 Message-ID: <5236D06D-31D9-41FC-81F2-B91E4238F65E@Wilcox-Tech.com> In-Reply-To: <526620325.132622.1764608245446.JavaMail.zimbra@raptorengineeringinc.com> References: <CANCZdfrQthqYeGYD_9LRcH94JJZuF2%2BUxAqf7Lcoe6p5VzJf9g@mail.gmail.com> <NqfDArT7jTPoIyfcShDccomNhLR9YUp1_S6kjK_NKIaiQVy2QK4n2KdbZIKm9gqda9fLP62MYQA-N5KOkECydNd1ktiUUuepzOVwCX8thgY=@proton.me> <202511261707.5AQH7N1u016543@critter.freebsd.dk> <Pine.NEB.4.64.2511261539520.27486@agnus.datazap.net> <aSdqppYvg5bWwuy6@talos-powerpc64le> <529626383.127814.1764191318804.JavaMail.zimbra@raptorengineeringinc.com> <aSrV3LKupuDGBtEk@talos-powerpc64le> <526620325.132622.1764608245446.JavaMail.zimbra@raptorengineeringinc.com>
index | next in thread | previous in thread | raw e-mail
On Dec 1, 2025, at 10:57, Timothy Pearson <tpearson@raptorengineering.com> wrote: > > ----- Original Message ----- >> From: "Piotr Kubaj" <pkubaj@freebsd.org> >> To: "Timothy Pearson" <tpearson@raptorengineering.com> >> Cc: "Al" <al@datazap.net>, "Poul-Henning Kamp" <phk@phk.freebsd.dk>, "Minsoo Choo" <minsoochoo0122@proton.me>, "Warner >> Losh" <imp@bsdimp.com>, "freebsd-arch@freebsd.org" <arch@freebsd.org>, "freebsd-ppc" <freebsd-ppc@freebsd.org> >> Sent: Saturday, November 29, 2025 5:15:40 AM >> Subject: Re: What's the plan for powerpc64 in FreeBSD 16 > >> On 25-11-26 15:08:38, Timothy Pearson wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "Piotr Kubaj" <pkubaj@freebsd.org> >>>> To: "Al" <al@datazap.net> >>>> Cc: "Poul-Henning Kamp" <phk@phk.freebsd.dk>, "Minsoo Choo" >>>> <minsoochoo0122@proton.me>, "Warner Losh" <imp@bsdimp.com>, >>>> "freebsd-arch@freebsd.org" <arch@freebsd.org>, "freebsd-ppc" >>>> <freebsd-ppc@freebsd.org> >>>> Sent: Wednesday, November 26, 2025 3:01:26 PM >>>> Subject: Re: What's the plan for powerpc64 in FreeBSD 16 >>> >>>> On 25-11-26 15:47:38, Al wrote: >>>>> >>>>> On Wed, 26 Nov 2025, Poul-Henning Kamp wrote: >>>>> >>>>>> Date: Wed, 26 Nov 2025 17:07:23 +0000 >>>>>> From: Poul-Henning Kamp <phk@phk.freebsd.dk> >>>>>> To: Minsoo Choo <minsoochoo0122@proton.me> >>>>>> Cc: Warner Losh <imp@bsdimp.com>, >>>>>> "freebsd-arch@freebsd.org" <arch@freebsd.org> >>>>>> Subject: Re: What's the plan for powerpc64 in FreeBSD 16 >>>>>> >>>>>> Minsoo Choo writes: >>>>>> >>>>>>> After reading replies, I still have questions why we should keep powerpc64be. >>>>>> >>>>>>> Second, regarding arguments about keeping big-endian support in codebase even >>>>>>> if no one actually physically runs the code: >>>>>>> This also applies to leaving 32-bit code (armv7) in tree for future >>>>>>> compatibility. >>>>>> >>>>>> I think that is a bit of a leap, although in principle I agree. >>>>>> >>>>>> However, I am much less convinced that a relevant new 32 bit platform >>>>>> will appear, than that somebody comes out with a 64 BE platform. >>>>>> >>>>>> Bit-rot is a thing, and unless we are willing to say "Screw anybody >>>>>> silly enough to create BE platform now or in the future" we should >>>>>> still guard against it. >>>>> >>>>> There is a number of new PowerPC 64 BE systems: >>>>> A1222 >>>> BE, but not 64-bit. It's supported via powerpcspe port on FreeBSD, which >>>> is already deprecated along with powerpc. >>>>> Sam460 several versions >>>> I'm not sure about that, I think it's also 32-bit. >>>>> Mirari (New PPC hardware) >>>> This one will be ugly, similarly to e5500. e5500 is 64-bit, but without >>>> Altivec, so it's below the usual baseline. Mirari will use e6500. e6500 >>>> supports BE with Altivec. It also supports LE, but without VSX. The >>>> current baseline for LE is POWER8, which supports VSX. >>>> e5500 works on FreeBSD, but requires building everything on your own, >>>> along with the OS itself, by using CPUTYPE?=e5500 in make.conf, >>>> otherwise Altivec instructions will be issued by clang. If we ever get >>>> binary packages on powerpc64, e5500 users will still need to build their >>>> own because of that. >>> >>> If that's correct, then ABIv2 would be broken in LE mode, making LE mode even >>> less useful on that hardware. I really don't want to be forced to keep the >>> early ABI support around just for quite old, fairly quirky cores. >> >> Why? ELFv2 itself works fine without VSX, e.g. on G5 and e5500, on BE. >> Why would running on LE specifically require VSX if the binaries are >> built without VSX? > > ABIv2 requires the use of VSX registers for argument passing. It's possible this still works at a hardware level on these devices, or that we simply haven't hit the spill level where they are needed for most (all?) function calls in practice. Regardless, it's a point of concern for legacy, non-OpenPOWER compliant hardware. This is not true. Quoting the ABI itself, §2.2.3: For the OpenPOWER ABI, the following parameters can be passed in registers: • Up to eight arguments can be passed in general-purpose registers r3 - r10. • Up to thirteen qualified floating-point arguments can be passed in floating-point registers f1 - f13 or up to twelve in vector registers v2 - v13. • Up to thirteen single-precision or double-precision decimal floating-point arguments can be passed in floating-point registers f1 - f13. • Up to six quad-precision decimal floating-point arguments can be passed in even-odd floating-point register pairs f2 - f13. • Up to 12 qualified vector arguments can be passed in v2 - v13. If you are not using VSX-sized vector arguments, v2-v13 are not necessary. And indeed, when compilers like GCC or Clang are passed -mno-vsx (implied by any -mcpu= lower than Power7), they won’t even reserve the optional vector register storage area in the stack frame. Both usages of vector registers for parameter passing are specified as “can”, not “shall” or “must”. And part of the reason that register storage area is optional is because Power cores may not have any vector extensions (see Microwatt, for example). I’m aware that the OpenPOWER conformance suite notes that “there are no optional sections [of the ISA]”, however Power ISA 3.0B (the version I have handy) states in §1.10: > an attempt to execute an instruction that is not provided by the implementation [shall invoke the] system illegal instruction error handler You may not be able to sell Microwatt (or Libre-SOC, or …) as “OpenPOWER ISA 3.x compliant”, but you can definitely run the majority of Linux and FreeBSD workloads on these cores without any issues. I am quite ready to die on the hill of VSX not being actually required by ABIv2 in any technical capacity, and I’ve spent significant time in the bowels of compilers, JITs, and the like for the past 8 years proving that true. Best, -Annahelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5236D06D-31D9-41FC-81F2-B91E4238F65E>