We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Is there a reason why banked registers SP and LR can't be accessed as r13_<mode> or r14_<mode>, but
one has to use SP_<mode> or LR_<mode> instead? It makes macros and inline assembly difficult.
In document (ARMv7-A/R ARM Issue C) it says:
Software using an MRS (Banked register) or MSR (Banked register) instruction specifies one of these registers using a name shown in Figure B9-1, or an alternative name for SP or LR.
Software using an MRS (Banked register) or MSR (Banked register) instruction specifies one of these registers using a
name shown in Figure B9-1, or an alternative name for SP or LR.
But in both the figure and the text the names are the same: SP or LR. There is no alternative.
Maybe considering them as regular registers r13/14 is deprecated? Especially for SP, a lot of operations are deprecated in ARMv7. With LR is seem less critical, but there might be core internals like a return stack that don't work too well if it is used as general purpose r14?
Hello,
as you say, the assembler of GCC does not accept r13_<mode> or r14_<mode> but accept sp_<mode> or lr_<mode>.
I think that's absurd.
I agree with you,
Best regards,
Yasuhiko Koumoto.
It is weird, especially when the destination register can be r13, r14 or r15 as well as sp, lr or pc.
Hi turboscrew,
I have to admit I can't see what the issue is here. The ARM ARM is very specific and clear; Figure B9-1 dictates the possible arguments and which mode they come from. The table under your quote is defining groupings of these registers.
Note that you are essentially accessing a "named register" and putting the result in a general purpose register. The named registers are given mnemonics to suit their purpose. General purpose registers (even if they are SP, LR or PC) aren't named registers, and follow the same mnemonics as any other "destination register" in an instruction. This is actually really quite consistent.
Let us assume that you had some code like:
{code}
mrs r15, LR_svc
This makes no logical sense in many, many ways (using r15 instead of the PC mnemonic, copying another mode's LR to the PC, and essentially this is a branch which would need some EXTREMELY specific justification!). The mnemonics are essentially born of the way things are encoded.
The use of MRS/MSR (Banked Register) is very specific and in those specific use cases (exception handler setup/design), r13, r14 for each mode are intended to be used as stack pointer (for pushing registers) and link register (to hold return from exception address). Since they're very specific in use and function, macros would be very specific to those use cases and therefore there's probably not a good reason to "clean it up" to allow specifying particular register names. It would make for a very fluffy, bloated assembler with a lack of intent present in the code itself.
One would assume you want to do:
.macro copybankedreg reg, mode
mrs \reg, \reg_\mode
.endm
Is there any reason you need a macro for that?
Ta,
Matt
Yes there is a reason: I'm (still) trying to put together a standalone gdb-stub for RPi 2B (using soft breakpoints).
That "partial emulation" is needed for single stepping to figure out what the PC will be after executing an instruction.
I'm using C and inline assembly:
#define READ_REG_MODE(retvar, rg, mode) \ asm volatile (\ "mrs %[reg], r%c[rn]_" #mode "\n\t"\ :[reg] "=r" (retvar)\ :[rn]"I"(rg):\ )
#define READ_REG_MODE(retvar, rg, mode) \
asm volatile (\
"mrs %[reg], r%c[rn]_" #mode "\n\t"\
:[reg] "=r" (retvar)\
:[rn]"I"(rg):\
)
But that only works upto rg =< 12.
Had to add special code for SP and LR.
I just wondered what is the "alternative name for SP or LR".
I only found one possibility: LR_<mode> or SP_<mode>.