Compiler vs Interpreter

ujuzui schrieb:

Natürlich macht ein Interpreter nicht überall Sinn. Auf einem Mikrocontroller wäre es ziemlich schwachsinnig eine interpretierte Sprache zu verwenden, da der Interpreter + Programmcode die Ressourcen schnell ausschöpfen würde.

Das stimmt so natürlich nicht. Ein Interpreter muss nicht immer gleich Perl/Python/Ruby mit allen mitgelieferten Bibliotheken bedeuten. Zum Beispiel Lua lässt sich bereits mit einem Ansi C Compiler übersetzen, ist eine voll funktionsfähige Sprache und bringt ein paar (optionale) Bibliotheken mit. Aber selbst die wäre für einen kleinen Mikrocontroller bereits überdimensioniert. Sehr kompakt bekommt man Interpreter für Lisp-Dialekte hin und für kleinere Skripte sind die bereits vollkommen ausreichend. Man denke zum Beispiel an so etwas wie eine read-eval-print-loop um mal eben etwas Code auf dem Mikrocontroller ausführen zu können um ein paar Informationen auszulesen, oder sogar einen Bug zu fixen/kaputte Daten wiederherzustellen. Dafür ist so ein kleiner Interpreter echt gold wert

knivil

Mikrocontroller + Interpreter: Forth

forth ist interpreter und compiler (threaded code-) zugleich.

knivil

Die Gretchenfrage: Wird Maschinencode interpretiert? Ja, von der Maschine ...

knivil schrieb:

Die Gretchenfrage: Wird Maschinencode interpretiert? Ja, von der Maschine ...

Ja, damit hast du natürlich recht. Bei einem Interpreter folgt aber noch die Indirektion, dass zunächst der Maschinencode des Interpreters und dieser somit den Programmcode ausführt. Das erfordert also mehr Instruktionen durch diesen "Umweg".

wenn man tief genug herabsteigt, wird letztlichendlich alles interpretiert - und sei es durch ein Schaltwerk, das nicht viel mehr macht, als Nanobefehle in Bitmuster auf einem Steuerbus umzusetzen (Decoder). Ein Maschinenbefehl ist auf dieser Ebene betrachtet bereits eine "Routine", die in compiliertem nanocode vorliegt.

add:

es gibt natürlich Alternativen, zum Beispiel asynchrone Systeme, ohne zentrales Schaltwerk gebaute Systeme usw.

!rr!rr_. schrieb:

wenn man tief genug herabsteigt, wird letztlichendlich alles interpretiert ...

Also erzeugt ein Compiler immer Code für einen speziellen Interpreter.
Und ein Compiler ist immer auch selbst ein Interpreter, da er Code interpretieren muß, um anderen Code zu erzeugen, der von irgendeiner Maschine (aus Soft- oder Hardware) interpretiert werden soll.

Aber was ist nun ein Codegenerator, der z.B. aus einer (grafischen) Metasprache C-Code erzeugt? Ein Compiler, ein Interpreter, oder beides?

knivil

Compiler ist immer auch selbst ein Interpreter

Nein, ein Compiler transformiert Quelltext in einer Darstellung in eine andere. Ein Interpreter fuehrt das Programm aus. Ein Interpreter erzeugt im Normalfall keinen Code.

Aber was ist nun ein Codegenerator, der z.B. aus einer (grafischen) Metasprache C-Code erzeugt?

Von einer Darstellung in eine andere, also Compiler.

knivil schrieb:

Ein Interpreter erzeugt im Normalfall keinen Code.

Kann man denn die Wirkung eines Interpreters, d.h. des Programms das er interpretiert, nicht ganz allgemein auch als Code bezeichnen? Sozusagen ein "Code", der in der realen Welt irgendetwas bewirkt? In dem Fall wäre der Interpreter auch nur ein Code-Konverter, wie ein Compiler.

knivil

Prinzipiell kann man das. Aber ich finde, dass diese Verwaesserung nicht von Nutzen ist. Ein Compiler ueberfuehrt die Darstellung des Programms in eine andere. Hat also erstmal keine Auswirkung auf "aeussere Welt", ein Interpreter setzt das Programm um, d.h. hat eine Wirkung. Darstellung und Wirkung in einen Topf zu werfen lehne ich ab. Es besteht ein fundamentaler Unterschied zwischen das Schreiben von "erschiesse XY!" und der eigentlichen Tat.

knivil schrieb:

Prinzipiell kann man das. Aber ich finde, dass diese Verwaesserung nicht von Nutzen ist.

Ich gebe dir Recht. Man kann vieles bis zur Unkenntlichkeit verallgemeinern, doch nützlich ist sowas eher selten. Ich wollts nur mal ansprechen.