WinAVR 2010 vs 2006: compiled code size

Go To Last Post
26 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have an old 20060421 version of WinAVR on my PC and compile all codes with it. Recently I've compiled a large C program for M168 (10 digit clock with multiple alarms and other functions):

clock.elf  :
section            size      addr
.data               222   8388864
.text             14976         0
.bss                142   8389086
.noinit               0   8389228
.eeprom               0   8454144
.stab               876         0
.stabstr            132         0
.debug_aranges       20         0
.debug_pubnames    2525         0
.debug_info        5783         0
.debug_abbrev       391         0
.debug_line        7418         0
.debug_str         2156         0
Total             34641

Then I skyped the whole project folder (including Makefile) to my friend with the latest 2010 build of WinAVR. He clicks make clean and make all, then reports:

clock.elf  :
section            size      addr
.data               222   8388864
.text             15216         0
.bss                142   8389086
.debug_aranges       32         0
.debug_pubnames    2525         0
.debug_info        8104         0
.debug_abbrev       704         0
.debug_line       10801         0
.debug_frame       1296         0
.debug_str         2234         0
.debug_loc         3564         0
.debug_ranges        24         0
Total             44864 

Why is the .text size 240 bytes larger? All compilation options are the same, he did not edit anything.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The compiler is a complex thing, thus there's no simple answer to your "why". The changes implemented in gcc throughout the years are big-processor-centric and sometimes pessimal to the small-processor AVR; also they may be more optimal to certain C-coding styles than to others.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

From my experience, the code size produced by the 4.7 release series is the first one to compete with the good, old 3.4.6.

WinAVR-20100110 is 4.3.3 and WinAVR-20060421 is 3.4.6.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

WinAVR-2006 did several wrong things. But yes, the executables were often smaller than WinAVR-2010.

However, why are you worried?
15216 bytes is still less than the 16384 available bytes of a mega168.

i.e. you have 1168 bytes free.
Even your 2006 compiler only gives you 1406 bytes free.

So both would still fit in a mega168 with a 512 byte bootloader like Optiboot. Neither would fit with the 2048 byte Diecimilia bootloader.

As SprinterSB has suggested, the latest compiler version might give you smaller code. (and has fixed the 2006 bugs)

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just to add that ultimately you can see where the sizes differ (a) by comparing the output of "avr-nm -size-sort" and/or (b) diffing the .lss files.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What "bugs" in 2006 do you mean? I am not aware of a single 2006 "bug".

The point with code from WinAVR20100110 and similar is that it is both more memory gulping and slower than from 3.4.6.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
From my experience, the code size produced by the 4.7 release series is the first one to compete with the good, old 3.4.6.

Where can I get 4.7?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The fact that you say you are using Windows suggests that simply getting 4.7.2 from Atmel might be the best course. Either get the whole Studio 6.1(SP1):

http://www.atmel.com/tools/atmel...

or if you only want a toolchain then:

http://www.atmel.com/tools/ATMEL...

that's a bit like a "WinAVR" but does not have quite as wide a range of utilities - bascially just the GCC and binutils.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

bascially just the GCC and binutils.

And GNU Make?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is this going to turn into Monty Python's "what have the Romans ever done for us?" ;-)

OK so GCC and binutils and make.

My point was that WinAVR comes with a whole load of other things (simulavr, avraice, avrdude, srec, Mfile, gnuwin32 tools including grep, find, sh and so on). Don't expect to get these in Atmel's "basic" toolchain. So leave a PATH to the WinAVR installation and it'll pick up anything that wasn't found further up the PATH in the Atmel toolchain installation.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I try AVR-GCC 4.8.0 20130306 and it throws a strange error with the same source and makefile:

