Re: What's the plan for powerpc64 in FreeBSD 16

Timothy Pearson <[email protected]> Mon, 1 Dec 2025 10:57:25 -0600 (CST)
Newsgroups gmane.os.freebsd.devel.ppc
Message-ID <526620325.132622.1764608245446.JavaMail.zimbra@raptorengineeringinc.com>

----- Original Message -----
> From: "Piotr Kubaj" <[email protected]>
> To: "Timothy Pearson" <[email protected]>
> Cc: "Al" <[email protected]>, "Poul-Henning Kamp" <[email protected]>, "Minsoo Choo" <[email protected]>, "Warner
> Losh" <[email protected]>, "[email protected]" <[email protected]>, "freebsd-ppc" <[email protected]>
> 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" <[email protected]>
>> > To: "Al" <[email protected]>
>> > Cc: "Poul-Henning Kamp" <[email protected]>, "Minsoo Choo"
>> > <[email protected]>, "Warner Losh" <[email protected]>,
>> > "[email protected]" <[email protected]>, "freebsd-ppc"
>> > <[email protected]>
>> > 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 <[email protected]>
>> >> > To: Minsoo Choo <[email protected]>
>> >> > Cc: Warner Losh <[email protected]>,
>> >> >     "[email protected]" <[email protected]>
>> >> > 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.