optimale avr-gcc compiler optionen

[Uwe S. (de0508)]

Hallo avr-gcc Entwickler!

welche avr-gcc compiler optionen verwendet ihr in einem Makefile?

Mein Fragestellung war, wie ich den cocoOS "cooperative task scheduler" 
- http://www.cocoos.net/ so verwenden kann, dass die erzeugte codegröße 
für atMega möglichst klein wird.

Anmerkung: Der cocoOS Version 2.1.0 habe ich noch einige #if #endif 
verpasst, so dass schon hier etwas gewonnen wurde.

Heute konnte ich meine noch fertiges Programm (atMega88) von 4490 auf 
3384 "verkleinern".

Somit sollte zukünftig auch der Einsatz eines atMega48 möglich sein.
Der Verwendete fastbootloader 2.9 belegt nur 512b, die ich bei einem 
atMega48 auch noch einsparen könnte.

Hier ein Ausschnitt aus dem Makefile

# see: http://www.tty1.net/blog/2008-04-29-avr-gcc-optimisations_en.html
OPT = s
CFLAGS = -g$(DEBUG)
CFLAGS += $(CDEFS) $(CINCS)
CFLAGS += -O$(OPT)
CFLAGS += -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums
CFLAGS += -ffunction-sections -fdata-sections -Wl,--gc-sections
CFLAGS += -fno-split-wide-types -fno-tree-scev-cprop
##CFLAGS += -fno-inline-small-functions
#CFLAGS += -ffreestanding
CFLAGS += -Wall -Wstrict-prototypes -Wl,--relax
CFLAGS += -Wa,-adhlns=$(<:.c=.lst)
CFLAGS += $(patsubst %,-I%,$(EXTRAINCDIRS))
CFLAGS += $(CSTANDARD)

Gibt es noch Verbesserungen oder Vorschläge?

[Johann L. (gjlayde)]

Uwe S. schrieb:
> Hallo avr-gcc Entwickler!
>
> welche avr-gcc compiler optionen verwendet ihr in einem Makefile?
>
> Mein Fragestellung war, wie ich den cocoOS "cooperative task scheduler"
> - http://www.cocoos.net/ so verwenden kann, dass die erzeugte codegröße
> für atMega möglichst klein wird.
>
> Anmerkung: Der cocoOS Version 2.1.0 habe ich noch einige #if #endif
> verpasst, so dass schon hier etwas gewonnen wurde.
>
> Heute konnte ich meine noch fertiges Programm (atMega88) von 4490 auf
> 3384 "verkleinern".
>
> Somit sollte zukünftig auch der Einsatz eines atMega48 möglich sein.
> Der Verwendete fastbootloader 2.9 belegt nur 512b, die ich bei einem
> atMega48 auch noch einsparen könnte.
>
> Hier ein Ausschnitt aus dem Makefile
> [code]# see:
> http://www.tty1.net/blog/2008-04-29-avr-gcc-optimisations_en.html
> OPT = s
> CFLAGS = -g$(DEBUG)
> CFLAGS += $(CDEFS) $(CINCS)
> CFLAGS += -O$(OPT)


> CFLAGS += -funsigned-char -funsigned-bitfields -fpack-struct
> -fshort-enums

Das sind keine Optimierungs-Optionen, sondern sie beeinflussen das ABI, 
d.h. die Binärkompatibilität des erzeugten Codes. Gleichwohl haben sie 
auch Einfluß auf die Codegröße.

> -fno-split-wide-types

Ob das was bringt hängt von deiner Quelle ab.

> -fno-inline-small-functions

Ditto. Inlining kann das Programm verkleinern (in den meisten Fällen) 
oder vergrößern (eher selten).

> -Wall -Wstrict-prototypes

Warnungen haber keinen Einfluß auf die Codegröße. Ratsam ist noch -W

> Gibt es noch Verbesserungen oder Vorschläge?

Das hängt von deinem Code ab, d.h. Assembler-Ausgabe überfliegen und 
schauen, ob gcc irgendwo klotzigen Code macht.

Und: Wenn du gute Optionen gefunden hast, bleib bei der 
Compiler-Version. Ansonsten kannst du den ganzen Zirkus wieder von vorne 
anfangen.

Bei mir sehe ich noch
-fno-move-loop-invariants
-fno-tree-loop-optimize
Diese erhöhen in manchen Grenzfällen die Registerlast, so daß ein Freme 
gebraucht wird, wo es ansonsten nicht nötig ist.

Zur Codeersparnis kann auch indirekte Adressierung führen, richtige 
Anwendung vorausgesetzt. Also im Listfile nach "Nestern" von 
4-Byte-Befehlen suchen und ggf. indirekt adressieren. Kandidaten dafür 
sind Nester von Strukturzugriffen.

[Uwe S. (de0508)]

Hallo Johan,

danke für die weitere Erklärung.

ich habe noch die Option

CFLAGS += -fno-move-loop-invariants

aus und ein miteinander verglichen und das spart mir nochmals 3330-3296 
= 34 Byte.