mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Compiler-Qualität allgemein?


Autor: Rolf F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachdem mir beim über 1000 EUR teuren Compiler von IAR aufgefallen ist,
dass der Bugs wie falsche Berechnung von Bitfeld-Größen, kein printf
mit %hu u. %u, kein sscanf von %3s, fehlerhaftes longjmp usw. hat
(wobei es nicht einmal warnings gibt) und nicht einmal kritisches wie
if(a=b) oder sinnloses/offensichtlich falsches wie {a == b} meldet,
interessiert mich ob das im embedded-Bereich normal ist.

Compiler wie gcc / MSPGCC haben solche Bugs und Semantik-Blindheit ja
nicht.

Autor: Frank Linde (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann versuch doch mal den AVRGCC. Soll aber keine Bewertung sein, bin
kein C-Freak.

Gruß, Frank

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für die printf-Formatierung gibt es u.a. folgende Optionen:

Conversion  Argument        Converted      Default  Pre-
 Specifier    Type            Value          Base  cision
   %u       int x          (unsigned int)x    10     1
  %hu       int x          (unsigned short)x  10     1
  %lu       long x         (unsigned long)x   10     1

Dem Linker muß man aber mitteilen, welchen Umfang/Parameter
formatted_write zulassen soll (Codegröße).

>> kritisches wie if(a=b) oder sinnloses/offensichtlich falsches wie
>> {a == b} meldet,
Die 1. Form benutze ich in z.B.: while(c = lese_taste());
Ein Meckern des Compilers würde mich nerven. GCC für den H8S meckert
glücklicherweise auch nicht !
Die 2. Form erzeugt bei mir eine Warnung: expression has no effect

Der Compiler hat auch Macken und Tücken; aber ob alle Deine obigen
Feststellungen zustreffen, weiß ich nicht. Vielleicht sind einige
'Schalter' nicht richtig verwendet. Wenn Du soviel Geld ausgegeben
hast, solltest Du Dich intensiver mit Deiner Investition befassen.

Autor: Rolf F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Für die printf-Formatierung gibt es u.a. folgende Optionen:
> ...

Ja, im Prinzip schon, aber wenn ich %hu oder %u angebe, bekomme ich nur
u ausgegeben; das sprintf vom IAR-Compiler kennt %hu u. %u nicht und
meldet das nicht einmal! Für mich ist sowas Sabotage, denn der
Sourcecode ist korrekt, aber das Ergebnis nicht.
Mit sscanf Datum und Zeit aus _DATE__ und __TIME_ auszulesen ist auch
nicht möglich, obwohl es nicht einmal eine Fehlermeldung gibt!
Da musste ich extra in ein array kopiern, 0x00 einfügen und jede
Variable mit atoi bzw. strcmp einlesen/vergleichen!


> Die 1. Form benutze ich in z.B.: while(c = lese_taste());

Naja, im Prinzip richtig, aber das ist zumindest bei der Zuweisung
einer Variablen fehlerträchtig und sollte eine Warnmeldung produzieren,
denn in 99 % aller Fälle ist das erfahrungsgemäß wirklich ein Fehler,
weil dort a == b gemeint war, aber tatsächlich a = b geschrieben wurd.


> Die 2. Form erzeugt bei mir eine Warnung: expression has no effect

Ja, das bin ich u. a. vom gcc so gewohnt und deshalb hat es mich
erstaunt, dass es überhaupt noch so einen sch*** Compiler gibt, der
zudem teuer ist und ein Dongel verlangt.
Dazu kommt ja noch, dass die IDE von IAR nicht einemal einen
Semantik-Checker enthält! Dass da das Revisionsverwalungssystem fehlt
und Datenmüll im Projekt-File angesammelt werden sind da noch die
geringsten Probleme.

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vorab: ich kenne den IAR-Compiler praktisch nicht.

@Michael:

> Die 1. Form benutze ich in z.B.: while(c = lese_taste()); Ein
> Meckern des Compilers würde mich nerven. GCC für den H8S meckert
> glücklicherweise auch nicht!

Zumindest mit -Wall sollte er es warnen.  Workaround:

while ((c = lese_taste())) ;

Das doppelte Klammerpaar nimmt er als Indikation, daß der
Programmierer das wirklich so wollte.

@Rolf:

> ... das sprintf vom IAR-Compiler kennt %hu u. %u nicht und meldet
> das nicht einmal!

Wohin soll es das dann auch melden?  printf/scanf Formatstrings werden
doch zur Laufzeit geparst.  (OK, dem IAR würde ich zutrauen, daß sie
die Bibliothek mit dem Compiler so eng verflochten haben, daß der
Compiler eigentlich wissen könnte, was in der Bibliothek tatsächlich
implementiert ist.  Bei der deutlich stärkeren Trennung von Bibliothek
und Compiler im GCC aber wäre eine solche Meldung schon viel
schwieriger.)

> Mit sscanf Datum und Zeit aus _DATE__ und __TIME_ auszulesen ist
> auch nicht möglich, obwohl es nicht einmal eine Fehlermeldung gibt!

Für die Fehlermeldung gilt das gleiche wie oben.  Ansonsten: Du mußt
Dir halt bei einem Controller stets gründlich Gedanken darum machen,
was der Compiler aus Deinem Geschriebsel denn überhaupt tun kann.
Meines Wissens legt der IAR konstante Strings (und zu sowas evaluieren
_DATE__ und __TIME_ letzlich) im ROM ab.  Das mußt Du dann dem
scanf() aber auch irgendwie sagen, da es mit an Sicherheit grenzender
Wahrscheinlichkeit standardmäßig seine Strings aus dem RAM parsen
will.  Die Harvard-Architektur des AVR läßt grüßen, für
Compilerhersteller ist das schon nicht so einfach.  Beim AVR-GCC
müßtest Du Dir um Strings im ROM dann stattdessen selbst Gedanken
machen, da der GCC mit Harvard praktisch überhaupt nicht umgehen kann.
Dafür würde Dein Beispiel zwar funktionieren (weil der AVR-GCC auch
konstante Strings standardmäßig in den RAM legt), aber es würde zur
Laufzeit permanent RAM gebunden für die Strings.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Rolf: in frmwri.c werden verschiedene #define verarbeitet
      -DFLOAT_SUPPORT        Full ANSI formatter
      -DNO_FLOATS            Full ANSI except floats
      -DREDUCED_SUPPORT      Reduced 'int' type of converter
Beim Linken wird mit -e_small_write oder -e_medium_write festgelegt, ob
die schlankeren Versionen verwendet werden sollen.

Die IDE verwende ich garnicht: ich schreibe u.a. eine .mak und eine
.xcl (Linkerscript) Datei und starte alles in einem DOS-Fenster, wie
sich das gehört mit cc.bat :-)
Aber die IDE sollte doch selbsttätig eine .xcl erzeugen, die man sich
auch ansehen kann. Da ich auch schon andere Compiler von diesem
Hersteller seit Jahren verwende, habe ich das Glück, auch noch viele
Quellen der .lib zu haben. 'Früher' mußte/konnte man sich seine
bevorzugte .lib noch selber generieren; Dongle gab's auch nicht.
Früher war eben alles besser.

