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