Interpreter

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche
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 Computerprogramm, das einen Programm-Quellcode im Gegensatz zu Assemblern oder Compilern nicht in eine auf dem System direkt ausführbare Datei übersetzt, sondern den Quellcode einliest, analysiert und ausführt. Die Analyse des Quellcodes erfolgt also zur Laufzeit des Programmes. Der Übergang zu Kommandozeileninterpretern ist unscharf, da diese häufig auch eine entsprechende Skriptsprache interpretieren können.

Auch Emulatoren gehören zu den Interpretern, da diese den Maschinencode des Gastsystems befehlsweise auf einem virtuellen Prozessor abarbeiten. Nicht dazu gehören viele virtuelle Maschinen, da diese Teile des Maschinencodes des Gastsystems auf dem Hostsystem ausführen können; dazu ist Binärkompatibilität der Prozessoren erforderlich.

Interpreter liegen zumeist in Maschinensprache des Zielprozessors vor, können aber auch selbst wieder in einer Interpretersprache vorliegen (siehe Beispiel unten) oder von einem Emulator interpretiert werden. Dies ist beliebig schachtelbar und wirkt sich dementsprechend auf die Abarbeitungsgeschwindigkeit aus.

Der größte Nachteil der Interpretersprachen ist die im Vergleich zu compilierten 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.

Geschwindigkeitssteigerungen[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. 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[Bearbeiten]

Dieser Artikel oder Abschnitt bedarf einer Überarbeitung. Näheres ist auf der Diskussionsseite angegeben. Hilf mit, ihn zu verbessern, und entferne anschließend diese Markierung.

Als Interpretersprachen werden häufig Programmiersprachen bezeichnet, deren Haupt- oder Erstimplementierung ein Interpreter ist, als Gegenteil wird meist der Begriff Compilersprache verwendet. Der Begriff Interpretersprache ist jedoch nicht sehr differenziert, da keine Einigkeit darüber herrscht, wann eine Programmiersprache eine Interpretersprache ist.

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 Arbeitspeicher zu verbrauchen. Compiler hingegen konnten viel Rechenzeit und auch viel Arbeitspeicher 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.

Grundsätzlich ist eine Programmiersprache nicht an eine Art der Implementierung gebunden.

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. 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.