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.
Given the information you have provided, the compiler doesn't appear to have done anything illegal.s.
Yep, that's entirely sensible, and precisely what APCS lets you do. What is means by "only in between subroutine calls" is that as soon as you call a subroutine that subroutine is free to clobber r0-r3 and r12 (in accordance with the APCS).
So if the caller has stored any intermediate value in any of these clobberable registers, and it wants to use the value after the subroutine it either has to move the value in to r4-r11 or r13-14 or write it to the stack. So you cannot store intermediates "across subroutine calls" in the parameter passing or IP register ... otherwise you risk loosing the value.
Most modern compilers operate on a "move the stack pointer once per function" (ignoring stack push and pop wrapping subroutines), so will essentially reserve enough space on the stack to ensure that any intermediate space on the stack for storing scratch values is allocated on function entry and freed on function exit. In your case, as you pointed out in your first post, the compiler stores r2 back to the stack as a scratch variable; the initial "push" of r2 and r3 is just to reserve the space without needing a second instruction to increment SP.
The APCS also requires the stack to be 8 byte aligned on function call, so r3 is probably pushed just to ensure an even number of registers are pushed, although your function may use that space for scratch stack too...
This would seem to me at least reasonably sensible - i.e. no need to shuffle registers around if you're going to pass them right into a subroutine anyway. That, however, is clearly not the sense in which ARM actually uses these registers and I wish they would use more explicit language to describe exactly what is, and is not, allowed.
But if that's the case, why is the compiler stacking registers r2 and r3 in the first place? If these can be corrupted arbitrarily then it is a complete waste of time to stack them under essentially any situation.
Now I think you've clarified that it will NOT necessarily stack r3?
What's the theory behind doing that?
If, on the other hand, the idea of this is to treat the stack as some sort of extension of the register space, so that each extended word corresponds to a fixed "stack" position, it isn't a stack anymore - at which point why not just read and write from heap or any other free memory area?
Why would armcc do something so glaringly illegal?
In this case, what it's doing is placing an item on the stack in a position which will certainly corrupt the stack.Looking through the disassembly for the offending function, I can see that the first line (as expected) is PUSH {r2-r4,r6-r11,lr}But then later in the code, and with NO other stack operations in the meanwhile (nor any function calls or other branches out of the current function context) it hasADD r2,r0,r4,LSL #2LDR r0,|L1.3728|STR r2,[sp,#4]As I understand it, since the stack is full-descending, this means that the value of r2 currently in the stack will get corrupted, because the STR instruction will store the (changed) current r2 value in the position occupied by the original r2. The function in concern is declared void receivePacket(void)so it's not expecting to return values in r2 or take arguments in r2.Why would armcc do something so glaringly illegal? Is there something I can do to fix this?