2 ms·
> I've always thought it odd that a CPU manufacturer would specify an ABI Why? It we all agree to use R13 as SP, the core designers can spend a few [hundred]
by dmitrygr 4y ago
> I've always thought it odd that a CPU manufacturer would specify an ABI
Why?
It we all agree to use R13 as SP, the core designers can spend a few [hundred] extra transistors optimizing accesses to [R13 + offset]. Perhaps adding such logic for ALL registers is too costly?
If we all agree that R14 is the return address, the prefetcher might want to prefetch instructions there, so return is faster. The core probably cannot afford the transistors to do that for ALL regs
ARM (and most other chips) will work if you do not follow those conventions, but they might not perform as well.
Eg: aarch64 instruction "ret" takes a register param and you can use any reg you wish, but at least on some microarchitectures implementing the aarch64 ISA, it will be faster if the param is the X30 register, since that is the agreed-upon return address reg, and some silicon was spent optimizing this case
- userbinator 4y agoWhy even call them R13/R14 then? Intel specifically assigned a stack and frame pointer on x86, and there are even special instructions to work with the former, and addressing modes for the latter (BP/EBP/RBP uses the stack segment). Interrupts and exceptions will also implicitly use the stack pointer. It's odd because ARM seems to be trying to present itself as being a RISC, when the architecture appears to be slowly becoming something else. The allowable addressing modes with each instruction in A64 clearly shows this.
- dmitrygr 4y agowell, for example in ARMv7 and below, it was common to use LR(r14) ALSO for math during the function body if there was register pressure. So it does assist a little. And the instruction set encoding is much simpler if every reg is just ... a reg. No need for push and pop if you can store with predecrement and load with postincrement. And those stores/loads are useful ALSO for non-stack ops, if your compiler is clever. _At the time_ the design made good sense. But in modern very-OoO cpus, you are right, and having SP and PC be GPRs is of little use and of non-negilible cost design-wise, which is why in aarch64, SP and PC are special and not GPRs like they were in ARMv7 and below. LR still is a GPR though
- pm215 4y agoIt's history, mostly. The very first Arm design didn't do anything special with r13 and r14, so using them as sp and lr was purely convention (you could have an upward growing stack in r0 if you wanted). The years roll by, and it turns out that in fact everybody follows the conventions, so it makes sense with cleverer hardware to optimise for r13-is-sp, and it's a reasonable tradeoff with Thumb to enforce r13-is-sp in return for being able to make the instructions smaller and save code size. The technical constraints and situation of 1983 are not the same as those of 2003 or 2023.
- fanf2 4y agoThere was always one instruction that made r14 special: BL, branch with link. Both r13 and r14 are special for exception handling and SWI instructions, because they have extra versions in the register banks, specifically for the supervisor mode stack pointer and exception return address.
- pm215 4y agoOh yes, good points.