5 ms·

> With ARM64, there are 32 integer registers, with a dedicated zero register, link register, and frame pointer register. One further register is reserved for th

by w-m 13y ago

> With ARM64, there are 32 integer registers, with a dedicated zero register, link register, and frame pointer register. One further register is reserved for the platform, leaving 28 general purpose integer registers. but http://www.arm.com/files/downloads/ARMv8_Architecture.pdf http://www.arm.com/files/downloads/ARMv8_Architecture.pdf says: 31 general purpose registers accessible at all times * Improved performance and energy * General purpose registers are 64-bits wide * No banking of general purpose registers * Stack pointer is not a general purpose register * PC is not a general purpose register * Additional dedicated zero register available for most instructions Which one is it? By the way, the ARMv8 resources are quite interesting overall and a bit more in-depth than the article. http://www.arm.com/products/processors/armv8-architecture.php?tab=ARMv8+Resources http://www.arm.com/products/processors/armv8-architecture.ph...

mikeash 13y ago
I'm not seeing the conflict between what I wrote and your quote from the architecture docs. Is it just confusion because the dedicated link register, frame pointer, and platform-reserved register are part of the ABI rather than the ISA?
- Scaevolus 13y ago
  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.
  - mikeash 13y ago
    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.
    - saurik 13y ago
      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.
      - brigade 13y ago
        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.
        saurik 13y ago
        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 :(.
      - stephencanon 13y ago
        “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.
- brigade 13y ago
  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.
stephencanon 13y ago
There are 31 GPRs. The zero register shares and encoding with SP, and is it’s own separate thing. From the 31 GPRs, x30 is the link register and x29 is the frame pointer. x30 can be used for other purposes within a routine, but x29 must always hold a valid frame record in the iOS ABI. Additionally, iOS reserves x18 (“The platform register”) for all use. So there are really 28 GPRs, or 29 if you include x30/lr, which is something of a hybrid.

by w-m 13y ago

mikeash 13y ago

I'm not seeing the conflict between what I wrote and your quote from the architecture docs. Is it just confusion because the dedicated link register, frame pointer, and platform-reserved register are part of the ABI rather than the ISA?

Scaevolus 13y ago
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.
- mikeash 13y ago
  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.
  - saurik 13y ago
    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.
    - brigade 13y ago
      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.
      - saurik 13y ago
        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 :(.
    - stephencanon 13y ago
      “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.
brigade 13y ago
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.

stephencanon 13y ago

There are 31 GPRs. The zero register shares and encoding with SP, and is it’s own separate thing. From the 31 GPRs, x30 is the link register and x29 is the frame pointer. x30 can be used for other purposes within a routine, but x29 must always hold a valid frame record in the iOS ABI. Additionally, iOS reserves x18 (“The platform register”) for all use. So there are really 28 GPRs, or 29 if you include x30/lr, which is something of a hybrid.