Date: Sun, 7 Dec 2025 03:03:59 +0300 From: Vadim Goncharov <vadimnuclight@gmail.com> To: Minsoo Choo <minsoochoo0122@proton.me> Cc: "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: What's the plan for powerpc64 in FreeBSD 16 Message-ID: <20251207030359.473cee11@nuclight.lan> In-Reply-To: <i3nZ5cAntG9M3Jic6ugrD-g_wE2kYdCPQ5JxIP8qVkLOP9xPYYq86uONHlbFeznSUnD_daQjTNHbvRgrEIQAP7GJsL213laqcMaoQMORnqs=@proton.me> References: <CANCZdfrQthqYeGYD_9LRcH94JJZuF2%2BUxAqf7Lcoe6p5VzJf9g@mail.gmail.com> <NqfDArT7jTPoIyfcShDccomNhLR9YUp1_S6kjK_NKIaiQVy2QK4n2KdbZIKm9gqda9fLP62MYQA-N5KOkECydNd1ktiUUuepzOVwCX8thgY=@proton.me> <20251130205134.36a2ac9d@nuclight.lan> <i3nZ5cAntG9M3Jic6ugrD-g_wE2kYdCPQ5JxIP8qVkLOP9xPYYq86uONHlbFeznSUnD_daQjTNHbvRgrEIQAP7GJsL213laqcMaoQMORnqs=@proton.me>
index | next in thread | previous in thread | raw e-mail
On Sun, 30 Nov 2025 18:39:23 +0000 Minsoo Choo <minsoochoo0122@proton.me> wrote: > 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. Who are you here to talk "we" ? > > 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. So what? Answered statement was about VLIW. This may mean that VLIW is certainly possible to be supported by LLVM or even new architectures to appear. > > 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. You did not even understood what I've said. The *same* software built for i386 or amd64 consumes different amount of memory (pointer sizes, mainly) and this means different price of memory when you pay for thousands of virtual machines in clouds. This is real money. Right now, in 2025. > > > 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. Seems you don't know even what "black swan" means. > > > 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? And so what? No guarantee. > 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. This is just your optimistic hopes. > > > 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. IBM? Seriously? Who cares about IBM in 2025 ? > 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.) You again completely missed point of IoT. -- WBR, @nuclighthelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20251207030359.473cee11>