> 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.
> 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.).
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.
> That would be a bytecode-to-asm.js compiler. Hence, no difference besides distribution.
Your "That" referred to something in my sentence "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.)" -- but I have no idea what. Please use a noun. What "That" did you mean?
I was not talking about a bytecode-to-asm.js compiler. I said asm.js code (output of Emscripten, hand-coded -- whatever typechecks) runs faster in other browsers such as Chrome than non-asm functionally equivalent code, even without AOT compilation. But as the blog post shows, AOT in Firefox is even faster at startup (and see the link on "throughput" for other wins).
Missing features are not being added to JS for the sake of asm.js. I clearly wrote we are adding SIMD, int64, etc. for hand-coded JS users. Ecma TC39 is not only concerned with "compile to JS" use-cases, we look at apps, libraries, and compilers.
For some reason, at least twice now, when I've written X, you've read Y or !X. Not sure why, but I hope this message is clear, at least!
If a hypothetical bytecode were designed, a compiler from this bytecode to asm.js would be just as fast in browsers without support for this bytecode (or for that matter asm.js) as asm.js is currently.
One would compile C/C++ to this bytecode and either ship it directly (to browsers that support it) or compile to asm.js and ship that (to browsers that don't support it).
This process I described is precisely how Dart works and while I don't particularly like Dart itself, I think its compilation/distribution mechanism is nice.
It's possible to do this later, after (and if) asm.js becomes popular. And it would even possible to eventually compile JS itself to this bytecode.
> But as the blog post shows, AOT in Firefox is even faster at startup (and see the link on "throughput" for other wins).
I am not immediately concerned with the merits of asm.js as implemented in Firefox at the moment.
> Missing features are not being added to JS for the sake of asm.js. I clearly wrote we are adding SIMD, int64, etc. for hand-coded JS users. Ecma TC39 is not only concerned with "compile to JS" use-cases, we look at apps, libraries, and compilers.
Sure, I guess. These features just seemed to me more important for asm.js than generic application JS (as opposed to, say, macros).
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