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

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 970 for PowerMac G5 was the last big-endian processor that physically runs FreeBSD. Other big-endian power processors like the ones until POWER7 (Yes, I know POWER4 to 7 technically support bi-endian, but they were effectively big-endian-only due to lack of firmware and software support) are only supported through pSeries VM according to FreeBSD Hardware Notes. Why would anyone use POWER4 to 7 on pSeries VM for real-life use cases? PowerPC 970 (which uses POWER4 microarchitecture) came out in 2002. At the same time, armv6 was released, and we already deprecated armv6 since FreeBSD 15. FreeBSD 15 will be supported until December 2029, so how many of these big-endian POWER processors that can ​​physically run FreeBSD will be available and run in production 27 years after its launch date?

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.

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?

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. 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? 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 still applications where the way data is stored matters, such as the protocols that move data across the Internet, which are defined as big-endian. So when a little-endian system needs to inspect or modify a network packet, it has to swap the big-endian values to little-endian and back, a process that can take as many as 10-20 instructions on a RISC-V target which doesn’t implement the Zbb extension." [1] I mean... FreeBSD devs need to implement, test, and build infrastructure for one​​ architecture because the manufacturer didn't implement one​​ extension? The B extension is part of the mandatory base in the RVA23 profile. RISC-V profile is recommendation to prevent platform fragmentation. If a 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 RISC-V designers like SiFive and Tenstorrent dedicate themselves to follow the RVA23 profile [2][3].

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.

For those reasons above, I support removal of powerpc64be and armv7 in FreeBSD 16.

[1] https://riscv.org/blog/to-boldly-big-endian-where-no-one-has-big-endianded-before/
[2] https://riscv.org/blog/risc-v-announces-ratification-of-the-rva23-profile-standard/
[3] https://tenstorrent.com/en/vision/tenstorrent-is-continuing-its-contributions-to-the-risc-v-open-source-ecosystem