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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
