3 ms·
On the third part, talking about the stack pointer: > “So”, you ask, “why not just reserve a register for this global variable?". I find it interesting that t
by cesarb 4y ago
On the third part, talking about the stack pointer:
> “So”, you ask, “why not just reserve a register for this global variable?".
I find it interesting that the 64-bit ARM architecture did go that way. The 32-bit ARM architecture had the stack pointer (and the instruction pointer) in a normal general-purpose register; when developing the 64-bit ARM architecture, which fixed many of the warts of the 32-bit ARM architecture which made it harder to have a high-performance implementation, they moved both the stack pointer and the instruction pointer into dedicated registers. So even in hardware, it made sense to reserve a special register for the stack pointer.
- masklinn 4y ago> So even in hardware, it made sense to reserve a special register for the stack pointer. I think it was mostly a question of cleanup / clarity of the interface: on ARM32, using R13/SP as a GPR could lead to odd behaviours and was a bit of a portability concern, to say nothing of R15 (PC/IP, which was only a GPR in name IIRC as some instructions excluded it and it had divergent side-effects). Also unlike every other GPR, R13 (and R14) was banked on all privileged modes (R0-R7 were shared across mode, and R7-R12 were banked in FIQ). Moving SP and PC to dedicated non-GPR makes the instruction set easier to work with (and allowed register 31 to pull double duty as a virtual reference to SP and ZR depending on instruction, and thus ARM to finally have a zero register).