So i'm curious as to why the ABI follows the ARM ABI so closely. It seems only to bring baggage that adds complexity, and imo hampers one of the features of the cpu - "zero-page" registers. I presume there is no need for any backward compatability with earlier revisions which have fewer registers for example.
Just off the top of my head, wouldn't something like the following make more sense?
r0-r7 arguments/scratch (caller save, or perhaps all scratch)
r8-r31 caller save
r32-r63 callee save
(the actual split point could be based on something more emperical than the beauty of symmetry)
with:
r63 link pointer (only hardware specific register, specifically at the end for that reason)
r62 stack pointer
r61 ... frame pointer/segment pointer, constants, whatever, etc.
Or perhaps even r63=pc for pc-relative addressing (if arm can justify it with only 16 registers, it's probably useful), r62=sp, etc. (obviously this isn't going to happen due to hardware requiring changes).
For example, having r4-r7 callee save puts a big break on being able to write tiny call-tree-leaf routines that use as many page-0 registers as possible for compactness. And are they all that useful in the caller? Obviously this is a trade-off, so it might not make much difference either way in practice but aesthetically and by 'gut-feeling', it just doesn't look optimal.
Apart from the use of r12 as the link register, the rest is purely a toolchain/software issue.
The ABI - why the ARM legacy?
by notzed » Tue Aug 13, 2013 12:36 am
- notzed
- Posts: 331
- Joined: Mon Dec 17, 2012 12:28 am
- Location: Australia
