Weddington, Eric wrote:
The main function should still be set up as a OS_main function, i.e.
it doesn't return anywhere.
From how I understand OS_main and from the sources, there is nothing that adds
noreturn semantics to OS_main. It's the same as OS_task except that OS_main
assumes that IRQs
-Original Message-
From: Georg-Johann Lay [mailto:a...@gjlay.de]
Sent: Monday, January 30, 2012 4:34 AM
To: Weddington, Eric
Cc: Bill Westfield; avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] Weird optimization issue with avr-gcc
4.5.3, re
naked.
Weddington, Eric wrote
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
William,
Are there any reasons you haven't tried avr-gcc 4.6.2? It was said
previously that there are many avr bug fixes in the gcc 4.6 version, and
it's also the current gcc version with better optimisations than 4.3 (I
haven't put much/any effort into 4.5). The gcc version used by Arduino
is
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,
William Chops Westfield schrieb:
To condense and summarize:
Resolution: optiboot will use the OS_main attribute instead of
naked. It doesn't disable the optimization, the resulting code is
small enough, and the attribute is more exactly appropriate and
correct as well. It was probably an
1. If you complain of missed optimisations, you should post the command line
switches you have used, the -Ox switch at least.
2. Don't use the naked attribute if you don't understand its implications -
here, main uses stack frame which has not been created due to naked; this might
work only by
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.
With 4.5.3 ? Whatever this issue is, it apparently snuck
Johann: I could reproduce it with one of the 4.7 packages (an older one) you
provided.
---
Moreover, in 4.7 it also stores the variable to stack frame even without naked,
so that could be called a missed optimisation/regression.
---
As far as code ineffiency goes, while there is always a
William Chops Westfield wrote:
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
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
On 27.01.2012 01:40, William Chops Westfield wrote:
(reports are that 4.5.2 produced smaller code than 4.3.2)
Hmmm...
defiant joe [~/tmp]: avr-gcc -dumpversion
4.3.4
defiant joe [~/tmp]: avr-gcc -ggdb -Os -c -mmcu=atmega328p
-mshort-calls foo.c
defiant joe [~/tmp]: avr-size foo.o
text
William Chops Westfield wrote:
Hi, don't forget to use reply to all or at least to CC the lists themselves.
On Jan 27, 2012, at 3:23 AM, Georg-Johann Lay wrote:
4.5.3 ? Whatever this issue is, it apparently snuck in between 4.5.2
and 4.5.3.
The only remarkable difference between 4.5.2 and
William \Chops\ Westfield wes...@mac.com wrote:
int main(void) __attribute__ ((naked)) __attribute__ ((section (.init9)));
Instead of trying to force main into being naked, I think it would be
better to use the OS_main attribute.
Btw., please subscribe to the list. You might miss replies
Jan Waclawek schrieb:
Moreover, in 4.7 it also stores the variable to stack frame even
without naked, so that could be called a missed
optimisation/regression.
Thanks for pointing this out. I was lost in all that optimization
conversation and thought it was an optimization issue from the
optimization issue with avr-gcc
4.5.3,re
naked.
Though I'm not sure I understand why the original complaint was
considered a
bug. They appear to have been counting on a naked C function to fall
in at the
top and fall out at the bottom, which seems like even more of an abuse
of
naked than I
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
To: avr-gcc-list@nongnu.org
Subject: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3,re
naked.
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
William Chops Westfield schrieb:
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.)
Any thoughts as to what might be going on here?
Thanks
How does it compile if you change the C code to this?:
[manually factoring out the common code]
Yes, that will fix this particularly obvious instance, but it looks
like gcc is failing to factor out common code like this in less
obvious places as well...
(Hmm. It behaves differently
22 matches
Mail list logo