On Sat, Aug 16 2025, Simon McVittie wrote: > On Sat, 16 Aug 2025 at 07:28:24 -0500, John Goerzen wrote: >>Without getting into a debate over whether i386 should or should not be >>dropped, as someone that runs other 32-bit archs, I wonder why armhf and >>armel weren't similarly targeted? > > Each of these 32-bit ports has different characteristics and different > tradeoffs.
Thank you, Simon. Your message (and your other one about compilers being unable to compile software within 4GB of VRAM) was very helpful and clarified a lot of points for me. John > > i386-without-SSE2 on real 32-bit CPUs (as opposed to i386 as a compatibility > architecture on newer CPUs) is a problematic porting target because it has > non-IEEE floating-point behaviour that frequently causes trouble: test suites > often expect to see the same exact values, simulations (e.g. networked games) > want to see deterministic results from running the same simulation on > different > CPUs, and the thing that finally prompted raising the baseline was that it > turned out that it even harms soundness (ability to generate correct machine > code) in LLVM/rustc. i386-with-SSE2 is a lot easier, because it has the same > IEEE floating point as every other release architecture, but there were only a > few CPU generations that have SSE2 but not 64-bit support (I think the > Pentium 4 > around 20 years ago was the most common example). > > armel is also on its way out, because it has a *different* characteristic that > makes it a problematic porting target: unlike every other release > architecture, > it doesn't have atomic operations in the baseline instruction set, and they > have > to be emulated. For example this is why mozjs/gjs had to be removed from armel > in trixie. I suspect we would have lost armel already if it wasn't for the > fact > that it's the newest/highest-functionality Debian port that will run > unmodified > on first-generation Raspberry Pi hardware, because ARMv6 is slightly too old > for > official Debian's armhf baseline; Raspberry Pi OS, a Debian derivative, works > around this by recompiling armhf with a lower baseline. > > armhf has had CPUs that can run it but not its successor manufactured more > recently than i386 or armel, has normal IEEE floating-point unlike i386, and > has > normal atomic operations unlike armel, so it is both less painful to support > and > more likely to be useful as a "bare metal" OS when compared with either i386 > or > armel. > > (I do think that armhf's useful lifetime is limited, too, though.) > > smcv
