NACH EINER KURZEN ERLÄUTERUNG DER FUNKTIONSWEISE EINES INTERPRETERS UND COMPILERS SOLL SCHWERPUNKT-MÄSSIG AUF DEN LINKER EINGEGANGEN WERDEN, DER LETZTENDLICH EIN ABLAUFFÄHIGES PROGRAMM ERZEUGT. EIN SOLCHER LINKER FÜR DAS GST-FORMAT, DER MIT DEM LATTICE C-COMPILER ENTSTAND. LIEGT ALS LISTING VOR.

Sicherlich weiß jeder, der in höheren Programmiersprachen programmiert, darüber Bescheid, daß der Computer diese Sprache nicht so ohne weiteres versteht. Er akzeptiert nämlich nur Anweisungen in seiner Maschinensprache, Auch allgemein besannt dürfte sein, daß dies beim ATARI ST die Maschinensprache des 68000-Prozessors ist. Solche Maschinensprachen sind für den Menschen beinahe unlesbar, denn die Maschinenbefehle sind allesamt durch Zahlen codiert, deren Bedeutung man in einer Tabelle nachschlagen kann. Dies sann man auch einem Assembler überlassen, dadurch wird die Maschinensprache Lesbarer und leichter anwendbar. Der Assembler übersetzt zum Beispiel Texte wie 'ADD # 1,D0’ in den codierten Maschinenbefehl $5240.

Aber auch in einer solchen Assemblersprache ist das Programmieren noch recht | mühselig. Man stelle sich etwa die Auswertung eines Ausdrucks, wie zum Beispiel z=3*(x+y), vor. In der 68000-Assemblersprache hätte man dazu etwa folgendes zu schreiben:

Die Schreibweise z=3*(x+y) ist eben doch : um einiges verständlicher. Deshalb existieren verschiedene höhere Programmiersprachen, die es ermöglichen, Programme in bedeutend lesbarerer Form zu schreiben. Allerdings müssen diese Programme, bevor sie ausgeführt werden, in die für den I Computer verständliche Form gebracht werden. Dafür gibt es grundsätzlich zwei Möglichkeiten, nämlich Interpreter und I Compiler.

Der Interpreter

Bekanntestes Beispiel dafür ist sicherlich der BASIC-Interpreter. Ein Interpreter durchläuft den Programm-Quelltext, analysiert dabei Befehl für Befehl und führt entsprechende Aktionen durch. Bei einer Zuweisung ‘neu=alt’ passiert etwa folgendes:

Das Wort ‘neu’ wird Buchstabe für Buchstabe gelesen, so lange, bis das '=’ Zeichen erreicht ist. Dann wird in einer Variablentabelle, die der Interpreter anlegt, nach der Variablen ‘neu’ gesucht. Ist diese gefunden, wird das Wort ‘alt’, wieder Buchstabe für Buchstabe gelesen und in der Variablentabelle nach ‘alt’ gesucht. Nachdem auch diese Variable gefunden wurde, kann der Wert von ‘alt’ auf die Variable 'neu' kopiert werden.

Wie man sieht, verlangt selbst eine einfache Zuweisung eine Menge Arbeit vom Interpreter. Stellt man sich nun noch vor. daß diese Zuweisung innerhalb einer Schleife stattfindet, kann man erahnen, warum Interpreter oft so langsam sind.

Der Compiler

...geht einen anderen Weg. Er analysiert den Quelltext nur einmal und übersetzt ihn vollständig in ein Maschinenprogramm. Dabei wird jeder Variablen eine Speicheradresse zugeordnet, und die Zuweisung ‘neu=alt’ wird beispielweise in den Maschinenbefehl ‘MOVE 1000,1002’ übersetzt, wobei 1000 der Speicherplatz für die Variable ‘alt’ und 1002 der Speicherplatz für die Variable ‘neu’ ist. Man kann sich jetzt leicht vorstellen, wieviel schneller das Programm wird, wenn es compiliert ist.

Grundsätzlich teilt man den Compilationsprozeß in drei Schritte ein, nämlich in lexikalische Analyse (Scanning), syntaktische Analyse (Parsing) und die Codeerzeugung (Code Generation). Häufig, aber nicht immer, können diese drei Phasen in einem einzigen Durchlauf (Pass) parallel durchgeführt werden. Beispiele dafür sind Sprachen wie PASCAL oder C. Obwohl bei PASCAL und C grundsätzlich möglich, wird der Compiler trotzdem oft in mehrere Phasen eingeteilt, um Speicher zu sparen. Die Kommunikation der Phasen untereinander erfolgt dann durch Zwischenfiles. Doch nun zur eigentlichen Arbeit des Compilers:

