Date: Sun, 07 Dec 2025 01:20:37 +0000 From: Minsoo Choo <minsoochoo0122@proton.me> To: Vadim Goncharov <vadimnuclight@gmail.com> Cc: "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: What's the plan for powerpc64 in FreeBSD 16 Message-ID: <aOcvf2xziok6NQUIWauFsYWH-OiKiSHuXhbZFFWUxS-AN6uIwoeZ6LkvXxacScUb3A7kwqLHIRKg0gOH7vUJElBPU65fJ9QGg9aOtNmTCs0=@proton.me> In-Reply-To: <20251207030359.473cee11@nuclight.lan> References: <CANCZdfrQthqYeGYD_9LRcH94JJZuF2%2BUxAqf7Lcoe6p5VzJf9g@mail.gmail.com> <NqfDArT7jTPoIyfcShDccomNhLR9YUp1_S6kjK_NKIaiQVy2QK4n2KdbZIKm9gqda9fLP62MYQA-N5KOkECydNd1ktiUUuepzOVwCX8thgY=@proton.me> <20251130205134.36a2ac9d@nuclight.lan> <i3nZ5cAntG9M3Jic6ugrD-g_wE2kYdCPQ5JxIP8qVkLOP9xPYYq86uONHlbFeznSUnD_daQjTNHbvRgrEIQAP7GJsL213laqcMaoQMORnqs=@proton.me> <20251207030359.473cee11@nuclight.lan>
index | next in thread | previous in thread | raw e-mail
On Saturday, December 6th, 2025 at 7:04 PM, Vadim Goncharov <vadimnuclight@gmail.com> wrote: > > > 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" ? FreeBSD developers or any developers with normal mindset, and I think "[aiming] to provide something that is regularly tested and then shipped to the user" is a good definition of normal mindset here. > > > 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. Originally I said, "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." And you said, "Meanwhile, Elbrus: exists. And there were even tries to port FreeBSD to it." I won't ask why the port has failed, but there should be a reason, right?. I know an architecture called Elbrus exists. But I said "none of them are suitable for FreeBSD" as well. There is a small probability for Elbrus or VLIW to be supported on LLVM. But seeing what happened to IA-64 in terms of compiler, I don't think it will be reasonable to do that. VLIW is a pain for compiler developers. My point was that support for IA-64 could be justified because it is **almost** impossible to have another VLIW architecture on FreeBSD in future. Since it seems that you think there could be another VLIW architecture suitable for FreeBSD future, do you think removal of IA-64 support was unreasonable? > > > 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. First, cloud vm is heavily 64-bit for both x86 and arm, so the use case you've mentioned is a special one. i386 is the most common 32-bit architecture for cloud vm and its support was already dropped in FreeBSD 15. I don't think the project cares about the use case you've mentioned. > > > > 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. There is a small possibility FreeBSD might need to support to support another 32-bit or big-endian platform. However, does considering "black swans" outweigh the cost of maintenance? You don't seem to understand my point here. I always say benefit vs cost and then you come up with another benefit that everyone knows but don't mention about the cost. Why is it smart to spend time and resources on 32-bit code just because someone is making a premature assumption? Is that excuse enough to justify the cost? > > > > 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. This is like saying people should always carry umbrellas because there is no guarantee for weather forecasts. At the end of my reply to Warner, I said "what people said in the replies is like finding El Dorado without maps or supporting evidence but just looking for it with groundless hope". There is no guarantee that El Dorado doesn't exist, but it's a bad idea to spend time and resources to find it. If you think that there will be no guarantee that companies won't follow the profile, why do you think RISC-V International created these profiles? > > 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. I gave examples of Arm and OpenPOWER and you call them "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 ? Huh? IBM is still relevant in 2025 for both the industry and developers. Everyone in CS/CE/EE world knows that. Here is section 2.4 of FreeBSD 15.0 Hardware Notes: IBM: Power System LC922 (POWER9) Power System IC922 (POWER8) QEMU: PowerNV Raptor CS: Talos II (POWER9) Blackbird (POWER9) Who do you think made these chips? > > 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. Because I already mentioned it through the examples of armv8 and RISC-V profiles. Again, none of 32-bit armv8 cores or RISC-V profiles support facilities required for FreeBSD.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aOcvf2xziok6NQUIWauFsYWH-OiKiSHuXhbZFFWUxS-AN6uIwoeZ6LkvXxacScUb3A7kwqLHIRKg0gOH7vUJElBPU65fJ9QGg9aOtNmTCs0=>