From: anton@mips.complang.tuwien.ac.at   
      
   scott@slp53.sl.home (Scott Lurndal) writes:   
   >anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:   
   >>aph@littlepinkcloud.invalid writes:   
   >>>I thought the AArch64 ILP32 design was pretty neat, but no one seems   
   >>>to have been interested. I guess there wasn't an advantage worth the   
   >>>effort.   
   >>   
   >>Alpha: On Digital OSF/1 the advantage was to be able to run programs   
   >>that work on ILP32, but not I32LP64.   
   >   
   >I understand what you're saying here, but disagree.   A program that   
   >works on ILP32 but not I32LP64 is fundamentally broken, IMHO.   
      
   In 1992 most C programs worked on ILP32, but not on I32LP64.  That's   
   because Digital OSF/1 was the first I32LP64 platform, and it only   
   appeared in 1992.  ILP32 support was a way to increase the amount of   
   available software.   
      
   >>x32: I expect that maintained Unix programs ran on I32LP64 in 2012,   
   >>and unmaintained ones did not get an x32 port anyway.  And if there   
   >>are cases where my expectations do not hold, there still is i386.  The   
   >>only advantage of x32 was a speed advantage on select programs.   
   >   
   >I suspect that performance advantage was minimal, the primary advantage would   
   >have been that existing applications didn't need to be rebuilt   
   >and requalified.   
      
   You certainly have to rebuild for x32.  It's a new ABI.   
      
   >>Aarch64-ILP32: My guess is that the situation is very similar to the   
   >>x32 situation.   
   >   
   >In the early days of AArch64 (2013), we actually built a toolchain to support   
   >Aarch64-ILP32.  Not a single customer exhibited _any_ interest in that   
   >and the project was dropped.   
   >   
   >> Admittedly, there are CPUs without ARM A32/T32   
   >   
   >Very few AArch64 designs included AArch32 support   
      
   If by Aarch32 you mean what ARM now calls the A32 and T32 instruction   
   sets (their constant renamings are confusing, but the A64/A32/T32   
   naming makes more sense than earlier ones), every ARMv8 core I use   
   (A53, A55, A72, A73, A76) includes A32 and T32 support.   
      
      
   > even the Cortex   
   >chips supported it only at exception level zero (user mode)   
      
   When you run user-mode software, that's what's important.  Only kernel   
   developers care about which instruction set kernel mode supports.   
      
   >The markets for AArch64 (servers, high-end appliances) didn't have   
   >a huge existing reservoir of 32-bit ARM applications, so there was   
   >no demand to support them.   
      
   Actually there is a huge market for CPUs with ARM A32/T32 ISA   
   (earlier) and ARM A64 ISA (now): smartphones and tablets.  Apparently   
   this market has mechanisms that remove software after relatively few   
   years and the customers accept it.  So the appearance of cores without   
   A32/T32 support indicates that the software compiled to A32/T32 has   
   been mostly eliminated.  Smartphone SoCs typically still contain some   
   cores that support A32/T32 (at least last time I read about them), but   
   others don't.  It's interesting to see which cores support A32/T32 and   
   which don't.   
      
   - anton   
   --   
   'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'   
     Mitch Alsup,    
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)