brendan at mozilla.com
Mon Jun 22 17:20:15 PDT 2009
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss