Zum Inhalt springen

„Interpreter“ – Versionsunterschied

aus Wikipedia, der freien Enzyklopädie
[ungesichtete Version][gesichtete Version]
Inhalt gelöscht Inhalt hinzugefügt
Pinguin.tk (Diskussion | Beiträge)
''Siehe auch'': Kompilierung
K Trennschärfe der Unterscheidung nicht gegeben. Programme resultieren aus Code in einer Programmiersprache, die interpretiert wird.
 
(286 dazwischenliegende Versionen von mehr als 100 Benutzern, die nicht angezeigt werden)
Zeile 1: Zeile 1:
{{Dieser Artikel|beschäftigt sich mit dem allgemeinen Begriff Interpreter in der Softwaretechnik. Weitere Bedeutungen unter [[Interpreter (Begriffsklärung)]].}}
Ein '''Interpreter''' (im Sinne der [[Softwaretechnik]]) ist ein [[Software]]-[[Computerprogramm|Programm]], das nicht in [[Maschinensprache]] kodierte Programme einliest, analysiert, übersetzt und ausführt. Interpreter haben gegenüber [[Compiler]]n den Vorteil, dass das interpretierte Programm auf allen [[Rechnerarchitektur]]en lauffähig ist, ohne dass es vorher neu übersetzt werden muss.


{{Belege fehlen|2=Dieser Artikel|1=Der Artikel, insbesondere geschichtliche Angaben sowie subjektive Aussagen sollten mit Belegen versehen werden.}}
Der größte Nachteil der Interpretersprachen ist die im Vergleich zu compilierten Programmen deutlich langsamere Ausführungsgeschwindigkeit. Bei einem Interpreter findet die zeitintensive Übersetzung des [[Quellcode]]s in Maschinensprache zur Laufzeit des Programmes statt, und mehrfach durchlaufene Programmteile müssen immer wieder neu übersetzt werden, im Gegensatz zu einem Compiler, bei dem das Programm schon vorher übersetzt wird. Eine Kompromißlösung ist ein [[Just-In-Time-Compiler]] (JIT-Compiler), bei dem das Programm auch erst zur Laufzeit übersetzt wird, allerdings wird der übersetzte Code zwischengespeichert, so dass mehrfach durchlaufen Programmteile nur einmal übersetzt werden müssen. Auch ermöglicht der JIT-Compiler eine stärkere Optimierung des Binärcodes.


Als '''Interpreter''' wird ein [[Computerprogramm]] bezeichnet, das eine Abfolge von Anweisungen anscheinend direkt ausführt,<ref name="Pearson-Compiler-2008" /> wobei das Format der Anweisungen vorgegeben ist. Der Interpreter liest dazu eine oder mehrere [[Quelltext|Quelldateien]] ein, analysiert diese und führt sie anschließend Anweisung für Anweisung aus, indem er den dafür vorgesehenen Programmcode (eventuell über Zwischenschritte letztendlich als [[Maschinensprache|Maschinencode]] für das jeweilige Computersystem) direkt ausführt. Interpreter sind deutlich langsamer als [[Compiler]], bieten im Allgemeinen jedoch eine bessere Fehleranalyse.<ref name="Pearson-Compiler-2008" />
Bekannte Interpretersprachen sind [[Basic]], [[Perl]], [[Python (Programmiersprache)|Python]], [[Ruby]] und viele andere.


Interpreter werden sowohl bei [[Programmiersprache]]n als auch [[Kommandozeileninterpreter]]n verwendet.
Für manche Sprachen (etwa [[Smalltalk (Programmiersprache)|Smalltalk]]) gibt es je nach Anbieter Interpreter, [[Bytecode]]-Interpreter, [[JIT-Compiler]], [[Compiler]], nach C Compiler oder auch .NET Versionen oder eine .NET Brücke.


== Verwendung ==
Bei Java wird der [[Quellcode]] zuerst in sogenannten Bytecode übersetzt (compiliert), der dann von den Java-Laufzeitumgebungen verschiedener Betriebssysteme (meist [[JIT-Compiler|JIT]]) compiliert oder interpretiert werden kann.


