Epimetheus

Not what you were looking for? try http://www.solarviews.com/eng/epimethe.htm or http://www.theoi.com/Ouranos/Epimetheos.html

Epimetheus is an implementation of the current ECMAScript 4.0 proposal in C++.  It is located in the Mozilla source tree at mozilla/js2. To build, first see the CVS page for details on logging in via CVS, and then:

cvs co mozilla/js2

will pull the complete source tree. In the js2 directory, you'll find a README file that contains details on building. Currently there are Windows (MSVC) and Linux build targets. The build target is a console shell executable that supports loading .js files as well as interactive execution.

Epimetheus implements most of the language as described in the current specification. In addition, a variety of features from the proposal have been added as well as sufficient to enable some ECMAScript3 functionality. For example, the ECMA3 libraries (Date, Math etc) are implemented, but not necessarily conforming exactly to ECMA3 prototype semantics.

Command line options:

-x	instruction trace (see 'trace' function below)
-t	parse tree printout (see 'trees' function below)
-f <filename>	load and execute a .js file. Multiple -f options can be specified, the shell quits after loading the last one
-i	enter interactive mode (used after a -f option)

Shell functions:

dump(<arg>)	prints a diagnostic inspection of the argument (currently only implemented for bytecode functions, classes and prototype instances)
load(<string>)	loads and executes the .js file specified by the string argument.
print(<arg>, ..)	prints the 'toString' value of each argument
trees()	toggles the state of the flag that controls printing of parse trees
trace()	toggles the state of the flag that controls instruction tracing.

What's missing:

There are holes in the specification - the implementation will track these as they get addressed. Notably; constructor semantics, method invocation.
Type optimization - currently only supports converting member access by name to direct slot access, much more is possible.
The GC - it's very much a junior woodchuck level design, at best it proves survival under memory pertubation.
ECMA3 semantics & SpiderMonkey compatibility - very much not in place.
Runtime model - needs to be further weaned from semantics based model, and performance

Example:

D:\ns_trunk\mozilla\js2\src\winbuild\Epimetheus\Debug>epimetheus
Welcome to Epimetheus.
ep> namespace ns1
ep> namespace ns2
ep> class A { ns1 var x; ns2 var x; function f() { return ns1::x; } }
ep> class B extends A { override function f() { return ns2::x; } }
ep> b = new B()
object
ep> b.ns1::x = 1
1
ep> b.ns2::x = 2
2
ep> b.f()
2
ep>

Internals:

(under construction)

Parser (ad hoc, recursive descent) produces trees; see classes StmtNode & ExprNode in parser.h

Semantics engine (JS2Metadata) consumes trees in two passes, modeled on design in ECMA document (Validate & Evaluate).
    Validate pass; begins building symbol tables, gathers type information, does attribute evaluation.
    Evaluate pass; generates bytecode into bytecodeContainer module.
        (either pass might invoke the interpreter for evaluation of attributes & other compile-time constants).
BytecodeContainer; 1 per function (or script block). Maintains gc-accessible lists of multinames, string etc.

Interpreter (JS2Engine)
Stack based bytecode, very SpiderMonkey like. JS Invocations don't use C-stack
Tagged values (like SpiderMonkey but using 4 bits because of long etc - would like to consider separate type stack)
Try/Catch mechanism - separate stack of handlers. Will re-throw across invocations.
Runtime model is a work in progress - currently the object layout owes too much to the semantic description from the proposal.

GC
Simple mark-and-sweep-to-free-list implementation. Requires cooperation from each runtime-stage data structure to recursively mark contained objects.

ECMA3 library support (js2array.cpp, js2date.cpp, js2math.cpp, js2number.cpp, js2regexp.cpp, js2string.cpp)
Implementation per ECMA3 spec. but against new runtime model.
X.prototype properties implemented as instance methods (except Math properties which were more comfortable as static members)

Known issues:

Object layout, property map
Strings, StringAtoms etc. Not consistently handled/gc'd.
Long/ULong arithmetic - doesn't catch overflow etc.