mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Vergleich C Compiler


Autor: Sebastian__ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich möchte jetzt ein paar Projekte mit verschieden AVR Controller in C
realisieren.
Welche der Folgenden C Compiler ist der Beste, für mich spielt die
Codezize und Workingspeed gefolgt von der unterstützung der
verschiedenen Controller ung Qualität der IDE eine Rolle.
Alles mal abgesehen vom anschaffungspreis der Compiler.

1. AVRGCC
2. CodeVision AVR Prof.
3. ImageCraft AVR C

Wo liegen die vor und nachteile dieser Compiler? Gibt es irgendwo
Benchmarkes? So in etwa auf jedem Compiler der selbe C code und dann
messen welcher am schnellsten ist und welche Codezize am geringsten
ist.
Ich habe bis jetzt zu 80% alles in ASM gemacht und komme damit auch
sehr gut zurecht, aber die entwicklungszeit der SW ist doch sehr lang
im vergleich zu einer SW die man teilweise in C schreiben kann.

Danke

MfG
Sebastian

Autor: BAB (Kai K.) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mach dir selbst ein bild...es gibt von allen testversionen

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
einen effektiven Vergleich kann es gar nicht geben, jeder wird Stärken
und Schwächen haben, den ultimativen besten wird es nicht geben. Es
kann sein, du wählst Testbedingungen, in der ein Compiler besondere
Schwächen hat und besondere Vorzüge gar nicht zum Tragen kommen -
Ergebnis: Compiler ist Sch...
Stimmt aber gar nicht, mit anderen Testbedingungen hätte es ganz anders
ausgesehen. Ausserdem sind Compiler immer Baustellen, welche mit jedem
feedback von den usern besser wird, kein Programmierer kann von Hause
aus optimale Algorithmen einbauen.
Bei mir stand die Wahl zwischen CodeVision und IAR, CodeVision hat mir
sehr zugesagt, letztendlich war auch der Preis ein Argument.

Autor: Sebastian__ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sagen wirs mal anders, wo liegen den die vor und nachteile von
bestimmten compilern, die bekommt man ja meist erst nach einiger zeit
und intensiver benutzung mit. Was mich zb. an GCC etwas stört bzw. was
es in meiner gunst sinken lässt ist die unübersichtlichkeit der
Biblioteken und dern handling, zum mal was basteln is es ja ok, aber
wenn man was ernsthaftes machen will muss man sich ja wenigstends auf
eine komponente verlassen können und nicht noch im compiler ständig
nach fehlern suchen.
Bei der Effizienz der Compiler geht es mir Hauptsächlich darum wie gut
sie zb. ein paar verschatelte Schleifen auflösen und eine Handvoll
signed Integer Operationen, hat schon mal jemand getestet wie groß da
die unterschiede zw. den Compilern sind?

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

Bewertung
0 lesenswert
nicht lesenswert
Was meinst du mit "Unübersichtlichkeit der Bibliotheken", und von
welchen Fehlern sprichst du?

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nö, habe ich nicht, da wird der Unterschied auch nicht besonders groß
sein, das ist trivial.
Deutliche Unterschiede wird vielleicht bei komplizierten math.
Funktionen mit float-Variablen geben, da könnte ich mir schon
vorstellen, dass es da ein paar 100 Takte Unterschied gibt, die
vielleicht bei der nächsten Funktion wieder wettgemacht werden. Wenns
aber so eng wird, dass das einem Design den Garaus macht, hat von
Anfang an zu eng (oder gar nicht) geplant.
Codegröße und Laufzeit kann man auch selbst stark beeinflussen, da
gibts einmal die Compileroptionen und zum anderen die eigene
Programmierweise.

Autor: Sebastian__ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas
ich finde zwar diesen Open Source gedamken toll, aber meines erachtens
ist der GCC für mich nicht übersichtlich genug, desweiteren treten
zwischen mit verschiedenen Versionen von Compilierten inkopatiblitäten
und die seltsammsten Fehler auf, die werden zwar dann nach und nach
ergründet, aber das ist dann auch kein Trost wenn man schnell ein
Ergebniss abliefern muss.
Ich werde mir jetzt mal selbst ein Bild davon machen inwiefern die
3Compiler meinen Anforderungen gerecht werden.

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

