Unterschied zwischen Compiler und Interpreter ?

TheToast

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.

finix

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.

Bashar

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

Th

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.

finix

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.

rapso

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.

finix

Sehr schön. Und nun versuch mal

Script := Programm

in dieses Weltbild zu integrieren.

rapso

finix schrieb:

Sehr schön. Und nun versuch mal
Script := Programm
in 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
-...

finix

Sorry.

Script == Programm

Bashar

Der Thread kann dann wohl begraben werden

rapso

finix schrieb:

Sorry.

Script == Programm

das hatte ich schon integriert.

in script steuert software
ein programm steuert hardware

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

finix

Also ist jetzt ein Script ein Programm und ein Programm ist ein Programm?

rapso

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

meine 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

finix

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

der unterschied ist eher fliessend. viele interpreter 'compilieren' quelltext zu bytecode, damit der eigentliche interpreter nicht den quelltext parsen muss (was zeit kostet). ...wurde aber schon gesagt irgendwie.
übrigens, wer mit interpretern o.ä. rumspielen will: http://www.ucalc.com/langbuilder.html

Bashar schrieb:

Der Thread kann dann wohl begraben werden

Was simmt denn nicht

zwutz

oO
so ein simples Thema und dann 4 Seiten? ^^

Ein Interpreter liest den Code,
ein Compiler übersetzt ihn.

Wär eigentlich alle (grob zumindest)
heutige Mischsysteme haben mit der eigentlichen Definition nix mehr gemein

Vorteil Interpreter:
- Plattformunabhängig (sofern interpreter vorhanden)
- der Skripter braucht nur nen Texteditor, mehr nicht
Nachteil Interpreter:
- der User hat den kompletten Code, kann ihn also auch verändern
- langsamer
- Fehler treten erst zur Laufzeit auf
- ohne Interpreter geht nix

Vorteil Compiler:
- Code ist großteils geschützt
- Programme sind Stand-Alone
- schnelle Ausfuehrung
- die meisten Fehler werden bereits waehrend des kompilierens entdeckt
Nachteil Compiler:
- Plattformabhaengig
- Aenderungen muessen erst neu kompiliert werden

evtl noch:
ein Interpreter sieht immer nur den Teil, den er grad liest
ein Compiler sieht den Code als ganzes

sorry, falls einiges davon geklaert wurde, aber ich hatte keine Lust, alles hier zu lesen

zwutz schrieb:

Nachteil Interpreter:
- der User hat den kompletten Code, kann ihn also auch verändern

das muss kein nachteil sein.

zwutz schrieb:

- Fehler treten erst zur Laufzeit auf

bei compiliertem code treten fehler beim compilieren und zur laufzeit auf.

finix

zwutz schrieb:

oO
so ein simples Thema und dann 4 Seiten? ^^

Dafür dass das Thema so simpel ist, liest sich dein Beitrag schon ein wenig kurios...

zwutz schrieb:

sorry, falls einiges davon geklaert wurde, aber ich hatte keine Lust, alles hier zu lesen

Ja, ungelesen einfach neue Phrasen reindreschen ist auch viel besser.