| Author |
Message |
|
|
 Posted: Dec 12, 2010 - 09:49 PM |
|
Joined: Apr 19, 2009
Posts: 200
|
|
I recently upgraded to AVR Studio 4.18 SP3, and the newest version of WinAVR 20100110. (I was using AVR Studio 4.18 SP1 and a ver of WinAVR 20090313)
I noticed right away that the optimizing has been significantly enhanced with option -Os, I recompiled some of my C lang programs and saw around 8% reduction in code size on average from WinAVR 20090313 to WinAVR 20100110. This is when the target MCU code space was nearly completely full.
Does anyone know what has been changed in the newest version of the GCC compiler, I am just interested to see what optimization enhancements were made. I am unable to find any change logs or version history.
Thanks guys! |
|
|
| |
|
|
|
|
|
|
Posted: Dec 13, 2010 - 12:59 AM |
|
Joined: Jun 21, 2005
Posts: 881
Location: Chicago area, USA
|
|
|
12oclocker wrote:
Does anyone know what has been changed in the newest version of the GCC compiler
I don't.
I normally use 20080610. But I also have 20100110 installed, and from time to time I use it just to see if there are any significant code size changes. I have not seen any. On the other hand, I normally compile with not just with -Os, but with several other options. For example, in one of a projects I have --param inline-call-cost=1. If I remove that option, then I see ~5% difference between the two versions. Maybe (I'm just speculating here) the significant improvement that you are seeing is not really due to changes in optimization per se, but rather in the default settings that are behind the -Os option.
Eugene |
|
|
| |
|
|
|
|
|
|
Posted: Dec 13, 2010 - 01:10 AM |
|
Joined: Apr 19, 2009
Posts: 200
|
|
|
Quote:
Maybe (I'm just speculating here) the significant improvement that you are seeing is not really due to changes in optimization per se, but rather in the default settings that are behind the -Os option.
That's probably whats going on. Such a large compilation difference was making me wonder how they did that, your speculation is likey what's actually going on. thanks  |
|
|
| |
|
|
|
|
|
|
Posted: Dec 13, 2010 - 09:22 AM |
|
Joined: Jul 18, 2005
Posts: 62219
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
The version you are talking about is well known for being much more aggressive with inlining. If anything (as it's a speed optimisation) this usually makes for faster code but that is LARGER not smaller as you've observed.
By the way make sure to use -Wl,-relax as it's a great optimisation and almost inevitably saves some space.
Cliff |
_________________
|
| |
|
|
|
|
|
|
Posted: Jul 15, 2012 - 02:53 PM |
|
Joined: Oct 08, 2008
Posts: 87
Location: N. California
|
|
This is an older post I know, but I recently updated my studio 4.18 to AVR-20100110. I went from 99.3% flash used to 95.2%, very similar to 12oclocker's outcome.
I have been optimizing whenever I needed to add more code to prevent hitting 100%, so when I got more than 4% just by switching to the new AVRGCC it was shocking and concerning. I have way to much code to test from scratch and I'm feeling uncomfortable trusting the outcome.
All that I do is change the two entries under
Project options --> customs options - External Tools
avr-gcc = \WinAVR-20090313\bin\avr-gcc.exe
make = \WinAVR-20090313\utils\bin\make.exe
to
avr-gcc = \WinAVR-20100110\bin\avr-gcc.exe
make = \WinAVR-20100110\utils\bin\make.exe
Optimization is set to -Os
Has anyone tracked down where this savings is coming from? |
|
|
| |
|
|
|
|
|
|
Posted: Jul 15, 2012 - 03:54 PM |
|
Joined: Jul 18, 2005
Posts: 62219
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
There's been myriad threads about the relative performance of the various issues of GCC - search them out. But the question really is: why not just switch back to the 2009 version if that was working just fine for you?
(if you really want to know what's changed diff the .lss). |
_________________
|
| |
|
|
|
|
|
|
Posted: Jul 15, 2012 - 04:12 PM |
|
Joined: Oct 08, 2008
Posts: 87
Location: N. California
|
|
|
clawson wrote:
There's been myriad threads about the relative performance of the various issues of GCC - search them out. But the question really is: why not just switch back to the 2009 version if that was working just fine for you?
(if you really want to know what's changed diff the .lss).
That's an easy question, getting a fraction of a percent requires rewriting and optimizing code. I don't like to touch code that is working. A "free" 4+% code space is hard to ignore.
For now, I have reverted back to the 2009 version and I'm hoping to find an answer.
I did search, hence the resurrection of this old post. It was by far the closest matching existing post. But this post was never fully addressed. I'll try a few more searches |
|
|
| |
|
|
|
|
|
|
Posted: Jul 15, 2012 - 04:26 PM |
|
Joined: Mar 27, 2002
Posts: 18520
Location: Lund, Sweden
|
|
With luck you could dig into the WinAVR revision control system, and analyze what was the baseline for the build of the two WinAVR versions...
I'm not sure if all ( as in ALL!) that went into the build was properly committed to the repository, and then properly tagged, so my suggestion might not be technically possible. And even if it is, I suspect it will be a daunting task.
I'd hope for EW, the man "at the hub of that build wheel", to pass by here and perhaps give some clues. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 15, 2012 - 04:59 PM |
|
Joined: Jul 18, 2005
Posts: 62219
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
| I'd also be interested to hear what SprinterSB and Wek have to say. I'm pretty sure it was Jan who's previously reported that the best ever code density he's had from avr-gcc dates back to something like a 2006 version (then again maybe it wasn't Jan?). |
_________________
|
| |
|
|
|
|
|
|
Posted: Jul 15, 2012 - 05:02 PM |
|
Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux
|
|
So you switch from WinAVR-20100110 back to WinAVR-20090313 just in order not to "lose" these 4% of code?
From what I can tell WinAVR-20100110 works very will, I never hit a bug with that version.
Smaller code size is not an indication of a miscompiling toolchain. For example, whan switching from 3.4.6 to 4.x I typically observed a code size increase of ~10%, yet 3.4.6 works 100% stable.
It might be the case that some of your code is not well written; missing volatile is a common example where a better optimizing compiler may hurt. But that's not a issue of the compiler, such things are issues in your code, of course.
GCC gets smarter and smarter over time. Sometimes this is good for AVR, sometimes not. There overall tendency is towards better code.
If you are interested in the changes made to GCC — which will certainly be the case when you (intend to) update your tools — is reading the release notes.
Because the aforementined compiler versions are 4.3.2 (20090313) esp. 4.3.3 (20100110) it's not that ease, because it's the same minor version.
If you are interested in the changes, you can read the ChangeLog or the problems fixed in 4.3.3.
From an other perspective it's easier: As 4.3.2 and 4.3.2 are from the same release series 4.3 but 4.3.3 comes with way more bug fixes than 4.3.2: What would be a reasonable choice?
Besides that, WinAVR comes with additional patches. So you may also want to have a look in the ./source directory where WinAVR distributons ship their patches. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 15, 2012 - 06:38 PM |
|
Joined: Oct 08, 2008
Posts: 87
Location: N. California
|
|
|
SprinterSB wrote:
So you switch from WinAVR-20100110 back to WinAVR-20090313 just in order not to "lose" these 4% of code?
The code output for 20090313 has a significant test and use history and represents known good code. So even though the new version resulted in 4+% code reduction, the resulting code falls in the risky untested category. |
|
|
| |
|
|
|
|
|
|
Posted: Aug 17, 2012 - 05:48 PM |
|
Joined: Oct 08, 2008
Posts: 87
Location: N. California
|
|
Finally spent a little time trying to determine why the new 20100110 was 4% more optimized than the WinAVR-20090313. I compiled with each and then used winmerge to compare the two resulting .lss files.
One thing that jumps out is that each time I see a EEPROM read or write in WinAVR-20090313, it re-instantiated the library code. So it seems that the code is repeated over and over rather than a single instantiation and a call.
I have looked for a bug fix list for WinAVR-20100110 but can't seem to find one to confirm if this was a known and corrected issue.
The title of the code with multiple instantiations is:
/** \ingroup avr_eeprom
Read one byte from EEPROM address \a __p. */
I can't find this at all in the WinAVR-20100110 code. Instead, I believe it was replaced with "eerd_byte_m64c1" |
|
|
| |
|
|
|
|
|
|
Posted: Aug 17, 2012 - 05:55 PM |
|
Joined: Jul 18, 2005
Posts: 62219
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
I can't find this at all in the WinAVR-20100110 code. Instead, I believe it was replaced with "eerd_byte_m64c1"
That's exactly what happened. AVR-LibC now has pre-compiled eerd/eewr functions for each processor (the _m64c1 suffix in your case).S So eeprom.h is hugely simplified and no longer mentions EECR, EEAR, EEDR et all but simply uses pre-processor concatentation to append the _m64c1 model number onto the end of the generic eerd_byte_* name and then this links with code in lib/<architecture>/libc.a, for example:
Code:
E:\WinAVR-20100110\avr\lib\avr5>avr-nm libc.a | grep eerd_byte_m6
00000000 T __eerd_byte_m64
00000000 T __eerd_byte_m640
00000000 T __eerd_byte_m644
00000000 T __eerd_byte_m644a
00000000 T __eerd_byte_m644p
00000000 T __eerd_byte_m644pa
00000000 T __eerd_byte_m645
00000000 T __eerd_byte_m645a
00000000 T __eerd_byte_m645p
00000000 T __eerd_byte_m6450
00000000 T __eerd_byte_m6450a
00000000 T __eerd_byte_m6450p
00000000 T __eerd_byte_m649
00000000 T __eerd_byte_m649a
00000000 T __eerd_byte_m649p
00000000 T __eerd_byte_m6490
00000000 T __eerd_byte_m6490a
00000000 T __eerd_byte_m6490p
00000000 T __eerd_byte_m64c1
00000000 T __eerd_byte_m64hve
00000000 T __eerd_byte_m64m1
|
_________________
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