In der lexikalischen Analyse wird der Quelltext eingeteilt in Symbole wie Konstanten, Namen, Schlüsselwörter, Begrenzungszeichen und Operatoren, Kommentare werden eliminiert. Gleichzeitig werden Namen stabeilen mit Variablen-, Konstanten-, Prozedumamen oder ähnlichem aufgebaut.

Die syntaktische Analyse arbeitet nicht mehr mit einzelnen Zeichen, sondern mit den vom Scanner gelieferten Symbolen. Dabei wird die eigentliche Syntaxprüfung vorgenommen, also die richtige Stellung der Schlüsselwörter, Strichpunkte etc. Der Parser liefert auch die Basis für die nachfolgende Codeerzeugung.

Die Codeerzeugung liefert im Prinzip ein lauffähiges Maschinenprogramm, es heißt jetzt Objektcode und wird in einer Objektdatei abgelegt. Dieses Programm kann noch - möglicherweise vom Compiler selbst - optimiert und danach vom Linker zum endgültigen Programm verarbeitet werden. Doch wozu nun noch der Linker?

Aufgaben des Linkers

Wie gesagt, ist das vom Compiler erzeugte Programm für sich alleine noch nicht lauffähig. Es befinden sich darin beispielsweise Unterprogrammaufrufe, die noch keine richtige Sprungadresse enthalten. Schreibt man in C etwa ‘printf(0)', so übersetzt der Compiler dies sinngemäß in folgendes Maschinenprogramm:

Das heißt im Klartext: Bringe die ‘0’ als Parameter auf den Stack, rufe dann das Maschinenprogramm ‘printf’ auf und bringe anschließend den Stack wieder in Ordnung. Nun weiß der Compiler aber noch gar nicht, wo das ‘printf’-Programm sich im Speicher befinden wird, deshalb kann er den JSR-Befehl nicht mit einer vernünftigen Adresse versorgen. Statt-dessen setzt er an dieser Stelle eine Mitteilung an den Linker ein, so daß dieser die fehlende Adresse ergänzen kann.

Erst der Linker weiß ja, wo sich das ‘printf’-Programm letztendlich befindet, denn er verbindet das compilierte Programm mit den entsprechenden Libraries (Bibliotheken), wo unter anderem auch das ‘printf-Unterprogramm versteckt ist. Dasselbe passiert, wenn man in einem Programm externe Variablen verwendet, die in einem anderen Quelltext definiert sind. Auch hier sind die endgültigen Adressen nur dem Linker bekannt. Das wäre dann auch schon die wichtigste Aufgabe des Linkers, aber er tut noch etwas mehr.

Beim TOS werden Programme in drei Bereiche aufgeteilt, TEXT, DATA und BSS. Der TEXT-Bereich (oder TEXT-Section) sollte immer Maschinenbefehle enthalten; der DATA-Bereich (oder DATA-Section) sollte Daten enthalten, darunter versteht man vordefinierte Felder, Stringkonstanten und so weiter; der BSS-Bereich (-Section) schließlich enthält Undefinierte Daten (leere Variablen oder Felder). Da die Daten im BSS-Bereich Undefiniert sind, ist es nicht nötig, sie auf Diskette abzuspeichern. Das Betriebssystem reserviert beim Start des Programms den nötigen Speicherplatz und besetzt ihn einfach mit Nullen vor.

In den Objektdateien, dazu gehören natürlich auch die Bibliotheken, sind die Einträge in die verschiedenen Sections bunt durcheinandergewürfelt und müssen vom Linker sortiert werden. Am Ende entsteht also eine große TEXT-Section, eine große DATA-Section und eine große BSS-Section. Nun aber ins Detail, und damit zum GST-Format:

Das GST-Obiectfile-Format

Das GST-Format entspricht gewissen Syntaxregeln, die vom Linker analysiert und überprüft werden. Der Linker arbeitet also genauso wie ein Compiler, nur die Syntaxregeln sind bedeutend einfacher. Diese Syntaxregeln sehen in Backus-Naur Form wie folgt aus:

