Kommen wir nun zur Symbolauflösung und dort praktisch zu den Funktionen, die ein Übersetzer,

ein Binder oder ein Lader im Zusammenhang mit all diesen Konzepten einer Adressbindung

denn letztendlich ausübt. Es geht hier um die Adresse als Symbol. Das heißt also eine Abbildung

von symbolisch nach numerisch. Wir haben eine symbolische Adresse, die steht in den Programmen

drin. Es sind die Namen unserer Variablen, unserer Prozeduren, die dann praktisch in einem

ja letztendlich mehrstufigen Verfahren aufzulösen sind, um nachher am Ende eine entsprechende

numerische Repräsentation, eine konkrete Adresse in einen bestimmten, sagen wir mal virtuellen

Adressraum nachher für einen Prozess vorzufinden. Hier mal das Beispiel, wir

kennen das Beispiel vom Anfang. Hier das Programm, was wir schon hatten, wo wir

dann eben viele Symbole, Benennungen, Bezeichnungen haben und letztendlich

geht es konkret genau darum, halt bestimmte Namen aufzulösen. Der Compiler

geht hin, der Kompilierer und verteilt dann letztendlich Programm, Text und

Daten, was man hier so sieht an Text und Daten, auf entsprechende Programmsegel

und Elemente. Dazu generiert er sogenannte Pseudobefehle, die nachher vom

Assemblierer weiterverarbeitet werden, um dann letztendlich genau diese

verschiedenen Segmentabschnitte zum Beispiel genau identifizieren zu können.

Der Assemblierer ordnet dann diesen Programmsymbol, letztendlich bestimmte

Werte und vor allem eben auch Attribute zu. Wertzuordnung findet so weit statt,

wie es der Assemblierer vornehmen kann. Er wird denn diese Symbole in einer

sogenannten Symboltabelle zusammensammeln und er wird eine

sogenannte Verlagerungstabelle für den Binder letztendlich anlegen, worin denn

praktisch noch beschrieben wird, an welchen Stellen bestimmte

Adressumsetzungen, Adresskorrekturen denn vorzunehmen sind in diesem Programm.

Dann haben wir den Binder, der platziert letztendlich das gebundene Programm, so

er es gebunden hat in und konnte in den Adressraum für dieses Betriebssystem.

Er produziert letztendlich das Lademodul für das Betriebssystem. Dieses

Lademodul muss zum Adressraumkonzept des Betriebssystems denn letztendlich

passen. Der Binder ist sehr stark abhängig von Funktionen und von

bestimmten Konzepten des Betriebssystems und umgekehrt kann man das fast genauso

sagen. Natürlich wird dann zusätzlich noch der Maschinencode generiert. Da haben

wir dann typischerweise zwei Schritte, die Kompilierung des Quellcodes in einer

andere symbolische Darstellung und letztendlich dann diese andere symbolische

Darstellung, die wird dann assembliert und letztendlich wird dann das

Binea-Programm gebunden, um denn nachher die endgültige numerische Auslegung

unseres Maschinenprogramms zu bekommen. Das haben wir am Anfang der Vorlesung

ja schon eingehend behandelt, wie diese Schritte hier letztendlich zu sehen sind.

Nun fangen wir mal mit dem Programm Kopf ab, da wo praktisch letztendlich Anweisungen

sind, die die Programm-Symbole auf bestimmte Bindeabschnitte verteilen. Das

sehen wir hier. Im wesentlichen sind es ist eine Liste von Pseudo-Befehlen, die

man halt absetzt. Die sind hier kurz kommentiert. Also wir sagen hier in der

Zeile 2 praktisch, dass es sich ums Datensegment handelt. Hier in der Zeile 7

sagen wir hier beginnt das Textsegment. Alles was sozusagen nach dieser

Segment-Anweisung letztendlich steht, wird dann in dieses entsprechende

Segment platziert. Also hier würden wir sagen, diese beiden Strings, die wir haben,

die gehen ins Datensegment und die Anweisungen, die dann hier hinter Main

kommen würden, hinter dem Symbol Main stehen würden, da sind dann normalerweise

die Maschinenbefehle codiert. Die gehen dann eben ins Textsegment. Also das ist

der ausführbare Bereich, den wir da haben. Die Symbole werden also bekannt gemacht

und sie werden auch mit bestimmten Attributen eben hier verknüpft.

Wir sagen also, welche Symbole ist ein Textsymbol, welches ein Datensymbol,