Softwaretest mit Code Optimierung

[Peter(TOO)]

Hallo Siro,

Ist doch für einen Automaten logisch! :-=

a = 0x83;
a = 0x03;

Da steht am Schluss immer 0x03 in a!

Wie schon geschrieben wurde, ist das ohne volatile für den Compiler nur eine Variable im Speicher!

a = 0;
a = 1;
a = 2;
a = 3;

Da macht nur a =3; Sinn, die anderen Werte werden dauernd überschrieben ohne je gelesen zu werden.

Die CPU, und der Compiler, behandeln bei dieser Architektur Register und Speicher genau gleich, da gibt es keinen Unterschied.
Da muss man dann halt mit volatile "nachhelfen" und den Compiler beibringen, dass sich diese Speicherzellen auch ohne zutun des Programms änder können, bzw. das Setzen und anschliessende Löschen eines Bits etwas bewirken.

Es gibt Architekturen, bei denen I/Os am einem separaten Bus hängen, da kann das der Compiler dann an der Adresse unterscheiden. z.B. der 8080 und auch die Nachfolger 8086 bis Pentium haben so einen separaten I/O-Bus. Beim 8080 gab es 256 I/O-Adressen, beim 8086 waren es dann 65KByte. Natürlich kann man aber auch bei dieser Familie I/Os im normalen Speicherbereich einbinden.

MfG Peter(TOO)

[Siro]

Jetzt, wo Du es so erklärst, fällt auch bei mir der Groschen (Centweise )

Na klar, der Compiler sieht, dass ich einer Variablen einen Wert zuweise, nix damit mache und dann einen neuen Wert zuweise.
Er kann den Sinn natürlich nicht erkennen, dass ich dies tue um an spezielle Register im UART heranzukommen.

Das leuchtet mir jetzt auch ein und damit hat er recht und darf das wegoptimieren.
Vielen Dank Peter

[Peter(TOO)]

Hallo,

Jetzt, wo Du es so erklärst, fällt auch bei mir der Groschen (Centweise )

Dann bist du jetzt reich

Es gibt noch weitere Optimierungen, das wird dann auch die Reihenfolge der Befehle umgestellt, z.B. um die FPU besser auszunutzen, kann man, während die FPU gerade rechnet noch ein paar Integer-Befehle abarbeiten. Das hängt dann aber sehr von der CPU-Architektur ab. Bei manchen RISC-CPUs geht das so weit, dass das Return einer Subroutine VOR dem letzten Befehl stehen muss!

Grundsätzlich muss man bei Funktionen, welche direkt I/Os bedienen mit der Optimierung sehr genau aufpassen! :Strom
Meistens ist es am Besten diese separat auszulagern und ohne Optimierung zu übersetzen.
Andernfalls kann schon eine neue Version des Compilers, mit verbesserter Optimierung, zu einem anderen Timing, und folglich zu Fehlern, führen.

Noch etwas grundsätzliches zur Funktion eines Compilers:
Zuerst wird eine lexikalische Prüfung vorgenommen, dabei wird im Prinzip die Rechtschreibung überprüft.
Anschliessend folgt die syntaktische Prüfung, bei welcher festgestellt wird ob aus den Wörtern auch gültige Sätze gebildet wurden.
Anschliessend bildet man eine Baumstruktur, welche den logischen Programmablauf darstellt und eigentlich Sprachunabhängig ist.
Diesen Sprachabhängigen Teil nennt man Front End.

An diesem Baum erfolgt dann die erste Optimierung, wie z.B. das wegoptimieren von unnötigen Variablen-Zugriffen und totem Code.

Der Code-Generator (Back End) erzeugt dann aus dem Baum den eigentlichen Maschinencode. Dieser Teil ist dann CPU spezifisch.
Hier wird dann weiter optimiert, vor allem da hin gehend, dass man viel benutzte Variablen möglichst in einem Register behält und erst am Ende der Berechnung in den Speicher schreibt (volatile verhindert auch diese Optimierung).
Weitere Optimierungen sind z.B. bei einer Multiplikation mit 2, das Ersetzen durch eine Addition oder einen Links-Shift, je nachdem was halt schneller ist.

MfG Peter(TOO)

[Siro]

Hallo Peter,
ich wollt mich nochmal bedanken, für die zusätzlichen Informationen.

Ich habe tatsächlich noch ein Problem gefunden. Ich habe eine "Inkontinenz" Inkonsistenz in meinem Code gefunden.
Im Header habe ich einen 32 Bit und in C-Code Modul einen 16 Bit Wert declariert/definiert. Das merkt der Compiler nicht und beim IAR-Compiler wird funktioneller Code erzeugt
der Gnu-Compiler hingegen erzeugt nicht funktionellen Code. Eindeutig meine Schuld , aber so unterschiedlich kann der erzeugte Code durch einen anderen Compiler halt werden.

Obwohl die Sourcen im Projekt zur Verfügung stehen, guckt der Compiler sie sich nicht an und damit gibt es auch kein Warning. Schade eigentlich.


Datei: FlowCalc.h
extern volatile U32 flowfactor;

Datei: FlowCalc.c
U16 flowfactor = 256;

mir fällt jetzt auch nichts ein, wie man solche Fehler vermeiden kann.

[botty]

Hallo Sisor,

kann es sein, dass Du FlowCalc.h nicht in FlowCalc.c inkludierst?

Also der GCC schreit normalerweise (oder spätestens bei -Wall) wenn eine Variable zuvor anders deklariert wurde, als sie dann später definiert wird.

Gruss
Chris

[Siro]

kann es sein, dass Du FlowCalc.h nicht in FlowCalc.c inkludierst?
Chris

Das kann nicht nur sein, sondern das ist so....

Wenn ich aus einer H-Datei nix brauche, includiere ich sie niemals. Sollte man das tun ?

Vielen Dank für den Hinweis Chris

[botty]

Was man immer macht, ist, dass man eine Include-Datei, in die zugehörige C-Datei inkludiert.
In Deinem Beispiel also FlowCalc.h in FlowCalc.c, eben genau um solche Fehler aufzudecken (Ich selbst habe den IAR-Compiler noch nie benutzt, aber auch der sollte dann meckern.).

Ausserdem schreibt man in eine H-Datei immer Guards, für den Fall das man aus Versehen sie mehrmals inkludiert - was ohne Guards wieder zu Fehlermeldungen führt.

Also fuer FlowCalc.h:

#ifndef _FlowCalc_h_
#define _FlowCalc_h_

/* Hier kommen jetzt alle defines, Deklarationen etc. */

#endif

[Peter(TOO)]

Hallo Chris,

Das kann nicht nur sein, sondern das ist so....

Wenn ich aus einer H-Datei nix brauche, includiere ich sie niemals. Sollte man das tun ?

Du musst das so betrachten.

1. Man schreibt irgendein Modul, welches teilweise Funktionen bereit stellt, welche aus anderen Modulen benutzt werden können.
2. Man schreibt zu diesem Modul eine Header-Datei, welche alles enthält, was zum externen Aufruf benötigt wird. Also natürlich die Funktionen, aber auch öffentliche Konstanten und Variablen-Konstrukte.
3. Überall wo dann dieses Modul verwendet werden soll, wird die Header-Datei includiert.
4. Damit der Compiler auch überprüfen kann, dass Header und Modul zusammenpassen, includiert man diese auch im Modul!
5. Alle Funktionen welche in dem Modul nicht öffentlich sein sollen, declariert man als static, dann kann diese auch der Linker nicht finden und man darf die selben Namen auch in einem anderen Modul verwenden.

So wird der Code auch für andere übersichtlicher, besonders wenn man etwas anpassen muss:
Alle Funktionen und Variablen welche als static deklariert sind, kann man problemlos anpassen ohne auf Aufrufe aus anderen Modulen acht geben zu müssen.
Alles was öffentlich verwendet wird ist in der Header-Datei und der Compiler kann überprüfen ob es passt.

MfG Peter(TOO)