avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Marek Michalkiewicz
Subject: [avr-gcc-list] Re: avr-gcc code generation and initialization of the return stack
Date: Wed, 5 May 2004 19:52:50 +0200
User-agent: Mutt/1.5.5.1+cvs20040105i

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:

 - 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...)

 - 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...)

 - 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)

Regards,
Marek



reply via email to

[Prev in Thread] Current Thread [Next in Thread]