Bewertung
0 lesenswert
nicht lesenswert
Von Inkompatiblitäten ist mir nichts bekannt. Die Funktionen inp(),
outp() und noch ein paar andere wurden für veraltet erklärt, ein paar
.h-Dateien wurden umbenannt, aber trotzdem kompilieren meine alten
Programme noch (zwar mit Warnungen, aber sie kompilieren). Mag sein
dass es beim Umstieg von gcc-2.95 auf 3.0 Probleme gab, aber vor 3.0
war der AVR-GCC sowieso nicht viel mehr als beta. Und leider haben
viele die uralten Windows-Versionen von http://8bit.at/avr/ und
avrfreaks.net noch lange weiterverwendet.

Im Moment ist der Compiler jedenfalls sehr gut benutzbar, die Libraries
sind ausgereift, und der Support ist super. Allerdings haben viele
Windows-User nach wie vor Probleme. Was für einen Unixer
selbstverständlich ist, kann für einen Windows-User völlig
unverständlich sein...

Autor: hebel23 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da muss ich Dir Recht geben. Ich habe zwar erst vor ca. 2 Monaten mit
dem AVRGCC angefangen (Version 3.3), bin aber sehr zufrieden damit. Die
Dokumentation ist sehr übersichtlich und der erzeugte Code ist
erstaunlich effizient. Besonders begeistert mich die Mathelibrary, mit
der man auch höhere mathematische Funktionen problemlos implementieren
kann. Ich habe die AVR´s bisher wegen der üblichen Vorurteile auch nur
mit Assembler programmiert, werde das aber in Zukunft nur noch in
Ausnahmefällen tun. Die anderen Compiler kenne ich (noch) nicht.

Gruß Andreas

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vorab:
Ich würde Dir den AVRGCC nahelegen; da bekommst Du hier die beste
Unterstützung.

Da Du schon Assembler programmiert hast, sind die beiden anderen
Compiler nicht so interesant für Dich. Mit denen kann man aber gut
lernen (wie man es nicht macht).

Z.B.: long i; for(i=0;i<70000;i++);
Ein Compiler zeigt Dir ganz genau wie es geht:
Unterprogramm aufrufen, um i mit 0 zu laden
Schleife:
{
  Unterprogramm aufrufen, um 70000 zu laden
  Unterprogramm aufrufen, um Vergleich durchzuführen
  Unterprogramm aufrufen, um i zu inkrementieren
}
Das braucht dann so seine 100 Byte und viel, viel Zeit.

Der andere Compiler zeigt Dir das Gegenteil:
Bei jeder Zuweisung long -> float wird hier 'schneller' Inline-Code
erzeugt. Jedesmal. Ein Unterprogramm würde ja den Lerneffekt
verhindern.

Einer der Compiler optimiert den erzeugten Code am Ende noch einmal.
Nur, wenn man einen µP mit 8K Flash angegeben hat und vor der
Optimierung 8,1K generiert wurden, gibt es keine Optimierung, sondern
Fehler.
Einer schafft bei float Berechnungen nur fünf gültige Stellen: mager.

Persönlich verwende ich den, den crazy horse nicht genommen hat. Der
optimiert teilweise so gut, daß selbst relevante Anweisungen
verschwinden. Aber nicht sofort, sondern erst wenn die Routine
erfolgreich getestet wurde und das Programm anschließend weiter
wächst.

Fazit: s.o. und Du kommst nicht umhin, Dich mit dem Compiler Deiner
Wahl intensiv auseinanderzusetzen, vor und nach der Anschaffung.

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was willst du damit eigentlich sagen, soll der Compiler so arbeiten,
dass man das Listfile noch versteht (wegen Lerneffekt und so)  oder
soll effektiver Code erzeugt werden?
Habe dein obiges Schleifenbeispiel mal mit CodeVision compiliert:
         ;      84  for(i=0;i<70000;i++);
000056 27ee        CLR  R30
000057 93e0 0084   STS  _i,R30
000059 93e0 0085   STS  _i+1,R30
00005b 93e0 0086   STS  _i+2,R30
00005d 93e0 0087   STS  _i+3,R30
          _0x2D:
00005f 91a0 0084   LDS  R26,_i
000061 91b0 0085   LDS  R27,_i+1
000063 9180 0086   LDS  R24,_i+2
000065 9190 0087   LDS  R25,_i+3
000067   +    __CPD2N 0x11170
000067 37a0        CPI  R26,LOW(0x11170)
000068 e1e1        LDI  R30,HIGH(0x11170)
000069 07be        CPC  R27,R30
00006a e0e1        LDI  R30,BYTE3(0x11170)
00006b 078e        CPC  R24,R30
00006c e0e0        LDI  R30,BYTE4(0x11170)
00006d 079e        CPC  R25,R30
            .ENDM