Die geschweiften Klammern deuten eine beliebige Wiederholung eines Elements an, auch nullmal ist erlaubt. Die eckige Klammer bedeutet null- oder einfaches Auftreten eines Elements. Der senkrechte Strich heißt “oder”.

Man sieht, daß ein Objektfile aus beliebig vielen Modulen bestehen kann. Wenn man ein normales Programm compiliert oder assembliert, entsteht ein Objektfile, das genau ein Modul enthält. Eine Library besteht im allgemeinen aus mehreren Modulen. Man kann sich Libraries selbst erzeugen, indem man mehrere Objektfiles aneinanderhängt.

Ein Modul beginnt mit einem -Kommando, gefolgt von beliebig vielen < chunk >s und endet mit einem -Kommando. Zum < string > ist noch zu sagen, daß das erste Byte die Länge des Strings angibt und dann entsprechend viele Zeichen folgen. Innerhalb eines < chunk >s stehen neben Symboldefinitionen und Referenzen die eigentlichen Datenbytes für eine Section. Im GST-Format sind beliebig viele Sectionnamen erlaubt, nicht nur TEXT, DATA und BSS. Ein ist ein Kommentar, der keine weitere Bedeutung hat. Mit < xdef > wird ein Symbolname(< string >) definiert, wobei den Wert des Symbols bezüglich des Sectionstarts der Section angibt. Es wird hier nicht vom Namen der Section Gebrauch gemacht, sondern von einer , die mit dem -Kommando dem Namen zugeteilt wird. Diese Vorgehensweise soll das Auftauchen immer wieder gleicher Namen im Objektfile vermeiden und so Speicher sparen. Negative s gehören zu Sectionnamen, positive < id >s zu normalen Symbolnamen und die Null bedeutet im < xdef >-Kommando, daß ein absolutes Symbol definiert

wird. Das < section >-Kommando legt fest, welcher Section die nachfolgenden Datenbytes zugeordnet werden sollen, es muß deshalb immer vor dem Auftauchen irgendwelcher Datenbytes stehen. Das -Kommando bestimmt eine absolute Adresse, ab der die Datenbytes abgelegt werden. Das -Kommando entspricht ziemlich genau dem < section >-Kommando, allerdings werden die folgenden Datenbytes nicht an die bereits vorhandene Section angehängt, sondern diese wird durch die neue Definition überschrieben und, falls der neue Bereich länger als der alte ist, verlängert. Mit dem < offset >-Kommando kann man eine bestimmte Position innerhalb der momentanen Section anwählen, von der ab dann die noch folgenden Datenbytes eingetragen werden. Das < xref >-Kommando trägt nun einen Symbolwert, beziehungsweise einen Wert der durch Additionen und Subtraktionen von Symbolwerten entsteht, an der augenblicklichen Position ein. Der Wert ergibt sich aus dem konstanten -Wert und die durch die folgenden s gegebenen Symbolwerte, die bei < op >='+' addiert und bei < op >=’-’ subtrahiert werden. Die spezielle Null hat hier die Bedeutung der augenblicklichen Position im Gesamtprogramm. Das Ergebnis kann nach der Berechnung als Byte, Wort oder Langwort verwendet werden, außerdem kann es vorzeichenbehaftet und sogar noch relativ zur augenblicklichen Position sein. Über diese Möglichkeiten gibt das im < xdef >-Kommando enthaltene Auskunft, die Bits dieses Bytes haben, falls sie gesetzt sind, folgende Bedeutung:

Bit 0 : Das Ergebnis ist ein Byte.
Bit 1 : Das Ergebnis ist ein Wort.
Bit 2 : Das Ergebnis ist ein Langwort .
Bit 3 : Das Ergebnis ist vorzeichenbehaftet .
Bit 4 : Das Ergebnis ist vorzeichenlos .
Bit 5 : Das Ergebnis ist PC-relativ zu interpretieren.
Bit 6 : Das Ergebnis benötigt zusätzliche Relozierung nach dem Laden, das heißt, es muß in eine Tabelle ein getragen werden, die sich am Ende des Programm-Files befindet, und die das Betriebssystem zur endgültigen Anpassung des Programms an die endgültige Startadresse benötigt.

Dazu jetzt ein kleines Beispiel in C :

Der LATTICE C-Compiler erzeugt daraus folgendes Programm:

Das zugehörige Objektfile sieht so aus:

