abi-aa

Normally you'd save more than just PC as AAPCS (https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aap...) mandates stack to be aligned to 8 bytes for "public interface" functions. But this is is not a "public" function so it's fine to only save lr here. "bx lr" is only used on it's own when the function doesn't call another function (altering lr), and doesn't need to save any registers. If you see pop {lr}; bx lr then that's code that's being compiled to explicitly support Armv4 (e.g. Arm7TDMI) EDIT: https://gcc.godbolt.org/z/TadnqescT

Here is ARM's explanation in the AAPCS64 (ARM 64-bit Architecture Procedure Call Standard): > Software developers creating platform-independent code are advised to avoid using r18 if at all possible. Most compilers provide a mechanism to prevent specific registers from being used for general allocation; portable hand-coded assembler should avoid it entirely. It should not be assumed that treating the register as callee-saved will be sufficient to satisfy the requirements of the platform. Virtualization code must, of course, treat the register as they would any other resource provided to the virtual machine. From: https://github.com/ARM-software/abi-aa/blob/2bcab1e3b22d5517...

You can also pass structs of floating point or SIMD types by register. They have to be 2-4 elements and all of the same type. These are called HFA (Homogeneous Floating-point Aggregate) and HVA (Homogeneous Short-Vector Aggregate). Source: the Procedure Call Standard for the Arm 64-bit Architecture https://github.com/ARM-software/abi-aa/blob/2021Q1/aapcs64/a...

My guess is that it's some effort to maintain some kind of compatibility with ARM32. Back when I used to write ARM asm, it was the ARM 26/32 days, and it was rXX for all the register named in the APCS. It doesn't seem to be as confusing as the x86 situation anyway: none of the registers are _really_ special purpose on ARM. Here's a link to the details in the ARM64 APCS: https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aap...

For more context, look at the standard ARM ABI spec. Apple’s ABI diverges from the standard one in some places, IIRC, but in this case it’s complying with it: the spec says that X18 (which it calls r18) can be reserved by platforms for platform-specific use. The spec also shows how the registers are divided into several categories, which helps explain the choice of X18: https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aap...

Latest versions of the ABI specifications linked in the Machine Specific section ARM: https://github.com/ARM-software/abi-aa/releases x86-64: https://gitlab.com/x86-psABIs/x86-64-ABI (go to most recent CI job and download artifacts for a compiled PDF)

> Apple changed some things that impact PyPy, like the register uses and ffi calling conventions. I thought everyone who used 64-bit ARM used ARM's AAPCS64 (https://github.com/ARM-software/abi-aa/blob/master/aapcs64/a...), so the register usage and FFI calling convention should be the same as on Linux and Windows. What did Apple do differently that would affect the PyPy JIT?

> The ARM architecture floating point units (VFP, NEON) support RunFast mode, which includes flush-to-zero and default NaN. The latter means that payload of NaN operands is not propagated, all result NaNs have the default payload, so in R, even NA * 1 is NaN. Luckily, RunFast mode can be disabled, and when it is, the NaN payload propagation is friendlier to R NAs than with Intel SSE (NaN + NA is NA). We have therefore updated R to disable RunFast mode on ARM on startup, which resolved all the issues observed. Hmm. ELF object files for Arm can represent this with build attributes [1]: Tag_ABI_FP_denormal, (=20), uleb128 0 The user built this code knowing that denormal numbers might be flushed to (+) zero 1 The user permitted this code to depend on IEEE 754 denormal numbers 2 The user permitted this code to de