« Return to Thread: extension modules

Re: extension modules

by Brendan Eich-3 :: Rate this Message:

On Jun 22, 2009, at 3:46 PM, kevin curtis wrote:

Alternatively, ecmascript in the tracemonkey, v8 and nitro generates
x86/ARM code. Maybe there could be a ecmascript subset which generates
fast machine code for algorithmic intensive code. ie ignores global
object and prototype and is maybe typed.

The engines you mention all accept the full language, no subsetting required. Using a subset may help performance, but it's not required.

I'm not sure how this is relevant to using multiple cores, though, since that would seem to require, at the least, a way to spawn worker code to run on each core. See Web Workers.

A subset similar to - or even
the same as - what Douglas Crockford is proposing for secure
ecmascript here: http://wiki.ecmascript.org/doku.php?id=ses:ses

No types there.

If JS is fast enough (with advisory subset usage at the programmer's discretion) that one does not need to write native code for performance, then you're right, there might be API or data flow reasons to want machine int and other low-level types.

But C-like ints that wrap around are not safe for broad usage on the web. This suggests an "unsafe" or "unmanaged" dialect, which is something we've thought about at Mozilla when self-hosting built-in methods. This is a far cry from SES!

Even if 'extension modules' in the browser aren't available in ES6 to
third party developers it could be useful for modules that need to be
implemented in c/c++ to conform to some set of standards. These
standards could be leveraged by users of ecmascript on the server and
elsewhere outside of the browser where security is not such an issue.
A new math module with a full set of math functions would be a good
example - perhaps the code could be shared across the
nitro/v8/tracemonkey engines as a proof of concept.

Perhaps. But the details of how the engine calls the native code, and how the native code might call back into the engine, differ significantly among those implementations. What you are describing sounds very much like the JNI.

/be

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

« Return to Thread: extension modules