Dazu folgende Erläuterungen: XDEF MAIN 0 -1 heißt, daß das Symbol MAIN den Wert 0 relativ zur Section -1 hat. Aus den vorangegangenen DEFINE-Kommandos erkennt man, daß -1 die TEXT-Section ist. Das Kommando XREF 0 54 + 6 heißt: Trage den Wert 0 plus den Wert des Symbols 6 als vorzeichenloses Langwort, mit Eintrag in die ‘Runtime-Relocation-Table", an der momentanen Programmposition ein. Symbol 6 ist, wie man am darüberliegenden DEFINE erkennt, das PRINTF-Symbol. Damit ist der JSR-Be-fehl vollständig mit der richtigen Adresse versorgt. Die Sections DATA. UDATA und DEBUG, die zwar per DEFINE erwähnt sind, erhalten keine Daten. Doch nun zum Linker selbst:

Die Arbeitsweise des Linkers LINK

Der hier vorgestellte Linker verarbeitet alle Objektfiles in einem Durchlauf (Pass) und erstellt das lauffähige Programm im Speicher. Der dazu nötige Speicherbereich ist auf 100 Kbyte festgelegt, kann aber per Option (fast) beliebig vergrößert oder verkleinert werden. Nach Fertigstellung des Programms im Speicher wird dieses auf Datei geschrieben. Der Aufbau des Programms aus den Objektfiles geschieht wie folgt:

Für jedes Sprachelement des Objektfiles steht im Programm genau eine Prozedur, die eben dieses Sprachelement analysiert, dies sind die Prozeduren:

Diese Prozeduren rufen sich den Syntaxregeln entsprechend gegenseitig auf. Diese Methode findet sich auch in vielen Compilern wieder; ein Compiler, der nach diesem Prinzip arbeitet, heißt ‘Recursive-Descent-Compiler". Da wir nun schon bei der Analogie zum Compiler sind, sei noch folgendes erwähnt: Scanner, Parser und Codegenerator arbeiten ineinander verschränkt, der Linker benötigt also nur einen einzigen Pass. Der Scanner ist realisiert in der Prozedur ‘nxsy’, die die Bytefolgen aus dem Objektfile in syntaktische Einheiten zerlegt. Diese Einheiten spiegeln sich in der Typdefinition von ‘DIRECT" wieder. Der Parser besteht genau aus den obengenannten Prozeduren, die nicht mehr mit den Datenbytes, sondern mit den vom Scanner gelieferten Einheiten arbeiten. Diese Prozeduren bewerkstelligen auch zum größten Teil die Codeerzeugung, das heißt, sie bringen die aus den Objektfiles ankommenden Sections in die endgültige Reihenfolge. Gleichzeitig bauen sie ein nicht unerhebliches Tabellenwerk auf, das das Auffinden Von Symbolen, Sections, Modulen und s ermöglicht.

Erst nach dem Einlesen sämtlicher Objektfiles sind (hoffentlich) alle Symbole definiert, und die aufgetretenen s können berechnet werden. Diese Berechnung geschieht in der Prozedur ‘all_xrefs\ die ihrerseits die Prozedure ‘calc_xref’ zur Bearbeitung eines s benutzt. In ‘all_xrefs’ entsteht auch die “Runtime-Relocation-Table”, die Tabelle also, die es dem Betriebssystem ermöglicht, das Programm an jede beliebige Position im Speicher zu verschieben. Die Prozedur ‘debug_table’ hängt, falls gewünscht, an das Programmfile noch die gesamte Symboltabelle an, die von einem symbolischen Debugger weiterverwendet werden kann. Das fertige Programm wird von der Prozedur ‘write_prog’ auf Datei geschrieben.

Bei Libraries gibt es nun die Besonderheit, daß die in ihr enthaltenen Modulen nur hinzugelinkt werden, wenn dort Symbole definiert sind, die auch woanders gebraucht werden. Die Prozedur ltest_module' liest deshalb zunächst ein ganzes Modul in einen Pufferspeicher und stellt fest, ob eines der in diesem Modul definierten Symbole benötigt wird. Nur wenn das der Fall ist, wird der Pufferinhalt dem Programm in gewohnter Weise hinzugefügt. Die Größe des Puffers ist mit 32 Kbyte vordefiniert, kann aber per Option geändert werden.

