Forum: PC-Programmierung Prinzip Compiler-Interpreter, Anfänger


von abc x. (enybase)


Lesenswert?

Hallo,

ich verstehe das Prinzip des "Interpreters", im Gegensatz zum Compiler, 
nicht richtig.

Laut Wikipedia oder Fachliteratur ist oft zu lesen:
"Ein Interpreter arbeitet den Quellcode anstelle des Prozessors ab".

Blöd gefragt, aber wie soll ein Stück Software denn etwas ausführen ohne 
Benutzung der CPU? Wenn ich a = b + c rechnen will, müssen doch trotzdem 
irgendwo, irgendwelche Daten in Registern herumgeschoben werden, oder 
nicht? Also will sagen, der Code muss doch so oder so "durch den 
Prozessor"..? Und dafür ist doch dann Maschinencode nötig, oder etwa 
nicht?

Oder geht es lediglich um den Zeitpunkt von Übersetzung und Ausführung?
Also der Compiler macht die Übersetzung komplett auf einmal und der 
Interpreter Stück für Stück, aber im Prinzip passiert dasselbe, nur 
zeitlich anders?

Und wieso soll nur ein Interpreter plattformunabhängig sein können?
Könnte es nicht einfach auch unterschiedliche Compiler für jede 
Plattform geben, so wie unterschiedliche VMs auf unterschiedlichen 
Systemen? C läuft doch auch auf unterschiedlichen Plattformen obwohl 
Compiler, man braucht halt evtl. hin und wieder andere Bibliotheken.

Ich versteh das nicht.
Kann mir bitte jemand eine Antwort für einen totalen Anfängerdummy 
geben?

Danke für Eure Zeit.

von Klaus W. (mfgkw)


Lesenswert?

Der Interpreter selbst ist natürlich eine Software, die direkt oder 
indirekt auf dem Prozessor läuft.

Der Unterschied ist nur: Wann wird der Quelltext betrachtet und 
analysiert?

Bei einem Compilersystem ist das lange, bevor das Programm läuft und 
wirklich arbeitet. Der Compiler (natürlich auch SW auf der CPU) schaut 
sich den Quelltext an, prüft ihn nach irgendwelchen Regeln und erzeugt 
daraus Maschinencode, der als Datei gespeichert wird. Irgendwann später 
wird dieses Programm dann direkt auf der CPU ausgeführt.

Bei einem Interpretersystem dagegen wird das Programm im Quelltext 
gespeichert und nicht weiter angefasst.
Erst beim Starten (wenn es also arbeiten soll) liest der Interpreter den 
Quelltext Stück für Stück und führt dann die Aktionen in  sich selbst 
aus, je nach Programm. Auf der CPU laufen also jeweils die Teile des 
Interpreters, die anhand des jeweiligen Programms für nötig erachtet 
werden.

Beispiel: eine Anweisung der Form x=i+3 wird bei einem Compilersystem in 
Maschinencode übersetzt, der erst eine Addition ergibt und dann die 
Zuweisung.
Bei einem Interpretersystem dagegen steckt im Interpreter Code, der 
addieren kann, substrahieren etc. und weil im Programm einen Addition 
und eine Zuweisung vorkommen, werden diese Teile des Interpreters dann 
aktiviert.

von Klaus W. (mfgkw)


Lesenswert?

S. M. schrieb:
> Und wieso soll nur ein Interpreter plattformunabhängig sein können?
> Könnte es nicht einfach auch unterschiedliche Compiler für jede
> Plattform geben, so wie unterschiedliche VMs auf unterschiedlichen
> Systemen? C läuft doch auch auf unterschiedlichen Plattformen obwohl
> Compiler, man braucht halt evtl. hin und wieder andere Bibliotheken.

Da hast du Recht.
Bei einer Interpretersprache müssen alle Anwender jeweils für ihr System 
den passenden Interpreter haben, um ein Programm ausführen zu können.
Bei einer Compilersprache brauchen sie entsprechend den passenden 
Compiler.

