www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik KEIL-Code-Optimierung: Wo sieht man die Veränderungen?


Autor: Erik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe eine Frage bezüglich der KEIL-Compiler-Optimierung.


---Worum geht es---
Ich habe schon oft gelesen, dass der KEIL-Compiler mit zu den Besten 
gehört in Bezug auf die Optimierungen und dass KEIL dementsprechend auch 
nicht genutzte Codeteile automatisch ausgliedert.
Um mein Problem so einfach wie möglich darstellen zu können, werde ich 
es anhand eines kleinen Beispiels erklären.


---Beispiel---
-main.c-
#include file1.h
test1()  //beliebige Funktion
test2()  //beliebige Funktion
test3()  //beliebige Funktion

-file1.h-
test3()  //Prototyp

-file1.c-
test3()  //Funktionsbeschreibung

Ich habe eine main.c mit diversen Funktionen. Die test3() hat den 
Prototypen und die Funktionsbeschreibung in der Datei file1.h/file1.c.
Wenn ich kompiliere erstellt KEIL die *.obj und *.ist Dateien. In den 
*.ist-Dateien sehe ich den Code in C und in Assembler zu jeder 
Codedatei.


---Frage---
Wenn ich jetzt den Funktionsaufruf von test3() in der main.c 
auskommentiere, dann werden auch automatisch die Dateien file1.h und 
file1.c überflüssig, dementsprechend auch der #include-Befehl für die 
file1.h.

Ich hätte gedacht, dass dann diese Codeteile jetzt in der *.ist nicht 
mehr auftauchen, bzw. die test3.ist erst gar nicht erstellt wird, weil 
die Codeteile darin nicht mehr benötigt werden.

Wieso wird das nicht rausoptimiert?
Sind die *.ist-Dateien überhaupt schon optimiert?
Kann man irgendwo den optimierten Code sehen?
Wirft KEIL automatisch alle Funktionen, Variablen, Definitionen, Dateien 
(*.c), usw. raus, wenn diese nirgends aufgerufen werden?

Danke im Voraus!

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erik schrieb:

> Wenn ich jetzt den Funktionsaufruf von test3() in der main.c
> auskommentiere, dann werden auch automatisch die Dateien file1.h und
> file1.c überflüssig, dementsprechend auch der #include-Befehl für die
> file1.h.

Das weiß aber der Compiler nicht.
test3 könnte ja auch noch von irgendwo anders aufgerufen werden, zb von 
einer Funktion in test2.c

Der Compiler hat nicht den Überblick über alle *.c Dateien. Er 
compiliert jedes einzelne *.c für sich.
Erst der Linker fügt die Einzelteile zusammen und erzeugt das fertige 
Programm. Und es ist erst der Linker, der feststellen kann, dass eine 
Funktion test3() überhaupt nicht aufgerufen wird und daher auch nicht im 
fertigen Programm nicht auftauchen muss.

Autor: Erik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso, dann sind die generierten Dateien zunächst einmal jeweils einzeln 
erstellt worden und nicht als ganzes zusammenhängendes Projekt. Erst der 
LINKER macht das und gliedert die nicht notwendigen Codeteile aus. Dann 
gibt es wohl auch nicht wirklich eine Möglichkeit die optimierte 
Variante sehen zu können.

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na, am Ende sollte doch wohl irgendein .hex herauskommen und da kannst 
du schon sehen ob es geschrumpft ist.

Autor: Erik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, in der HEX-File ist dann alles drin, aber aus der erkenne ich gar 
nichts mehr heraus. Ich hätte gerne die Veränderungen als Code (C oder 
Assembler) gesehen. Ich dachte nämlich, dass der Compiler alle 
Optimierungen durchführt.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erik schrieb:
> Ja, in der HEX-File ist dann alles drin, aber aus der erkenne ich gar
> nichts mehr heraus.

Musst du auch nicht.
Es reicht, wenn die kleiner wird :-)

> Ich hätte gerne die Veränderungen als Code (C oder
> Assembler) gesehen.

Assembler hättest du eine Chance.
Aber C-Code ist so nicht möglich. Der Compiler optimiert nämlich auf 
viel tieferen Stufen als auf C-Code Ebene. Da werden ganze Statements 
oder Teile davon umgestellt, konstante Ausdrücke herausgezogen, Code 
fällt ganz oder teilweise weg. Doppelte Berechnungen werden zu einer 
zusammengefasst, Variablen eliminiert, etc.

Kurz und gut: Für den Compiler ist der C-Code nur Input. Zwischendurch 
wird der immer wieder umgeformt in Zwischenebenen für die es keine 
C-Entsprechung gibt. Und ganz zum Schluß kommt hinten irgendwann 
Maschinencode raus. Kurz vor diesem Ende findet zb die 
Peephole-Optimization statt, bei der auf Assemblerebene noch einmal nach 
wiederkehrenden Mustern und Vereinfachungen gesucht wird. Da ist man 
aber von der C-Ebene schon so weit entfernt, dass es praktisch unmöglich 
ist, diese Veränderungen auf C-Ebene abzubilden.

Wenn du deine rausoptimierte Funktion suchst, musst du im Linker Map 
File nachsehen. Dort müsste die Funktion nicht mehr aufscheinen.

> Ich dachte nämlich, dass der Compiler alle
> Optimierungen durchführt.

Das tut er auch.
Nur keine Sorge.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.