How does it fair on test262? http://test262.ecmascript.org/
-- kangax On Wed, Oct 19, 2011 at 6:26 AM, Yusuke Suzuki <[email protected]>wrote: > Hello. > > I wrote new ECMA262 5.1 full support engine "iv / lv5" in C++. > This is highly inspired from JSC, V8 and SpiderMonkey. (especially JSC) > > https://github.com/Constellation/iv > > This aims at most precise engine to ECMA262 5.1 specification. (like > the great engine,) > > I read ECMA262 and wanted precise engine to understand this spec, so I > created. > > features, > > all ECMA262 5.1th features > (strict mode, direct call / indirect call to eval, > PropertyDescriptor, early errors, Object.prototype.toString.call(null > / undefined), Object extras, Array extras, etc.) > BESEN // for example, directive prologure including octal value and > strict directive is rejected. > function test() { "¥02"; "use strict"; } > stack VM > JSC like bytecode based PIC > ES5 oriented structures in C++ (PropertyDescriptor, > Attributes(Enumerable, Writable, Configurable)) > optimized JSArray (using vector and hash map) > but this array implements full features of ECMA262 5.1th. for example, > > var ary = [0, 1]; > Object.defineProperty(ary, 'length', { writable : false }); > ary.length = 4; // of cource, in strict mode, this raises error. > print(ary.length); // 2 > try { > ary.push(2); // throw TypeError, because [DefineOwnProperty] > with throw = true is called. > } catch (e) { > print(e); > } > ary[3] = 2; // of cource ... > print(ary.length); // 2; > > minimum source code > 2 engines, VM and AST Interpreter. we can switch it by command line > option. > bytecode based backtrack RegExp (read re1 report and source code to > study VM based RegExp runtime, and implemented it) > ES5 oriented optimization > for example, > if I get "eval" keyword in strict mode, don't make variable > dynamic (hold on heap variable with offset access) > because direct call to eval in strict mode cannot create new > variable in upper local call site environment. > > At first, I created AST Interpreter (named "teleporter") which > algorithm is just the same to ECMA262 specification. > And after it is done, I created optimized bytecode VM (named "railgun"). > These 2 engines are abstracted, so we can switch it at runtime. > ('--interp option') > AST Interpreter is very slow, but this source code is exactly the same > to ECMA262 specification algorithm, so this may be interesting for > spec readers. > > And, SunSpider is available for this engine, so, you can bench it. > (sorry, probably slow, because of no JIT...) > > I'm planning to create own GC (now using BoehmGC library), and create > JIT module. > > Finally, I'm respecting JSC, V8, SpiderMonkey, BESEN implementors great > works. > > Thanks. > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
