From: smcv@debian.org 
  
 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 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)