As someone who's been a vigorous proponent of (P)NaCl for a long time, I have to say that I'm excited to see this. If it can truly deliver on its promise (near-native-code speeds with no imposed GC overhead), it will be a truly welcome advance indeed.<p>I hope that if it does succeed that it will open up even more possibilities, like optional SSE/AVX intrinsics (for added speed in the most demanding software) and threading support.<p>It's great and educational to see an alternative approach to the problem that is obviously quite different than (P)NaCl. May the best technology win.
Prior discussion (with comments from dherman, Luke Wagner, and various other Mozilla employees): <a href="http://news.ycombinator.com/item?id=5227274" rel="nofollow">http://news.ycombinator.com/item?id=5227274</a>
Why would we go this route? Why not just define a bytecode spec and be done with all of this nonsense? Mozilla is perfectly free to implement the bytecode by compiling it to a restricted subset of JS (in fact, it might make a lot of sense to do so). Defining a simple register or stack based machine and producing bytecode for it would greatly simplify the job of implementers, it would make defining the specification and determining compliance with the standard very straight forward, and it would let us eventually do web programming without being tied to a specific language.
I get the point of Math.imul, but it seems at odds with the idea of asm.js being backward compatible. I guess it's easy enough to provide a polyfill (MDN even provides one), but that seems rather inelegant.
Just to inject another viewpoint into this -<p>I don't care that asm.js is backward compatible with JavaScript. If my program uses an appreciable fraction of the available CPU an it has to act real time in some fashion (anywhere from 60fps for a game to simply acting responsive in a GUI app), execution several times slower by a standard JS VM is no better than no execution. If I want to be cross-platform in the hopefully <i>near</i> future where asm.js is not widely supported, I would pick Chrome and Firefox to support for now and use a NaCl plugin for the former. From this perspective, a "true" bytecode VM would be no worse - and it would hardly be boiling the ocean, since the size of code required to parse a simple bytecode is negligible. (If you want to compile it efficiently, either you bring in all of LLVM or modify your JS engine, which is hardly negligible, but asm.js is the same in that regard. The only difference is <i>parsing</i>.)<p>But I think it's nice that the "bytecode" is human readable and pretty much writable. It will be better to use a (possibly lightweight) too to compile to asm.js, but it's nice that small kernels can just be written without a compiler.
x | 0 as declaring int. +x as declaring float. Math.imul to multiply integers. seriously???!!! It took me roughly half an hour to decide whether it's an elaborate joke or an actual idea.<p>Also javascript (without introducing new concepts) is not low level enough to write down everything you might need (have fun implementing 64bit integer operations with overflow for example).