„Interpreter“ – Versionsunterschied

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
[gesichtete Version][gesichtete Version]
Inhalt gelöscht Inhalt hinzugefügt
Nächster Teil eines Überarbeitungsversuchs...
Markierung: 2017-Quelltext-Bearbeitung
4:1 war ein Blödsinn, es ist 5-20:1... Mit Quelle
Markierung: 2017-Quelltext-Bearbeitung
Zeile 31: Zeile 31:
Interpreter liegen zumeist in [[Maschinensprache]] des Zielprozessors vor, können aber auch selbst wieder in einer Interpretersprache vorliegen. Ein Nachteil der Interpretersprachen ist die im Vergleich zu kompilierten Programmen deutlich langsamere Ausführungsgeschwindigkeit. Reine Interpreter lesen und analysieren den Quellcode eines Programmes und führen dann die entsprechenden Aktionen aus. Dies ist im Vergleich zu Compilersprachen, bei denen das Programm vor seiner Ausführung in Maschinencode übersetzt wird, der dann vom Prozessor direkt ausgeführt wird, vergleichsweise zeitaufwändig. Der Vorteil liegt darin, dass reine Interpreter auf jeder [[Rechnerarchitektur]] lauffähig sind, wenn der Quellcode des Interpreters dort übersetzt werden kann.
Interpreter liegen zumeist in [[Maschinensprache]] des Zielprozessors vor, können aber auch selbst wieder in einer Interpretersprache vorliegen. Ein Nachteil der Interpretersprachen ist die im Vergleich zu kompilierten Programmen deutlich langsamere Ausführungsgeschwindigkeit. Reine Interpreter lesen und analysieren den Quellcode eines Programmes und führen dann die entsprechenden Aktionen aus. Dies ist im Vergleich zu Compilersprachen, bei denen das Programm vor seiner Ausführung in Maschinencode übersetzt wird, der dann vom Prozessor direkt ausgeführt wird, vergleichsweise zeitaufwändig. Der Vorteil liegt darin, dass reine Interpreter auf jeder [[Rechnerarchitektur]] lauffähig sind, wenn der Quellcode des Interpreters dort übersetzt werden kann.
Interpretierter Code ist in etwa fünf bis 20 Mal langsamer als kompilierter Code.<ref name="ETAPS2000-Notes" />
Bei der [[Java Virtual Machine]] (JVM) ist das Verhältnis in etwa 4:1, der Interpreter ist also in etwa viermal so langsam wie optimierter Maschinencode.
=== Geschwindigkeitssteigerungen ===
=== Geschwindigkeitssteigerungen ===
Zeile 106: Zeile 106:
| Seite = 147
| Seite = 147
| Hervorhebung = Interpreter Compiler
| Hervorhebung = Interpreter Compiler
}}}}
</ref>
<ref name="ETAPS2000-Notes">
{{Literatur
|Autor=David A. Watt
|Titel=Compiler Construction
|TitelErg=9th International Conference, CC 2000
|Sammelwerk=Lecture Notes in Computer Science, Volume 1781
|Verlag=Springer-Verlag
|Ort=Berlin, Heidelberg, New York
|Datum=2000
|ISBN=978-3-540-67263-0
|Seiten=300
|Sprache=en
|Online=
{{Google Buch
| BuchID = -cTZQ6P3WV8C
| Seite = 35
| Hervorhebung = interpreter 5-20 times slower
}}}}
}}}}
</ref>
</ref>

Version vom 15. September 2019, 20:13 Uhr

Als Interpreter wird ein Computerprogramm bezeichnet, das eine Abfolge von Anweisungen scheinbar direkt ausführt,[1] wobei das Format der Anweisungen vorgegeben ist. Der Interpreter liest dazu eine oder mehrere Quelldateien ein, analysiert diese und führt sie anschließend Anweisung für Anweisung aus, indem er die Anweisungen in Maschinencode übersetzt, die ein Computersystem direkt ausführen kann. Interpreter gelten als etwas langsamer als Compiler, bieten im Allgemeinen jedoch eine bessere Fehleranalyse als Compiler.[1]

Interpreter werden sowohl bei Programmiersprachen verwendet als auch bei Computerprogrammen.

Verwendung

Programmierung

Bei der Programmierung ist ein Interpreter fast immer ein Bestandteil der Softwareentwicklung.

In ihrer Reinform übersetzen Compiler – im Unterschied zu Interpretern – die Anweisungen aus den Quelldateien in einem oder mehreren Durchläufen in Maschinencode für ein vorher festgelegtes Zielsystem und erstellen so ein ausführbares Computerprogramm. Jedoch gibt es bereits hier die Unterscheidung zwischen Compiler-Compiler und Interpreter-Compiler, genauso wie es auch Interpreter-Interpreter und Compiler-Interpreter gibt.[2]

