Hi.
I just began yesterday to move from gcc-4.2.0/avr-libc-1.4.6 to
gcc-4.3.0/avr-libc-1.6.2 (with the patches taken from WINAVR0610).
I first experienced a significant code growth (about 4%) because of:
- functions like eeprom_read/write_byte() that now inline more code,
hence I had to write wrapper functions like you did in your example for
putchar(). In a previous run of 'hand optimization', I did replace
fputc() calls directly to 'myputc' (stream->putc()), sparing even more
bytes (the size of fputc()) while getting more speed (often the checks
performed in fputc() (i.e. (if((stream->flags...)) are useless (depends
on the application considered)).
- gcc-4.3.0 seems to automatically inline bigger static functions than
gcc-4.2.0. I have to use -finline-limit to a very low value like 10.
I now have a code size with gcc-4.3.0/avr-libc-1.6.2 a litle bit smaller
than with gcc-4.2.0/avr-libc-1.4.6. (and I will have to perform
extensive tests to check that the application still works :)) and I
reclaimed the 256 bytes of RAM that were previously lost because of
__clz_tab (my main reason for moving to a newer compilation chain)
IMHO the 'stock' distribution of avr-gcc/avr-libc should be tuned to
give results as good (hence small) as possible with -Os since most of
the traffic in the mailing lists seems code size oriented, so I have a
point of view similar to Wouter.
Or have link options like '-lprintf_min' for features that would be
compiled in different ways to meet the user goals.
Or have conditional compilation of headers according to the optimization
required, (so in Wouter's case putchar() would be kept as a function
call with -Os, but replaced with fputc() with -O2/3), however I dunno if
there is a macro or something already defined allowing this without
passing yet another -D option to the compiler.
Bernard
Wouter van Gulik wrote:
Hi list,
Currently putchar is defined as
#define putchar(__c) fputc(__c, stdout)
which causes C code like this:
putchar(' ')
To generate assembler like this:
lds r22,__iob+2
lds r23,(__iob+2)+1
ldi r24,lo8(32)
ldi r25,hi8(32)
call fputc
This is 8 bytes (lds == 4 bytes) for loading the stream pointer.
If we change this to a "real" putchar call we would save 8 bytes per
putchar call. the putchar call would then load the correct stream:
int putchar(int c)
{
return fputc(stdout, c);
}
The cycle penalty would be the extra call and return.
IMHO losing 7,8 or 10 cycles per call for a gain of 8 bytes per call
seems very acceptable to me. Especially if it concerns functions like
putchar and friends.
Other opinions? Otherwise I will file a bug report.
Wouter
_______________________________________________
AVR-libc-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
_______________________________________________
AVR-libc-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
