Compiler vs Interpreter
-
SeppJ schrieb:
Großartig. Dann ist der Vorteil von Interpretern also, dass Programme > 40 MB groß sind, damit sie sich wie compilierte Programme anfühlen?
du meinst Nachteil?
wenn man unbedingt die alles-ist-drin.exe haben muss, ja. Aber da wirds bei statisch gelinkten, kompilierten C++ oder Common Lisp Programmen auch nicht viel besser.
-
SeppJ schrieb:
Großartig. Dann ist der Vorteil von Interpretern also, dass Programme > 40 MB groß sind, damit sie sich wie compilierte Programme anfühlen?
Nein, es erfordert nur einen entsprechenden Installer, der das System einmalig so konfiguriert, dass sich die Programme ohne weitere Handlung des Benutzers ausführen lassen. Mag natürlich sein, dass der Installer eine gewisse Größe hat, um alle erforderlichen Komponenten mitzubringen. Würde man diese mit dem Programmcode bündeln, dann wäre folglich das gesamte Programmpaket größer. Aber das ist ja auch bei dem Kompilaten der Fall.
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.
Aber davon war hier ja auch nie die Rede.
-
SeppJ schrieb:
Großartig. Dann ist der Vorteil von Interpretern also, dass Programme > 40 MB groß sind, damit sie sich wie compilierte Programme anfühlen?
Bescheuerte Argumentation, entweder die Laufzeitumgebung die mein Programm benötigt ist auf dem PC vorhanden oder eben nicht. Falls nicht muss ich sie eben mitliefern. In welcher Sprache ich mein Programm schreibe ist dann auch egal. Wenn ich pech hab muss ich für mein C++ Programm eben auch ein installer schreiben der die VS Redistributable oder Qt oder wasauchimmer mitinstalliert.
-
Ein Interpreter simuliert zur Laufzeit eine Maschine, während ein Compiler Code für eine reale oder virtuelle Maschine generiert. Das ist eigentlich der einzige Unterschied. Alles andere relativiert sich durch spezielle Technologien.
-
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
-
Mikrocontroller + Interpreter: Forth
-
forth ist interpreter und compiler (threaded code-) zugleich.
-
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?
-
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.
-
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.