Der Unterschied ist nur, daß jeder Depp ein Programm in Python, Perl 
oder was auch immer anklicken kann; falls der richtige Interpreter in 
der richtigen Version vorhanden ist, klappt es.

Beim Kompilieren gibt es erfahrungsgemäß mehr Fallstricke und viele DAUs 
sind damit überfordert.

von Frank E. (Firma: Q3) (qualidat)


Lesenswert?

Es gibt da auch noch quasi eine "Zwischenwelt" zwischen Interpreter und 
Compiler: ByteCode, wie ihn z.B. Java (nicht JavaScript!) verwendet.

Wie bei einem Compiler wird der Quelltext analysiert und dann aber nicht 
in einen prozessortypischen Code umgewandelt (und gespeichert), sondern 
in den Code einer virtuellen Sotware-CPU. Damit ist dieser Teil nich vom 
Betriebssystem (Win, Mac, Linux) abhängig, auf dem er später läuft.

Bei der Ausführung wird dann nur ein sehr abgespeckter und sehr 
schlanker Interpreter verwendet, der dann natürlich wieder 
systemspezifisch ist. Bei Java ist das die Java-Engine.
Wegen der an dieser Stelle nicht mehr nötigen Syntax-Analyse ist das 
auch schneller als bei einem klassischen Interpreter.

Ich glaube Flash macht das so ähnlich.

von abc x. (enybase)


Lesenswert?

Vielen Dank für die Antwort! Hat mir sehr geholfen!!!

gruss,biene

von Christoph F. (saij)


Lesenswert?

Danke auch für die sehr informativen Antworten.

Gruß
Saij

von Wilhelm F. (Gast)


Lesenswert?

In der Zeit, als es noch keine Cross-Compiler für µC auf dem PC gab, gab 
es eine Handvoll µC, die einen Mini-Interpreter auf dem Chip hatten. Ca. 
Anfang bis Mitte der 1990-er Jahre. Man hatte auf dem PC, der noch kein 
Windows hatte, einen Texteditor und ein Terminal als Standardsoftware, 
viel mehr war es damals oft nicht. Es war aber eine Möglichkeit, 
überhaupt einen Quelltext am PC zu schreiben, und den per Terminal 
irgendwo über RS232 zu senden. Der Interpreter interpretiert das 
Programm aus dem Quelltext direkt. Solche µC waren sogar besonders für 
den Hobbybereich konstruiert, hatten aber auch Bugs, die vom Hersteller 
nie beseitigt wurden. Ein bekannter war z.B. der 8051AH-BASIC von INTEL. 
Von Zilog gab es auch sowas, ich glaube, eine Z86xx-Serie. Der Quelltext 
wurde da einfach über ein Terminal mit RS232 auf den µC bzw. über einen 
Bootloader im µC auf externes größeres RAM geladen. Auch hatten die 
Chips einen Algorithmus, der ein EPROM brennen konnte, wenn man das 
Board demnach mit Hardware erweiterte. Die Zeiten waren noch einfach, 
man war noch weit von Compilieren und Debuggen auf dem PC-Monitor 
entfernt.

Der Interpreter ist um einiges langsamer als ein echter Maschinencode, 
aber für Hobbyanwendungen reichte das. Z.B. wenn einer eine Uhr für den 
Wohnzimmerschrank bastelte, o.ä.. Für eine Aufzugssteuerungslogik 
reichte es auch. Vor etwa 15 Jahren war noch kein Freeware-C-Compiler 
wie heute im Internet erhältlich. Ich brasselte damals noch mit dem 
Cross-Assembler herum, konnte am PC den Maschinencode erstellen, und 
Fehlermeldungen erhalten. Und das war gegen so einem Interpreter ein 
echter Fortschritt, wenn man die Dinge im Griff hat.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.