News for hackers. Stuff that matters.
Re:Why Mozilla Matters by haberman on Friday February 15, 2013 @06:27PM (#5229383)
> asm.js is essentially just a JS encoding of LLVM

This seems like a bit of a stretch; how do you encode an indirect branch in JS?

But it looks like an interesting project and I look forward to seeing what they are able to accomplish. I think it may be difficult to get native code performance while also being a secure enough sandbox to run in-process with the browser. LLVM is fast in large part because does not have the requirement of being a sandboxed attack surface. Making it safe will require performance compromises, like guards on loads and stores. Even (P)NaCl, despite its sandboxing, runs in a separate process, limiting the damage if the sandbox is broken out of. JavaScript has traditionally taken the approach of achieving safety by exposing only high-level concepts (objects, attributes, etc); if it aims to support lower-level programming idioms with low overhead that may be at odds with also being highly safe.

It's an interesting design space and I will be curious to watch the project evolve.

Re:Why Mozilla Matters by pcwalton on Friday February 15, 2013 @07:37PM (#5229738)
"This seems like a bit of a stretch; how do you encode an indirect branch in JS?"

asm.js has a switch instruction to cover most uses of indirect branches. First-class function pointers are being worked on for a future version of the spec. So this should cover the vast majority of use cases of indirect branching. If this is not enough, I could imagine an extension of JavaScript to support e.g. first-class labels. (Note that LLVM did not support first-class labels for a long time, and of course portable C does not.)

"Making it safe will require performance compromises, like guards on loads and stores."

Naturally, but this is also the case with NaCl or PNaCl, unless NaCl drops all of its software fault isolation techniques and starts relying solely on the OS sandbox. I suppose in theory one could compile asm.js in this way if it was really desired. The entry and exit points from asm.js to the DOM are fairly well defined, so in theory one could IPC them as well.

I'm personally skeptical that asm.js adds much more security risk over the JavaScript JIT that already must exist, however; the semantics of asm.js are extremely simple even compared to LLVM (as asm.js is untyped), much less the full semantics of JavaScript.

Re:Why Mozilla Matters by haberman on Sunday February 17, 2013 @09:52PM (#5237891)
If it delivers on its promise (native-ish code speeds without imposed GC overhead), I'll be the first in line to use it! :)