PCpcwalton·Feb 19, 2013
"Why not just define a bytecode spec and be done with all of this nonsense?"
Because such bytecode would not be backwards compatible.
"Defining a simple register or stack based machine and producing bytecode for it would greatly simplify the job of implementers"
Let's take as a given that every browser that wants to implement asm.js needs a JavaScript parser (for JS content on the Web) and an asm.js compiler IR. The question, then, is whether it's simpler to write a verifier that simply walks over parse trees or whether it's simpler to write a reader for whatever custom bytecode is defined. I don't think that the verifier is much harder: the JS version of the verifier clocks in at just over 1,000 lines of code [1], which is nothing compared to the size of the VM as a whole. Certainly that 1,000 lines of code doesn't justify breaking backw
Read the rest
ards compatibility, in my mind.
"it would make defining the specification and determining compliance with the standard very straight forward"
The specification already more or less exists, and determining compliance is straightforward: 1,000 lines of code for the reference implementation.
"it would let us eventually do web programming without being tied to a specific language"
asm.js doesn't tie you to a language. On the contrary, it allows you to use alternative languages in order to get better performance than you would if you used normal JavaScript. JS is used as the transport format for backwards compatibility, nothing more. In fact, in SpiderMonkey, asm.js has its own set of IR opcodes (Asm*) that are separate from the JavaScript opcodes.
[1]: https://github.com/dherman/asm.js