Forum: Compiler & IDEs Unterschied zu IAR


von Anton W. (antonwert)


Lesenswert?

Worin liegen Unterschiede zwischen GCC und IAR C Compiler für AVR?
- Sind die erzeugten HEX-Files vom IAR besser als die vom GCC?
- Ist der C Syntax anders?
- Sind die Header Files gleich?

von Μαtthias W. (matthias) Benutzerseite


Lesenswert?

Hi

>- Sind die erzeugten HEX-Files vom IAR besser als die vom GCC?
Anderst: Ja. Besser? Kommt auf die Betrachtungsweise an. IAR erzeugt
wohl besseren (schneller, kleiner) Code als der GCC. Das Verhältnis
Preis/Qualität ist aber beim GCC deutlich besser.

>- Ist der C Syntax anders?
Ja, insbesonder beim Handling von Konstanten im Flash und bei der
ISR-Handhabung.

>- Sind die Header Files gleich?
Die C-Standard-Header sollten es (zumidest in größeren Teilen) sein.
Alles was mit IO und Hardware zu tun hat wird anderst sein.

Matthias

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

> Alles was mit IO und Hardware zu tun hat wird anderst sein.

Nö, nicht so schlimm.  Nachdem vor ca. 5 Jahren GCC nachgezogen hat
und die inp()- und outp()-Notwendigkeit entfallen ist, benutzen
praktisch alle AVR-C-Compiler die von Atmel in den Datenblättern und
Beispielen angwandte Form der direkten Portzuweisung (PORTB = 42; i =
PIND; ...).

Neben den schon genannten Dingen bezüglich memory spaces (RAM
vs. Flash-ROM vs. EEPROM) und Interrupts sind es vor allem
Kleinigkeiten.  So werden beim IAR Interrupts mit __enable_interrupt()
ein- und mit __disable_interrupt() wieder ausgeschaltet, bei avr-libc
nimmt man sei() und cli().

Der IAR erzeugt im Durchschnitt vielleicht 10...15 % kompakteren Code,
wobei ich letztens bei einer zeitkritischen Anwendung feststellen
musste, dass ein GCC mit -O3 zwar nochmal weitere 10 % auf die
Codegröße drauflegt, aber dafür auch ca. 10 % schneller war als der
IAR in seiner schnellsten Optimierung.  Das ist natürlich jetzt alles
andere als repräsentativ, aber vielleicht ein Anhaltspunkt.

Zum IAR wird eine kommerzielle libc von P. J. Plauger (eine der
,,Urgrößen'' von C) mitgeliefert, die wirklich alles abdeckt, was
der
Standard bietet -- bis hin zu einer kompletten Implementierung von
wide chars und einem kompletten EC++ (embedded C++).

Dann gibt es wieder andere Dinge, in denen ein GCC oder eine avr-libc
eindeutig die Nase vorn haben.  Die inline-assembler-Funktionalität
von GCC lässt vermutlich jeden anderen Compiler komplett links liegen,
so kryptisch sie auch zu benutzen sein mag.  Beim IAR kann man dem
asm-Statement keinerlei Parameter (Variablen aus dem C-Programm etc.)
zuweisen, für alles, was über ein einfaches »asm("nop");«
hinausgeht,
begiebt man sich also auf ein ziemliches Glatteis, dass die nächste
Compilerversion intern irgendwas anders tun könnte als die jetzige.
(GCC inline asm ist wahrscheinlich am interessantesten für die
Implementeure der Bibliothek selbst, gar nicht mal so sehr für den
Endanwender.)  Die umfassende generische C-Bibliothek hat auch ihre
Schattenseiten: alles, was AVR-spezifisch wird, kommt eher knapp weg.
So haben die stdio-Funktionen keine vollständigen Satz von
Parallelfunktionen mit angehängtem _P (Formatstring liegt im program
space), besonders die wichtige Funktion vfprintf_P() fehlt.  Andere
der Annehmlichkeiten der avr-libc wie verallgemeinerte Behandlung von
sleep_mode und watchdog fehlen ebenfalls.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

"begibt" schreibt sich natürlich ohne "ie". ;-)

von Michael (Gast)


Lesenswert?

Ein Punkt wäre vielleicht noch erwähnenswert. Beim IAR kann man recht
einfach auf double umschalten. Es wird dann eine andere Lib verwendet,
die dann mit 64-Bit für float/double rechnet. Ist recht schnell.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.