ubuntuusers.de

Den Thread habe ich mal abgetrennt.

(hier kommt er her: http://forum.ubuntuusers.de/topic/32794/ )

Zur Frage möchte ich folgendes beitragen:

Wenn man sich die Mühe macht, zwischen Compiler und Interpreter zu unterscheiden, dann deswegen, weil es Unterschiede gibt.
Die Gemeinsamkeit, daß der Prozessor letztlich Bits manipuliert und im Speicher herumschiebt, sieht von den Details ab.

Wenn die Begriffe einen Sinn haben, dann doch den, zu unterscheiden, und der Unterschied ist, daß beim Kompilieren der Übersetzungsvorgang stattfindet, ohne daß das Programm ausgeführt wird, während der Interpreter den Code zur Laufzeit des Programms übersetzt.

Bytecode für eine virtuelle Maschine stellt ein Zwischending dar, weil der Code einmal übersetzt wurde, aber nicht als Maschinencode vorliegt - jedenfalls nicht als Code, der von der physikalischen Maschine selbst verstanden wird, sondern eben von einer virtuellen.

Daß selbst nativer Code in einer VM (z.B. VMWare) ausgeführt werden kann, und es andererseits Hardware gibt, die z.B. Java-Bytecode nativ ausführt, macht die Abgrenzung zu einer diffizilen sophistischen Herausforderung.
Als Interpreter würde ich dennoch ein Programm bezeichnen, das Quellcode verarbeitet und ausführt.

Hier ist übrigens noch ein 4-Seiten-Thread, der sich langsam der gleichen Frage zugewandt hat:

http://forum.ubuntuusers.de/topic/32265/

user unknown hat geschrieben:

Den Thread habe ich mal abgetrennt.

(hier kommt er her: http://forum.ubuntuusers.de/topic/32794/ )

Zur Frage möchte ich folgendes beitragen:

Wenn man sich die Mühe macht, zwischen Compiler und Interpreter zu unterscheiden, dann deswegen, weil es Unterschiede gibt.

Da stimme ich zu, ich habe ja auch mehrfach Punkte dafuer genannt.
user unknown hat geschrieben:

Die Gemeinsamkeit, daß der Prozessor letztlich Bits manipuliert und im Speicher herumschiebt, sieht von den Details ab.

Wenn die Begriffe einen Sinn haben, dann doch den, zu unterscheiden, und der Unterschied ist, daß beim Kompilieren der Übersetzungsvorgang stattfindet, ohne daß das Programm ausgeführt wird, während der Interpreter den Code zur Laufzeit des Programms übersetzt.

Auch hier stimme ich zu und habe dies auch ausdruecken wollen. Es ging ja um die Arbeitsweise von Interpreter und Compiler, welche meiner Meinung nach recht aehnlich ist. Dazu hab ich ja schon genug geschrieben, denke ich...

EDIT: Im Prinzip koennten wir auch mit Interpilern und Compretern weiter machen, allerdings wird es dann noch ein wenig missverstaendlicher, als es schon mit dem Bytecode wurde, da diese momentan noch nicht einmal standardisiert sind. Trotzdem sind im Laufe der letzten Jahre die Unterschiede zwischen Compilern und Interpretern geringer geworden, wenn auch noch vorhanden.

rincewind hat geschrieben:

Aha. Sorry wenn ich langsam etwas genervt klinge, aber woraus glaubst Du besteht so ein Compiler (Oder generell irgendein Programm)? Oder was ein Compiler ist?

Der innere aufbau eines Compilers ist irrelevant, es geht schliesslich um die Arbeitsweise. Natuerlich bestehen heutige Compiler aus Modulen und Funktionen, aber das ist keine notwendigkeit. Du kannst genausogut alles in ein Programm klatschen und hoffen das du dich bei den Sprüngen nicht verhedderst.

rincewind hat geschrieben:

Natuerlich fuehrt der Compiler das fertige Programm nicht aus. Ich dachte eigentlich, dass ich das auch schon so geschrieben

Eigentlich nicht, oder du hast es sehr geshcickt verschleiert das du es genau nicht meinst 😉

rincewind hat geschrieben:

Chaoswind hat geschrieben:

rincewind hat geschrieben:

Ein Interpreter nimmt ein Wort und findet heraus wie es in der Zielsprache heisst.

Nein.
Er findet heraus welche Funktion damit verbunden ist.

Hm. Auch hier ein Verstaendnisproblem, nehme ich an. Was macht denn die gefundene Funktion? Richtig, sie erzeugt Maschinencode, welcher dann sofort ausgefuehrt wird.

seufz
Also noch mal: Ein reiner Interpreter kompiliert nicht, niemals, zu keinem Zeitpunkt und nimmermehr.
Der Interpreter erzeugt keinen Maschinencode, oder irgendwelchen Code in sonst irgendeiner Sprache. Der Code existiert bereits und der Interpreter entscheidet lediglich welcher Code wann und mit welchen Parametern ausgeführt wird.

Compiler übersetzen und Interpreter rufen auf, so simpel ist das.

Das gilt wie gesagt fuer die reinen Programme. Aber mittlerweile hat sich da ganze ja vermischt. Die Interpreter haben noch einen Compiler der vorher den Quelltext optimiert, bevor dann der Interpreter (aka Virtuelle Maschine) den Code interpretiert und die Entsprechenden Funktionen der Physikalischen Maschine aufruft.
rincewind hat geschrieben:

Deshalb hatten die oberen Zeilen ein Minus davor. Die Zeile "Ausfuehrung des Codes als Maschinencode" hat keine listenartige Markierung, weil sie eine Bemerkung ist, die verdeutlichen sollte, dass der Code eben danach als Maschinencode ausgefuehrt

Ach? Dann entschuldige. Du hast aber dann tatseachlich eine effiziente art der tauschung 😉

rincewind hat geschrieben:

Deshalb ist der untere Part von Deinem Post irrelevant, auch wenn ich immer noch nicht nachvollziehen kann, warum Du Vergleiche eines Bereiches bringst, in denen eine Menge andere Faktoren eine Rolle spielen. Das ist meiner Meinung nach ein anderer Film. Bitte bleib bei Deinen Beispielen bei Interpreter, Bytecode-Interpreter und Compiler. Weder habe ich einen Browser geschrieben, noch kenne ich mich mit den genauen Mechanismen wirklich aus und zusaetzlich interessiert es mich auch nicht.

Der Punkt ist, in beiden faellen geschieht dasselbe. Code wird interpretiert und verknpüfte Funktionen werden aufgerufen.
Wie gesagt, Interpreter erzeugen in der regel keine Maschinensprache. Allerdings ist das natuerlich keine bedienung.

Aber ok, dann nehmen direkt einen Interpreter der allseits bekannt sein sollte: die Bash.
Ich hoffe du kennst die Arbeitsweise der Bash. Wenn wir mal die eingebauten Funktionen weglassen, dann ruft die Bash einfach nur externe Programme auf. Sie kompiliert die Programme nicht, sie erstellt auch keinen Maschinencode, sie ruft einfach nur andere Programme/Funktionen auf die bereits existieren, also schon vorher Kompiliert wurden.

Chaoswind hat geschrieben:

rincewind hat geschrieben:

Aha. Sorry wenn ich langsam etwas genervt klinge, aber woraus glaubst Du besteht so ein Compiler (Oder generell irgendein Programm)? Oder was ein Compiler ist?

Der innere aufbau eines Compilers ist irrelevant, es geht schliesslich um die Arbeitsweise. Natuerlich bestehen heutige Compiler aus Modulen und Funktionen, aber das ist keine notwendigkeit. Du kannst genausogut alles in ein Programm klatschen und hoffen das du dich bei den Sprüngen nicht verhedderst.

Der innere Aufbau ist nicht irrelevant, da ich darüber geschrieben habe (allerdings habe ich das anscheinend nicht deutlich genug gemacht), als ich die Vergleiche angestellt habe. Abgesehen davon hängt die Arbeitsweise de Compilers vom inneren Aufbau ab, aber das wissen wir sicher beide.
Was meinst Du mit "alles in ein Programm klatschen?" Was ist alles? Wenn Du ungenaue Aussagen triffst, darfst Du Dich nicht über ungenaue Antworten beschweren.
Chaoswind hat geschrieben:

rincewind hat geschrieben:

Natuerlich fuehrt der Compiler das fertige Programm nicht aus. Ich dachte eigentlich, dass ich das auch schon so geschrieben

Eigentlich nicht, oder du hast es sehr geshcickt verschleiert das du es genau nicht meinst 😉

Da bin ich nicht der Einzige. Aber Du hast recht, ich hatte es nicht explizit geschrieben, wahrscheinlich bin ich davon ausgegangen, dass man es zwischen den Zeilen lesen kann da ich nichts dagegen schrieb. Ein Fehler, wie jetzt klar wird. Ich versuche mich zu bessern und klarere Formulierungen zu benutzen.
BTW sollte man meiner Meinung nach in einer Diskussion versuchen, den Anderen zu verstehen und nicht jedes geschriebene oder nicht geschriebene Wort zu dessen Lasten auszulegen, sonst kann das schnell nach Polemik riechen, insbesonder wenn man den Gegenüber nicht weiter kennt. Nichts für Ungut.
Chaoswind hat geschrieben:

seufz
Also noch mal: Ein reiner Interpreter kompiliert nicht, niemals, zu keinem Zeitpunkt und nimmermehr.

Das habe ich nirgends behauptet. Ich nehme an, Du spielst auf meine Bemerkung zu Bytecode-Interpretern an. Dort schrieb ich, dass man sich streiten könne, ob man in dem Kontext kompilieren sagen kann oder nicht.
Chaoswind hat geschrieben:

Der Interpreter erzeugt keinen Maschinencode, oder irgendwelchen Code in sonst irgendeiner Sprache.

Wie wird dann etwas ausgeführt? Natürlich kommt am Ende Maschinensprache heraus, sonst könnte kein Prozessor irgendetwas damit anfangen. Der Weg ist eben ein Anderer als beim Compiler, da sind wir uns doch einig, dachte ich?
Chaoswind hat geschrieben:

Der Code existiert bereits und der Interpreter entscheidet lediglich welcher Code wann und mit welchen Parametern ausgeführt wird.

Das ist so lange richtig, wie man ausschließlich externe Programme durch ein interpretiertes Skript aufrufen lässt. Damit würde man einen Interpreter aber zu einfach darstellen und alle (mittlerweile) normalen Sprachkonstrukte wie Bedingungen, Schleifen, Variablen etc. unter den Tisch fallen lassen. Das Bild ist so auf jeden Fall verzerrt und nicht richtig. Selbst batches haben gewisse Zusatzfeatures, die man beachten sollte.

Das Folgende ist stark vereinfacht, um die wesentlichen Aspekte beispielhaft darzustellen.
<Vereinfachung>
Ein Compiler besitzt genauso wie ein Interpreter Übersetzungstabellen (in etwa das, was Du "verknüpfte Funktionen" genannt hast) mit deren Hilfe der Quelltext bearbeitet wird.

Die Maschinensprache ist also im Compiler und im Interpreter vorhanden.

Der Interpreter schaut ein Komando/eine Zeile in seiner Übersetzungstabelle nach und schickt die Entsprechung als Maschinencode zum Prozessor, der ihn daraufhin ausführt. Ob das nun ein in den Interpreter eingebautes Kommando ist oder ein Aufruf eines externes Programmes stellt einen Unterschied dar, ich beziehe mich hier auf ein internes Kommando wegen der schon angesprochen meiner Meinung nach zu starken Simplifizierung. Der Interpreter muss am Ende Maschinencode ausgeben, da der Prozessor nur Maschinencode versteht. Dieser Maschinencode ist natürlich generiert/erstellt/erschaffen worden (und zwar aus den vorhandenen Übersetzungstabellen), denn vor der Interpretation war er so nicht vorhanden. Als Beispiel möchte ich hier Variablen nennen, die zur Laufzeit verändert werden.
Der Maschinencode ist aber nicht wirklich greifbar und ist nach der Ausführung nicht mehr vorhanden.

Der Compiler schaut genauso in seiner Übersetzungstabelle nach und gibt die Entsprechung von Funktionen (ich meine Funktionsaufrufe, nicht Definitionen von Funktionen im Quelltext) in Maschinencode in eine Binary, welche dann irgendwann vom Benutzer über das OS ausgeführt werden kann. Auch hier wird Maschinencode generiert/erstellt/erschaffen (und zwar auch aus den vorhandenen Übersetzungstabellen).
</Vereinfachung>
Chaoswind hat geschrieben:

Compiler übersetzen und Interpreter rufen auf, so simpel ist das.

So steht es in vielen Lehrbüchern und auch an der Uni lernt man es so, richtig. Aber wie so oft sind die Dinge (ganz allgemein gesagt) im realen Leben und wenn man sich mit einer Thematik beschäftigt hat eben anders (z.B. komplizierter), als es in den Lehrbüchern (bzw. es an der Uni dargestellt wird) steht. Lehrbücher (und Vorlesungen) werden oft für Einsteiger konzipiert, deshalb werden manche Bereiche simplifiziert, dadurch stimmt manches eben nur teilweise. Fast jeder reale Interpreter hat eingebaute Befehle.
Chaoswind hat geschrieben:

Das gilt wie gesagt fuer die reinen Programme.

Das ist zu ungenau. Was sind "reine Programme"?
Chaoswind hat geschrieben:

Aber mittlerweile hat sich da ganze ja vermischt. Die Interpreter haben noch einen Compiler der vorher den Quelltext optimiert, bevor dann der Interpreter (aka Virtuelle Maschine) den Code interpretiert und die Entsprechenden Funktionen der Physikalischen Maschine aufruft.

Hier stimme ich Dir zu. Allerdings könnte ich Dir jetzt die Gleichsetzung von Interpreter und VM per aka negativ auslegen und Dich fragen, was genau Du mit den "Entsprechenden Funktionen" meinst, ich habe aber verstanden, was Du damit sagen willst.
Chaoswind hat geschrieben:

rincewind hat geschrieben:

Deshalb hatten die oberen Zeilen ein Minus davor. Die Zeile "Ausfuehrung des Codes als Maschinencode" hat keine listenartige Markierung, weil sie eine Bemerkung ist, die verdeutlichen sollte, dass der Code eben danach als Maschinencode ausgefuehrt

Chaoswind hat geschrieben:

Ach? Dann entschuldige. Du hast aber dann tatseachlich eine effiziente art der tauschung 😉

Siehe oben. Bitte stell Dich nicht dumm, ein paar Zeilen weiter hast Du im gleichen Post beim Bytecode-Interpreter die Zeile ohne Minus (welches ich klar als Listenzeichen verwendet habe) auch verstanden, sonst hättest Du konsequenterweise auch dazu etwas schreiben müssen. Auch hier kann das schnell nach Polemik riechen.
Chaoswind hat geschrieben:

rincewind hat geschrieben:

Deshalb ist der untere Part von Deinem Post irrelevant, auch wenn ich immer noch nicht nachvollziehen kann, warum Du Vergleiche eines Bereiches bringst, in denen eine Menge andere Faktoren eine Rolle spielen. Das ist meiner Meinung nach ein anderer Film. Bitte bleib bei Deinen Beispielen bei Interpreter, Bytecode-Interpreter und Compiler. Weder habe ich einen Browser geschrieben, noch kenne ich mich mit den genauen Mechanismen wirklich aus und zusaetzlich interessiert es mich auch nicht.

Der Punkt ist, in beiden faellen geschieht dasselbe. Code wird interpretiert und verknpüfte Funktionen werden aufgerufen.
Wie gesagt, Interpreter erzeugen in der regel keine Maschinensprache. Allerdings ist das natuerlich keine bedienung.

Aber ok, dann nehmen direkt einen Interpreter der allseits bekannt sein sollte: die Bash.
Ich hoffe du kennst die Arbeitsweise der Bash. Wenn wir mal die eingebauten Funktionen weglassen, dann ruft die Bash einfach nur externe Programme auf. Sie kompiliert die Programme nicht, sie erstellt auch keinen Maschinencode, sie ruft einfach nur andere Programme/Funktionen auf die bereits existieren, also schon vorher Kompiliert wurden.

Siehe oben. Mit dem Auslassen der eingebauten Funktionen/Sprachkonstrukte simplifizierst Du meiner Meinung nach zu stark. In diesem engen Rahmen Deines Beispiels stimme ich Dir aber zu.

Die Frage für mich ist, ob diese Diskussion noch Sinn macht. Manchmal versteht man sich einfach so nicht, manchmal will man es nicht, aus welchen Gründen auch immer. Vielleicht kriegen wir ja noch die Kurve.

rincewind hat geschrieben:

Chaoswind hat geschrieben:

Der Interpreter erzeugt keinen Maschinencode, oder irgendwelchen Code in sonst irgendeiner Sprache.

Wie wird dann etwas ausgeführt? Natürlich kommt am Ende Maschinensprache heraus, sonst könnte kein Prozessor irgendetwas damit anfangen.

NEIN. Der Interpreter hat bestimmte Abläufe in SEINEM Programmcode. Der ist kompiliert. Zum Interpretieren liest der reine Interpreter z.b. eine Zeile. Er sieht dann zum bsp., dass da ein Stückchen Code steht, das ein Window erzeugt. Das Compiliert unser reiner Interpreter NICHT (!!!!), sondern ruft die Window-Erzeugt-Funktion in SEINEM, von den Entwicklern schon compiliertem, Maschinencode auf. NICHTS WIRD DABEI KOMPILIERT. Alle Funktionen sind im Interpreter-Programm oder in Libs schon vorhanden und müssen nurnoch ausgeführt werden.

Wenn der I (so nenn ich jetzt den Interpreter) z.b. in Assembler programmiert ist, liest einen Codeabschnitt, der, zum Beispiel, ein Window erzeugt. Das erkennt er und "jump't" an die Stelle im Binärcode des I . Alles ist schon Compiliert.

Ist das so schwer?

mfg Tobias

tobiasschulz hat geschrieben:

Wenn der I (so nenn ich jetzt den Interpreter) z.b. in Assembler programmiert ist, liest einen Codeabschnitt, der, zum Beispiel, ein Window erzeugt. Das erkennt er und "jump't" an die Stelle im Binärcode des I . Alles ist schon Compiliert.

Ist das so schwer?

mfg Tobias

Ja klar, und weiter? Er "jumpt" an die Stelle des Binärcodes und führt es aus. Was wird also im Endeffekt ausgeführt? → Binärcode

rincewind hat geschrieben:

tobiasschulz hat geschrieben:

Wenn der I (so nenn ich jetzt den Interpreter) z.b. in Assembler programmiert ist, liest einen Codeabschnitt, der, zum Beispiel, ein Window erzeugt. Das erkennt er und "jump't" an die Stelle im Binärcode des I . Alles ist schon Compiliert.

Ist das so schwer?

mfg Tobias

Ja klar, und weiter? Er "jumpt" an die Stelle des Binärcodes und führt es aus. Was wird also im Endeffekt ausgeführt? → Binärcode

Ja, aber es wird nicht kompiliert. Nichts erzeugt. Alles ist schon da.

mfg Tobias

Ja, aber es wird nicht kompiliert. Nichts erzeugt. Alles ist schon da.

mfg Tobias

Wo schreibe ich denn bitte, dass der Interpreter etwas kompiliert? Hallo?

Muss ich erst einen Beispielinterpreter schreiben und den Quelltext posten, damit Ihr versteht was ich meine? Sonderbar, die meisten anderen Menschen verstehen mich im Normalfall recht gut.

Beispiel:
Wenn ich in einem interpretierten Skript eine Variable definiere und ihr einen Wert zuweise, ist die nicht schon im Interpreter vorhanden, ebensowenig wie ihr Wert. Sie wird interpretiert. Ihr Wert wird später im Maschinencode der durch den Prozessor abgearbeitet wird in irgendeiner Form zu finden sein.
Wenn ich einen Quelltext compiliere und darin eine Variable samt Zuweisung habe, wird ihr Wert gleich in Binärcode transferiert.

Wenn Ihr unter einem reinen Interpreter versteht, dass wirklich alles von extern aufgerufen wird, verstehe ich ja Euren Standpunkt, habe ich ja auch geschrieben. So einen absolut reinen Interpreter gibt es aber (fast) nicht mehr im realen Leben. Genau darum ging es mir.

rincewind hat geschrieben:

Der innere Aufbau ist nicht irrelevant, da ich darüber geschrieben habe (allerdings habe ich das anscheinend nicht deutlich genug gemacht), als ich die Vergleiche angestellt habe. Abgesehen davon hängt die Arbeitsweise de Compilers vom inneren Aufbau ab, aber das wissen wir sicher beide.

Was interessiert mich der Modulare Aufbau eines Compilers? Das prinzipielle Vorgang ist immer identisch, und alleine darum diskutieren wir doch. Ob der Compiler nun die einzelnen Aufgabenteile an verschiedene Module weiterleitet oder aus einer riesigen Funktion besteht, aendert an der Aufgabe 'Sprache A nach Sprache B übersetzen' doe überhaupt nichts.

rincewind hat geschrieben:

Was meinst Du mit "alles in ein Programm klatschen?" Was ist alles? Wenn Du ungenaue Aussagen triffst, darfst Du Dich nicht über ungenaue Antworten beschweren.

Alles an Funktionalitaet die ein Compiler bietet. Das Ergebniss aendert sich nicht, egal wie der Compiler seine Funktionen verteilt. Aber das hab ich nun schon oft genug geschrieben. Ausser den fuer seine Arbeit notwendigen Funktionen, fuehrt ein Compiler keine Funktionen aus. Insofern ist es vollkommen irrelevant fuer das Konstrukt Compiler wie er im inneren tickt. Wichtig ist wie er sich nach aussen hin verhaelt.

rincewind hat geschrieben:

Da bin ich nicht der Einzige. Aber Du hast recht, ich hatte es nicht explizit geschrieben, wahrscheinlich bin ich davon ausgegangen, dass man es zwischen den Zeilen lesen kann da ich nichts dagegen schrieb. Ein Fehler, wie jetzt klar wird. Ich versuche mich zu bessern und klarere Formulierungen zu benutzen.

Nun, du hast es unkommentiert und in entsprechender Formulierung an die Liste gehaengt. Ausserdem hast du dasselbe auch an anderer stelle behauptet. Da ist das mit zwischen den Zeilen lesen etwas schwierig, wenn die Zeilen das genaue gegenteil behaupten.

rincewind hat geschrieben:

Chaoswind hat geschrieben:

Der Code existiert bereits und der Interpreter entscheidet lediglich welcher Code wann und mit welchen Parametern ausgeführt wird.

Das ist so lange richtig, wie man ausschließlich externe Programme durch ein interpretiertes Skript aufrufen lässt.
Damit würde man einen Interpreter aber zu einfach darstellen und alle (mittlerweile) normalen Sprachkonstrukte wie Bedingungen, Schleifen, Variablen etc. unter den Tisch fallen lassen. Das Bild ist so auf jeden Fall verzerrt und nicht richtig. Selbst batches haben gewisse Zusatzfeatures, die man beachten sollte.

Nein, das sind alles Funktionen die auf der Physikalischen Maschine laufen. Meine güte, ein Taschenrechner erzeugt doch auch keinen Code nur weil er ein paar Zahlen in den Speicher laedt und verrechnet.

rincewind hat geschrieben:

Der Interpreter schaut ein Komando/eine Zeile in seiner Übersetzungstabelle nach und schickt die Entsprechung als Maschinencode zum Prozessor, der ihn daraufhin ausführt. Ob das nun ein in den Interpreter eingebautes Kommando ist oder ein Aufruf eines externes Programmes stellt einen Unterschied dar, ich beziehe mich hier auf ein internes Kommando wegen der schon angesprochen meiner Meinung nach zu starken Simplifizierung. Der Interpreter muss am Ende Maschinencode ausgeben, da der Prozessor nur Maschinencode versteht. Dieser Maschinencode ist natürlich generiert/erstellt/erschaffen worden (und zwar aus den vorhandenen Übersetzungstabellen), denn vor der Interpretation war er so nicht vorhanden. Als Beispiel möchte ich hier Variablen nennen, die zur Laufzeit verändert werden.

So betrachtet, ist ausnahmslos jedes Programm ein Compiler und Interpreter.

rincewind hat geschrieben:

Der Compiler schaut genauso in seiner Übersetzungstabelle nach und gibt die Entsprechung von Funktionen (ich meine Funktionsaufrufe, nicht Definitionen von Funktionen im Quelltext) in Maschinencode in eine Binary, welche dann irgendwann vom Benutzer über das OS ausgeführt werden kann. Auch hier wird Maschinencode generiert/erstellt/erschaffen (und zwar auch aus den vorhandenen Übersetzungstabellen).

So betrachtet stimmt das an und fuer sich, mit dem unterschied das du es IMHO auf einer viel zu tiefen ebenen betrachtest.

rincewind hat geschrieben:

Fast jeder reale Interpreter hat eingebaute Befehle

Ich glaube ich hab das schon mehrmals erwaehnt, aber es ging mir hier immer um den reinen unoptimierten klassischen Interpreter. Und das mit den internen und externen Funktionen hab ich nur als Beispiel zur veranschaulichung gebracht, um klar zu machen ein Interpreter deligiert und nicht übersetzt.
rincewind hat geschrieben:

Chaoswind hat geschrieben:

Das gilt wie gesagt fuer die reinen Programme.

Das ist zu ungenau. Was sind "reine Programme"?

Reine unoptimierte Interpreter, wie z.b. die Bash. Nichts wo irgendein Compiler zwischengeschaltet ist, oder andere Performanceverbesserungen benutzt werden. Das der Übergang fliessend ist und in der Realitaet niemals nur die reine Lehre anzutreffen ist, ist klar.

rincewind hat geschrieben:

Chaoswind hat geschrieben:

Aber mittlerweile hat sich da ganze ja vermischt. Die Interpreter haben noch einen Compiler der vorher den Quelltext optimiert, bevor dann der Interpreter (aka Virtuelle Maschine) den Code interpretiert und die Entsprechenden Funktionen der Physikalischen Maschine aufruft.

Hier stimme ich Dir zu. Allerdings könnte ich Dir jetzt die Gleichsetzung von Interpreter und VM per aka negativ auslegen und Dich fragen, was genau Du mit den "Entsprechenden Funktionen" meinst, ich habe aber verstanden, was Du damit sagen willst.

Funktion im sinn von die Maschine macht irgendwas, nicht als Bauteil Modularer Programmierung. Ok, ist etwas salopp formuliert. Du kannst es auch gerne (Hardware)Befehle oder wie auch immer nennen.

rincewind hat geschrieben:

Chaoswind hat geschrieben:

Ach? Dann entschuldige. Du hast aber dann tatseachlich eine effiziente art der tauschung 😉

Siehe oben. Bitte stell Dich nicht dumm, ein paar Zeilen weiter hast Du im gleichen Post beim Bytecode-Interpreter die Zeile ohne Minus (welches ich klar als Listenzeichen verwendet habe) auch verstanden, sonst hättest Du konsequenterweise auch dazu etwas schreiben müssen. Auch hier kann das schnell nach Polemik riechen.[/quote]

Das war auch eindeutiger Kommentar erkennbar, mit einem Punkt am ende. Der andere war einfach nur ein Stichpunkt, kein satz, kein erkennbarer Kommentar. Wie gesagt, reine fehlinterpretation.

So langsam wünschte ich diese Forum haette einen Usenet-Zugang. So lange Texte machen in dem schmalen Editor hier nicht wirklich laune 🙄

rincewind hat geschrieben:

Ja, aber es wird nicht kompiliert. Nichts erzeugt. Alles ist schon da.

Wo schreibe ich denn bitte, dass der Interpreter etwas kompiliert? Hallo?

Im ursprünglichen Zitat mit dem unsere Diskussion startete (welches allerdings nicht von dir stammte) war die rede davon das Interpreter Komilieren.Und auch sonst redest du die ganze Zeit davon das ein Interpreter etwas in Maschinencode übersetzt.

Reden wir jetzt über dasselbe, nur in verschiedenen Ecken?

Chaoswind hat geschrieben:

rincewind hat geschrieben:

Der innere Aufbau ist nicht irrelevant, da ich darüber geschrieben habe (allerdings habe ich das anscheinend nicht deutlich genug gemacht), als ich die Vergleiche angestellt habe. Abgesehen davon hängt die Arbeitsweise de Compilers vom inneren Aufbau ab, aber das wissen wir sicher beide.

Was interessiert mich der Modulare Aufbau eines Compilers? Das prinzipielle Vorgang ist immer identisch, und alleine darum diskutieren wir doch. Ob der Compiler nun die einzelnen Aufgabenteile an verschiedene Module weiterleitet oder aus einer riesigen Funktion besteht, aendert an der Aufgabe 'Sprache A nach Sprache B übersetzen' doe überhaupt nichts.

Zum Teil ja, zum Teil nein. Stellenweise haben wir über den prinzipiellen Vorgang diskutiert, an anderen Stellen habe ich über den inneren Aufbau gesprochen.
Chaoswind hat geschrieben:

rincewind hat geschrieben:

Was meinst Du mit "alles in ein Programm klatschen?" Was ist alles? Wenn Du ungenaue Aussagen triffst, darfst Du Dich nicht über ungenaue Antworten beschweren.

Alles an Funktionalitaet die ein Compiler bietet. Das Ergebniss aendert sich nicht, egal wie der Compiler seine Funktionen verteilt. Aber das hab ich nun schon oft genug geschrieben. Ausser den fuer seine Arbeit notwendigen Funktionen, fuehrt ein Compiler keine Funktionen aus. Insofern ist es vollkommen irrelevant fuer das Konstrukt Compiler wie er im inneren tickt. Wichtig ist wie er sich nach aussen hin verhaelt.

Die inneren Werte des Compilers sind sehr wohl interessant, wenn man sich mit der Materie weiter bschäftigen will. Klar ist es egal wie der Compiler seine Funktionen verteilt, da sind wir uns einig.
Chaoswind hat geschrieben:

rincewind hat geschrieben:

Da bin ich nicht der Einzige. Aber Du hast recht, ich hatte es nicht explizit geschrieben, wahrscheinlich bin ich davon ausgegangen, dass man es zwischen den Zeilen lesen kann da ich nichts dagegen schrieb. Ein Fehler, wie jetzt klar wird. Ich versuche mich zu bessern und klarere Formulierungen zu benutzen.

Nun, du hast es unkommentiert und in entsprechender Formulierung an die Liste gehaengt. Ausserdem hast du dasselbe auch an anderer stelle behauptet. Da ist das mit zwischen den Zeilen lesen etwas schwierig, wenn die Zeilen das genaue gegenteil behaupten.

Wo habe ich behauptet, dass eine Compiler den Maschinencode ausführt? Ich habe nicht betont, dass er das nicht macht, weil ich es für völlig klar hielt.
Chaoswind hat geschrieben:

rincewind hat geschrieben:

Chaoswind hat geschrieben:

Der Code existiert bereits und der Interpreter entscheidet lediglich welcher Code wann und mit welchen Parametern ausgeführt wird.

Das ist so lange richtig, wie man ausschließlich externe Programme durch ein interpretiertes Skript aufrufen lässt.
Damit würde man einen Interpreter aber zu einfach darstellen und alle (mittlerweile) normalen Sprachkonstrukte wie Bedingungen, Schleifen, Variablen etc. unter den Tisch fallen lassen. Das Bild ist so auf jeden Fall verzerrt und nicht richtig. Selbst batches haben gewisse Zusatzfeatures, die man beachten sollte.

Nein, das sind alles Funktionen die auf der Physikalischen Maschine laufen. Meine güte, ein Taschenrechner erzeugt doch auch keinen Code nur weil er ein paar Zahlen in den Speicher laedt und verrechnet.

rincewind hat geschrieben:

Der Interpreter schaut ein Komando/eine Zeile in seiner Übersetzungstabelle nach und schickt die Entsprechung als Maschinencode zum Prozessor, der ihn daraufhin ausführt. Ob das nun ein in den Interpreter eingebautes Kommando ist oder ein Aufruf eines externes Programmes stellt einen Unterschied dar, ich beziehe mich hier auf ein internes Kommando wegen der schon angesprochen meiner Meinung nach zu starken Simplifizierung. Der Interpreter muss am Ende Maschinencode ausgeben, da der Prozessor nur Maschinencode versteht. Dieser Maschinencode ist natürlich generiert/erstellt/erschaffen worden (und zwar aus den vorhandenen Übersetzungstabellen), denn vor der Interpretation war er so nicht vorhanden. Als Beispiel möchte ich hier Variablen nennen, die zur Laufzeit verändert werden.

So betrachtet, ist ausnahmslos jedes Programm ein Compiler und Interpreter.

Im Prinzip ist es auch so.
Chaoswind hat geschrieben:

rincewind hat geschrieben:

Der Compiler schaut genauso in seiner Übersetzungstabelle nach und gibt die Entsprechung von Funktionen (ich meine Funktionsaufrufe, nicht Definitionen von Funktionen im Quelltext) in Maschinencode in eine Binary, welche dann irgendwann vom Benutzer über das OS ausgeführt werden kann. Auch hier wird Maschinencode generiert/erstellt/erschaffen (und zwar auch aus den vorhandenen Übersetzungstabellen).

So betrachtet stimmt das an und fuer sich, mit dem unterschied das du es IMHO auf einer viel zu tiefen ebenen betrachtest.

Genau auf der Ebene ist es für mich interessant. Wahrscheinlich aber für ein Programmierforum innerhalb eines Linuxforums nicht.
Chaoswind hat geschrieben:

rincewind hat geschrieben:

Fast jeder reale Interpreter hat eingebaute Befehle

Ich glaube ich hab das schon mehrmals erwaehnt, aber es ging mir hier immer um den reinen unoptimierten klassischen Interpreter. Und das mit den internen und externen Funktionen hab ich nur als Beispiel zur veranschaulichung gebracht, um klar zu machen ein Interpreter deligiert und nicht übersetzt.

Wie gesagt beim absolut reinen (=dummen) Interpreter sind wir uns doch einig.
Chaoswind hat geschrieben:

rincewind hat geschrieben:

Chaoswind hat geschrieben:

Das gilt wie gesagt fuer die reinen Programme.

Das ist zu ungenau. Was sind "reine Programme"?

Reine unoptimierte Interpreter, wie z.b. die Bash. Nichts wo irgendein Compiler zwischengeschaltet ist, oder andere Performanceverbesserungen benutzt werden. Das der Übergang fliessend ist und in der Realitaet niemals nur die reine Lehre anzutreffen ist, ist klar.

Du verstehst sicher, dass es schwierig wird vom Begriff "reine Programme" auf einen Interpreter zu schliessen. Aber damit wäre dass ja auch geklärt und auch in dem Punkt scheinen wir uns einig zu sein.
Chaoswind hat geschrieben:

rincewind hat geschrieben:

Chaoswind hat geschrieben:

Aber mittlerweile hat sich da ganze ja vermischt. Die Interpreter haben noch einen Compiler der vorher den Quelltext optimiert, bevor dann der Interpreter (aka Virtuelle Maschine) den Code interpretiert und die Entsprechenden Funktionen der Physikalischen Maschine aufruft.

Hier stimme ich Dir zu. Allerdings könnte ich Dir jetzt die Gleichsetzung von Interpreter und VM per aka negativ auslegen und Dich fragen, was genau Du mit den "Entsprechenden Funktionen" meinst, ich habe aber verstanden, was Du damit sagen willst.

Funktion im sinn von die Maschine macht irgendwas, nicht als Bauteil Modularer Programmierung. Ok, ist etwas salopp formuliert. Du kannst es auch gerne (Hardware)Befehle oder wie auch immer nennen.

War eigentlich eine rhetorische Frage, ich hatte Dich ja auch so verstanden 😉
Chaoswind hat geschrieben:

rincewind hat geschrieben:

Chaoswind hat geschrieben:

Ach? Dann entschuldige. Du hast aber dann tatseachlich eine effiziente art der tauschung 😉

Siehe oben. Bitte stell Dich nicht dumm, ein paar Zeilen weiter hast Du im gleichen Post beim Bytecode-Interpreter die Zeile ohne Minus (welches ich klar als Listenzeichen verwendet habe) auch verstanden, sonst hättest Du konsequenterweise auch dazu etwas schreiben müssen. Auch hier kann das schnell nach Polemik riechen.

Das war auch eindeutiger Kommentar erkennbar, mit einem Punkt am ende. Der andere war einfach nur ein Stichpunkt, kein satz, kein erkennbarer Kommentar. Wie gesagt, reine fehlinterpretation.[/quote] Ich hätte das deutlicher ausdrücken sollen, sehe ich ein.
Chaoswind hat geschrieben:

So langsam wünschte ich diese Forum haette einen Usenet-Zugang. So lange Texte machen in dem schmalen Editor hier nicht wirklich laune 🙄

Absolute Zustimmung. Vor allen Dingen funktionieren ab einer gewissen Länge die kleinen Helferlein wie Zitat teilen nicht mehr zuverlässig 🙄

Chaoswind hat geschrieben:

rincewind hat geschrieben:

Ja, aber es wird nicht kompiliert. Nichts erzeugt. Alles ist schon da.

Wo schreibe ich denn bitte, dass der Interpreter etwas kompiliert? Hallo?

Im ursprünglichen Zitat mit dem unsere Diskussion startete (welches allerdings nicht von dir stammte) war die rede davon das Interpreter Komilieren.Und auch sonst redest du die ganze Zeit davon das ein Interpreter etwas in Maschinencode übersetzt.

Reden wir jetzt über dasselbe, nur in verschiedenen Ecken?

Ja. Das habe ich auch schon versucht zu erklären. Wir sind uns eigentlich einig, reden aber in verschieden Ebenen (ohne Wertung gemeint) bzw. anderen Sprachen

rincewind hat geschrieben:

Chaoswind hat geschrieben:

So betrachtet, ist ausnahmslos jedes Programm ein Compiler und Interpreter.

Im Prinzip ist es auch so.

Hm, damit hast du aber eine recht einzigartige Sicht, vor allem aber eine IMHO extrem vereinfachte.

rincewind hat geschrieben:

Genau auf der Ebene ist es für mich interessant. Wahrscheinlich aber für ein Programmierforum innerhalb eines Linuxforums nicht.

Das hat weniger etwas mit dem ort, als mit der recht ungewöhnlichen Sicht zu tun. So wenige Studierte scheinen sich hier ja auch nicht aufzuhalten.

rincewind hat geschrieben:

Chaoswind hat geschrieben:

So langsam wünschte ich diese Forum haette einen Usenet-Zugang. So lange Texte machen in dem schmalen Editor hier nicht wirklich laune 🙄

Absolute Zustimmung. Vor allen Dingen funktionieren ab einer gewissen Länge die kleinen Helferlein wie Zitat teilen nicht mehr zuverlässig 🙄

Ich glaub nicht das die Software da prinzipielle probleme hat. Eher verrutscht der Umbruch mit der Zeit und wir haben einfach keine möglichkeit sauber die Marker zu setzen. BBCode ist einfach Menschenunfreundlich an dem Punkt.

Chaoswind hat geschrieben:

rincewind hat geschrieben:

Chaoswind hat geschrieben:

So betrachtet, ist ausnahmslos jedes Programm ein Compiler und Interpreter.

Im Prinzip ist es auch so.

Hm, damit hast du aber eine recht einzigartige Sicht, vor allem aber eine IMHO extrem vereinfachte.

Nicht wirklich einzigartig. Analog zu Linux: alles ist eine Datei 😉
Ich denke, es kommt darauf an, in welchem Bereich man programmiert, welche Paradigmen man beherrscht/einsetzt und welche Erfahrungen dabei man macht. Das meine Sicht für einen Entwickler, der z.B. unter Gnome oder KDE mit den entsprechenden Bibliotheken arbeitet ungewohnt erscheinen mag, leuchtet mir ein.
Chaoswind hat geschrieben:

rincewind hat geschrieben:

Genau auf der Ebene ist es für mich interessant. Wahrscheinlich aber für ein Programmierforum innerhalb eines Linuxforums nicht.

Das hat weniger etwas mit dem ort, als mit der recht ungewöhnlichen Sicht zu tun. So wenige Studierte scheinen sich hier ja auch nicht aufzuhalten.

Naja, einen Bezug zum "studiert haben" sehe ich hier eigentlich nicht wirklich, ist aber wohl Ansichtsache und eher eine andere Diskussion.
Chaoswind hat geschrieben:

Ich glaub nicht das die Software da prinzipielle probleme hat. Eher verrutscht der Umbruch mit der Zeit und wir haben einfach keine möglichkeit sauber die Marker zu setzen. BBCode ist einfach Menschenunfreundlich an dem Punkt.

Egal wie, es nervt 😉

rincewind hat geschrieben:

Chaoswind hat geschrieben:

Aber mittlerweile hat sich da ganze ja vermischt. Die Interpreter haben noch einen Compiler der vorher den Quelltext optimiert, bevor dann der Interpreter (aka Virtuelle Maschine) den Code interpretiert und die Entsprechenden Funktionen der Physikalischen Maschine aufruft.

Hier stimme ich Dir zu. Allerdings könnte ich Dir jetzt die Gleichsetzung von Interpreter und VM per aka negativ auslegen und Dich fragen, was genau Du mit den "Entsprechenden Funktionen" meinst, ich habe aber verstanden, was Du damit sagen willst.

Zumindest bei Java ist das nicht so.
Die VM bekommt den Quelltext gar nicht zu sehen, sondern optimiert den Bytecode.