“Any good software engineer will tell you that a compiler and an interpreter are interchangeable.”

„Jeder gute Software-Entwickler wird Ihnen sagen, dass Compiler und Interpreter austauschbar sind.“

Tim Berners-Lee: Torben Ægidius Mogensen: Introduction to Compiler Design. Springer Science & Business Media, London 2011, ISBN 978-0-85729-828-7 (englisch, eingeschränkte Vorschau in der Google-Buchsuche).

Ist in die letzte Stufe ein Interpreter, so erfolgt die Übersetzung der Quelldatei zur Laufzeit des Programmes.[3][4] Der Übergang zu Kommandozeileninterpretern ist unscharf, da diese häufig auch eine entsprechende Skriptsprache interpretieren können.

Programmiersprachen, die Quelltext nicht kompilieren sondern eine Eingabe oder eine Quelldatei stats interpretieren, werden auch als „Interpretersprache“ oder Skriptsprache bezeichnet. Klassische Interpretersprachen sind z. B. BASIC wie GW-BASIC, Tcl oder JavaScript. Bei einigen weiteren Programmiersprachen kann ein Programmierer zwischen Interpreter und Compiler wählen. Es gibt jedoch auch extern entwickelte Compiler für eigentlich reine Interpretersprachen.

Computerprogramme

