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

On Wed, 26 Nov 2025 15:50:35 +0000
Minsoo Choo <minsoochoo0122@proton.me> wrote:

> On Monday, November 17th, 2025 at 11:58 AM, Warner Losh <imp@bsdimp.com>
> wrote:
> 
> > Greetings,
> >
> > As we're getting close to the release date for FreeBSD 15.0, it's time to
> > take stock of another architectures. This time, I'd like your feedback on
> > the following plans.
> >
> > We'd like to retire powerpc64 and powerpc64le just before the FreeBSD
> > stable/16 branch.
> >
> > This would give powerpc64 another two years of support in main, followed
> > by sustaining support on stable/14 and stable/15 until the end of those
> > branches.
> >
> > We've come to this point because the port is dwindling and we have a cost
> > associated with keeping it around. The number of developers has fallen off
> > so only a couple remain. Issues in powerpc are taking longer and longer to
> > discover and resolve. The hardware has been a huge source of frustration
> > for clusteradmin and we've no alternative for developers. There's only a
> > tiny user base. We have trouble building packages for it. Also, powerpc
> > has a number of interesting features of the architecture that make it the
> > odd arch out.
> >
> > It's also big endian. While that may seem like a reason to keep it around,
> > if we really can't support it and we're not actively testing functionality
> > of the system, then keeping this around actually doesn't help keep us
> > honest. It just gives us a burden we must bear.
> >
> > In my opinion, powerpc64 appears to have already fallen below critical
> > mass, despite being a sentimental favorite for a number of FreeBSD
> > developers. As such, I'd like us to consider planning to retire it before
> > we branch 16.
> >
> > My questions today: Are you using this port? How many people are using it?
> > And what's the installed base? It appears to be somewhat less than that of
> > either i386 or armv7 based on user surveys and popularity at conferences.
> > Also, any other comments you might have.
> >
> > Warner  
> 
> After reading replies, I still have questions why we should keep powerpc64be.
> 
> Most people seem to agree with keeping support for powerpc64le, so I won't
> talk about that here.
> 
> First, regarding arguments that people still use powerpc64be:
> When was the last time big-endian powerpc64 processor came out? Here when I
> say big-endian, I mean big-endian-only without bi-endian support. PowerPC

And if bi-endian, so what? This is user's choice in which mode to put
processor, OS have to just support. "Tools, not policy."

> Many people have talked about leaving big-endian or 32-bit support in source
> tree for future compatibility. No one (except for one person who mentioned
> big-endianRISC-V) answered more important question: Will there be big-endian
> or 32-bit architecture in future that will be on par with existing 64-bit
> little-endian architectures? If there will be, when? And will they be
> suitable for FreeBSD's use cases?

Oh, again this ignorance? Of course, they WILL be. Look at the IoT world, when
device with dozen of kilobytes of RAM (C2 class by RFC 7228) is luxury yet. Of
course, they will evolve to 32-bit machines to support more memory, here will
be time for FreeBSD - if nobody will forget how ti support it.

> For example, we removed IA-64 support in stable/11. IA-64 was the last (and
> the only) VLIW architecture we had. No one questioned why we just keep it
> for future VLIW architectures. VLIW is still used in some industries like
> Groq (which I believe is a scam). But none of them are suitable for FreeBSD.

Meanwhile, Elbrus: exists. And there were even tries to port FreeBSD to it.

> We should ask the same question for big-endian and 32-bit architectures.
> Someone said future 32-bit architectures can have memory space bigger than
> 4GB through extensions and tricks. Why would any manufacturer do that if
> they have existing 64-bit architectures that have been working for decades?

The point is exactly opposite - to have LESS memory consumed, which is
applicable even today for cloud VMs. This is real money.

> Another person mentioned RISC-V big endian. In what scenario will a company
> launch big-endian RISC-V processor to compete with existing little-endian
> RISC-V processors? A blog post from RISC-V International says: "There are

You ask questions based on linear predictions without any black swans.
However, world is changing trends right now.

> manufacturer chose not to implement what is in the RVA23 profile, then they
> mean they don't care about keeping the ecosystem consistent by keeping
> distance with defragmentation. If that's the case, it is not our
> responsibility to support their architectures. Fortunately, most major

Fragmented ecosystem is most expected scenario in practice - we've all seen
this with e.g. many Unix clones before 1990-s.

> Talking proactively about future big-endian or 32-bit architectures is waste
> of time when we even don't know whether it will exist or not. FreeBSD is
> modern operating system, and it has more requirements than just a typical
> microprocessor for embedded systems like Arm Cortex-M that lacks components
> like MMU or page tables. To my view, even after reading what people replied
> here, the possibility for a company launching big-endian or 32-bit
> architecture with those components converges to zero. If I'm missing any of
> those ​​physical architectures (not just supported through VM) that will
> appear in the next ten years, please let me know. But if what I'm talking
> here is correct, what people said in the replies is like finding El Dorado
> without maps or supporting evidence but just looking for it with groundless
> hope.

Leaving support for such architecture types is cheap. Much cheaper than doing
everything from ground up anew, if/when it will still happen.

-- 
WBR, @nuclight