extension modules

kevin curtis kevinc1846 at googlemail.com
Tue Jun 23 10:21:16 PDT 2009


The requirement of security and speed don't always coincide! The
subset/dialect idea is interesting.

The tracemonkey, v8 and nitro engines have the ability to compile to
machine code. How about:

'performance modules' which would be written in and parsed as a subset
of ES which is *extremely sympathetic to the machine code generating
infrastructure* of the ecmascript engines and thus generates efficient
machine code. Without being to closely tied to (specific)
implementations.

For example:

module myfastmod;
use performance; // pragma that indicates this is perf module

let x:int = 0 // ES6 type annotation to indicate this will be turned
into a c int at some point
... etc

Code in a performance module that does not interact with the ES VM via
module public api's should be able to be compiled particularly
efficiently.

Also, performant c++ code seems to use templates rather than
traditional OO with virtual methods. Nitro/v8/tm seem to doing a form
of dynamic templating when at runtime they try to figure out the types
that are being passed as parameters to functions and generate machine
code. (Or in hot loops in tm's case). Maybe the engines could be given
a helping hand via the ES subset in perf modules - and type
annotations.

But too many subsets could add confusion. Type annotations are in ES6
(i think). Could there be a subset that meets both security and
performance issues.
Or even perf as a subset of secure. e.g: use secure, perf. Would a
performance subset need to be unsafe/unmanaged.


More information about the es-discuss mailing list