To condense and summarize:
Problem:
optiboot, a very small bootloader, grows signficantly in binary size when going
from gcc 4.5.2 to gcc 4.5.3. This turns out to be because it misses code
factoring optimizations in optiboot's main() function, which is declared with
attribute naked to save
On Jan 27, 2012, at 9:36 AM, Georg-Johann Lay wrote:
OS_main/OS_task won't have the problem, but such functions cannot be used in
.initN, of course. Except in the case where the code is in .init9 with custom
startup code.
Which is exactly what optiboot is doing.
Perfect. Problem explained,
On Jan 26, 2012, at 2:10 PM, Georg-Johann Lay wrote:
I tested the code with avr-gcc 4.5 and command line options -Os -mmcu=atmega8
With the attributes, the object size is 54 bytes.
Without the attributes the object size is 64 bytes.
4.5.3 ? Whatever this issue is, it apparently snuck in
To condense and summarize:
Problem:
optiboot, a very small bootloader, grows signficantly in binary size when going
from gcc 4.5.2 to gcc 4.5.3. This turns out to be because it misses code
factoring optimizations in optiboot's main() function, which is declared with
attribute naked to save
On Jan 27, 2012, at 12:38 PM, Joerg Wunsch wrote:
please subscribe to the list. You might miss replies otherwise.
I am subscribed (at gmail); I've just be replying with the wrong from address
:-(
BillW
___
AVR-GCC-list mailing list
A week or so ago I mentioned that avr-gcc 4.5.3 caused the optiboot bootloader
(used by Arduino and etc) to grow 22 bytes (from 500 bytes to 522 bytes,
pushing it over the size that it needs to be.)
This took a while to track down, because it's weird. Apparently gcc is
optimizing code
I'm told that I should post questions here rather than on avr-freaks.
Here's one...
(some additional discussion at http://www.avrfreaks.net/index.php?name=PNphpBB2file=viewtopict=9
) 4.3.4 behaves the same, and
there are NO right shifts of SIGNED variables involved...
Is there something