Seltsames Problem mit Compilerübersetzung

Marcel_74 wrote:

> endlos: if(whattodo == 1)  {
>    updatetime();
>    updatedisplay();
>    whattodo = 0;
>
>   };
>
> goto endlos;

Wenn man solchen Code schreibt sollte ein vernuenftiger Compiler das 
sowieso nicht mehr uebersetzen.

Um im Bild zu bleiben: Statt vom Glauben abzufallen solltest du lieber 
die K&R Bibel nochmal lesen, und zwar im Abschnitt zu "volatile".

Der Compiler stellt nämlich völlig zurecht fest, dass dieser Code 
spätestens nach einer Runde mit "whattodo=1" auf eine leere Totschleife 
rausläuft, und optimiert die nun auf maximale Performance. Es kann nicht 
damit rechnen, dass da vielleicht ein Interrupt die Variable wieder 
setzt. Nicht ohne "volatile".

Einen Vorwurf kann man dem Compiler allerdings machen: Dass er den 
ersten der beiden abschliessende Sprünge drin gelassen hat. Der ist 
nämlich komplett überflüssig.

> Was ich allerdings nicht verstehe, ist die Tatsache, dass "richtig"
> compiliert wird, wenn noch Code zwischen dem Ende des if-Blocks und dem
> Goto steht.

Na A. K. hats doch schon gesagt: Informier dich mal über "volatile".

Der Compiler weiss nicht, dass dein whattodo in einer isr geändert wird 
und nimmt deshalb an, dass der Code im if-Block nur einmal ausgeführt 
werden kann. Mit volatile, kannst du dem Compiler sagen, dass die 
Variable ihren Wert "unvorhersehbar" ändern kann. Dann wird er solche 
Optimisierungen unterlassen.

Warscheinlich weil man goto nicht ohne Not einsetzen sollte, wegen des 
Stils ;P

1

while(1) {

2

  if(whattodo == 1)  {

3

   updatetime();

4

   updatedisplay();

5

   whattodo = 0;

6

  };

7

}

tut das von dir gewünschte :)

Wenn du Anweisungen einfügst, dann kommt der Compiler ggf zu anderen 
Annahmen bzgl der Relevanz deines Codes.

Vieleicht wäre es hilfreich die Variablendefinition mit anzugeben. Und 
ein Beispiel geht/geht nicht, das man sieht WELCHE anweisung genau 
eingefügt wurden.

Marcel_74 wrote:

> Was ich allerdings nicht verstehe, ist die Tatsache, dass "richtig"
> compiliert wird, wenn noch Code zwischen dem Ende des if-Blocks und dem
> Goto steht.

Und wenn er dann mal das tut was du von ihm willst bist du auch wieder 
nicht glücklich. ;-)

Im ersten Fall steht zwischen dem =0 und der Abfrage davon kein Code der 
irgendwas verändern könnte. Im zweiten Fall befürchtet er möglicherweise 
eine Identität der beiden Variablen (aliasing) - was zwar dank des 
gleichen Wertes egal wäre, aber trotzdem den Optimierungstest aushebelt.

Marcel_74 wrote:

> Ja, ich habe mich mittlerweile über volatile informatiert. Gute Sache
> sowas ;-) Mir wäre es ja fast lieber, wenn der Compiler nicht so stark
> mitdenkt.

Anfangs gab es das in C-Compilern auch nicht. War nicht nötig. Bis weit 
in der 80er Jahre haben viele C-Compiler weitgehend das gemacht, was in 
der Zeile drin stand. Erst als die Compiler anfingen, auch über 
Statement-Grenzen hinweg zu optimieren, statt Registeroptimierung dem 
Programmierer zu überlassen, wurde das wichtig (hast du dich mal 
gefragt, warum es in C ein Keyword "register" gibt?).

Manch andere Compiler, vor allen solche die auf Microcontroller 
spezialisiert sind, sind bei derartiger Optimierung und Umordnung von 
Code nicht so agressiv. Sei es weil eine Akkumulator-Architektur wie 
68xx,PIC,8051 dafür wenig Raum lässt oder fehlendes tiefes Pipelining es 
einfach unnötig macht, sei es weil es manchen Programmierern übel 
aufstösst ;-). Der GNU-Compiler hingegen muss sich mit Compilern für 
High-Performance-Computing messen und optimiert dementsprechend 
agressiv. Und einiges davon merkt man auch in der AVR-Version, und es 
gereicht dort auch nicht immer zum Vorteil.

Marcel_74 wrote:

> Gibt es eine Übersicht über die Art der Optimierungen, die der Compiler
> vornimmt? Woher soll ich wissen was kritisch ist und was nicht?

Falscher Ansatz. Richtig programmieren heisst die Devise. Und um dich 
vor sowas warnen zu können, müsste er mehr wissen als er wissen kann. 
Das ist ja grad der Witz dran: erst "volatile" sagt ihm das.

Regel: Der Compiler weiss nichts über Interrupt-Routinen, d.h. auch wenn 
es im Quelltext anders aussieht, weiss er nicht dass timer_interrupt() 
eine Interrupt-Routine ist.

Marcel_74 wrote:

> Ich Grunde weiß doch der Compiler, dass ich eine Variable in einer
> if-Bedingung teste, die im Verlaufe des Programms (genauer: main) nicht
> verändert wird. Ich werde ja auch gewarnt, wenn ich eine Variable
> daklariere und diese anschließend nicht verwende.

Das ist richtig. Vielleicht gibt's auch eine Warnung die man extra dazu 
einschalten kann.

Allerdings ist das mit den Warnungen so eine Sache. Wenn man damit zu 
weit geht, dann hat jedes normale Programm so viele ganz normale 
Warnungen, dass man die ernsten übersieht.

So war es früher in Compilern durchaus üblich, auf Code wie
  if (1 == 2)
lautstark hinzuweisen. Die Devise war, dass der Anwender doch den 
Präprozessor verwenden soll. Das hat sich allerdings geändert, seit der 
Präprozessor etwas schlecht angesehen ist und umgebungsabhängige 
Fallunterscheidungen in übersichtlicher Weise direkt dem Compiler 
überlassen werden.

Im Makefile steht dann beispielsweise
   -DVERSION=1
und im Code
   if (VERSION == 2)
      ...
was man traditionell aber unübersichtlich mit
   #if VERSION == 2
gemacht hat.