Soll ich also annehmen, dass der interpretierte Teil eine Anforderung in der Sprachspezifikation ist, oder ist es irreführend zu sagen, dass die Sprache eine interpretierte Programmiersprache ist, wenn der Unterschied zwischen einer Sprache und ihren vielen Implementierungen beachtet wird?
EcmaScript-Experten verwenden häufig den Begriff "ES-Interpreter", um sich auf eine Implementierung von EcmaScript zu beziehen, in der Spezifikation wird dieser Begriff jedoch nicht verwendet. Die Sprache im Überblick beschreibt insbesondere die Sprache , in Interpreter unabhängigen Bedingungen:
ECMAScript ist objektbasiert: Grundlegende Sprach- und Hostfunktionen werden von Objekten bereitgestellt, und ein ECMAScript-Programm ist ein Cluster kommunizierender Objekte.
Daher geht EcmaScript von einer "Host-Umgebung" aus, die als Anbieter von Objektdefinitionen definiert ist, einschließlich aller Objekte, die E / A oder andere Links zur Außenwelt zulassen, jedoch keinen Interpreter erfordern.
Die Semantik von Anweisungen und Ausdrücken in der Sprache wird in Form von Vervollständigungsspezifikationen definiert, die in einem Interpreter trivial implementiert sind, die Spezifikation erfordert dies jedoch nicht.
8.9 Der Fertigstellungsspezifikationstyp
Die Fertigstellung Typ wird verwendet , um das Verhalten von Aussagen zu erklären ( break, continue, returnund throw) , die nicht - lokale Transfers von Steuer auszuführen. Werte des Completion - Typs sind Tripel der Form ( Typ , Wert , Ziel ), wobei Typ eines ist normale , bricht , weiterhin , Rückkehr oder werfen , Wert ist jeder ECMAScript Sprache Wert oder leer , und Ziel ist irgendein ECMAScript Identifikator oder leer .
Der Begriff „abrupte Fertigstellung“ bezieht sich auf jede Fertigstellung mit einem anderen als dem normalen Typ .
Die nicht-lokalen Steuerübertragungen können in Anordnungen von Anweisungen mit Sprüngen konvertiert werden, die eine native oder Bytecode-Kompilierung ermöglichen.
"EcmaScript Engine" ist möglicherweise eine bessere Möglichkeit, dieselbe Idee auszudrücken.
Es gibt anscheinend keine statischen Compiler für JavaScript
Das ist nicht wahr. Der "Interpreter" von V8 kompiliert intern in nativen Code, Rhino kompiliert optional intern in Java-Bytecode und verschiedene Mozilla-Interpreter ({Trace, Spider, Jager} Monkey) verwenden einen JIT-Compiler.
V8 :
V8 erhöht die Leistung, indem JavaScript vor der Ausführung in systemeigenen Maschinencode kompiliert wird, anstatt Bytecode auszuführen oder ihn zu interpretieren.
Rhino :
public final void setOptimizationLevel(int optimizationLevel)
Stellen Sie die aktuelle Optimierungsstufe ein. Es wird erwartet, dass die Optimierungsstufe eine ganze Zahl zwischen -1 und 9 ist. Alle negativen Werte werden als -1 interpretiert, und alle Werte über 9 werden als 9 interpretiert. Eine Optimierungsstufe von -1 gibt an, dass der Interpretationsmodus immer aktiv ist benutzt. Die Stufen 0 bis 9 geben an, dass möglicherweise Klassendateien generiert werden. Bei höheren Optimierungsstufen wird die Leistung zur Kompilierungszeit in Relation zur Laufzeitleistung gesetzt. Die Optimierungsstufe kann nicht größer als -1 festgelegt werden, wenn das Optimierungspaket zur Laufzeit nicht vorhanden ist.
TraceMonkey :
TraceMonkey erweitert Mozillas JavaScript®-Engine (bekannt als „SpiderMonkey“) um native Code-Kompilierung. Es basiert auf einer an der UC Irvine entwickelten Technik namens "trace trees" und baut auf Code und Ideen auf, die mit dem Tamarin Tracing-Projekt geteilt wurden. Das Nettoergebnis ist eine massive Geschwindigkeitssteigerung sowohl im Browser-Chrome als auch im Webseiteninhalt.