1. Good primitive data types (e.g. full width machine integers)
2. SIMD
3. Tail calls
4. Threads
5. Structs
6. Gotos
7. Memory management
Once you add these you lose the supposed advantages of asm.js in practice. You lose the light weight. You lose realistic backwards compatibility because programs using these features will run so slow on normal JS VMs that they're unusable, or in the case of tail calls the program will stackoverflow on a normal JS VM.
No, an asm.js that supported all of these would still just be JavaScript, which is far more lightweight than PNaCl. Besides, these features dovetail with things we want for JavaScript anyway: SIMD, tail calls, full width machine integers are things all JavaScript programs need. By implementing them once and for all we help both regular JavaScript and asm.js.
> You lose realistic backwards compatibility because programs using these features will run so slow on normal JS VMs that they're unusable
No, we are compiling programs that use these already, and they are not too slow as to be unusable. For example, Unreal Engine 3.
> No, an asm.js that supported all of these would still just be JavaScript, which is far more lightweight than PNaCl.
What makes asm.js "far more lightweight" than PNaCl? What more "lightweight" means here anyway?
> No, we are compiling programs that use these already, and they are not too slow as to be unusable. For example, Unreal Engine 3.
Do you mean the Epic Citadel demo which runs fine on smartphones. So you made it run more or less smoothly on beefy x86 desktops, how much of an achievement is that? Is it that "OMG I run my game from the 80s inside the browser with HTML5 CANVAS!!!" thing again?
> It's much simpler than LLVM and reuses the components of the JavaScript engine that already must exist in browsers.
But LLVM IR has complexity for a reason - you need to be able to generate efficient code from it for multiple architectures. As I mentioned elsewhere, "reusing JS components" is a very unfortunate party line because it keeps us tied to this one JS forever and ever, and we should try to see beyond that.
The Relooper solves this problem for compilers, and it is extremely effective in practice. Besides, you can always solve the lack of goto with code duplication, with no loss in performance.
Except code duplication destroys performance because the instruction cache isn't infinite. I think we can agree that the relooper isn't the optimal solution to this problem...it's a compromise that works pretty well, but its a compromise nonetheless. It also means that you need to involve the LLVM toolchain anyway, just like in pnacl. I don't know if pnacl is a better solution or asm.js, but what I do know is that both are compromise and both have advantages and disadvantages.
1. Good primitive data types (e.g. full width machine integers)
2. SIMD
3. Tail calls
4. Threads
5. Structs
6. Gotos
7. Memory management
Once you add these you lose the supposed advantages of asm.js in practice. You lose the light weight. You lose realistic backwards compatibility because programs using these features will run so slow on normal JS VMs that they're unusable, or in the case of tail calls the program will stackoverflow on a normal JS VM.