There is no dedicated frame pointer-- that would be part of the ABI. The stack pointer and zero register are both encoded as register 31, and the meaning depends on context.

My statement encompasses both the ISA and the ABI, which I hope was implied by my previous comment.... From the perspective of a userland software writer, there's not much point in trying to distinguish between the two.

Is the frame pointer register really "dedicated" by the compiler? (I haven't had the time to upgrade everything I need to upgrade yet to install the new Xcode and check this directly.) With 32-bit ARM, there is a register denoted "fp", but with iOS 2.0 Apple started compiling without a dedicated frame pointer (instead using that register temporarily for some kind of thread-local storage variable, before moving that elsewhere and freeing up the register entirely). I was under the impression that dedicated frame pointers are only used when you have less-than-awesome compilers that are unable to keep track of the moving stack pointer target as it performs optimizations.

It's "required" by Apple's ABI that the frame pointer always point to a valid stack frame; just the same as on armv7. It's for debugging and ensuring backtraces are always valid. Not modifying the current frame pointer complies with this, which is what -fomit-leaf-frame-pointer does. But it's an ABI violation to use it as a general-purpose register.

It sounds like you're partially confusing this with r9, which is a completely different story - r9 was globally reserved by the system until iOS 3.0, then allowed. This equivalent in arm64 is x18, which again is globally reserved by the system.

Yeah, I got the backstory mixed up with r9, I think because it coincided with fp being largely renamed to r11 due to iOS using r7 as the frame pointer instead (which I now remember the patch I had to merge for). Sorry :(.

“fp” is an alias for r11; despite its name, it was never used as a frame pointer in iOS (the iOS tools set up a frame pointer in r7 by default, as many of the original thumb instructions cannot easily access r8-r12).

More generally, a frame pointer of some sort is necessary to deal with variable-sized stack allocations, and often useful for performance analysis and debugging tools, so many compilers set them up by default even when they aren’t strictly necessary.

The jumbling around of the register purposes (r11 moving to r7 despite r11 being "fp") combined with the early change to the meaning of r9 is what bit me; sorry about the confusion :(.

The link register isn't reserved in either AAPCS64 or Apple's ABI so it's effectively 29 GPRs. Yes it has a specially-defined purpose at function bounds, but it's perfectly fine to use it for whatever within a function, just like it was in armv7.