Achtung! Prozeduren innerhalb eines Moduls kann der Linker nicht einzeln hinzufügen oder weglassen, denn innerhalb eines Moduls können sich die Prozeduren gegenseitig aufrufen, ohne daß der Linker davon etwas merkt. Definiert man etwa in einem C-Quelltext zwei Prozeduren, von denen eine die andere aufruft, so kann der Aufruf meist bereits vom Compiler durch einen relativen Sprung compiliert werden, der Linker hat an dieser Stelle dann keine Arbeit mehr.

Zum Aufbau und Suchen von Tabellen existieren folgende Prozeduren:

'app_mod' : Einfügen eines Modulnamens in die Modulnamentabelle; dies ist eine lineare Liste. 'app_xsy' : Einfügen eines Symbols in einen binären Baum. 'app_sec' : Einfügen einer Sectiondefinition in eine lineare Liste. 'src_xsy' : Suchen eines Symbols im Binärbauin. 'src sec' : Suchen einer Sectiondef inition in der linearen Liste.

Der Vollständigkeit halber seien noch die folgenden Prozeduren erwähnt:

'halt' : Abbruch des Programms nach einem fatalen Fehler. 'strnicmp' Vergleich zweier Strings ohne Unterscheidung von Klein- und Großbuchstaben mit Längenbegrenzung. 'statistic' : Anzeige der Sections mit Längenangabe 'list xsy' Ausdrucken aller oder nur Undefinierter Symbole. 'get drct' : Ein Byte aus dem Objektfile lesen. 'get byte' : Ein Byte entweder aus dem Modulpuffer oder dem Objektfile lesen 'move_up' Speicherbereich nach oben schieben, um so Platz für die Erweiterung einer Section zu schaffen ’init mem' Speicherbereiche per 'malloc' reservieren 'make ext' Falls ein Dateiname keine Extension besitzt, so wird hier eine angehängt. Dazu werden die Funktionen 'stcgfe' und 'strmfe' aus der Library des LATTICE-C gebraucht, 'stcgfe' isoliert die Extension aus einem Dateinamen, 'strmfe' fügt eine neue Extension an. 'command line' : Diese Prozedur analysiert die Kommandozeile und setzt entsprechende Flags.

Weshalb überhaupt noch einen Linker für das GST-Format ?

Besitzer des GST-Linkers werden sich sicherlich schon oft über die mangelnde Geschwindigkeit desselben, aber auch über die immer wiederkehrenden Bomben während des Linkprozesses geärgert haben. Der hier vorgestellte Linker arbeitet bei Diskettenbetrieb mit der 4.5-fachen Geschwindigkeit und hat bisher auch bei größeren Programmen keine Bomben geworfen.

Ein weiterer Nachteil des GST-Linkers besteht darin, daß dieser nur die TEXT-Section des ablauffähigen Programms benutzt. Das heißt, daß alle in den Objektfiles definierten Sections dort landen. Bei der DATA-Section (initialisierte Felder, Stringkonstanten usw.) wäre das nicht weiter schlimm, wer in seinem Programm aber leere Felder von mehreren Kilobytes Größe vereinbart hat, wird sicher wenig Verständnis dafür haben, daß diese unnötigerweise Speicherplatz auf der Diskette belegen. Normalerweise sind nämlich nur TEXT- und DATA-Bereiche auf Datei abgelegt, der BSS-Bereich wird erst nach dem Laden des Programms vom Betriebssystem initialisiert. Dieser Linker verteilt die Bereiche richtig auf TEXT-, DATA- oder BSS-Section, so daß die ablauffähigen Programme nicht selten gewaltig zusammenschrumpfen. Dies kann aus Kompatibilitätsgründen an- und abgeschaltet werden.

Welche Sections wo landen, ist in der Prozedur ‘def_section' festgelegt. Diese ordnet beliebigen Sectionnamen die Zahl -1 zu, so daß diese Sections in die TEXT-Section des TOS gelangen. Sections mit Namen ‘DATA’ wird die Kennung -2 zugeteilt, was zur Folge hat, daß diese auch in die DATA-Section des TOS gebracht werden. Sections mit Namen ‘ÜDATA’ und ‘BSS' bekommen die Kennung -3 und werden dadurch der BSS-Section des TOS zugeordnet. Diese wird, im Gegensatz zur Vorgehensweise des Original-GST-Linkers, nicht auf Diskette abgespeichert, falls man die -SEC Option eingeschaltet hat. Die Namen sind kompatibel zum LATTICE C, dieser nennt die BSS-Section nämlich ‘UDATA’, und zum Metacomco Assembler, der schon den richtigen Namen "BSS' verwendet. Wer noch andere Sections im BSS-Bereich untergebracht haben möchte, kann dies in ‘def_section’ in analoger Weise eintragen.

