Liebe Kundin, Lieber Kunde,

Ist ein Compiler wichtig? Was für eine Frage. Klar brauche ich den, um meinen geschriebenen Programmcode zu übersetzen. Sonst „kriege ich den ja nicht zum Laufen“. Ich denke, mit dem Compiler verhält es sich so wie mit jedem Gegenstand des täglichen Gebrauchs, dessen einwandfreie und zuverlässige Funktion man als Selbstverständlichkeit hinnimmt.

So wie mit dem Hammer, den ich brauche, um einen Nagel in die Wand zu schlagen. Neudeutsch nennt man so etwas „Commodity“, eine Ware, so wie jede andere, nichts Besonderes.
Ist er das wirklich?

Unverzichtbare Leistung

Zu dieser Zeit war ein Compiler etwas Avantgardistisches, ein Exot, dessen Tun von jedem Assembler Programmierer mit Argwohn beäugt wurde, weil er mit einer neumodischen Hochsprache (Fortran, Cobol, später C) gefüttert werden wollte, und angeblich korrekten und ausführbaren Maschinencode erzeugen soll. Misstrauisch betrachtete der Experte den „Output“, denn die vertraute Maschinensprache war ja schließlich die Messlatte. Hokuspokus? Aus damaliger Sicht schon.

Es dauerte Jahre bis das Vertrauen in die Arbeitsweise und das Ergebnis der Compilierung das heutige Niveau erreicht hatte. Dabei geht es schon lange nicht mehr nur darum, eine Quellsprache in eine Zielsprache zu übersetzen. Die wesentlichen Architekturmerkmale heutiger Compiler wurden bereits vor mehr als 30 Jahren entwickelt.

Getrieben durch den rasanten Anstieg von embedded Anwendungen in allen Bereichen unseres täglichen Lebens geht es heute vielmehr darum, die Laufzeit des Zielprogramms auf der Zielhardware zu optimieren und dessen Speicherplatzbedarf zu minimieren. Der Leistungsanspruch an heutige Produkte und der Kostendruck treiben diese Entwicklung erbarmungslos an.

Selbst auf einem geräumigen ARM Mikrocontroller spielt die Codegröße eine Hauptrolle, und ist entscheidend bei der Auswahl eines Compilers. Es ist ganz offensichtlich, dass ein Zusammenhang besteht zwischen der Codegröße und der Leistungsaufnahme der Zielhardware. Kleiner Programmcode übersetzt sich direkt zu geringem Energieverbrauch, was gerade in Zeiten hoher Sensibilität für den Umgang mit Energie ein essentieller Punkt ist.

Die Spreu vom Weizen

Die meisten heutigen C/C++ Compiler arbeiten für sich gesehen sehr leistungsfähig, egal ob sie proprietär vom Chip-Hersteller oder von einem unabhängigen Hersteller stammen, egal ob der Compiler Freeware ist oder relativ viel Geld gekostet hat. Die Spreu trennt sich sehr schnell vom Weizen, wenn man sich beispielsweise anschaut, wie ein Compiler für ein bestimmtes Betriebssystem optimiert ist, oder wie kompatibel er mit der gewählten Debug-Lösung ist.

Dann können die tatsächlich auflaufenden Kosten des Freeware-Compilers in Bezug auf Entwicklungszeit und Projektkosten leicht den Anschaffungspreis eines gekauften Compilers übersteigen.

Wichtig in diesem Zusammenhang ist auch die EABI-Norm (Embedded Application Binary Interface), die sicherstellt, das Software-Module mit jedem anderen dieser Norm entsprechenden Modul, auch anderer Hersteller, verlinkt werden können.

Die AEABI-Norm definiert dies für ARM Controller. Damit können zum Beispiel Module, die mit GNU, ARM Realview und der IAR Embedded Workbench erzeugt worden sind, verlinkt werden. IAR Systems war bereits 2007 der erste Hersteller, der mit dem IAR Compiler, Assembler, Linker und Debugger dem ARM EABI 2.0 Standard, basierend auf ELF/DWARF 3.0, erfüllt hatte.

Sind sie sicher? Sind Sie sicher?

Die wichtigste Frage ist: Wie können wir sicherstellen, dass embedded Systeme wirklich sicher sind?

So leistungsfähig die Programmiersprache C auch ist, enthält sie doch verschiedene Bereiche, die nach dem ANSI C Standard explizit als undefiniert deklariert sind, und andere, die von der jeweiligen Implementierung frei definiert werden können.

Will man also ein „sicheres“ C Programm schreiben, reicht es nicht aus, dass das Programm so läuft, wie der Programmierer es sich vorgestellt hat. Es muss immer noch korrekt funktionieren, wenn es auf eine andere Umgebung portiert wird. Wichtig ist auch, dass der Quellcode für andere Programmierer unmissverständlich und eindeutig ist, und keinen Raum für falsche Interpretationen zulässt, was eine große Bedeutung erhält, wenn der Code weiter entwickelt wird.

Um diese Unabwägbarkeiten in den Griff zu bekommen, hat die Motor Industry Software Reliability Association (MISRA) einen Subset der C Programmiersprache definiert, und damit einen konkreten Beitrag zur Sicherheit in der C Programmierung geleistet. Als MISRA C bekannt, ist dieser Subset im „Guide for the Use of the C Language in Vehicle based Software“ definiert.

Dort stehen insgesamt 127 Regeln, die entweder als notwendig oder ratsam bezeichnet werden.

Zum Beispiel verbietet Regel 118 die Ver- wendung von dynamisch zugewiesenem Speicher, Regel 101 sagt, dass keine Pointer-Arithmetik verwendet werden darf, und Regel 102 besagt, dass nicht mehr als 2 Levels von Pointer-Umleitungen verwendet werden sollen.

Um sicheren, MISRA C konformen Code zu schreiben, ist es daher notwendig, ein Werkzeug zu haben, dass die Einhaltung dieser Regeln überprüft. Für die meisten unterstützten Hardwareplattformen hat die IAR Embedded Workbench hierfür einen eingebauten MISRA C Checker, der sich dieser Aufgabe annimmt – für Sie eine Gewähr, auf der „sicheren“ Seite zu sein.

Dabei sollten wir aber das Fundament nicht vergessen, das die Basis für alle Entwicklungen darstellt, und an dessen Qualität nicht sparen. Nicht umsonst sprechen wir ja von einer Toolkette, in der ein leistungsfähiger Compiler ein absolut unverzichtbares Glied darstellt – ohne ihn geht gar nichts.

Herzliche Grüsse,
Ihr

Anmerkung zum neuen Telekommunikationsgesetz (seit 1.03.2006):
Sie erhalten diese Nachricht aufgrund eines bestehenden Kundenkontaktes oder aufgrund einer Anfrage an uns oder einen unserer Partner. Sollten Sie in Zukunft keine Zusendungen mehr von uns wünschen, so klicken Sie bitte auf Unsubscribe in der Fußnote dieser Email. Sie werden unverzüglich aus dem Verteiler genommen.
Impressum: Medieninhaber und Herausgeber: Carnica Technology, A-9620 Hermagor, www.carnica-technology.com, Email: info@carnica-technology.com