=== Programmierung ===
''Siehe auch'': [[Kompilierung]]
Bei der Programmierung ist ein Interpreter fast immer ein Bestandteil der [[Softwareentwicklung]].


In ihrer Reinform übersetzen Compiler –&nbsp;im Unterschied zu Interpretern&nbsp;– die Anweisungen aus den Quelldateien in einem oder mehreren Durchläufen in Maschinencode für ein vorher festgelegtes Zielsystem und erstellen so ein [[Ausführbare Datei|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.<ref name="Software-Engineering-1969" />
[[da:Fortolker]]

[[en:Interpreter (computing)]]
{{Zitat
[[et:Interpretaator]]
|Text=Any good software engineer will tell you that a compiler and an interpreter are interchangeable.
[[fr:Interpréteur]]
|Sprache=en
[[ja:インタプリタ]]
|Autor=[[Tim Berners-Lee]]
[[ko:인터프리터]]
|Übersetzung=Jeder gute Software-Entwickler wird Ihnen sagen, dass Compiler und Interpreter austauschbar sind.
[[lt:Interpretatorius]]
|ref=<ref>{{Literatur |Autor=Torben Ægidius Mogensen |Titel=Introduction to Compiler Design |Verlag=Springer Science & Business Media |Ort=London |Datum=2011 |ISBN=978-0-85729-828-7 |Sprache=en |Online={{Google Buch |BuchID=KvDustn1eikC |Seite=97 |Hervorhebung=Interpreter Compiler}}}}</ref>}}

Ist die letzte Stufe ein Interpreter, so erfolgt die Übersetzung der Quelldatei zur [[Laufzeit (Informatik)|Laufzeit]] des Programms.<ref>{{Internetquelle |url=https://www.xovi.de/wiki/Interpreter |titel=Was ist ein Interpreter? |werk=XOVI |sprache=de |abruf=2019-05-29}}</ref><ref name="xovi">{{Internetquelle |autor=Michael Bürger |url=https://www.bg.bib.de/portale/bes/Progentwicklung/Programmiersprachen/Programmiersprachen-110.htm |titel=Interpretersprachen |werk=bib.de |sprache=de |offline=1 |archiv-url=https://web.archive.org/web/20170910221922/https://www.bg.bib.de/portale/bes/Progentwicklung/Programmiersprachen/Programmiersprachen-110.htm |archiv-datum=2017-09-10 |abruf=2019-05-29}}</ref>

Programmiersprachen, die Quelltext nicht kompilieren, sondern eine Eingabe oder eine Quelldatei stets interpretieren, werden auch als „Interpretersprache“ oder [[Skriptsprache]] bezeichnet. Klassische Interpretersprachen sind z.&nbsp;B. [[Tcl]], [[JavaScript]] oder einige [[BASIC]]-Varianten.

Bei einigen Programmiersprachen kann zwischen Interpreter und Compiler gewählt werden. So befand sich im [[Festwertspeicher|ROM]] der meisten [[8-Bit-Architektur|8-Bit]]-Computer wie dem [[Commodore 64|C64]] für eine flüssige Programmentwicklung ohne Kompilierphasen ein BASIC-Interpreter; zur Beschleunigung fertig entwickelter Programme konnte ein kompatibler Compiler (z.&nbsp;B. [[Commodore 64#Basic-Boss BASIC-Compiler|BASIC BOSS]]) extern geladen werden. Auch die meisten Versionen von [[MS-DOS]] enthielten einen BASIC-Interpreter (z.&nbsp;B. [[GW-BASIC]]), zu dem ein kompatibler Compiler (hier [[BASCOM]]) erworben werden konnte.

Bei einigen Programmiersprachen wird auch ein [[Bytecode]] als [[Zwischencode]] erzeugt, der bereits optimiert ist, jedoch zur Ausführung abermals einen Interpreter auf dem Zielsystem benötigt.

=== Computerprogramme ===
[[Shellskript|Skripte]] für [[Kommandozeileninterpreter]], etwa [[Stapelverarbeitungsdatei]]en oder [[Unix-Shell]]-Skripte, werden ebenfalls von einem Interpreter ausgeführt. Damit das Skript nicht als Kommandozeilen-[[Parameter (Informatik)|Parameter]] angegeben werden muss, gibt es auf [[Unixoides System|Unix-artigen]] Systemen und Shells das sogenannte [[Shebang]]&nbsp;– das Skript ruft sich damit den passenden Interpreter –&nbsp;mithilfe der Shell&nbsp;– 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.&nbsp;a. bei [[Emulator]]en ebenfalls der Fall, die Maschinencode für andere Computersysteme analysieren, umschreiben und für das Computersystem, auf dem sie gerade laufen, interpretiert ausführen. [[Virtuelle Maschine]]n zählen jedoch nicht dazu, da diese große Teile des Maschinencodes des Gastsystems auf dem Hostsystem uninterpretiert direkt ausführen. Auch [[Spiel-Engine|Game-Engines]] können Interpreter sein, wenn sie die eigentlichen Spieledaten, meist als [[Bytecode]], auf der jeweiligen [[Plattform (Computer)|Plattform]] interpretiert ausführen.

== Eigenschaften ==
Interpreter liegen zumeist in [[Maschinensprache]] des Zielprozessors vor, können aber auch selbst wieder in einer Interpretersprache vorliegen. Der größte Nachteil ist dabei die gegenüber einem Compiler geringere Ausführungsgeschwindigkeit. Diese ist der Tatsache geschuldet, dass der Compiler sich während des Kompilierungsprozesses die Zeit nehmen kann, den Code zu optimieren, der somit auf dem jeweiligen Zielsystem schneller ausgeführt wird. Derlei Optimierungen sind jedoch zeitaufwendig, sodass ein Interpreter meist eine direkte Umsetzung auf Maschinencode durchführt, was jedoch in Summe wieder langsamer ist als der optimierte Code durch den Compiler.<ref>https://bmu-verlag.de/uberblick-uber-verschiedene-programmiersprachen/ BMU-Verlag: Überblick über Programmiersprachen (Compiler und Interpreter)</ref>

Interpretierter Code ist in etwa fünf bis 20 Mal langsamer als kompilierter Code.<ref name="ETAPS2000-Notes" />

Zu den Vorteilen von interpretiertem Code zählt, neben der besseren Fehleranalyse, die Unabhängigkeit von einer vorher festgelegten [[Rechnerarchitektur]]&nbsp;– denn interpretierter Code läuft auf jedem System, auf dem es einen Interpreter dafür gibt.

=== Geschwindigkeitssteigerungen ===
Eine Kompromisslösung ist ein [[Just-in-time-Kompilierung|Just-in-time-Compiler]] (JIT-Compiler), bei dem das Programm erst zur [[Laufzeit (Informatik)|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. JIT-Compiler sind allerdings nur auf einer bestimmten Rechnerarchitektur lauffähig, weil sie Maschinencode für diese Architektur erzeugen, und benötigen weit mehr [[Arbeitsspeicher]] als reine Interpreter.<ref name="ETAPS2000-Notes" />

=== Zwischencode ===
Eine weitere Zwischenstufe sind [[Bytecode]]-Interpreter. Dabei wird der Quelltext (vorab oder zur Laufzeit) in einen einfachen Zwischencode übersetzt, der dann von einem Interpreter –&nbsp;auch häufig als virtuelle Maschine bezeichnet&nbsp;– ausgeführt wird. Dies ist z.&nbsp;B. bei [[Java (Programmiersprache)|Java]] durch die [[Java Virtual Machine]] (JVM) der Fall. Es entspricht dem Konzept Compiler-Interpreter, da der Zwischencode bereits in Teilen optimiert kompiliert wurde (Quelltext&nbsp;→ Compiler&nbsp;→ Zwischencode als Bytecode&nbsp;→ Interpreter&nbsp;→ Ausführung auf dem Zielsystem).

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

=== Mischformen ===
Da JIT-Code nicht automatisch schneller ist als interpretierter Code, verwenden manche [[Laufzeitumgebung]]en eine Mischform. Ein Beispiel dafür ist die JVM. Dabei wird der JIT-Compiler parallel mit dem Interpreter verwendet, wobei der jeweils schnellere Ausführungspfad „gewinnt“.<ref name="Core-Java-2008" />

== Interpretersprachen ==
{{Überarbeiten}}
Als Interpretersprachen werden häufig [[Programmiersprache]]n bezeichnet, deren Haupt- oder Erstimplementierung ein Interpreter ist, als Gegenteil zu einer Programmiersprache, die einen [[Compiler]] verwendet (Compilersprache).<ref>{{Literatur |Autor=Christian Wagenknecht, Michael Hielscher |Titel=Formale Sprachen, abstrakte Automaten und Compiler |TitelErg=Lehr- und Arbeitsbuch für Grundstudium und Fortbildung |Verlag=Springer-Verlag |Datum=2009 |ISBN=978-3-8348-0624-6 |Online={{Google Buch |BuchID=mXlrWEexCbMC |Seite=74}}}}</ref> Grundsätzlich ist eine Programmiersprache nicht an eine Art der Implementierung gebunden und es existieren Mischformen aus den beiden 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 kompiliert 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 (Programmiersprache)|C]] ist sehr stark darauf ausgelegt, kompiliert 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 (Programmiersprache)|APL]], [[BASIC]], [[Forth (Programmiersprache)|Forth]], [[Perl (Programmiersprache)|Perl]], [[Python (Programmiersprache)|Python]], [[Ruby (Programmiersprache)|Ruby]], [[PHP]] und viele andere.<ref name="xovi" /> Als eine Unter- oder verwandte Kategorie der Interpretersprachen werden manchmal die [[Skriptsprache]]n genannt.

Bekannte Programmiersprachen, die üblicherweise in Bytecode übersetzt werden, sind [[Java (Programmiersprache)|Java]], [[C-Sharp|C#]], Perl und Python.

Für manche Sprachen (etwa [[Smalltalk (Programmiersprache)|Smalltalk]]) gibt es je nach Anbieter Interpreter, Bytecode-Interpreter, JIT-Compiler oder Compiler in andere Sprachen (beispielsweise nach C oder für [[.NET (Oberbegriff)|.NET-Plattformen]]).

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

== Einzelnachweise ==
<references>
<ref name="Pearson-Compiler-2008">
{{Literatur
|Autor=Alfred V. Aho, Monica S. Lam, Ravi Sethi, Jeffrey D. Ullman
|Titel=Compiler: Prinzipien, Techniken und Werkzeuge
|Verlag=Pearson Deutschland
|Datum=2008
|ISBN=978-3-8273-7097-6
|Seiten=1253
|Online={{Google Buch |BuchID=pTKAwL64NkoC |Seite=3 |Hervorhebung=Interpreter}}}}
</ref>
<!-- <ref name="Introduction-to-Compiler-Design">
{{Literatur
| Autor = Torben Ægidius Mogensen
| Titel = Introduction to Compiler Design
| Verlag = Springer Science & Business Media
| Ort = London
| Datum = 2011
| Sprache = en
| ISBN = 978-0-85729-828-7
| Online ={{Google Buch
| BuchID = KvDustn1eikC
| Seite = 97
| Hervorhebung = Interpreter Compiler
}}
}}</ref> -->
<ref name="Software-Engineering-1969">
{{Literatur
|Autor=Julius T. Tou
|Titel=Software Engineering
|TitelErg=Proceedings of the Third Symposium on Computer and Information Sciences held in Miami Beach, Florida, December, 1969
|Verlag=Academic Press
|Ort=New York / London
|Datum=1970
|ISBN=0-323-15744-0
|Seiten=288
|Sprache=en
|Online={{Google Buch |BuchID=MXln3I0z90QC |Seite=147 |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
|Band=Vol. 1781
|Verlag=Springer-Verlag
|Ort=Berlin / Heidelberg / New York
|Datum=2000
|ISBN=3-540-67263-X
|Seiten=300
|Sprache=en
|Online={{Google Buch |BuchID=-cTZQ6P3WV8C |Seite=35 |Hervorhebung=interpreter 5-20 times slower}}}}
</ref>
<ref name="Core-Java-2008">
{{Literatur
|Autor=R. Nageswara Rao
|Titel=Core Java: An Integrated Approach. Covers Concepts, Programs and Interview Questions
|Verlag=Dreamtech Press
|Ort=New Delhi
|Datum=2008
|ISBN=978-81-7722-836-6
|Seiten=664
|Sprache=en
|Online={{Google Buch |BuchID=gwxBt1wHsasC |Seite=12 |Hervorhebung=interpreter JIT compiler}}}}
</ref>
</references>

{{Normdaten|TYP=s|GND=4162129-3|REMARK=Ansetzungsform GND: „Interpretierer“.}}

[[Kategorie:Programmierwerkzeug]]

Aktuelle Version vom 11. Dezember 2024, 11:38 Uhr

Als Interpreter wird ein Computerprogramm bezeichnet, das eine Abfolge von Anweisungen anscheinend 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 den dafür vorgesehenen Programmcode (eventuell über Zwischenschritte letztendlich als Maschinencode für das jeweilige Computersystem) direkt ausführt. Interpreter sind deutlich langsamer als Compiler, bieten im Allgemeinen jedoch eine bessere Fehleranalyse.[1]

Interpreter werden sowohl bei Programmiersprachen als auch Kommandozeileninterpretern verwendet.

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[3]

Ist die letzte Stufe ein Interpreter, so erfolgt die Übersetzung der Quelldatei zur Laufzeit des Programms.[4][5]

Programmiersprachen, die Quelltext nicht kompilieren, sondern eine Eingabe oder eine Quelldatei stets interpretieren, werden auch als „Interpretersprache“ oder Skriptsprache bezeichnet. Klassische Interpretersprachen sind z. B. Tcl, JavaScript oder einige BASIC-Varianten.

Bei einigen Programmiersprachen kann zwischen Interpreter und Compiler gewählt werden. So befand sich im ROM der meisten 8-Bit-Computer wie dem C64 für eine flüssige Programmentwicklung ohne Kompilierphasen ein BASIC-Interpreter; zur Beschleunigung fertig entwickelter Programme konnte ein kompatibler Compiler (z. B. BASIC BOSS) extern geladen werden. Auch die meisten Versionen von MS-DOS enthielten einen BASIC-Interpreter (z. B. GW-BASIC), zu dem ein kompatibler Compiler (hier BASCOM) erworben werden konnte.

Bei einigen Programmiersprachen wird auch ein Bytecode als Zwischencode erzeugt, der bereits optimiert ist, jedoch zur Ausführung abermals einen Interpreter auf dem Zielsystem benötigt.

Computerprogramme

[Bearbeiten | Quelltext bearbeiten]

Skripte für Kommandozeileninterpreter, etwa Stapelverarbeitungsdateien oder Unix-Shell-Skripte, werden ebenfalls von einem Interpreter ausgeführt. Damit das Skript nicht als Kommandozeilen-Parameter angegeben werden muss, gibt es auf Unix-artigen Systemen und Shells das sogenannte Shebang – das Skript ruft sich damit den passenden 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 gerade laufen, interpretiert ausführen. Virtuelle Maschinen zählen jedoch nicht dazu, da diese große Teile des Maschinencodes des Gastsystems auf dem Hostsystem uninterpretiert direkt ausführen. Auch Game-Engines können Interpreter sein, wenn sie die eigentlichen Spieledaten, meist als Bytecode, auf der jeweiligen Plattform interpretiert ausführen.

Interpreter liegen zumeist in Maschinensprache des Zielprozessors vor, können aber auch selbst wieder in einer Interpretersprache vorliegen. Der größte Nachteil ist dabei die gegenüber einem Compiler geringere Ausführungsgeschwindigkeit. Diese ist der Tatsache geschuldet, dass der Compiler sich während des Kompilierungsprozesses die Zeit nehmen kann, den Code zu optimieren, der somit auf dem jeweiligen Zielsystem schneller ausgeführt wird. Derlei Optimierungen sind jedoch zeitaufwendig, sodass ein Interpreter meist eine direkte Umsetzung auf Maschinencode durchführt, was jedoch in Summe wieder langsamer ist als der optimierte Code durch den Compiler.[6]

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

Zu den Vorteilen von interpretiertem Code zählt, neben der besseren Fehleranalyse, die Unabhängigkeit von einer vorher festgelegten Rechnerarchitektur – denn interpretierter Code läuft auf jedem System, auf dem es einen Interpreter dafür gibt.

Geschwindigkeitssteigerungen

[Bearbeiten | Quelltext bearbeiten]

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. JIT-Compiler sind allerdings nur auf einer bestimmten Rechnerarchitektur lauffähig, weil sie Maschinencode für diese Architektur erzeugen, und benötigen weit mehr Arbeitsspeicher als reine Interpreter.[7]

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. Dies ist z. B. bei Java durch die Java Virtual Machine (JVM) der Fall. Es entspricht dem Konzept Compiler-Interpreter, da der Zwischencode bereits in Teilen optimiert kompiliert wurde (Quelltext → Compiler → Zwischencode als Bytecode → Interpreter → Ausführung auf dem Zielsystem).

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.

Da JIT-Code nicht automatisch schneller ist als interpretierter Code, verwenden manche Laufzeitumgebungen eine Mischform. Ein Beispiel dafür ist die JVM. Dabei wird der JIT-Compiler parallel mit dem Interpreter verwendet, wobei der jeweils schnellere Ausführungspfad „gewinnt“.[8]

Interpretersprachen

[Bearbeiten | Quelltext bearbeiten]

Als Interpretersprachen werden häufig Programmiersprachen bezeichnet, deren Haupt- oder Erstimplementierung ein Interpreter ist, als Gegenteil zu einer Programmiersprache, die einen Compiler verwendet (Compilersprache).[9] Grundsätzlich ist eine Programmiersprache nicht an eine Art der Implementierung gebunden und es existieren Mischformen aus den beiden 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 kompiliert 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, kompiliert 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.[5] 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 für .NET-Plattformen).

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

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. a b Alfred V. Aho, Monica S. Lam, Ravi Sethi, Jeffrey D. Ullman: Compiler: Prinzipien, Techniken und Werkzeuge. Pearson Deutschland, 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 0-323-15744-0, S. 288 (englisch, eingeschränkte Vorschau in der Google-Buchsuche).
  3. 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).
  4. Was ist ein Interpreter? In: XOVI. Abgerufen am 29. Mai 2019.
  5. a b Michael Bürger: Interpretersprachen. In: bib.de. Archiviert vom Original (nicht mehr online verfügbar) am 10. September 2017; abgerufen am 29. Mai 2019.
  6. https://bmu-verlag.de/uberblick-uber-verschiedene-programmiersprachen/ BMU-Verlag: Überblick über Programmiersprachen (Compiler und Interpreter)
  7. a b David A. Watt: Compiler Construction. 9th International Conference, CC 2000. In: Lecture Notes in Computer Science. Vol. 1781. Springer-Verlag, Berlin / Heidelberg / New York 2000, ISBN 3-540-67263-X, S. 300 (englisch, eingeschränkte Vorschau in der Google-Buchsuche).
  8. R. Nageswara Rao: Core Java: An Integrated Approach. Covers Concepts, Programs and Interview Questions. Dreamtech Press, New Delhi 2008, ISBN 978-81-7722-836-6, S. 664 (englisch, eingeschränkte Vorschau in der Google-Buchsuche).
  9. Christian Wagenknecht, Michael Hielscher: Formale Sprachen, abstrakte Automaten und Compiler. Lehr- und Arbeitsbuch für Grundstudium und Fortbildung. Springer-Verlag, 2009, ISBN 978-3-8348-0624-6 (eingeschränkte Vorschau in der Google-Buchsuche).