mikrocontroller.net

Forum: Compiler & IDEs Size Benchmark mit GCC, Imagecraft und IAR


Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Tag allerseits

Da ich mit meinem Imagecraft Compiler schon seit langem etwas
unzufrieden bin und für ein neues Project die Weichen neu stellen
möchte, habe ich mir die Mühe gemacht, die Trial-Versionen von Atman
und Iar zu beziehen und diese untereinander zu testen. Dabei liess ich
die Frage nach der Geschwindigkeit des erzeugten Codes beiseite, da
Geschwindigkeit in meinen Projekten nie eine Rolle spielt.

GCC von Atman (gcc-3.4.5)
Imagecraft (6.31A / prof.)
IAR (4.12A)

Der übersetzte Code enthaelt sogut wie keine Array's im Flash; will
sagen, der ganze Code ist 100% Arbeit für den Controller.
Alle Compiler wurden auf beste Size-Optimierung eingestellt und es
wurde ebenfalls auf C++ verzichtet.
Die erste Ziffer gibt die Grösse für den Controller Atmega8, die zweite
für den Controller Atmega16 in Bytes an. Dabei ist mir aufgefallen, dass
alle Compiler für den Atmega8 einen viel kompakteren Code erzeugen.

     Atmega8   Atmega16
GCC: 7170   /  7604
ICC: 7288   /  7680
IAR: 5950   /  6298


Beim IAR wurde ich misstrauisch und habe den erzeugten Code in das
Geraet geladen: laeuft einwandfrei.

Meine persönliche Entscheidung: Ich werde bei der Auswahl des
Controllers eine Nummer grösser einsteigen und GCC nehmen.

MfG

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
es wäre schön wenn du CodevisionAVR noch in den Test einbeziehen
könntest und dein Programm hier rein stellen könntest also die C
sourcen.

MfG
Sebastian

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Dabei ist mir aufgefallen, dass alle Compiler für den Atmega8 einen
viel kompakteren Code erzeugen."

Bis 8kB werden RCALL und RJMP verwendet, darüber sind alle Calls und
Jumps doppelt so groß (4 Byte).


Daß der IAR deutlich kleineren Code erzeugt, wird wohl daran liegen,
daß er 8Bit Berechnungen auch 8Bittig ausführt. Der GCC dagegen
erweitert oft unnötiger Weise auf 16Bit, z.B. bei switch-Anweisungen.


Peter

Autor: Fabian Scheler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du beim GCC nur die Option -Os verwendet, oder hast du auch
-ffunction-sections bzw. -fdata-sections verwendet (in Kombination mit
-gc-sections beim Linker)?

Ciao, Fabian

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Daß der IAR deutlich kleineren Code erzeugt, wird wohl daran liegen,
> daß er 8Bit Berechnungen auch 8Bittig ausführt. Der GCC dagegen
> erweitert oft unnötiger Weise auf 16Bit, z.B. bei
> switch-Anweisungen.

Außerdem kann der IAR gerade bezüglich der RJMPs einiges optimieren,
d. h. alle JMPs, deren Ziel innerhalb der ±4-KB-Grenze liegt, werden
zu RJMPs gewandelt.  Björn Haase hat etwas ähnliches mittlerweile für
den GCC 4.x vorgestellt, er benutzt es auch bereits in
Produktionscode, ich hab's mir aber noch nicht angesehen.

Der GCC 4.1.0 ist nach meinen Erfahrungen in der Codegröße irgendwo in
der Mitte zwischen dem GCC 3.4.x und dem IAR, insofern wäre es
interessant, den gleichen Code auch noch einmal auf einem GCC 4.1.0 zu
testen.  Mehmet, falls du den Code freigeben kannst, biete ich mich
für einen Test an.  Ich würde mich ggf. auch bereit erklären, den Test
danach noch einmal mit einem gepatchten GCC 4.x mit dem linker
relaxation patch von Björn zu testen.

> Hast du beim GCC nur die Option -Os verwendet, oder hast du auch
> -ffunction-sections bzw. -fdata-sections verwendet (in Kombination
mit
> -gc-sections beim Linker)?

Das bringt bei ordentlichem Code rein gar nichts.  Nur, wenn der
Programmierer nicht wusste, was er alles aufgeschrieben hat, und
dadurch toter Code entstanden ist, kann man damit was rausholen.

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg Wunsch

Also den Code möchte ich nicht public machen, aber waere gerne dazu
bereit, diesen Dir persöhnlich und nur zu Testzwecken zukommen zu
lassen.
Wenn Du mir also Deine email Adressen nennen würdest ...

MfG

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Sebastian

Den Codevision haette ich auch gerne getestet, aber deren Trialversion
ist leider size-limitiert, weshalb ein Test nicht möglich ist.

MfG

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg

"Außerdem kann der IAR gerade bezüglich der RJMPs einiges
optimieren"

scheint sich aber nicht groß auszuwirken, der Unterschied 8kB/16kB ist
bei IAR und GCC etwa gleich (6%).


Peter

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wenn Du mir also Deine email Adressen nennen würdest ...

Nun, Gugel hätte dir sicher mehr als eine erzählt. :)

joerg_wunsch +at+ uriah.heep.sax.de

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg

Mail ist unterwegs ....
Na, bin dann mal gespannt, wie das Resultat ausfallen wird.

MfG

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, ich habe für die Anzahl der scheduler mal eine Hausnummer
eingetragen... aber ich vermute, dass die Codegröße davon nicht
abhängt, nur der RAM-Verbrauch.

Interessanterweise komme ich mit einem ungepatchten GCC 4.1.0 auf
gleiche Größen wie der GCC 3.4.5 dir gebracht hat.

Aber: ich habe mal alle .o-Dateien außer main.o in eine
Bibliothek gestopft und dann beim Linken lediglich main.o
plus diese Bibliothek angegeben, sodass nur die tatsächlich
benötigten Objektmoduln gelinkt werden.  Damit komme ich auf:

ATmega8 ATmega16
6996    7372

Immer noch ein gutes Stück entfernt von den IAR-Werten, aber ich
vermute, du hast noch ein wenig ,,Aufräumpotenzial'', da
offenbar nicht alle Funktionen wirklich benutzt werden.
(-ffunction-sections + -gc-sections hat übrigens nichts gebracht,
erst die Methode mit der Bibliothek.)

Ich werde mir noch Björns linker relaxation Patch mal reinziehen.
Kann aber ein, zwei Tage dauern.

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist richtig, dass einige Funktionen nicht benutzt werden.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Es ist richtig, dass einige Funktionen nicht benutzt werden.

Die werden aber bei GCC trotzdem alle gelinkt, weil du ja alle
.o-Dateien auf der Kommandozeile angegeben hast.  IAR linkt
(vermutlich) nur referenzierte Funktionen.  Die Bibliotheks-
Methode linkt zumindest nur die Objektmodule, die wirklich
referenziert werden (die aber trotzdem noch komplett, also
wenn eine Funktion referenziert wird, wird alles gelinkt).

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst Du bitte die Dateien scheduler.c und standby.c löschen.

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg

Beim Imagecraft hat das Löschen der Dateien zu keiner Aenderung in der
Grösse des erzeugten Codes geführt. Beim GCC gab's aber eine eklatante
Steigerung von 7170 auf 7596 Bytes. (... Kopfkratzen ... )

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich die beiden Dateien lösche, komme ich auf 6940/7372 Bytes
(ATmega8/16).  Mit oder ohne Bibliothek ist dann egal.

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gelten diese Werte für den 4.1 Compiler?
Gilt weiterhin Deine obige Aussage, dass es sogut wie keinen Unerschied
zwischen 3.4.5 und 4.1 gibt?

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Mehmet,
kannst du mit den Code unter:
netforum@gmx.de zukommen lassen?
Ich würde dann mal ein Test mit CodevisionAVR machen.

Sebastian

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Gilt weiterhin Deine obige Aussage, dass es sogut wie keinen
> Unerschied zwischen 3.4.5 und 4.1 gibt?

Ja, zumindest für den ungepatchten.  Björn Haases Patch muss
ich erst noch einbauen.

Autor: Fabian Scheler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit den verschiedenen Größen bezüglich Bibliothek und gelöschten
bzw. nicht gelöschten Source-Files ist klar: wirft man dem GNU Linker
ein Objekt-File hin, wandert es auch in die ausführbare Datei, ob ein
Symbol daraus referenziert wird oder nicht ... bei Bibliotheken ist
dies nicht der Fall.

Zum Thema: -ffunction-sections + -gc-sections
Bei typischen Embedded-Toolchains arbeiter der Linker standardmäßig als
smart Linker, diese beiden Optionen sind hier also stanardmäßig
aktiviert, bei der GNU Toolchain ist dies nicht der Fall. Das Argument
aufgeräumter Code zieht nicht - wenn man etwas implementiert sollte man
immer darauf achten Belange zu trennen, was zusammen gehört sollte  aber
auch in dieselbe Überstzungseinheit wandern (z.B. der Übersichtlichkeit
halber, die Implementierung einer C++-Klasse), man muss aber nicht
unbedingt immer alle Methoden referenzieren, die in einer
Übersetzungseinheit implementiert sind.

Ciao, Fabian

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> (-ffunction-sections + -gc-sections hat übrigens nichts gebracht,
> erst die Methode mit der Bibliothek.)

Das ist seltsam, beim arm-elf-gcc funktioniert das einwandfrei.

Was noch helfen könnte ist -combine mit -fwhole-program.

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.