> Here we had to change a few times of AVR-GCC versions only to be able to > process new AVR chips while keeping older ones up to date. And each > time, since GCC 3.4.6, I've seen code bloat with newer versions and had > to spend time only to get the the same application fit in the same > memory footprint for older chips using a newer GCC (we want to keep a > single compiler version for all of our devices). > While I agree that fixing some of the missed optimisations would be nice, and that it's a pain to have to deal with installing a new version of AVR-GCC then fiddling with old projects to get them to fit again, I've found that newer versions of GCC are actually as good or better than old ones in most cases for code size generation.. the problem is that they are worse with no extra options.
If you take some of the suggestions posted to this list previously for options such as "--param inline-call-cost=3" (or 2), "-fno-split-wide-types" and "-fno-inline-small-functions" in some combination, usually the result is as small or smaller. Unfortunately, because the effect of these flags varies between GCC versions, and because older versions of GCC don't support the last two, it's hard to generate a Makefile that will compile a given project optimally with different versions of AVR-GCC. This is the best I came up with so far: CFLAGS?=-Os -Wall -mmcu=atmega48 -L/usr/lib/binutils/avr/2.18/ --param inline-call-cost=3 `avr-gcc --version | head -1 | awk -F" " '{ printf $$3 >= 4.3 ? "-fno-split-wide-types -fno-inline-small-functions" : "" }'` It's a hack, I know, but I tested it on several versions of AVR-GCC with reasonably good results. I doubt it'll work universally but could be quite good in a number of cases. Unfortunately I don't have enough time to work on AVR-GCC's internals but next time I come across a badly missed optimisation I'll submit as detailed a bug report as I can. Another hint, this may seem obvious but I missed it for a while: declare as many functions "static" as you can, so that if they are inlined then there won't have to be an extra non-inlined copy stored. Nicholas _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list