Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03520.jsonl.gz/1892

Die Aufgabe des Compilers ist die Übersetzung eines für den Menschen lesbaren Quelltextes in einen maschinennäheren Code gleicher Bedeutung. Diese recht einfache Erklärung beinhaltet aber nicht den Umfang dieser Aufgabe. Die Übersetzung eines Quelltextes muss in mehrere Teilaufgaben gegliedert werden. Zunächst müssen die Symbole erkannt, danach die Syntax kontrolliert, darauf die internen Tabellen für die verwendeten Strukturen generiert, die Typenkontrolle durchgeführt und schliesslich der Code erzeugt werden. Für ein Fehlerprotokoll ist unter Umständen ein weiterer Durchgang nötig. Erstaunlicherweise ist übrigens das Weiterlaufen nach einem Fehler eine der schwierigsten Aufgaben des Compilerbauers. Auch sollte der Compiler so absturzsicher wie möglich sein.
Ein Mehrpasscompiler führt jeden Arbeitsgang für sich und einer nach dem anderen aus. Dazu müssen Zwischendateien erzeugt und von jedem Durchgang wieder gelesen werden. Dies führt zu einer langsamen Compilation und, falls im Hauptspeicher zwischengespeichert wird, zu einem erhöhten Speicherbedarf.
Ein Einpasscompiler führt diese Arbeitsgänge parallel aus. Jedes Programmelement, dessen Struktur erkannt wird, wird sofort in Code umgewandelt. Ein Einpasscompiler wird dadurch extrem schnell, ohne dass dem Programmierer Nachteile erwachsen.2.13Einzig alle referenzierten Objekte müssen vor dem Gebrauch deklariert sein.
Der Amiga -Compiler ist ein Einpasscompiler. Der erzeugte Code ist Maschinencode des MC68000, je nach Prozessortyp erweitert um die speziellen Fähigkeiten. Dies bewirkt sehr schnelle Programme. Als Beispiel diene der Compiler selbst, der ebenfalls in programmiert wurde.
Die Quelldateien sind normale Textdateien. Wird ein Definitionsmodul compiliert, erzeugt der Compiler eine Symboldatei. Aus Implementations- oder Programm-Moduln entstehen Objektdateien (Abbildungen 2.2 und 2.3).
Eine Symboldatei dient als Referenz bei einem Import dieses Moduls. Es handelt sich um eine übersetzte Version der Schnittstelle. Um eine vollständige Typen- und Versions-Kontrolle zu ermöglichen, ist ein eindeutiger Schlüssel2.14abgelegt. Importiert ein Modul ein anderes Modul, so wird für die Compilation dessen Symboldatei gelesen. Dies ermöglicht eine vollständige Typenkontrolle.
Objektdateien aus Implementationsmoduln oder aus Programmoduln werden ähnlich behandelt. Bei Implementationsmoduln wird kontrolliert, ob alle in der Definition vermerkten Prozeduren auch implementiert sind. Ebenfalls wird die Gleichheit des Prozedurkopfs in Definition und Implementation geprüft. Die Schlüssel aller importierten Moduln werden vermerkt. So kann beim nachfolgenden Linkvorgang kontrolliert werden, ob die Definition eines importierten Moduls nicht zwischenzeitlich geändert wurde.
Zu jeder Objektdatei wird auch eine sogenannte Referenzdatei erzeugt. Die Referenzdatei enthält Informationen, die in erster Linie vom Debugger benötigt werden. Ausserdem greifen Profiler, Library-Linker und Dekodier-Programme darauf zu. Für die Compilation und den Linkvorgang haben die Referenzdateien keine Bedeutung.
Wird während der Compilation ein Fehler in der Quelldatei gefunden, bricht die Übersetzung nicht ab. Es wird versucht, mit vernünftigen Annahmen weiter zu übersetzen. So können mehrere Fehler des Quelltextes in einem Übersetzungsvorgang gefunden werden. Nicht möglich ist dies allerdings, wenn ein Modul, das in einer Import-Liste verlangt wird, nicht gefunden wird; dann bricht die Compilation ab.
Alle gefundenen Fehler bis zu einem Maximum von 150 Fehlern werden in einer vom Compiler erzeugten Fehlerdatei festgehalten. Die Fehlerdatei hat den Namen der Eingabedatei, erweitert um den Buchstaben ,,E``. Wird beispielsweise das Modul ,,InOut.mod`` übersetzt, so erzeugt der Compiler eine Datei ,,InOut.modE``im gleichen Verzeichnis. Die Fehlerdatei wird dann vom Editor oder vom Fehlerlister eingelesen, um alle Fehler im Klartext anzuzeigen.