Was sind die Motivationen hinter kompilieren von byte-code?
Ich bin arbeiten, mein eigenes Spielzeug Programmiersprache. Für jetzt bin ich der Interpretation des source-Sprache von AST und ich Frage mich, welche Vorteile das kompilieren in ein byte-code und dann interpretieren, könnte es mir zur Verfügung stellen.
Denn jetzt habe ich drei Dinge im Auge:
- Traversierung des syntaxbaums hundert mal langsamer als die Ausführung von Anweisungen in einem array, insbesondere, wenn die array-Unterstützung O(1) random access(ie. springen 10 Anweisungen oben und unten).
- In typisierten Ausführung Umgebung, ich habe einige run-time-Kosten, weil mein AST ist eingegeben, und ich bin ständig Durchlaufen es(ie. Ich habe 10 verschiedene Arten von Knoten, und ich brauche, um zu überprüfen, welche Art ich bin auf jetzt ausführen). Vielleicht kompilieren, um eine nicht typisierte byte-code kann helfen, das zu verbessern, da nach der Typprüfung und Kompilierung, ich hätte eine nicht typisierte Werte und code.
- Kompilieren von byte-code kann bessere Portabilität.
Sind meine Punkte richtig? Was sind einige andere Motive hinter kompilieren zu bytecode?
- Durch das laufen auf einem Interpret erhöht es die Portabilität des Codes
- ja, das war schon in meinem Kopf, ich vergaß hinzuzufügen ..
- das ist falsch. Serialisiert ASTs werden können, die gleichermaßen tragbar. Bytecode kann in der Tat nicht tragbar; Python-bytecode ist spezifisch für jede version des interpreters.
- Es ist auch einfacher, als die Interpretation einer AST - bytecode sollte low-level genug. Zusammenstellung einer high-level-Sprache, um eine bytecode-ist einfacher als die Interpretation einer high-level Sprache sofort. E. g., anstatt die Aufrechterhaltung einer Umgebung mit komplizierten Semantik, anstatt sich bis auf Variablen-Namen, etc., Sie müssen nur eine einfache stack-frame der Zugriff über einfaches load-und store-Anweisungen.
Schreibe einen Kommentar
Du musst angemeldet sein, um einen Kommentar abzugeben.
Geschwindigkeit ist der Hauptgrund; Auswertung ASTs ist einfach zu langsam in der Praxis.
Ein weiterer Grund für die Verwendung von bytecode ist, dass es trivial serialisiert (gespeichert auf der Festplatte), so dass Sie es zu verteilen. Dies ist, was Java tut.
Den Punkt der Erzeugung von byte-code (oder anderen "leicht " interpretiert" form wie threaded code) ist im wesentlichen die Leistung.
Für ein AST-intepreter zu entscheiden, was als Nächstes zu tun, die es braucht, die zum Durchlaufen des Baums, Knoten untersuchen, bestimmen den Typ der Knoten, überprüfen Sie den Typ eines Operanden, überprüfen Sie die Rechtmäßigkeit und entscheiden, welche speziellen Fall der AST-designated operator gilt (es heißt "+", aber es bedeutet, dass 16 bit hinzufügen oder string verketten?), bevor es schließlich führt eine Aktion.
Nimmt man die Letzte Handlung und erzeugt eine Art von leicht interpretiert die Struktur, dann auf "Ausführung" Zeit der interpreter kann einfach nur auf Handlungen durchführen, ohne, dass die überprüfung/Besondere-case-Bestimmung.
Anderen aktuellen Ausrede ist, dass wenn Sie generiert byte-code für eine beliebige Anzahl von gut bekannten virtuellen Maschinen (JVM, MSIL, Parrot, etc.) Sie haben nicht einmal-code-interpreter. Für die JVM und MSIL, erhalten Sie auch den Vorteil des JIT-compilers mit Ihnen verbunden sind, und mit einer sorgfältigen Gestaltung der Sprache ist, die Kompatibilität mit sehr großen Bibliotheken, die die eigentliche Attraktion von Java und C#.