Skripte für Kommandozeileninterpreter, etwa Stapelverarbeitungsdateien oder [[Unix-Shell]-Scripte, werden ebenfalls von einem Interpreter ausgeführt. Damit der Skript nicht als Kommandozeilen-Parameter angegeben werden muss, gibt es auf Unix-artigen Systemen und Shells das sogenannte Shebang – der Skipt ruft sich damit den Interpreter, mithilfe der Shell, sozusagen selbst auf.

Bei Computerprogrammen spricht man ebenfalls von Interpretern, sobald der Code nicht direkt vom Computersystem ausgeführt werden kann oder soll. Dies ist u. a. bei Emulatoren ebenfalls der Fall, die Maschinencode für andere Computersysteme analysieren, umschreiben und für das Computersystem, auf dem sie ausgeführt werden, interpretiert ausführen. Virtuelle Maschinen zählen jedoch nicht dazu, da diese Teile des Maschinencodes des Gastsystems auf dem Hostsystem uninterpretiert direkt ausführen.

Eigenschaften

Interpreter liegen zumeist in Maschinensprache des Zielprozessors vor, können aber auch selbst wieder in einer Interpretersprache vorliegen. Ein Nachteil der Interpretersprachen ist die im Vergleich zu kompilierten Programmen deutlich langsamere Ausführungsgeschwindigkeit. Reine Interpreter lesen und analysieren den Quellcode eines Programmes und führen dann die entsprechenden Aktionen aus. Dies ist im Vergleich zu Compilersprachen, bei denen das Programm vor seiner Ausführung in Maschinencode übersetzt wird, der dann vom Prozessor direkt ausgeführt wird, vergleichsweise zeitaufwändig. Der Vorteil liegt darin, dass reine Interpreter auf jeder Rechnerarchitektur lauffähig sind, wenn der Quellcode des Interpreters dort übersetzt werden kann.

Interpretierter Code ist in etwa fünf bis 20 Mal langsamer als kompilierter Code.[5]

Geschwindigkeitssteigerungen

Eine Kompromisslösung ist ein Just-in-time-Compiler (JIT-Compiler), bei dem das Programm erst zur Laufzeit, jedoch direkt in Maschinencode übersetzt wird. Danach wird der übersetzte Code direkt vom Prozessor ausgeführt. Durch Zwischenspeicherung des Maschinencodes müssen mehrfach durchlaufene Programmteile nur einmal übersetzt werden. Auch ermöglicht der JIT-Compiler eine stärkere Optimierung des Binärcodes. Allerdings sind solche Interpreter natürlich nur auf einer bestimmten Rechnerarchitektur lauffähig, weil sie Maschinencode für diese Architektur erzeugen.

Eine weitere Zwischenstufe sind Bytecode-Interpreter. Dabei wird der Quelltext (vorab oder zur Laufzeit) in einen einfachen Zwischencode übersetzt, der dann von einem Interpreter – auch häufig als virtuelle Maschine bezeichnet – ausgeführt wird.

Besonders in den 1980er Jahren benutzte man die Zwischenstufe, Befehle zum Eingabezeitpunkt in leichter dekodierbare Tokens umzuwandeln, die bei der (List-)Ausgabe wieder in Klartext umgewandelt wurden. Neben der Geschwindigkeitssteigerung war die Kompression des Quelltextes ein gewichtiges Argument. Prinzipiell war es damit auch möglich, jeweils muttersprachliche Schlüsselwörter zu verwenden, wenn man den Datenaustausch auf Basis des tokenisierten Quellprogramms durchführte.

Interpretersprachen

Als Interpretersprachen werden häufig Programmiersprachen bezeichnet, deren Haupt- oder Erstimplementierung ein Interpreter ist, als Gegenteil zu einer Programmiersprache, die einen Compiler verwendet (Compilersprache).[6] Grundsätzlich ist eine Programmiersprache nicht an eine Art der Implementierung gebunden und es existieren Mischform aus den beiden gegenteiligen Ansätzen.

Es gibt jedoch auch Programmiersprachen, die unter Gesichtspunkten der späteren Implementierung gestaltet wurden; dies ist bei manchen älteren Sprachen noch gut zu erkennen. So mussten Interpreter aufgrund der geringen Leistungsfähigkeit der frühen Computer möglichst einfach und klein gehalten werden, um nicht zu viel Rechenzeit und Arbeitsspeicher zu verbrauchen. Compiler hingegen konnten viel Rechenzeit und auch viel Arbeitsspeicher verbrauchen, denn wenn das Programm lief, waren sie nicht mehr aktiv. Deshalb wurden Sprachen, die interpretiert werden sollten, so gestaltet, dass sie einfach analysiert und ausgeführt werden können. Wohingegen Sprachen, die compiliert werden sollten, auch aufwändig zu analysierende und bearbeitende Konstrukte enthalten konnten. Heute spielt dies beim Entwurf einer Programmiersprache nur noch in den allerseltensten Fällen eine Rolle.

Für einige Sprachen existieren verschiedenartige Implementierungen. Hierbei sticht die Sprache Scheme hervor, für die eine unüberschaubare Vielzahl an Implementierungen existiert, die auf vielen verschiedenen Konzepten basieren. Hierzu noch ein Beispiel: Die Programmiersprache C, ist sehr stark darauf ausgelegt compiliert zu werden. Doch es existieren trotzdem Interpreter wie der CINT und der Ch für diese Sprache und das, obwohl C oft als ein Paradebeispiel für eine Sprache genannt wird, die keine „Interpretersprache“, sondern eine „Compilersprache“ ist.

Als Interpretersprachen bekannt sind APL, BASIC, Forth, Perl, Python, Ruby, PHP und viele andere.[4] Als eine Unter- oder verwandte Kategorie der Interpretersprachen werden manchmal die Skriptsprachen genannt.

Bekannte Programmiersprachen, die üblicherweise in Bytecode übersetzt werden, sind Java, C#, Perl und Python.

Für manche Sprachen (etwa Smalltalk) gibt es je nach Anbieter Interpreter, Bytecode-Interpreter, JIT-Compiler oder Compiler in andere Sprachen (beispielsweise nach C oder .NET).

Der Übergang zwischen reinen Interpretern und reinen Compilern ist fließend.

Einzelnachweise

  1. a b Alfred V. Aho, Monica S. Lam, Ravi Sethi, Jeffrey D. Ullman: Compiler: Prinzipien, Techniken und Werkzeuge. Pearson Deutschland GmbH, 2008, ISBN 978-3-8273-7097-6, S. 1253 (eingeschränkte Vorschau in der Google-Buchsuche).
  2. Julius T. Tou: Software Engineering. Proceedings of the Third Symposium on Computer and Information Sciences held in Miami Beach, Florida, December, 1969. Academic Press, New York, London 1970, ISBN 978-0-323-15744-5, S. 288 (englisch, eingeschränkte Vorschau in der Google-Buchsuche).
  3. Was ist ein Interpreter? » XOVI. Abgerufen am 29. Mai 2019.
  4. a b Michael Bürger: Interpretersprachen. Abgerufen am 29. Mai 2019.
  5. David A. Watt: Compiler Construction. 9th International Conference, CC 2000. In: Lecture Notes in Computer Science, Volume 1781. Springer-Verlag, Berlin, Heidelberg, New York 2000, ISBN 978-3-540-67263-0, S. 300 (englisch, eingeschränkte Vorschau in der Google-Buchsuche).
  6. Christian Wagenknecht, Michael Hielscher: Formale Sprachen, abstrakte Automaten und Compiler. Lehr- und Arbeitsbuch für Grundstudium und Fortbildung. Springer-Verlag, 2009, ISBN 3-8348-0624-2 (eingeschränkte Vorschau in der Google-Buchsuche).