Re: [avr-gcc-list] Frame Layout, Stack Layout

[Georg-Johann Lay]

Josef Eisl schrieb:

> Hello,
>
> I recently tried to find out how the avr-gcc frame layout (stack layout)
> looks like. I couldn't find any official documentation about this or is
> there an *avr-gcc internals* manual I have not found yet?
> I've created a figure [1] showing the stack after a CALL instruction and
>  how I think it works. I have assumed that avr-gcc was called with -O0.
> I understand that the optimizer removes instructions if they are not 
needed.
> There are a few things I am not sure about:
>
> - In which order is the return address saved on the stack? Unfortunately
> there is no hint about that in the description of the CALL instruction.
> I assumed that the high byte is pushed before the low byte, correct?
> Is it the same on devices with 22bit PC?


This question is treated in the AVR hardware manual.
Some insns in machine description [1] like insn "indirect_jump" use RET 
to perform an ijump and reveal the sequence that bytes must go onto the 
stack: LSB pushed first. AFAIR RETI addresses are encoded differently.

> - What is the right terminology? Frame Layout, Stack Layout, Activation
> Record?


Frame resp. stack layout.

> In my understanding the epilogue is used to save call-saved registers
> (and the frame pointer Y) as well as reserving memory for function
> arguments and local variables (that is the actual frame, right?) on the
> stack. Storing the content of the argument registers on the stack is not
> really a part of the prologue.


No. The prologue saves call-saved regs that are used by the function. 
Call-saved regs are the regs that are not call-used, i.e. a call does 
not change their values resp. original values are restored by epilogue, 
so the caller can rely on these values. For a definition of call-used 
regs take a look at CALL_USED_REGISTERS in [2].

Prologue sets up the frame pointer if needed. Some regs like __zero_reg 
(R1) are special: the avr backend assumes that this reg always contains 
the value 0. This GPR is not allocated by the compiler engine; it is 
used implicitely by some insns. "Implicitely" means that this reg just 
exists in assembler output templates an must be restored by hand every 
time it is clobbered. Insn "*mulqi3_enh" in [1] in an example for that 
technique. As insns may assume R1 to be 0, ISR prologue must set it to 0 
(and, of course, restore it's value in ISR epilogue). R1 belongs to 
FIXED_REGISTERS in [2]. Also note that behaviour of GPRs can be changed 
by means of options -ffixed-<n> et al. Prologue allocates space on the 
stack for local variables that live in the frame by adjusting the stack 
pointer.

The epilogue undoes all this: Free frame by adding some value to SP, 
restoring regs and returning with the appropriate return instruction RET 
or RETI provided the function is not naked.

Function args that are passed via stack like args of vararg functions 
are pushed by the caller, and the calles pops there args. This is 
controlled by RETURN_POPS_ARGS in [2]. Which function args is passed 
where is controlled by various macros/hooks like FUNCTION_ARG in [2] and 
avr_return_in_memory in [3].

Georg-Johann

[1]
http://gcc.gnu.org/viewcvs/trunk/gcc/config/avr/avr.md?revision=142856&view=markup

[2]
http://gcc.gnu.org/viewcvs/trunk/gcc/config/avr/avr.h?revision=144870&view=markup

[3]
http://gcc.gnu.org/viewcvs/trunk/gcc/config/avr/avr.c?revision=144870&view=markup