Unterschied zwischen Compiler und Interpreter ?
-
Ok thx
-
Elektronix schrieb:
Ein Interpreter ist ein Programm, das den Quellcode Deines Programmes Befehl für Befehl zur Laufzeit ließt, in Maschinencode umsetzt und ausführt.
Richtig bis auf den Teil "in Maschinencode umsetzt". Wenn er das tun würde wär es ein Compiler.
Ein Kompiler setzt den gesamten am Stück Quellcode in Maschinensprache um und speicher diese als Exe-Datei ab. Erst dann kannst Du Dein Programm ausführen.
Nein, siehe oben. Man kann auch Programmteile im Speicher compilieren und von dort ausführen. Ein Compiler muss übrigens keine Maschinensprache erzeugen, Bytecodecompiler sind in letzter Zeit auch recht häufig ...
(Die meisten Compiler haben eine Option, mit der Du die Exe aus dem Arbeitsspeicher heraus ausprobierenkannst, ohne sie abzuspeichern).
Die meisten? Welche denn? Außer Turbo Pascal fällt mir keiner ein.
Der Nachteil beim Compiler ist, daß er nur für eine bestimmte Plattform compilieren kann. Für eine andere Plattform brauchst Du einen entsprechenden angepaßten Compiler. Wobei dies natürlich auch für den Interpreter gilt, also kann man hier nicht unbedingt von Nachteil sprechen.
Da ein Interpreter keinen Code erzeugt, gilt das eben nicht. Er muss nur selbst lauffähig sein.
Ein Nachteil der Interpreter ist: Mit ihnen laufen Programme wesentlich langsamer. Vorteil: Laufzeitfehler lassen sich leichter aufspüren, weil der Interpreter die Ausführung verweigert. Ein Kompiler kann Laufzeitfehler (z. B. falsch initialisierte Zeiger) nicht erkennen.
Der Interpreter kann auf nicht initialisierte Zeiger zugreifen und dann halt abstürzen, und der Compiler kann Code generieren, der jeden Zeigerzugriff vorher prüft.
-
Hallo,
einen Compiler für einen Compiler gibt es meines Wissens nach nicht.
-
Bashar schrieb:
"in Maschinencode umsetzt". Wenn er das tun würde wär es ein Compiler.
Wenn er das nicht tut- was führt der Rechner dann aus?
Elektronix schrieb:
(Die meisten Compiler haben eine Option, mit der Du die Exe aus dem Arbeitsspeicher heraus ausprobierenkannst, ohne sie abzuspeichern).
Die meisten? Welche denn? Außer Turbo Pascal fällt mir keiner ein.
Sorry, ich meinte hier nicht die Compiler, sondern meistens die IDEs. Da ich immer nur mit IDEs arbeite, verwechsle ich die manchmal...
Elektronix schrieb:
Der Nachteil beim Compiler ist, daß er nur für eine bestimmte Plattform compilieren kann. Für eine andere Plattform brauchst Du einen entsprechenden angepaßten Compiler. Wobei dies natürlich auch für den Interpreter gilt, also kann man hier nicht unbedingt von Nachteil sprechen.
Da ein Interpreter keinen Code erzeugt, gilt das eben nicht. Er muss nur selbst lauffähig sein.
Eben. Ein Interpreter als Programm ist plattformabhängig. Für mich ergeben sich da keine Unterschiede. Der Unterschied ist, daß bei Weitergabe eines Programmescodes der (plattformabhängige!) Interpreter ebenfalls vorhanden sein muß. Die Plattformunabhängigkeit ist nur gegeben, wenn sicher ist, daß es für alle gewünschten Systeme entsprechende Interpreter gibt.
-
Monger schrieb:
Hallo,
einen Compiler für einen Compiler gibt es meines Wissens nach nicht.Und wie programmiert man dann Compiler? Im Bitcode?
-
Elektronix schrieb:
Bashar schrieb:
"in Maschinencode umsetzt". Wenn er das tun würde wär es ein Compiler.
Wenn er das nicht tut- was führt der Rechner dann aus?
Eine Unterfunktion des Interpreters mit Eingabedaten als Parameter aufrufen (z.B. ;)). Jedenfalls keinen selbst generierten Maschinencode.
Elektronix schrieb:
Der Unterschied ist, daß bei Weitergabe eines Programmescodes der (plattformabhängige!) Interpreter ebenfalls vorhanden sein muß.
Der Unterschied ist vor allem, dass man den Interpreter (im Idealfall) für eine andere Plattform unverändert neu übersetzt. Der Compiler (zumindest das Backend, welches den Maschinencode generiert) muss für jede Plattform neu geschrieben oder u.U. erheblich angepasst werden.
EDIT: Verben ergänzt
-
Selbst wenn der Interpreter sich nicht direkt für eine andere Plattform übersetzen lässt, es muss nr der Interpreter angepasst/neugeschrieben werden und alle zu Interpretierenden Programme funktionieren (im Idealfall) auf auch der neuen Plattform.
In der Uni wurde uns folgender Satz noch gesagt: Ein interpretiertes Programm ist genau dann schneller, wenn man es nur einmal benutzt.
-
CStoll schrieb:
Artchi schrieb:
Ein Interpreter wandelt nichts in Maschinencode um. Der interpretiert immer und immer wieder plaintext.
Mit dem Plaintext wird aber der Rechner nicht sehr viel anfangen können - folglich muß der Interpreter den Plaintext-Befehl in etwas übersetzen, was der Rechner versteht -> Maschinencode (diesen Maschinencode jagt er allerdings "nur" durch den Rechner und vergisst ihn dann wieder).
Genau das ist eben nicht der Fall.
-
Dass er den Quellcode interpretiert stimmt aber auch nicht ganz, außer vielleicht für Shellscripte und ähnliches, normalerweise wird er eine Zwischencodedarstellung interpretieren (AST oder Bytecode (was ihn dann auch fast schon zu einer Art Compiler macht)).
-
Ein Compiler erzeugt aus einer Sprache einen Code (Text) in einer anderen Sprache, während ein Interpreter sofort während der Übersetzung den Code auf der gleichen Maschine ausführt.
Und es gibt auch noch Compiler-Compiler, welche aus einer Sprachbeschreibung (für einen Compiler) einen Compiler erzeugen.
Diese sind besonders für das sog. "Bootstrapping" nützlich, d.h. um in kurzer Zeit einen Compiler für eine neue Maschine (Prozessor) zu erstellen.
-
Mir ging's um den Maschinencode-Part. Ein Interpreter übersetzt nichts in Maschinencode; und selbst wenn doch (Stichwort "JIT"), wird da sicher nichts gleich wieder vergessen.
Dass in so einem System auch ein Parser, ggf. ein Compiler steckt, klar -- aber dennoch wird das ganze interpretiert, nicht direkt ausgeführt.
-
mein verstaendniss ist
ein script steuert software die das script interpretiert (mittels interpreter)
ein programm steuert hardware die nur noch maschinencode sieht (mittels compiler uebersetzt).ein emulator ist dabei als interpreter von programmen anzusehen.
-
Sehr schön. Und nun versuch mal
Script := Programmin dieses Weltbild zu integrieren.
-
finix schrieb:
Sehr schön. Und nun versuch mal
Script := Programmin dieses Weltbild zu integrieren.
ich scheiter schon dabei diese zuweisung in mein gehirn zu integrieren. kannst du deine anforderung umformulieren? ansonsten sehe ich da 1000 sachen drinn.
-jedes script hat ein programm das es interpretiert?
-ein script beinhalten ein programm? huh
-...
-
Sorry.
Script == Programm
-
Der Thread kann dann wohl begraben werden
-
finix schrieb:
Sorry.
Script == Programmdas hatte ich schon integriert.
in script steuert software
ein programm steuert hardwareum es noch hervor zu heben koennte ich auch abstrahiert behaupten, dass ein script das program fuer eine software ist, genau wie jede instruktion vom microcode fuer sich auch ein programm in einer cpu ist (deswegen kann man heutzutage auf CPUs mit einer neuen firmware bugs fixen.)
-
Also ist jetzt ein Script ein Programm und ein Programm ist ein Programm?
-
finix schrieb:
Also ist jetzt ein Script ein Programm und ein Programm ist ein Programm
vielleicht verstehst du es wenn ich es auf ein anderes model uebertrage.
script->grossvater
program->vater
cpu->kindmeine abstraktion war nun, dass ein script fuers program genau so ein program ist wie das program ein programm fuer die cpu ist.
also
ein grossvater ist fuer den vater genau so vater, wie der vater ein vater fuers kind ist.
wie gesagt. das ist meine ansicht ;), ich hab nicht vor euch davon zu ueberzeugen sie auch zu teilen ... ich hoffe das macht ihr freiwillig
-
Bashar schrieb:
Der Thread kann dann wohl begraben werden
Vielleicht kann ja ein zuständiger Mod einfach den Part ab meinem Beitrag oben löschen oder raussplitten...