Aarch64 support added (opens in new tab)

> 1. For DSP / image processing, 64-bit SIMD allows you to operate on twice as many elements as 32-bit SIMD

I think this is very much wrong. You do get more SIMD registers, but both 32-bit and 64-bit ARM have 128 bits wide SIMD registers. Same number of elements per instruction.

> 2. For normal computing, you get 31 64-bit registers instead of 15 32-bit registers (essentially 4x register memory)

Almost right. 14 vs 31. On 32-bit ARM, R13 is stack pointer, and R15 is PC, program counter. 64-bit ARM doesn't have PC mapped to register file anymore.

> 3. 128-bit floating point

As far as I know, AArch64 does not have 128-bit floating point. Nor would it really be useful except in very rare circumstances.

I am pretty sure that all of the benchmarks showed 64-bit ARM losing to 32-bit, though, by a few percent. The issue is that most code is not able to take advantage of SIMD, and almost all code is not register limited by any stretch, particularly as people tend to write such small functions, and we don't have calling conventions that can try to build register windows (like, "this is an A function that uses this subset of registers while this one is a B function that uses this subset of registers, so if we call a B from an A we don't have to save anything") combined with the top of the stack often being a virtual construct in the CPU anyway (mapped to virtual registers). With the ability for 32-bit ARM to compile stuff to half the code size (due to the Thumb variants), which lets it use half the limited instruction cache space and load faster from disk, it just isn't a very interesting upgrade. Oh: and programs tend to use a lot more memory, as now all of their pointers are twice as big. Some of these downsides are mitigated by the ability to play tricks like tagged pointers (you can't actually use all 64 bits for an address: only 48 or 52 or something are actually wired to the address bus), but except for specialized stuff (where the SIMD and floating point benefits really matter), the only real benefit is "the address space is larger" (a truly useful thing, FWIW, making it much easier to work with large files). (Oh: and it is easier for me to reverse engineer your code due to more useful invariants in the calling conventions ;P. This part makes me really happy.)

I used the x32 ABI at a previous job, for an ARM-on-x86 emulation project. The x32 ABI outperformed both x86 and x86_64 for that purpose. It wasn't a huge margin, but it was enough to make us want to use it over x86_64.

I wish I still had the performance data for that, so this would be more than an anecdotal comment.

AArch64 was def designed for this too. You can use the w registers (the lower 32 bit halves of the GPRs) as load/store arguments, which pretty much only makes sense in an x32 like ABI.

32bit I mean. I’m fairly certain no one has made a 33bit arm variant yet :)

This. AArch64 is far more than a simple "ARM, but with 64-bit addresses" change, most obviously predicated instructions are gone (which is a big deal for OoOE) and exceptions are vastly simpler.

What do you mean? There is the /pae switch. Also isn’t each process limited to 4gb under 32bit pae