[Top][All Lists]
[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
- [avr-gcc-list] avr-gcc code generation and initialization of the return stack, Torleif Sandnes, 2004/05/05
- [avr-gcc-list] Re: avr-gcc code generation and initialization of the return stack, Theodore A. Roth, 2004/05/05
- [avr-gcc-list] Re: avr-gcc code generation and initialization of the return stack,
Marek Michalkiewicz <=
- Re: [avr-gcc-list] avr-gcc code generation and initialization of the return stack, Julius Luukko, 2004/05/06
- Re: [avr-gcc-list] avr-gcc code generation and initialization of the return stack, Torleif Sandnes, 2004/05/07
- RE: [avr-gcc-list] avr-gcc code generation and initialization of the return stack, Larry Barello, 2004/05/07
- Re: [avr-gcc-list] avr-gcc code generation and initialization of the return stack, Brian Dean, 2004/05/08
- Re: [avr-gcc-list] avr-gcc code generation and initialization of the return stack, Jeff Barlow, 2004/05/08
- Re: [avr-gcc-list] avr-gcc code generation and initialization of the return stack, Julius Luukko, 2004/05/10
- Re: [avr-gcc-list] avr-gcc code generation and initialization of the return stack, Torleif Sandnes, 2004/05/13
- Re: [avr-gcc-list] avr-gcc code generation and initialization of the return stack, Theodore A. Roth, 2004/05/13
- Re: [avr-gcc-list] avr-gcc code generation and initialization of the return stack, Torleif Sandnes, 2004/05/21