avr-libc-dev
[Top][All Lists]
Advanced

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

Re: [avr-libc-dev] [bug #19050] gcrt1.S should call main rather thanjump


From: Marek Michalkiewicz
Subject: Re: [avr-libc-dev] [bug #19050] gcrt1.S should call main rather thanjumping to it
Date: Tue, 13 Feb 2007 22:21:29 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

Hello,

On Tue, Feb 13, 2007 at 10:35:41AM -0700, Eric Weddington wrote:

> > 1. Loss of two bytes of RAM for storing 'main' return address 
> > in stack.

True, but probably no big deal anymore - today, most interesting
devices have more RAM than the ones at the time when the original
decision was made.  If main() never returns, and you are really
out of RAM, the two bytes could still be used to store something.

> > 3. If in 'main' function 'call-saved' registers (r2..r17) 
> > will be used, then
> > they will be saved in a stack. 

This can be worked around by making sure main() never returns, and
adding the "noreturn" attribute - then no registers should be saved.

Some time ago I suggested to implement a new attribute, meaning "this
function doesn't need to save any registers".  The h8300 target calls
it "OS_Task", and you can see it as "__C_task" in IAR C code examples
in some of the Atmel's app notes.  The difference from "noreturn" is
that the funcion can return - return value from main() will be passed
to exit() as usual, and gcrt1.S doesn't care about saving registers.

> Can someone remember what was the reasoning behind making main() a normal
> function? Is the reason still valid?

Keeping things simpler and more maintainable - the logic was already
quite complicated, and it affects AVR-GDB which (last time I looked
into it - not sure about the current status) did some scanning of
function prologues, and had to handle main() specially, too.

For similar reasons, I'd suggest to consider dropping -mcall-prologues
which saved a little code size at the cost of speed, and made a lot of
sense a few years ago, when flash sizes were much smaller than today.
And, it probably wouldn't work with the new 3-byte PC devices anyway.
(The option probably should still be accepted as a no-op, to avoid
breaking existing Makefiles - it was only a hint, and the different
prologues were not guaranteed, only used when they saved code size).

Hope this helps,
Marek




reply via email to

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