Mir ist der Unterschied so relativ klar. Nur würde mich interessieren, wie weit „nach unten“ der Compiler und Interpreter übersetzt. Kann das der Prozessor schon verstehen, oder muß nochmals ein Übersetzungsprogramm eingeschalten werden? Ich würde mich freuen, wenn man mir so schnell wie möglich antworten könnte, daß ich diese Informationen für eine Klausur brauche.
Schon jetzt recht herzlichen Dank
Andreas Frank
Hallo Andreas
Leider sind die Grenzen ziemlich verwischt und deshalb gibt es keine einfache Antwort auf deine Frage. Ich beschreibe dir mal die typischen definitionen:
ASSEMBLER (Steinzeit)
Übersetzt die Mnemonics (Mehr oder weniger sinnvolle Kürzel z.B. „SHLL A“) direkt in denjenigen Binärwert welchen die CPU direkt „versteht“. Die Speicheradressen (z.B. für eine Variable) müssen hier direkt als Speicher-Adresse angegeben werden.
Als Resultat erhält man ein Memory-Image welches genau an diejenigen Speicher-Adressen kopiert werden muss für welche es geschrieben wurde.
(Der Bergrif „Mnemonic“ stammt von Augusta Ada Byron, welche das erste Programm geschrieben hat. Muss zwischen 1843 und 1853 gewesen sein.)
ASSEMBLER (Modern)
Heutige Assembler können Variablen und Funktionen über einen Namen (Label) ansprechen und enthalten auch Hochsprachen-Elemente wie z.B. FOR … NEXT oder DO … WHILE Konstrukte. Meistens wird nicht direkt ein Memory-Image erstellt sondern eine Objekt-Datei welche dann vom LINKER in ein Memory-Image umgewandelt wird.
LINKER
Der Linker nimmt die verschiedenen Objekt-Dateien, fügt sie zusammem und übernimmt das Adressfixup. D.h. der Assembler oder Compiler hat zwar den Maschinenkode fertig erstellt, wusste aber noch nicht wo die einzelnen Variablen und Funktionen im Speicher tatsächlich hinkommem. Deshalb hat er an den enstprechenden Stellen im Kode nur Verweise hinterlegt (in der Form: Hier muss die Adresse der Variablen „A“ eingetragen werden oder hier muss die Adresse der Funktion „XYZ“ eingetragen werden)
INTERPRETER
Der Interpreter ist ein kleiner Sysiphus.
Er holt sich eine Zeile Text, wie vom Programmierer geschrieben, Analysiert sie und ruft dann die entsprechenden Funktionen auf. Wenn er die gleiche Zeile 100 mal abarbeiten muss wird dieser Vorgang auch 100 mal wiederholt. Ein weiterer Nachteil besteht beim Aufruf von Funktionen und beim Zugriff auf Variablen. Funktionen müssen bei jedem Aufruf zuerst im Programm-Text gesucht werden. Eine Variable muss man irgenwie in einer Liste verwalten und dort suchen und wenn sie noch nicht besteht den entsprechenden Speicherplatz zuweisen.
COMPILER
Hier wird zuerst der ganze Programm-Text analysiert, optimiert (z.B. Konstante Ausdrücke wie „a+(3*4)“ berechnet und als „a+12“ wieder eingesetzt) und eine Objekt-Datei erzeugt welche dann vom LINKER noch nachbearbeitet werden muss.
(Die alten Unix C-Compiler haben nur ein Assembler-Listing erzeugt, welches dann mit dem Assembler in den Maschinen-Kode übersetzt werden musste. Die meisten C-Compiler haben diese Arbeitsweise noch als Option enthalten)
Die Bezeichnung COMPRETER und INTERPILER sind nicht wissenschaftlich definiert.
COMPRETER
Hier wird entweder P-Code (Pseudo-Code) für eine virtuelle CPU erstellt welcher dann zur Laufzeit von einem Interpreter abgearbeitet werden muss (z.B. MS-Basic, Java, UCSD-Pascal). Der Vorteil ist hierbei, dass der P-Code Interpreter meist sehr einfach an eine reale CPU angepasst werden kann und somit ein einmal übersetztes Programm auf fast jeder CPU ausgeführt werden kann und dass das Programm „unter Kontrolle“ gehalten werden kann (Java).
Die andere möglichkeit besteht darin einfach alle Befehle in entsprechende Aufrufe einer Laufzeit-Bibliothek zu übersetzen.
In jedem Fall besteht bei diesem Konzept die möglichkeit der Optimierung des Kodes und der Bereitstellung von Speicher für die Variablen zur Übersetzungs-Zeit.
INTERPILER
Bei diesem Konzept werden die Schlüsselwörter in sogenante Token übersetzt. D.h. jedem Schlüsselwort wird eine Zahl zugeordnet und im Speicher anstelle des entsprechenden Textes abgelegt. Dadurch wird zum einen Speicherplatz gespart und zum anderen muss der Interpreter nicht mehr den Ganzen Text analysieren.
RUNTIME LOADER
Bei verschieden Betriebssystemen besteht das Problem, dass zum Zeitpunkt des Übersetztens nicht bekannt ist an welche Stelle im Speicher das Program später geladen wird. Hier wird (z.B. bei einer MS-EXE Datei) das Programm so gelinkt als wenn es ab der Adresse 0 geladen wird. Es wird zusätzlich eine Tabelle für das Adress-Fixup erstellt welche Teil der EXE-Datei ist. Die Adress-Fixup-Tabelle gibt dem Runtime-Loader an, welche Speicherstellen im Programm korigiert werden müssen. Meist muss dort nur die tatsächliche Adresse, an welche das Programm geladen wurde, zum bestehenden Speicherinhalt addiert werden.
Ich hoffe Du bist jetzt nicht total verwirrt. Es gibt noch einige Varianten die ich hier nicht angesprochen habe z.B. müssen bei Programmen welche in einem ROM abgelegt werden, bevor das Programm gestartet werden kann, noch die Werte, für mit Konstanten vorbelegten Variablen, aus dem ROM ins RAM kopiert werden.
MfG Peter
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]