If I'm understanding things correctly, the JS produced is a subset of ES3. The use of typed arrays simply give supporting platforms an additional speed boost.
According to Brendan Eich: "all of JS (ES3) is 'universally supported' [by asmjs]"
@BrendanEich So would I be right in thinking that the point of asm.js is to tie together all the universally supported bits of JS?
BrendanEich @BrendanEich
@no_other_alias No, all of JS (ES3) is "universally supported". http://asmjs.org/ is a no-GC-pause well-typed compiler target language.
=====
@no_other_alias is asking if asm.js is about formalizing a JS subset that's universally supported (in all browsers). Eich says no, all of JS (ES3) is universally supported (so no subsetting is required for cross-browser compabitility). Asm.js is about formalizing a JS subset that can be compiled to much faster machine code.
So I don't think Eich is making a claim about asm.js backward-compatibility here.
Typed arrays are a background thing in this case. The code one writes in asm.js (or compiles to asm.js) doesn't mention them at all. IE6 will see the code and use normal arrays, because as far as it knows, that's the only kind of array there is.
Sadly not, I overshot the mark slightly here (what worse an advocate for your stuff than an incorrect advocate!). Typed arrays allow for things like casting, where the same chunk of 'heap' can be seen through multiple views, and interpreted as char* by one, and float* by the other.
It can't even be shimmed on IE6, since you can't overload the array indexing operator there.
It's entirely possible and easy to implement an extension/variant of Asm.js that could legitimately target these browsers, by providing shimmable names for the array indexing operation, but diminishing returns and all that..
Note nnethercote (parent comment) is one of Mozilla's engineering ninjas and author of Valgrind, it's pretty likely he knows what he's talking about here.
That's not what backward-compatibility means here. IE6 sees ordinary JavaScript code and executes it. It's true that it can't do the typed-array magic in the background, but it doesn't have to. The JavaScript code that IE6 sees has the same result as compiled asm.js code would; it just does it in a less-optimal way.
That's all that asm.js really is: a set of JavaScript coding conventions that (when followed) prove to be easy to optimize to near-native levels of speed, along with a compiler hint to tell the runtime that these conventions are being used. IE6 doesn't understand the compiler hint, but because the asm.js code is still valid JavaScript, it'll still run.
I suspect that either nnethercote and I are using different definitions of backward-compatibility, or nnethercote is mistaken as to what exactly asm.js is. Authorities are less likely to make mistakes, but they can still make them.
