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 _______________________________________________ AVR-libc-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
