[avr-gcc-list] Re: avr-gcc code generation and initialization of the return stack

[Theodore A. Roth]

On Wed, 5 May 2004, Marek Michalkiewicz wrote:

> Hello,
>
> On Wed, May 05, 2004 at 04:13:47PM +0200, Torleif Sandnes wrote:
> >
> > >It seems like the main function does an re-initialization of the return
> > >stack (SPL/SPH). Actually, the new JTAGICE mkII expects the stack pointer
> > >not to be modified this way apart from in the system startup-code, or the
> > >single-stepping mechanisms wont work. The avr-gcc does set up the stack
> > >properly in the startup-code, so I dont clearly see why it's done over
> > >again
> > >in 'main'.
> >
> > Do any of you know why the stack is reinitialized this way?
>
> Mainly historical reasons - it has been that way since the beginning,
> the initialization in startup code has been added later, but main()
> still does this for backwards compatibility (new avr-gcc working with
> old avr-libc).
>
> > Can gcc's code egeneration be changed to not reinitialize the return stack?
>
> It would be a good idea to make main() a normal function (no special
> handling at all) - it has been discussed, just not done yet.  A few
> things to remember though:

Why not still treat main specially but just don't init the stack. We're
just doing a jump from the startup code, so it doesn't really need to a
regular function.

>
>  - a new function attribute telling GCC to not save any call-saved
>    registers should be implemented to avoid waste of both program
>    memory and stack space for the unnecessary push/pop operations
>    (startup code doesn't expect main() to save any registers)
>
>  - 2 bytes of stack will still be wasted for main() return address
>    (could sometimes be a problem on small chips with 128 bytes SRAM,
>    when you fight for the last byte...)

You don't waste that currently since we just jump to _exit(). Here's a
dump of a bare bones main():

int main (void)
{
  ca:   cf ef           ldi     r28, 0xFF       ; 255
  cc:   d0 e1           ldi     r29, 0x10       ; 16
  ce:   de bf           out     0x3e, r29       ; 62
  d0:   cd bf           out     0x3d, r28       ; 61
    return 0;
}
  d2:   80 e0           ldi     r24, 0x00       ; 0
  d4:   90 e0           ldi     r25, 0x00       ; 0
  d6:   0c 94 6d 00     jmp     0xda

000000da <_exit>:
  da:   ff cf           rjmp    .-2             ; 0xda

I've patched gcc to not produce the stack init in main (patch attached)
and then I get this:

int main (void)
{
    return 0;
}
  ca:   80 e0           ldi     r24, 0x00       ; 0
  cc:   90 e0           ldi     r25, 0x00       ; 0
  ce:   0c 94 69 00     jmp     0xd2

000000d2 <_exit>:
  d2:   ff cf           rjmp    .-2             ; 0xd2


>
>  - support issues (significant changes in avr-gcc and avr-libc at the
>    same time, making sure that everyone upgrades both, answering to
>    all resulting bug reports...)

That's not too bad since we are already talking about going to
per-device multilib for avr-libc. Although my patch for gcc doesn't
require any changes to avr-libc (I'm probably being naive about it
though).

>
>  - bug: stack initialization in startup code (which will remain after the
>    one in main() is removed) doesn't see the modified value of __stack
>    (if changed from the default = RAMEND), unless this has already been
>    fixed (the problem is that the use of __stack must be in a different
>    object file, not crt*.o where it is defined - possibly to libgcc.a?)
>
>  - good: removing SP initialization from main() means one less place
>    where we must fix the "devices with 8-bit stack pointer" problem :-)
>    (just found another such place: libgcc support for -mcall-prologues)

---
Ted Roth
PGP Key ID: 0x18F846E9
Jabber ID: address@hidden

gcc-avr-no-main-sp-init-2.diff
Description: Text document