tobiasschulz
Anmeldungsdatum: 31. Mai 2006
Beiträge: 339
Wohnort: /root/
|
Sid Burn hat geschrieben: Ich bin während der Suche auf Perl + SDL, pygame etc. gestoßen, kann aber nicht beurteilen, ob das Alternativen wären, denn gerade die Performance sollte schon recht gut sein, da eine Menge (Berechnungen, Animationen, Sounds und Musik) im Hintergrund laufen sollten ohne das die Spielfigur beim Laufen ruckelt... Ist das mit einer Skriptsprache überhaupt zu machen?
Warum sollte es nicht gehen? Beziehungsweise ist es eigentlich Falsch Perl/Python/Ruby als Skriptsprache abzustempeln. Es macht ja auch keiner bei Java. Alle drei genannten Sprachen haben gemeinsam das Sie den Sourcecode VOR der Ausführung in Bytecode umwandeln und dann eine Virtuelle Maschine den Bytecode ausführt. Genau das gleiche was Java auch macht, nur gibt man dort nicht den Sourcecode weiter, sondern man kompiliert sein Programm Manuell nach Bytecode und gibt es dann erst weiter. Ansonsten sind die Sprachen von den Techniken her nicht so großartig unterschiedlich wie mein Meinen würde.
Hmmm. Wikipedia: Scriptsprache
Skriptsprachen (üblich auch Scriptsprachen) sind Programmiersprachen, die vor allem für kleine, überschaubare Programmieraufgaben gedacht sind. Sie verzichten oft auf bestimmte Sprachelemente, deren Nutzen erst bei der Bearbeitung größerer Projekte zum Tragen kommen. So wird etwa in Skriptsprachen auf den Deklarationszwang von Variablen verzichtet – vorteilhaft zur schnellen Erstellung von kleinen Programmen (siehe auch Rapid Prototyping), bei großen hingegen von Nachteil, etwa wegen der fehlenden Überprüfungsmöglichkeit von Tippfehlern in Variablennamen. Programme, die in Skriptsprachen geschrieben sind, werden auch Skripte genannt. Skripte werden fast ausschließlich in Form von Quelltextdateien ausgeliefert, um so ein einfaches Bearbeiten und Anpassen des Programms zu ermöglichen.
Wikipeida: Prg.-sprache
Programmiersprache ist eine formale Sprache zur Erstellung von Verarbeitungsanweisungen für Rechnersysteme. Programmiersprachen drücken Berechnungen sowohl in einer für einen Computer, als auch in einer für den Menschen lesbaren und verständlichen Form aus. Sie sind notwendig, da die natürlichen Sprachen für eine genügend detaillierte und präzise Beschreibung von Computerberechnungen zu vieldeutig sind. Die durch eine Programmiersprache ausgedrückte, von einem Menschen lesbare Beschreibung heißt Quelltext (oder auch Quellcode/Programmcode) (Beispiel "Hallo Welt!"). Den Arbeitsprozess diese Computerprogramme zu erstellen, nennt man Programmieren. Er wird durch Programmierer vorgenommen. Der entstandene Quelltext muss schließlich in eine Anweisungsfolge für den Computer, die Maschinensprache übersetzt werden. Dies ist vergleichbar mit dem Übersetzen von natürlichen Sprachen, jedoch ist dieser Arbeitsschritt durch die Verwendung von Programmiersprachen mittels eines Übersetzungsprogramms automatisierbar. Das Endprodukt dieser Übersetzung nennt man Computerprogramm. Je nachdem, ob diese Übersetzung vor oder während der Ausführung des Computerprogramms erfolgt, unterscheidet man zwischen kompilierenden oder interpretierenden Übersetzungsprogrammen. Es existieren verschiedene Meinungen, welche Eigenschaften eine Programmiersprache besitzen sollte. Allgemein wird jedoch akzeptiert, dass zumindest die grundlegende mathematische Arithmetik ausgedrückt werden können sollte. Oft erscheint der von der Programmiersprache vorgegebene Programmierstil und die Zweckgebundenheit der Programmiersprache wichtig. Eine theoretische Erkenntnis ist die notwendige Eigenschaft der Turing-Vollständigkeit, falls sie die volle Funktionalität des Computers ausnutzen soll; dies kann bis hin zum sich selbst verändernden Programm dienen.
Bei Java wird der Code in Bytecode (= Maschinensprache) umgewandelt. Das hat den Vorteil, dass es von der plattform unabhängig ist, da die Java-VM (wie der Name sagt) eine Virtuelle Maschine ist. Java-Bytecode ist also Maschinencode, der halt nur nicht vom Betriebsystem/Prozessor "interpretiert" wird, sondern von der VM. Fakt ist: Perl, Python und Ruby sind Programmiersprachen.
|
Chaoswind
Anmeldungsdatum: 10. August 2005
Beiträge: 544
|
tobiasschulz hat geschrieben: Bei Java wird der Code in Bytecode (= Maschinensprache) umgewandelt. Das hat den Vorteil, dass es von der plattform unabhängig ist, da die Java-VM (wie der Name sagt) eine Virtuelle Maschine ist. Java-Bytecode ist also Maschinencode, der halt nur nicht vom Betriebsystem/Prozessor "interpretiert" wird, sondern von der VM.
Bei Python und Perl ebenfalls.
|
Sid_Burn
Anmeldungsdatum: 23. Oktober 2004
Beiträge: 2159
|
Nicht alles was bei Wikipedia drin steht ist richtig... Beziehungsweise stimmt es schon was ich geschrieben habe. Hier auch mal einen Ausschnitt aus wikipedia.de Interpreter
Eine weitere Zwischenstufe sind Bytecode-Interpreter. Dabei wird der Quelltext zur Laufzeit vor seiner Ausführung in einen einfachen Zwischencode übersetzt, der dann von einem Interpreter, auch häufig als virtuelle Maschine bezeichnet, ausgeführt wird.
Perl/Python/Ruby sind solche Interpreter die Ihre Skripte VOR der Ausführung zu Bytecode Kompilieren. Letztendlich führen Perl/Python/Ruby auch nur den Bytecode aus. Es sind jedenfalls keine reine Interpretierte Sprachen wo jeder Befehl erst vor seiner Ausführung Kompiliert wird. Wenn du dein Programm weiter gibst dann gibst du halt den Sourcecode weiter. Wenn du das "Skript" aber ausführst wird alles in bytecode kompiliert, und dann erst der Bytecode ausgeführt. Das Programm das den bytecode letztendlich ausführt ist nichts anderes als ein interpreter, nur nennt man das meistens Virtuelle Maschine wenn er Bytecode ausführt. Bei Java gibst du nicht den Sourcecode weiter sondern deinen kompilierten Bytecode. Und der Bytecode wird dann identisch wie bei Perl/Python/Ruby von einer VM ausgeführt. Da man aber halt den Sourcecode weiter gibt, wird es immer noch als Skriptsprache abgestempelt. Wenn man die Technik dahinter genauer betrachtet ist es eigentlich falsch. Allerdings sage ich dazu auch Trotzdem Skriptsprache, weil es halt als Merkmal trägt den Sourcecode weiter zu geben. Letztendlich ist es das selbe als wenn jemand über "Linux" spricht. In den meisten Fällen wird der Begriff falsch verwendet und man meint meistens "GNU/Linux" und eben nicht nur den Kernel "Linux". Wenn man aber über Details spricht sollte man doch den Unterschied zwischen beiden begriffen kennen. Letztendlich kannst du Perl/Python/Ruby sowie auch Java zu den Interpretierten Sprachen zählen. Alle Sprachen benötigen einen Interpreter damit du diese Ausführen kannst. Allerdings ist es wie gesagt ein Spezieller Interpreter der halt Bytecode ausführt und dann meistens Virtuelle Maschine genannt wird. Ändert aber nichts an der Tatsache das du alle genannten Sprachen zu den Interpretierten zählen kannst, und da gehört Java ebenfalls dazu.
Bei Java wird der Code in Bytecode (= Maschinensprache) umgewandelt. Das hat den Vorteil, dass es von der plattform unabhängig ist, da die Java-VM (wie der Name sagt) eine Virtuelle Maschine ist. Java-Bytecode ist also Maschinencode, der halt nur nicht vom Betriebsystem/Prozessor "interpretiert" wird, sondern von der VM.
Um es nochmal deutlich zu machen. Perl/Python/Ruby macht es genauso wie Java. Und Bytecode ist keine Maschinensprache!!! Und das ganze sogar schon länger als es Java gibt. Die allererste Sprache die diese Technik übrhaupt benutzt hat war soweit ich weiß Pascal. Das ist die erste Sprache soweit ich weiß die eine Virtuelle Maschine benutzt hat. Der einzige Unterschied. Perl/Python/Ruby ⇒ Weitergabe des Sourcecode ⇒ Bei Ausführung Kompilierung in Bytecode und Ausführung des Bytecodes in der VM. Java ⇒ Manuelles Kompilieren in bytecode ⇒ Weitergabe von Bytecode ⇒ Ausführung von VM Bei Perl/Python/Ruby sparst du dir also ein Schritt. Bei Perl weiß ich aber zumindest das du den extra Schritt den du bei Java machst trotzdem erledigen kannst. Dafür gibt es das Programm "perlcc" das bei Perl gleich mitgeliefert wird. Du kannst damit Perl in Bytecode kompilieren und dann ausführen lassen, oder auch als eine ELF Binary Kompilieren, so das auf dem Ziel System gar kein Installierter Interpreter(VM) benötigt wird. http://www.heise.de/ix/artikel/2000/07/169/
Kaum eine Frage erscheint so oft in den einschlägigen Newsgroups wie die nach einem Perl-Compiler. Dabei liefert das Programm den Compiler frei Haus: Bei jedem Aufruf eines Skripts durchforstet der Interpreter den Code nach Syntaxfehlern, kompiliert Perl-Konstrukte in internen Bytecode und führt diesen dann mit einer virtuellen Maschine aus.
Allerdings ist das Manuelle Kompilieren nicht von Anfang an eingebaut gewesen. Mit Perl 6 bzw. Parrot wird das aber letztendlich auch Offiziel Unterstützt werden.
|
Chaoswind
Anmeldungsdatum: 10. August 2005
Beiträge: 544
|
Sid Burn hat geschrieben: Perl/Python/Ruby sind solche Interpreter die Ihre Skripte VOR der Ausführung zu Bytecode Kompilieren. Letztendlich führen Perl/Python/Ruby auch nur den Bytecode aus. Es sind jedenfalls keine reine Interpretierte Sprachen wo jeder Befehl erst vor seiner Ausführung Kompiliert wird.
Was meinst du mit Ausführen? Reine Interpretersprachen kompilieren nichts, sondern rufen irgendwelche Funktionen oder (wie im extremfall Bash) sogar externe Programme/Skripte auf. Andererseits, was ist schon wirklich rein heutzutage? :> Sid Burn hat geschrieben:
Wenn du dein Programm weiter gibst dann gibst du halt den Sourcecode weiter. Wenn du das "Skript" aber ausführst wird alles in bytecode kompiliert, und dann erst der Bytecode ausgeführt. Das Programm das den bytecode letztendlich ausführt ist nichts anderes als ein interpreter, nur nennt man das meistens Virtuelle Maschine wenn er Bytecode ausführt. Bei Java gibst du nicht den Sourcecode weiter sondern deinen kompilierten Bytecode. Und der Bytecode wird dann identisch wie bei Perl/Python/Ruby von einer VM ausgeführt.
Ich weiss nicht wie das bei Perl ist, aber in Python kann man auch die kompilierten Dateien weitergeben. Sid Burn hat geschrieben:
Da man aber halt den Sourcecode weiter gibt, wird es immer noch als Skriptsprache abgestempelt. Wenn man die Technik dahinter genauer betrachtet ist es eigentlich falsch. Allerdings sage ich dazu auch Trotzdem Skriptsprache, weil es halt als Merkmal trägt den Sourcecode weiter zu geben.
Skriptsprache wird mittlerweile vor allem für die abstraktionsebene benutzt. Steht ja schon im Wikipedia-Artikel. Die Sprachen sind einfacher und verzichten auf verschiedene kontrollmöglichkeiten die eine schnelle Entwicklung ausbremsen. Sid Burn hat geschrieben:
Um es nochmal deutlich zu machen. Perl/Python/Ruby macht es genauso wie Java. Und Bytecode ist keine Maschinensprache!!! Und das ganze sogar schon länger als es Java gibt. Die allererste Sprache die diese Technik übrhaupt benutzt hat war soweit ich weiß Pascal. Das ist die erste Sprache soweit ich weiß die eine Virtuelle Maschine benutzt hat.
Was ist mit Lisp? Wurde da nicht auch von anfang an interpretiert?
|
rincewind
Anmeldungsdatum: 6. Dezember 2004
Beiträge: 415
Wohnort: /Universum/Erde /Europa/Deutschland /Hessen/MR/Marburg
|
Juchhu, eine Diskussion um Interpreter und VM 🙄 Vielleicht können wir ja einen neuen Thread dafür aufmachen oder einen der Alten wiederbeleben... ...egal. Chaoswind hat geschrieben: Sid Burn hat geschrieben: Perl/Python/Ruby sind solche Interpreter die Ihre Skripte VOR der Ausführung zu Bytecode Kompilieren. Letztendlich führen Perl/Python/Ruby auch nur den Bytecode aus. Es sind jedenfalls keine reine Interpretierte Sprachen wo jeder Befehl erst vor seiner Ausführung Kompiliert wird.
Was meinst du mit Ausführen? Reine Interpretersprachen kompilieren nichts, sondern rufen irgendwelche Funktionen oder (wie im extremfall Bash) sogar externe Programme/Skripte auf.
Richtig, deshalb hat Sid Burn ja auch erklärt, an welchen Punkten sich Perl/Python/Ruby von den reinen Interpretersprachen unterscheiden. Chaoswind hat geschrieben: Die Sprachen sind einfacher und verzichten auf verschiedene kontrollmöglichkeiten die eine schnelle Entwicklung ausbremsen.
Den Punkt verstehe ich nicht. Was meinst Du z.B. mit "Ausbremsen der schnellen Entwicklung"? Könntest Du das erläutern?
|
tobiasschulz
(Themenstarter)
Anmeldungsdatum: 31. Mai 2006
Beiträge: 339
Wohnort: /root/
|
rincewind hat geschrieben: Chaoswind hat geschrieben: Die Sprachen sind einfacher und verzichten auf verschiedene kontrollmöglichkeiten die eine schnelle Entwicklung ausbremsen.
Den Punkt verstehe ich nicht. Was meinst Du z.B. mit "Ausbremsen der schnellen Entwicklung"? Könntest Du das erläutern?
Er meint wohl, dass mit Scriptsprachen die Entwicklung schneller geht, da auf kontrollmöglichkeiten verzichtet wird, die die Entwicklung verlangsaamen.
|
rincewind
Anmeldungsdatum: 6. Dezember 2004
Beiträge: 415
Wohnort: /Universum/Erde /Europa/Deutschland /Hessen/MR/Marburg
|
tobiasschulz hat geschrieben: Er meint wohl, dass mit Scriptsprachen die Entwicklung schneller geht, da auf kontrollmöglichkeiten verzichtet wird, die die Entwicklung verlangsaamen.
Ja ok, jetzt hat es klick gemacht, danke ☺ Aber mich wuerden dann noch die bei Skriptsprachen fehlenden verschiedenen Kontrollmoeglichkeiten interessieren.
|
Chaoswind
Anmeldungsdatum: 10. August 2005
Beiträge: 544
|
rincewind hat geschrieben:
Chaoswind hat geschrieben: Sid Burn hat geschrieben: keine reine Interpretierte Sprachen wo jeder Befehl erst vor seiner Ausführung Kompiliert wird.
Was meinst du mit Ausführen? Reine Interpretersprachen kompilieren nichts, sondern rufen irgendwelche Funktionen oder (wie im extremfall Bash) sogar externe Programme/Skripte auf.
Richtig, deshalb hat Sid Burn ja auch erklärt, an welchen Punkten sich Perl/Python/Ruby von den reinen Interpretersprachen unterscheiden.
Lies das Quoting noch mal durch 😉 rincewind hat geschrieben: Chaoswind hat geschrieben: Die Sprachen sind einfacher und verzichten auf verschiedene kontrollmöglichkeiten die eine schnelle Entwicklung ausbremsen.
Den Punkt verstehe ich nicht. Was meinst Du z.B. mit "Ausbremsen der schnellen Entwicklung"? Könntest Du das erläutern?
Keine Variablendeklaration, keine zeitaufwendige Typisierung, etc. Alles halt was die Arbeit verlangsamt und fuer die Entwicklung an sich nicht notwendig ist.
|
rincewind
Anmeldungsdatum: 6. Dezember 2004
Beiträge: 415
Wohnort: /Universum/Erde /Europa/Deutschland /Hessen/MR/Marburg
|
Chaoswind hat geschrieben: Lies das Quoting noch mal durch 😉
Hab ich getan... Trotzdem setzt ein Interpreter jede zu interpretierende Zeile in irgendeiner Form nacheinander in Maschinencode um und fuehrt sie aus. Man kann sich streiten, ob man das "kompilieren" nennen kann. Mag sein, dass ich da jetzt gerade auf der Leitung stehe (seit gestern ein Weiheitszahn weniger ☹)... Chaoswind hat geschrieben: Keine Variablendeklaration, keine zeitaufwendige Typisierung, etc. Alles halt was die Arbeit verlangsamt und fuer die Entwicklung an sich nicht notwendig ist.
Ok, Variablendeklaration ist eine Einstellungssache, beim Rest ack.
|
Chaoswind
Anmeldungsdatum: 10. August 2005
Beiträge: 544
|
rincewind hat geschrieben: Chaoswind hat geschrieben: Lies das Quoting noch mal durch 😉
Hab ich getan... Trotzdem setzt ein Interpreter jede zu interpretierende Zeile in irgendeiner Form nacheinander in Maschinencode um und fuehrt sie aus. Man kann sich streiten, ob man das "kompilieren" nennen kann.
[/quote] Der Klassische Interpreter analysiert einen Text und ruft jeweils passende Funktionn auf. Ein Compiler dagegen wandelt einen Text aus eine Sprache in eine andere. Und das ist dann exakt der unterschied zwischen beiden vorgängen. Man könnte auch sagen der eine Deligiert, und der andere Diktiert.
|
rincewind
Anmeldungsdatum: 6. Dezember 2004
Beiträge: 415
Wohnort: /Universum/Erde /Europa/Deutschland /Hessen/MR/Marburg
|
Chaoswind hat geschrieben: Der Klassische Interpreter analysiert einen Text und ruft jeweils passende Funktionn auf. Ein Compiler dagegen wandelt einen Text aus eine Sprache in eine andere.
Hm. Ein Interpreter analysiert den Quelltext eines Skriptes und ruft jeweils eine passende Funktion auf. Man koennte also sagen, er wandelt durch den Aufruf der passenden Funktion die aktuelle Zeile des Quelltextes des Skriptes in Maschinencode um. Man koennte also sagen, er wandelt einen Text in eine dem Rechner verstaendliche Sprache um. Ein Compiler analysiert also den Quelltext des Programmes und setzt ihn gesamtheitlich in eine dem Rechner verstaendliche Sprache um. Auch er macht das durch Aufrufe von Funktionen. Beide uebersetzen also eine Sprache (Quelltext) durch den Aufruf von Funktionen in eine Andere. Der Unterschied ist dann also der Zeitpunkt, an dem die Uebersetzung stattfindet. Ob man beides nun Kompilieren nennt oder nicht, swie gesagt, darueber kann man streiten. Beispiel: Ich schreibe einen eigenen Interpreter (rincewindMegaSkript) in C. Den Interpreter muss ich natuerlich kompilieren, er liegt also in Maschinencode vor. Dann schreibe ich ein Skript und lasse es meinen Interpreter ausfuehren. Folglich uebersetzt mein Interpreter den in rincewindMegaSkript geschriebenen Quelltext Zeile fuer Zeile durch den Aufruf der passenden Funktionen in Maschinencode und fuehrt ihn aus. Jetzt kommt noch der Bytecode-Interpreter ins Spiel: Hier passiert im Prinzip fast das gleiche wie im Beispiel, nur das eben nicht Zeile fuer Zeile uebersetzt wird, sondern das Skript als Ganzes erst in Bytecode transformiert und dann erst in einer VM ausgefuehrt (also in Maschinensprache uebersetzt) wird. Und das ist so bei Perl und Python, von Ruby habe ich keine Ahnung. Hier wird also in zwei Stufen uebersetzt. Und genau diesen Unterschied von Bytecode-Interpreter zum Interpreter hat Sid Burn erklaert. BTW, der Wikipedia-Artikel ist in der Tat ein wenig seltsam, z.B. ist Python als Interpreter- und als Bytecodesprache aufgefuehrt, Perl aber nicht...
|
Chaoswind
Anmeldungsdatum: 10. August 2005
Beiträge: 544
|
rincewind hat geschrieben: Ein Interpreter analysiert den Quelltext eines Skriptes und ruft jeweils eine passende Funktion auf. Man koennte also sagen, er wandelt durch den Aufruf der passenden Funktion die aktuelle Zeile des Quelltextes des Skriptes in Maschinencode um.
Nein. Er generiert die Funktion nicht, die existiert bereits. rincewind hat geschrieben:
Ein Compiler analysiert also den Quelltext des Programmes und setzt ihn gesamtheitlich in eine dem Rechner verstaendliche Sprache um. Auch er macht das durch Aufrufe von Funktionen.
Nein. Ein Compiler nimmt ein Wort und findet heraus wie es in der Zielsprache heisst. Dazu ruft er keine anderen Funktionen auf, ausser jene die ihm zur Analyse dienen. rincewind hat geschrieben: Beide uebersetzen also eine Sprache (Quelltext) durch den Aufruf von Funktionen in eine Andere.
Interpreter übersetzen nicht, sie fuehren aus. Ein Webbrowser generiert auch keinen Bytecode, nur weil er ein HTML-Dokument interpretiert.
|
rincewind
Anmeldungsdatum: 6. Dezember 2004
Beiträge: 415
Wohnort: /Universum/Erde /Europa/Deutschland /Hessen/MR/Marburg
|
Chaoswind hat geschrieben: rincewind hat geschrieben: Ein Interpreter analysiert den Quelltext eines Skriptes und ruft jeweils eine passende Funktion auf. Man koennte also sagen, er wandelt durch den Aufruf der passenden Funktion die aktuelle Zeile des Quelltextes des Skriptes in Maschinencode um.
Nein. Er generiert die Funktion nicht, die existiert bereits.
? Das klingt so, als koennte man bei einem Compiler Funktionen benutzen, die es nicht gibt... Dass meinst Du aber sicher nicht. Chaoswind hat geschrieben: rincewind hat geschrieben:
Ein Compiler analysiert also den Quelltext des Programmes und setzt ihn gesamtheitlich in eine dem Rechner verstaendliche Sprache um. Auch er macht das durch Aufrufe von Funktionen.
Nein. Ein Compiler nimmt ein Wort und findet heraus wie es in der Zielsprache heisst. Dazu ruft er keine anderen Funktionen auf, ausser jene die ihm zur Analyse dienen.
Ein Interpreter nimmt ein Wort und findet heraus wie es in der Zielsprache heisst. Nochmal ausfuehrlicher: Ein Compiler macht im Groben folgendes: - Lexikalische Analyse des kompletten Codes - syntaktische Analye des kompletten Codes - semantische Analyse des kompletten Codes - Erzeugen von Metacode - Codoptimierung - Codegenerierung Ausfuehrung des Codes als Maschinencode Ein Interpreter macht im Groben folgendes: - Lexikalische Analyse der aktuellen Zeile - syntaktische Analye der aktuellen Zeile - semantische Analyse der aktuellen Zeile - Ausfuehrung des der aktuellen Zeile entsprechenden Maschinencodes Ein Bytecode-Interpreter im Groben macht folgendes: - Lexikalische Analyse des kompletten Codes - syntaktische Analye des kompletten Codes - semantische Analyse des kompletten Codes - Erzeugen von Metacode des kompletten Codes - Codoptimierung des kompletten Codes - Bytecodegenerierung des kompletten Codes - Ausfuehrung von Bytecode in einer VM Eine Vm setzt am Ende den Bytecode auch nur in Maschinensprache um. Chaoswind hat geschrieben: rincewind hat geschrieben: Beide uebersetzen also eine Sprache (Quelltext) durch den Aufruf von Funktionen in eine Andere.
Interpreter übersetzen nicht, sie fuehren aus. Ein Webbrowser generiert auch keinen Bytecode, nur weil er ein HTML-Dokument interpretiert.
Nein, das macht ein Webbrowser in der Tat nicht, sonst waere es ein Bytecode-Interpreter. Was fuehren Interpreter denn Deiner Meinung nach aus? Natuerlich uebersetzen Interpreter, deshalb heissen sie ja auch so (Interpretieren = Auslegen, Uebersetzen). Wenn Du per Skript ein "druck_aus()" an den Interpreter schickst, schaut der nach welche Entsprechung "druck_aus()" die in dem jeweiligen Maschinencode hat (bzw. bricht er es vorher noch in viele kleine Haeppchen herunter) und fuehrt den dann aus. Genau das macht ein Compiler eben auch, nur zu einem anderen Zeitpunkt. Im Prinzip ist mir das alles voellig wurscht.
|
Chaoswind
Anmeldungsdatum: 10. August 2005
Beiträge: 544
|
rincewind hat geschrieben: Chaoswind hat geschrieben: rincewind hat geschrieben: Ein Interpreter analysiert den Quelltext eines Skriptes und ruft jeweils eine passende Funktion auf. Man koennte also sagen, er wandelt durch den Aufruf der passenden Funktion die aktuelle Zeile des Quelltextes des Skriptes in Maschinencode um.
Nein. Er generiert die Funktion nicht, die existiert bereits.
? Das klingt so, als koennte man bei einem Compiler Funktionen benutzen, die es nicht gibt... Dass meinst Du aber sicher nicht.
Compiler benutzen auch keine Funktionen(ausser jenen fuer ihre Arbeit), sie fuehren das Programm schliesslich nicht aus. Allerdigns erschaffen sie neue Funktionen indem sie die Funktionen die im Quellcode definiert werden, in ausfuehrbaren Code übersetzen. 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. Nochmal ausfuehrlicher: rincewind hat geschrieben:
Ein Compiler macht im Groben folgendes: ... Ausfuehrung des Codes als Maschinencode
Nein, genau das macht ein Compiler nicht. Der Code wird von der Zielmaschine ausgeführt. Ob das jetzt ein realer Prozessor oder eine Virtuelle Maschine, ist da irrelevant. Anderes beispiel. Nimm Wikisyntax die in HTML umgewandelt wird. Das ist an und fuer sich auch ein Kompiliervorgang. Das Endergebniss wird dann aber im Browser umgesetzt, nicht vom Parser/Compiler/Wiki/wie-du-es-nennen-willst.
|
rincewind
Anmeldungsdatum: 6. Dezember 2004
Beiträge: 415
Wohnort: /Universum/Erde /Europa/Deutschland /Hessen/MR/Marburg
|
Chaoswind hat geschrieben: Compiler benutzen auch keine Funktionen(ausser jenen fuer ihre Arbeit), sie fuehren das Programm schliesslich nicht aus. Allerdigns erschaffen sie neue Funktionen indem sie die Funktionen die im Quellcode definiert werden, in ausfuehrbaren Code übersetzen.
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? Ein Compiler ist auch nur ein Programm welches in Maschinencode vorliegt. Vor dem Kompilieren war er mal eine Menge Quelltext mit vielen Funktionen, welche genau festlegen, wie der zu compilierende Quelltext aussehen muss und wie er in Maschinensprache uebersetzt werden muss. Punkt. Natuerlich fuehrt der Compiler das fertige Programm nicht aus. Ich dachte eigentlich, dass ich das auch schon so geschrieben hatte, aber dazu spaeter mehr. Das was Du als "erschaffen von Funktionen" bezeichnest, nenne ich "uebersetzen in Maschinensprache". Die Funktionen werden nicht erschaffen, sie werden einfach moeglichst weit heruntergebrochen, damit sie in Maschinensprache darstellbar sind. Welche "Funktionen" sollten Compiler denn eigentlich benutzen koennen, die nicht zu ihrer "Arbeit" gehoeren? 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. Chaoswind hat geschrieben: Nochmal ausfuehrlicher: rincewind hat geschrieben:
Ein Compiler macht im Groben folgendes: ... Ausfuehrung des Codes als Maschinencode
Nein, genau das macht ein Compiler nicht. Der Code wird von der Zielmaschine ausgeführt. Ob das jetzt ein realer Prozessor oder eine Virtuelle Maschine, ist da irrelevant. Anderes beispiel. Nimm Wikisyntax die in HTML umgewandelt wird. Das ist an und fuer sich auch ein Kompiliervorgang. Das Endergebniss wird dann aber im Browser umgesetzt, nicht vom Parser/Compiler/Wiki/wie-du-es-nennen-willst.
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 wird. Egal ob Prozessor, VM oder sonst etwas. Damit sollte klar werden, dass am Ende IMMER Maschinencode herauskommt, die Unterschiede liegen grob gesagt nur in der Lebensdauer des erstellten Maschinencodes und dem Zeitpunkt der Erstellung (EDIT: und der Aufuehrung des erstellten Codes). 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. Schau Dir bitte mal folgende Links an, auch wenn die Qualitaet schwankt: Compiler Compilerbau Kompilierung Interpreter Bytecode Maschinensprache Weiter Informationen findest Du sicher per Google. EDIT: Vielleicht koennte einer der Supporter/Moderatoren den Teil hier abtrennen und zu einem eigenen Thread machen, denn mit dem Ursprungsthema hat das heir recht wenig zu tun.
|