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, <
c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)