00006e f4ac        BRGE _0x2E
00006f 91e0 0084   LDS  R30,_i
000071 91f0 0085   LDS  R31,_i+1
000073 9160 0086   LDS  R22,_i+2
000075 9170 0087   LDS  R23,_i+3
000077   +    __SUBD1N -1
000077 5fef        SUBI R30,LOW(-0x1)
000078 4fff        SBCI R31,HIGH(-0x1)
000079 4f6f        SBCI R22,BYTE3(-0x1)
00007a 4f7f        SBCI R23,BYTE4(-0x1)
            .ENDM
00007b 93e0 0084   STS  _i,R30
00007d 93f0 0085   STS  _i+1,R31
00007f 9360 0086   STS  _i+2,R22
000081 9370 0087   STS  _i+3,R23
000083 cfdb        RJMP _0x2D

sehe da nicht viel weitere Optimierungsmöglichkeit, allenfalls die
Schleifenvariable direkt in Registern statt im SRAM abzulegen, dass
macht CodeVision mit long-Variablen prinzipiell nicht, selbst wenn noch
freie Register da wären. Wie löst IAR das Beispiel?

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

Bewertung
0 lesenswert
nicht lesenswert
Mit so einem "Programm" Compiler vergleichen zu wollen, ist völlig
sinnlos, eine leere for-Schleife hat doch keinerlei Funktion.

Nur eine Sache die mir aufgefallen ist:

000077 5fef        SUBI R30,LOW(-0x1)
000078 4fff        SBCI R31,HIGH(-0x1)

Der GCC macht stattdessen einfach "adiw R30, 1".

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit welchem Compiler ich welches Verhalten hatte (s.o.) weiß ich nicht
mehr. Ich war 'bedient' und hatte beide wieder von der Platte
entfernt.

So sieht das bei mir aus, wobei ich eine while-Schleife nehmen mußte,
um ein Inkrementieren zu erzwingen. Bei for wird optimiert, indem i mit
dem Endwert geladen und bis 0 gezählt wird. Da ich die Schleife in ein
ATmega-Programm gesteckt habe, werden die MOVW eingesetzt.

Nun gut, beim AVR wird man keine char feld[10000] löschen wollen
(können). Aber eine langsame Schleife wird auch nicht schneller, wenn
sie mit Inhalt gefüllt wird.

    946          void verz()
    947          {
    948          long i=0;
   \                     verz:
   \   00000000   E040                 LDI     R20,0
   \   00000002   E050                 LDI     R21,0
   \   00000004   E060                 LDI     R22,0
   \   00000006   E070                 LDI     R23,0
    949            while(i++ < 70000);
   \                     ??verz_0:
   \   00000008   018A                 MOVW    R17 : R16,R21 : R20
   \   0000000A   019B                 MOVW    R19 : R18,R23 : R22
   \   0000000C   5F4F                 SUBI    R20,255
   \   0000000E   4F5F                 SBCI    R21,255
   \   00000010   4F6F                 SBCI    R22,255
   \   00000012   4F7F                 SBCI    R23,255
   \   00000014   3700                 CPI     R16,112
   \   00000016   4111                 SBCI    R17,17
   \   00000018   4021                 SBCI    R18,1
   \   0000001A   4030                 SBCI    R19,0
   \   0000001C   F3AC                 BRLT    ??verz_0
    950          }
   \   0000001E   9508                 RET

Wenn Ihr Lust habt, ein reales Programm zu vergleichen, hier eine
Vorgabe. http://www.mino-elektronik.de/fmeter/fm_software.htm
Wenn alles gut geht, läuft es auf einem 2313.

