Allg. Frage zum Optimierer

Es ist dann weder ratsam, zu optimieren, noch nicht zu optimieren.
Es ist schlichtweg egal.

Es ist trotzdem ratsam, denn wenn man ein Programm nie mit Optimizer 
probiert hat, dann ist die Überraschung gross, wenn man nach 2 Jahren 
und der soundsovielsten Erweiterung die nun endlich nicht mehr 
unoptimiert reinpasst nochmal beim Debugging von vorne anfangen muss um 
die ganzen fehlenden volatiles zu finden.

Wer volatiles weglässt...

...findet sich dann hier im Forum wieder. Massenhaft. Schlimmer als die 
"defekten" Pins vom Port C des Mega16/32.

Aber auch an anderen Stellen kann man Schiffbruch erleiden. 
Beispielsweise weil die "__delay_xx" Schleifchen erst mit Optimierung 
ihre wahre Kunst entfalten.

Sash schrieb:
> Ich werde das Programm mit und ohne
> Optimierer in allen Funktionen testen,

Das ist sicher eine gute Idee.

Sash schrieb:

> Wenn ich ein Programm habe das ohne Optimierer in den Flash-Speicher
> passt und auch nicht auf Laufzeit optimiert sein muss, ist es dann
> trotzdem ratsam den Optimierer einzuschalten oder eher nicht ?

Es muss auch sichergestellt sein, daß das RAM ausreicht.

Ohne Optimierung legt gcc lokale Variablen auf dem Stapel ab, was flott 
zu merklichem (dynamischem) RAM-Verbrauch führen kann. Weil der 
Verbrauch dynamisch ist -- also erst zur Laufzeit entsteht -- ist er nur 
schwer statisch schätzbar und Tools wie avr-size helfen überhaupt nicht 
dabei.

Man sollte also eine ungefähre Vorstellung davon haben, wie viel RAM 
maximal belegt wird -- das gilt natürlich auch dann, wenn man optimieren 
lässt.

gcc kennt die Optimierungsstufe -O1, die optimiert und dabei halbwegs 
debugbare Programme erzeugt.

Häufig kann man den Optimizer zum Debugging mittels Inline-Assembler 
auch gezielt an einzelnen Stellen am Optimieren hindern.

Beispiel:

1

i += 20;

2

asm("" : "=m" (i) : "m" (i));

3

i += 30;

Der Inline-Assembler verhindert, dass der Compiler die beiden Additionen 
zusammenfassen kann, da die Variable ja im Assemblercode verändert 
werden könnte. Ausserdem sorgt die Zuweisung der Variablen an 
Memory-Operanden dafür, dass der Compiler die Variable tatsächlich im 
Speicher anlegen muss.

Sehr nützlich, wenn man aufgrund der Rahmenbedingungen nicht komplett 
auf die Compileroptimierung verzichten kann.

Andreas

Link zu schrieb:
> A. K. schrieb:
>> ...findet sich dann hier im Forum wieder. Massenhaft. Schlimmer als die
>> "defekten" Pins vom Port C des Mega16/32.
> Aus Neugier:
> Was meinst du damit?
> Hat das was mit JTAG zutun?

Standardfrage:
Hilfe, mein <Gerät hier einsetzen, meistens ein LCD> funktioniert nicht.
Ich habe es am Port C angeschlossen.

Standardantwort (noch ehe der Frager den Code präsentiert):
JTAG am Port C abschalten

Trefferquote, das man richtig liegt: >90%