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.
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.
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.
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.
Vielen Dank für die Antwort! Hat mir sehr geholfen!!! gruss,biene
Danke auch für die sehr informativen Antworten. Gruß Saij
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.