avr-gcc (GCC) 4.8.0 20130306 (experimental)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Compiling C: clock.c
avr-gcc -c -mmcu=atmega168 -I. -gdwarf-2 -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef -Wa,-adhlns=obj/clock.lst  -std=gnu99 -Wundef -MD -MP -MF .dep/clock.o.d clock.c -o obj/clock.o 
clock.c:788:5: error: attempt to use poisoned "SIG_OVERFLOW0"
 ISR(SIG_OVERFLOW0){
     ^
In file included from clock.c:21:0:
clock.c: In function 'SIG_OVERFLOW0':
clock.c:788:5: warning: 'SIG_OVERFLOW0' appears to be a misspelled signal handler [enabled by default]
 ISR(SIG_OVERFLOW0){
     ^

What's this?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In my experience, some of the significant differences in code size came from changed decisions about when to automatically inline small functions. You can try adding "-fno-inline-small-functions" to your compile.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The SIG_xxx vector names have been deprecated for quite some while in favour of the xxx_vect names and are now "poisoned" (see poison preprocessor pragma). See http://www.nongnu.org/avr-libc/u... .

Unfortunately, the poisoning thing appears not to be documented in the avr-libc documentation - I'd expect to see it in both the page I gave link above, and in http://www.nongnu.org/avr-libc/u... . Anybody with account at savannah might want to fill a feature request to the avr-libc bugtracker (I am too lazy to do it myself).

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Anybody with account at savannah might want to fill a feature request to the avr-libc bugtracker (I am too lazy to do it myself).

Done:

https://savannah.nongnu.org/bugs...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The WINAVR 2010 tends to inline short functions unwanted.
-fno-inline-small-functions
avoid this.
And:
-Wl,--relax
may also save some Flash.

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
In my experience, some of the significant differences in code size came from changed decisions about when to automatically inline small functions. You can try adding "-fno-inline-small-functions" to your compile.
I added this, of course. And also
    -Os -mstrict-X
    -finline-limit=value
    --param case-values-threshold=value
    -fno-move-loop-invariants
    -fno-tree-loop-optimize
    -fno-tree-switch-conversion
    -fno-caller-saves
    -fno-tree-ter
    -no-split-wide-types
    -ffunction-sections -Wl,--gc-sections -mrelax
or a combination of them. Nonetheless 3.4.6 code is about 10% smaller than 4.3.3 code.

And I have a fairly good understanding of how GCC works. The 3.4.6 code is close to assembler.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
And I have a fairly good understanding of how GCC works.

Extreme modesty displayed there, making it the understatement of the year.. :D

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Call me naive, but I like something to work straight out of the box.

Yes, I am sure that you can make any version of avr-gcc behave differently.

The Winavr-2006 size issue comes up when people try compiling "usbtinyisp" for a Tiny2313. There have been several discussions on this topic. e.g. https://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=110969&start=0

No, I can't find any justification of my "Winavr-2006 had a few bugs" statement. I expect that any issues would be covered by the realease notes.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Nonetheless 3.4.6 code is about 10% smaller than 4.3.3 code.

Try 4.7 or 4.8. For me 4.8 compiled 14464 bytes.
PS. The "poisoned" behavior can be switched off with CDEFS += -D__AVR_LIBC_DEPRECATED_ENABLE__.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

PS. The "poisoned" behavior can be switched off with CDEFS += -D__AVR_LIBC_DEPRECATED_ENABLE__.

Far better to fix it now - surely the poisoning is just the next step towards complete removal. It has been almost 8 years since SIG_* was deprecated!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So, Watchmaker; you wouldn't be a "Moatie," would you?

The largest known prime number: 282589933-1

In my humble opinion, I'm always right. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wek wrote:
The compiler is a complex thing, thus there's no simple answer to your "why". The changes implemented in gcc throughout the years are big-processor-centric and sometimes pessimal to the small-processor AVR; also they may be more optimal to certain C-coding styles than to others.

JW

Not to hijack, but I love it when I learn a great new English word, especially from someone I presume is not a native speaker?

Thanks
Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Call me naive, but I like something to work straight out of the box.

Yes, but putting a full set of gcc tools "in the box" with each 16k open-source AVR project is not particularly practical!

Professionally, you realize pretty quickly that "fix Y for compiler version X" can end up being a pretty substantial part of your maintenance activity. And that you'd better put the tools under revision control as well as your product source code.

gcc seems to be particularly prone to such things, having the "what's good for processor X is bad for processor Y" syndrome, as well as the "I had a great idea for rewriting the Z, and it only made a few things not-backward-compatible." Perhaps it's the "no you can't rant and rave at us because you're a big customer and we broke your code. We're not getting paid!" effect.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Not to hijack, but I love it when I learn a great new English word ["pessimal"] [...]

Not to hijack either, but that was a gem! And a little digging at Wiktionary also reveals "pessimize" and "pessimum". Lovely words!

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry to continue the thread hijack but I've just been reading "Dissolution" by C J Sansom (http://www.amazon.co.uk/Dissolution-Shardlake-C-J-Sansom/dp/0330450794) - an excellent murder mystery set at the time of Henry VIII dissolution - and I don't think I've read anything that has taught me so many really good new words in a long time (usually P D James novels in fact!). If you want to expand your vocabulary it's well worth a look.

Apologies again for "off topic".