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

On Sunday, November 30th, 2025 at 12:51 PM, Vadim Goncharov <vadimnuclight@gmail.com> wrote:
> 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."

This thread came from the cost of maintenance issue. We aim to provide something that is regularly tested and then shipped to the user. IBM is shifting towards little-endian after POWER8, and I see this as a trend. You are correct that it's the user's choice to decide on which endian to run their system, but it is our choice to drop big-endian support if the cost is bigger than the benefit. But I think NetBSD folks can provide what you want.

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

Again, the cost of maintenance. Porting e2k to FreeBSD isn't an issue here. Is Elbrus an architecture that we can support without the making the cost bigger than the benefit? Our whole build system is around llvm and llvm doesn't even support e2k.

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

This argument doesn't make sense. Using less memory doesn't necessarily mean going back to 32-bit architecture. Everyone wants to consume less memory, but then why 32-bit architectures came out after 16-bit and 64-bit architecture came out after 32-bit? Sometimes the advance of technology doesn't allow us to consume the amount of memory we used to.

> 
> > 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.

I think you are not getting the trend. There is no 32-bit RISC-V profile that supports running modern operating systems like FreeBSD. Arm dropped 32-bit after armv8 except for Cortex-M and Cortex-R, which can't run FreeBSD.

> 
> > 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.

And people learned lessons from the fragmentation era and that's why everyone is working hard to defragment the ecosystem.

RISC-V has profiles without enforcement, but still, companies like SiFive and Tenstorrent stick with them voluntarily. Why do you think they do that?

Arm ISA is strictly protected by Arm and companies can choose an ISA version (like armv8.5) to ensure that their chips work without much effort on software side.

OpenPower states that companies cannot promote their chip as Power if tbeir chip does not implement all the required instructions in the profile.

We are not living in pre-1990s anymore.

> > 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.

It won't happen as I mentioned above. You've mentioned "trend" above, then bring a documented trend like profile specification or IBM's statement on leaning towards big-endian.

I think you are misunderstanding software development. Operating systems don't need to support every single architecture or chip in the world. We selectively support them based on cost/benefit judgement. Anyone can bring patches for new architecture but they should also ensure that it will be maintained and tested regularly. Look what happened to riscv64sf or some variants of mips according to arch(7).

You might ask, "what is the threshold for cost/benefit judgement?"  Like many open-source projects, we don't have documented or numerical threshold for that. However, we refer to the past examples of removing platform support to make decisions for current cases. I can tell that FreeBSD has a lower threshold than NetBSD. (I won't compare to Linux because it is just a kernel. You can compare FreeBSD with distros though.)