Optimizer Unterschiede mit GCC - Codevision - IAR

[Björn G. (tueftler)]

Hi da.

Habe ab und an das Problem das mein WinAVR z.B. if/then Konstrukte weg 
optimiert obwohl er es nicht sollte.
Beispiel habe ich gerade nicht zur Hand, da keine Zeit um einen Code so 
umzuschreiben das es veröffentlichbar und zugleich ersichtlich ist.

Ich denke das Problem hatten schon einige das plötzlich was nicht mehr 
funktionierte und ein Zweig nicht mehr assembliert wurde.

Da es mich so langsam nervt irgendwelche Funktionen in einzelne .c 
Dateien zu extrahieren die ich nicht optimieren lasse suche ich derzeit 
nach einer Lösung für das Problem.

Wie sieht es denn bei Codevision oder IAR in dem Falle aus?
Funktioniert es da besser?

Evtl. kann das ja jemand beantworten.

Gruß Björn

[DerAlbi (Gast)]

Du schiebst da etwas auf einen Compilerfehler was du 99.9% dein Fehler 
ist.
Wenn sich das Verhalten deines Programms wegen der Optimierung ändert 
sind das entweder Timingprobleme, Nachlässigkeit mit volatile oder Stack 
oder Heap-Speicher-Schweinereien.
If/else wird nicht wegoptimiert, wenn es nicht wegoptimiert werden kann.

[XTerminator (Gast)]

Björn G. schrieb:
> Da es mich so langsam nervt irgendwelche Funktionen in einzelne .c
> Dateien zu extrahieren die ich nicht optimieren lasse suche ich derzeit
> nach einer Lösung für das Problem.

Du solltest in dem "wegoptimierten" Zweig halt auch etwas tun, was 
Einfluß auf die weitere Programmausführung hat.

[Rolf M. (rmagnus)]

Björn G. schrieb:
> Da es mich so langsam nervt irgendwelche Funktionen in einzelne .c
> Dateien zu extrahieren die ich nicht optimieren lasse suche ich derzeit
> nach einer Lösung für das Problem.

Die Lösung ist, herauszufinden, welchen Fehler du machst und ihn zu 
beheben. Der Compiler optimiert nicht einfach so Sachen weg, die 
benötigt werden.

> Wie sieht es denn bei Codevision oder IAR in dem Falle aus?
> Funktioniert es da besser?

Es funktioniert auch bei GCC sehr gut, daher liegt die Vermutung nahe, 
daß du etwas falsch machst. Ohne ein Beispiel wird dir aber keiner sagen 
können, was der konkrete Fehler ist.

[Johann L. (gjlayde)]

Björn G. schrieb:

> Wie sieht es denn bei Codevision oder IAR in dem Falle aus?
> Funktioniert es da besser?

Vielleicht funktioniert den Code damit weil diese Compiler weniger 
optimieren. Aber dadurch wird dein Code nicht korrekt: Du verschiebst 
das Problem nur nach hinten anstatt es zu lösen.

Löse das Problem, um es los zu werden. Verschiebe es nicht an eine 
andere Stelle.

> Evtl. kann das ja jemand beantworten.

Beachte Warnungen des Compilers und schreibe robusten Code.

Was zählt, ist der Code, der ausgeführt wird und nicht der Code, den 
irgendein Debugger anzeigt oder nicht anzeig, siehe [[Compilerfehler#Die 
häufigsten Nicht-Fehler]].

Mir ist kein Fehler im WinAVR bekannt, der zur kompletten, unerlaubten 
Entfernung eines if-else Zweiges führt.

Ist der Code wirklich weg? Oder wird er nur nicht ausgeführt? Mit Code 
meine ich auch Code und nicht irgendne mehr oder weniger sinnfreie 
Debugger-Ansicht.

[Oliver (Gast)]

Björn G. schrieb:
> Habe ab und an das Problem das mein WinAVR z.B. if/then Konstrukte weg
> optimiert obwohl er es nicht sollte.

Was ist denn "dein" WinAVR?

Ansonsten wurde schon alles gesagt. avr-gcc optimiert keine 
if/the-Konstrukte weg, die nachweislich durchlaufen werden müssen, um 
das zu tun, was im Programm steht. Punkt.

Oliver

[Peter D. (peda)]

Der AVR-GCC optimiert gnadenlos mehrfache Einlesungen derselben Variable 
weg, wenn diese nicht volatile definiert ist.
Z.B. wenn Dein if/else in einer Schleife erfolgt.


Peter

[gcc (Gast)]

Peter Dannegger schrieb:
> Der AVR-GCC optimiert gnadenlos mehrfache Einlesungen derselben Variable
> weg, wenn diese nicht volatile definiert ist.
wozu er auch berechtigt ist, denn so wurde es ihm ja erklärt.

[Johann L. (gjlayde)]

Peter Dannegger schrieb:
> Der AVR-GCC optimiert gnadenlos [...] weg

Übersetzung "gnadenlos": Der Compiler übersetzt den Code so, daß das 
Ergebnis den Erfordernissen des C-Standards und der Implementierung 
entspricht.

Die Implementierung (hier avr-gcc) legt Dinge fest, die im Standard 
"Implementation defined" sind, wie etwa die Größe des Typs int.

[Oliver (Gast)]

Björn G. schrieb:
> Ich denke das Problem hatten schon einige das plötzlich was nicht mehr
> funktionierte und ein Zweig nicht mehr assembliert wurde.

Um das noch zu beantworten: Nein.

Oliver

[Matthias L. (matze88)]

Björn G. schrieb:
> Hi da.
>
> Habe ab und an das Problem das mein WinAVR z.B. if/then Konstrukte weg
> optimiert obwohl er es nicht sollte.
> Beispiel habe ich gerade nicht zur Hand, da keine Zeit um einen Code so
> umzuschreiben das es veröffentlichbar und zugleich ersichtlich ist.

Um die Beiträge der anderen mal etwas deutlicher auszudrücken:

Bring und ein Beispiel bei dem das wirklich der Fall ist, damit der 
Fehler im Compiler ausgemerzt werden kann - bedenke dabei, die 
angesprochenen Punkte: Dein Code muss natürlich (nach C-Standard) auch 
das tun können, was du von ihm verlangst...

[Oliver (Gast)]

Björn G. schrieb:
> Wie sieht es denn bei Codevision oder IAR in dem Falle aus?

Um das auch noch zu beantworten: Wenn du von diesen die kommerzielle 
Version gekauft hast, dann kannst du solche Fragen dem dortigen Support 
stellen. Die beantworten das dann professionell ;)

Oliver

[Peter D. (peda)]

Björn G. schrieb:
> Ich denke das Problem hatten schon einige das plötzlich was nicht mehr
> funktionierte und ein Zweig nicht mehr assembliert wurde.

Ja, das passiert schonmal.

In der Regel ist das dann ein logischer Fehler, z.B. ein Ausdruck ist 
immer wahr oder immer falsch.

Also einfach nochmal den wegoptimierten Teil gründlich anschauen, dann 
merkt man schnell seinen Fehler. Z.B. ein | an einer Stelle, wo ein & 
hin sollte.

Ich nutze das manchmal sogar aus, um Code zeitweise zu löschen.

if( 1 | ... )

entfernt den Test und führt den if-Zweig immer aus (der else-Zweig wird 
auch gelöscht).
Bzw. umgekehrt:

if( 0 & ... )

Das fehlende volatile löscht den Code auch nur dann, wenn das 
Verschieben vor die Schleife immer wahr bzw. immer falsch ergibt.


Peter