Aufruf des Linkers

Der Linker sollte als “TTP”-Programm benannt werden, denn er erwartet die Eingabe einer Kommandozeile, die der des GST-Linkers sehr ähnlich ist, und folgendes Aussehen haben sollte:

module : ist der Dateiname einer Objekt-Datei, die gelinkt werden soll. Dieser Name wird vom Linker immer mit ".BIN" ergänzt.

control : ist der Name einer Control-Datei, in der Linkeranweisungen stehen.

listing : ist der Name einer List-Datei,

program : ist der Dateiname des fertigen Programms .

Als Options sind zulässig:

In beiden Fällen wird an die Dateinamen die Extension “.BIN” angehängt, falls keine andere vorhanden ist. Die Defaultwerte für die Options sind:

Die Defaultfilenamen sind:

Der < module >-Dateiname ist also immer notwendig.

Schließlich und endlich nun noch die Fehlermeldungen, die erscheinen können:

• Error 0: Out of memory Beim Aufruf der malloc-Funktion konnte der gewünschte Speicher nicht zur Verfügung gestellt werden. Die einzige Abhilfe wäre hier, den Computer ohne Accessories zu starten, um mehr Speicher zu haben.
• Error 1: Program memory too small Das Programm ist größer als 100 Kbyte, beziehungsweise als der mit der SEC Option vereinbarte Speicher. Abhilfe: Mit der -SEC Option mehr Speicher reservieren.
• Error 2: Error in binary File. Das Objektfile entspricht nicht dem GST-Format. Leider hat der Metacomco-Assembler die Eigenart, unter gewissen Umständen fehlerhafte Objektfiles zu produzieren. Im allge meinen hilft es, in bestimmten Datenbereichen (etwa bei Stringkonstanten) zusätzliche Bytes einzufügen. Genaueres läßt sich hier leider nicht sagen.
• Error 3: Too many operands in XREF. In einem XREF-Kommando können maximal 10 Symbole in eine Berechnung eingehen, sind es einmal mehr, so erscheint diese Fehlermeldung. In der Praxis dürfte das allerdings kaum Vorkommen. Trotzdem Abhilfe: Konstante XMAX im Quelltext erhöhen und den Linker neu kompilieren.
• Error 4: Illegal section id. Im einem Modul ist die Anzahl verschiedener Sections auf 20 begrenzt (sinnvoll sind sowieso nur drei). Sollten es dennoch mehr sein, so erscheint diese Meldung. Abhilfe: Ändern der Konstanten MAX NDEF und neucompilieren des Linkers.
• Error 5: Illegal symbol id. In einem Modul (nicht im gesamten Programm!) ist die Anzahl verschiedener Symbole auf 500 begrenzt. Sollten es dennoch mehr sein, so erscheint diese Meldung. Abhilfe: Ändern der Konstanten MAXPDEF und neucompilieren des Linkers.
• Error 6: ORG encountered. Das ORG-Kommando in einem Objektfile wird mangels Bedarf nicht vom Linker unterstützt.
• Error 7: Should not occur Taucht nie auf.
• Error 8: Word or longword at odd address. Dies ist ein Fehler im Objektfile, für den der Compiler oder Assembler verantwortlich ist.
• Error 9: Buffer too small. Der Puffer, der zum Zwischenspeichern für Module aus den Libraries gebraucht wird, ist zu klein. Abhilfe: mit der -BUF Option mehr Speicher reservieren.
• Error 10: Cannot write file correctly. Das Programmfile kann nicht fehlerfrei geschrieben werden.

Im allgemeinen ist dann kein Platz mehr auf der Diskette. Außer diesen fatalen Fehlern werden natürlich Undefinierte oder mehrfach definierte Symbole gemeldet, dies führt aber nicht zum Abbruch des Programms.

Sollte das Linken nicht geklappt haben, meldet der Linker dem aufrufenden Programm einen Fehlercode 1, ansonsten Null. Manche Shell-Programme (wie z.B. das “MENU+” von Meta-comco) machen Gebrauch davon.

Ingo Eichenseher

ENDE