| > That's like saying int64 is a subset of float64 because you can use two floats to encode it. No. (x>>>0) is uint32(x), (x|0) is int32(x). Please read http://asmjs.org/spec/latest/. > True, this would be one of the decisions to be made when designing a bytecode format. Indeed, no clean-slate design, we have learned from the past. Dropping goto leaves less to change in asm.js. You need to produce the missing semantics or else we're just arguing syntax. > Asm.js running on a browser that doesn't have support for it is just as slow as output from bytecode-to-JS compiler would be. No, asm.js on browsers that do not use AOT compilation is already faster than non-asm.js for the workloads of interest (compiled from C/C++, etc.). Anyway, speed was not the issue. => evolution is harder with two syntaxes. Trojan is usually pejorative -- beware Greeks bearing gifts and all that ;-). No worries, but really, it does not make sense to do a second syntax for asm.js, at least not yet. Maybe in the farther future when JS has reached some fixed point. /be |
That would be a bytecode-to-asm.js compiler. Hence, no difference besides distribution.
I was not aware so many features are getting added to JS for the sake of asm.js. Other than structure/array abstractions (like LLVM's), which largely only improve debugging, I can't think of important missing features that can't be fixed with compilers or extra APIs.
The only major objection remains lack of elegance (which is indeed largely a syntax/decoding argument). I guess browsers environments are doomed to be ugly and quirky.