Autor: Michael (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Da ich noch einen 'alten' Compiler wiedergefunden hatte (ImageC), habe
ich in ein Demoprogramm '8515intr' die besagte Schleife eingefügt.
Das Listing besser als Anlage. Ob man auf min. Code oder max. Speed
einstellt ändert nichts an der prinzipiellen Vorgehensweise. Soll jeder
für sich bewerten, ob die Codeerzeugung in seinem Sinne und
empfehlenswert ist.

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

Bewertung
0 lesenswert
nicht lesenswert
Wie schon gesagt, ich finde so eine leere Schleife völlig ungeeignet für
Compilervergleiche. Manche Compiler werden z.B. erkennen dass in der
Schleife nichts passiert und sie einfach durch i=70000 ersetzen,
teilweise "aufrollen" (so ähnlich macht es der GCC) usw.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas:
Hast Du vielleicht mein o.g. Programm durch AVRGCC 'mal compiliert ?
Das würde mich interessieren und doch auch mehr zeigen.

Natürlich ist eine Bewertung eines Compilats eine andere Sache, aber
irgendwo muß man doch versuchen, eine Bewertung anzusetzen. Oder ist
und bleibt das ein Tabu ?

Autor: Matthias (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi

habs eben mal probiert.
Nachdem ich den AVRGCC dann davon überzeugen konnte das Ding mit
diversen Warnings zu kompilieren warf er eine Codegröße von etwa 5700
Byte aus. War aber bei der Verwendung von float als Datentyp zu
erwarten. Da ist der AVRGCC AFAIK noch nicht besonders gut optimiert.
Außerdem hab ich das flash als Speicherort einfach entfernt und die
Variablen somit ins RAM verlagert. Im Anhang mal die Datei die mit ein
paar warnings vom GCC compiliert wird.

Matthias

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Matthias, obwohl die Größe etwas heftig ist. In wager Erinnerung
ist mir bei ImageC so ca. 2,5K, bei CodeV etwas weniger.

GCC habe ich sonst bei 68K und H8S eingesetzt; dort sieht der Code sehr
gut aus und ist geschickt optimiert. Die 8-Bitter sind eben etwas
anders zu handhaben als die dickeren µPs.

Autor: Matthias (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi

könntest du mal das angehängte Programm (auch eine Art Frequenzzähler)
durch den IAR jagen?

Matthias

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@Michael: mit diesem Code misst man wohl weniger die Optimierung des
Compilers als die Größe der Float-Bibliothek. Ungelinkt braucht das
Programm 1214 Byte.

@Matthias: leider fehlt zum Kompilieren die code.h.

Wo wir gerade so schön am Compiler-Vergleichen sind: im Anhang ist das
nächste Testobjekt. Bitte nur kompilieren, nicht linken (Option -c beim
gcc).

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ergebnis

Autor: Matthias (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi

@Andreas
du meinst die tools.h

Matthias

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

Bewertung
0 lesenswert
nicht lesenswert
Natürlich (wie komm ich nur auf "code")?

Hier ergibt das Programm 1304 Byte.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

was zu erwarten war. Sind bei mir auch genau 1304 Byte. (aktuelle
WINAVR) Merkwürdigerweise braucht der 3.3er GCC den ich gestern unter
Linux compiliert hab ein paar Byte mehr.

Matthias

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

Bewertung
0 lesenswert
nicht lesenswert
Hast du den aktuellen Snapshop runtergeladen oder den 3.3 Release?
Meinen habe ich heute aus der aktuellsten Version kompiliert.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

mit dem aktuellen Snapshot (gcc 3.3 vom 21.7.2003) sind es ganau 4 Byte
mehr als mit dem WINAVR. Kann das evtl. an einer anderen avrlibc
liegen?

avr-libc-20030512cvs.tar.gz

Matthias

Autor: Michael (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, Matthias zuerst.
Die BIT0_POS +++ habe ich einfach nur nach Gutdünken definiert.
eeprom_read + eeprom_write habe ich nur als external deklariert und
nicht eingefügt und nichts gelinkt. Dafür alles auf max. speed für
einen 2313 eingestellt.
Ohne zu linken erzeugt meine Quelle fm.c bei mir 1022 Byte.

Ich finde es angenehm und würde es weiter begrüßen, die vorliegenden
Beispiele ohne Hickhack und Geschrei zu behandeln. Es ist viel Aufwand,
wenn sich jeder immer alle Demos für eigene Versuche installieren muß.

Daß AVRGCC soviel 'fließenden' Code dazulinkt, ist merkwürdig. Es
werden nur FMUL + FDIV gebraucht. Offensichtlich ist die Bibliothek zu
'grob' angelegt. Bei dickeren ATmegas ist das in der Regel belanglos.

Autor: Michael (Gast)
Datum:
Angehängte Dateien:
  • gcd.s90 (1013 Bytes, 120 Downloads)

Bewertung
0 lesenswert
nicht lesenswert
Andreas:
Anbei das Ergebnis zu dbg.c. Die erweiterten Befehle zu ATmega sind
nicht aktiviert; wenn doch, dann werden es zwei Byte weniger (MOVW bei
gcd_3:)

Vielleicht hat Crazy Horse noch etwas compiliert.

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.