Hallo Siro,
Im wesentlichen gibt es zwei, sich widersprechende, Optimierungen:
- Codegrösse
- Geschwindigkeit
Von daher müssen nie beide Optimierungen sein
Grundsätzlich muss nicht optimiert werden, Codegrösse kann helfen, ein grosses Programm noch ins ROM zu bringen.
Grundsätzlich sollte der Code nicht kaputt optimiert werden, zumindest von der Ablauflogik her.
Das andere Problem ist das Laufzeitverhalten, hier ändert sich das Timing, was zu Problemen mit der Peripherie führen kann.
Von der Programmlogik kann eine leere for-Schlaufe wegoptimiert werden, da deren Entfernen nichts an der Ablauflogik ändert. Dumm nur wenn das ein Delay war
Allerdings kann man die Optimierung auch meistens über #pragma im Code steuern, sodass man kritische Teile von der Optimierung ausnehmen kann.
Das mit dem "volatile"-Problem verstehe ich nicht so ganz? Da vermute ich, dass da grundsätzlich etwas nicht ganz sauber im Programm ist, aber erst beim Optimieren wirklich entdeckt wird.
Typisches Beispiel:
Ohne Optimierung wird Status bei jedem Durchgang neu geladen.Code:while (!Status) { // warten bis bereit }
Bei der Optimierung auf Geschwindigkeit wird "Status" nur einmal geladen und in einem Register aufbewahrt, das spart Speicher-, bzw. Peripherie-Zugriffe.
Nun ist es aber so, dass man bei einer sauberen Programmierung z.B. I/Os IMMER als "volatile" deklariert!
"volatile" ist besonders wichtig bei der Optimierung und besagt dem Compiler, dass sich der Zustand dieser Variablen jederzeit ändern kann, auch wenn dies vom Programmablauf her nicht "sichtbar" ist.
Ein C-Compiler kennt den Unterschied zwischen einer normalen Variablen im RAM und einem Port nicht. Allerdings kann "volatile" auch wichtig sein, wenn eine Variable in einer ISR verändert wird.
MfG Peter(TOO)
Lesezeichen