Mein letzter Fehler (den ich gemerkt habe) mit dem Compiler war das
vollständige Wegoptimieren einer Zuweisung 'flag = 1;' in einer
kleinen, überschaubaren Funktion. Funktion war getestet, alles lief,
bis eines Tages mit gewachsener Codegröße das globale 'flag' nicht
mehr gesetzt wurde. Der Fehler zeigte sich selbstverständlich an einer
ganz anderen Stelle. Erst ein 'volatile char flag;' ließ die
Zuweisung wieder auftauchen. Die Frage nach Compiler-Qualität könnte
man auch so formulieren: Wo sind die Schmerzen am geringsten?

Autor: Rolf F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also brauche ich einen Compiler-Test, der longjmp, sscanf, fprintf usw.
testet u. die Bugs auflistet sowie anzeigt, welche Warnungen (z. B. für
{a==b;}ausgegeben werden sollten. Ein Compiler, der bei {a==b;} nicht
einmal eine Warnung ausgibt ist schließlich sinnlos (wenn man nicht
ständig einen Semantik-Checker benutzt); da kann ich ja gleich
Assembler nehmen.
Welche Compiler-Tests gibt es denn?

Autor: Rolf F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich habe mal angefangen und folgenden Minimal-Test geschrieben:

// Minimal compiler test for C compiler.
//
// The compiler MUST produce the warnings like these in the comments
// below if he should be used for programming more than hello world
programs,
// because humans do produce often such semantik errors!

void
main (void)
{
  int a, b, c, d, e, f, g, h;

  if (a = b)         // warning: suggest parentheses around assignment
used as truth value
    c = d << e + f;  // warning: suggest parentheses around + or -
inside shift
  g == h;          // warning: statement with no effect
}


Wie gesagt besteht der gcc diesen Test und der ICC430 vom IAR Embedded
Workbench 1.26A Vollversion (mit Dongle) versagt auch bei allen
aktivierten Warnungen/Fehlermeldungen völlig!
Sowas schrottiges wie ICC430 verkauft ja nicht einmal Microsoft!
Naja, die Berichte von Hardware-Herstellern (TI) sowie in ELV und
FUNKAMATEUR sollte man wohl nie ernst nehem.

Mal sehen was ich an Semantik-Checkern als Workaround für diesen sch***
Compiler nehemn kann.

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.