No, it's an IR that happens to have an identical representation in JavaScript. But that clever hack gets muddy already with things like Math.imul. And it's going to diverge far more given the demand for e.g. threading, sync primitives, shared memory, and vectored operations. I honestly don't see how asm.js can be made into anything beyond its current demo state without major changes to the JavaScript language and APIs.
Those changes would benefit regular JavaScript as well, so it's not a divergence. Regular JavaScript developers are already asking for SIMD (and that's why Dart is implementing it, after all). They were asking for more predictable math operations, and Math.imul is good for that. Threading too. Changes made for asm.js lift all boats.
The parent comment said that asm.js was a subset of JavaScript. You said "no", but none of the things you said contradict that. asm.js is, right now, a subset of JavaScript. Which, of course, is its entire raison d'être.
My statement was correct. It's not JavaScript, which is why you use a keyword to switch to a different compiler mode. It's a clever hack to use an equivalent subset of JavaScript as an IR (accepting a few polyfills). However, it's not exactly honest to frame it as "just JavaScript."
What really does worry me is the ugly things that will be necessary to make asm.js genuinely viable as a platform. Yes, some proposals will have general utility for JavaScript, but many will not. And some will be downright dangerous. For example, how are you going to address pthreads compatibility, which e.g. Epic is saying they need?
> My statement was correct. It's not JavaScript, which is why you use a keyword to switch to a different compiler mode.
I'm afraid your statement really wasn't correct. asm.js is both syntactically and semantically JavaScript. OdinMonkey is a pure optimization; any observable divergence in behavior (other than timing, which of course all engines are allowed to do) is a bug that will be fixed. The fact that SpiderMonkey uses a prolog directive (not a keyword), which is also of course valid ECMAScript, to trigger a different kind of optimization does not change the fact that it is a valid implementation of JavaScript.
I'm sorry if I'm coming across negatively. It's not my intent. And please don't presume that my concerns about asm.js are in any way tied to projects that other people in Google/Chrome work on, or that I'm entirely supportive of them. That said, I am curious if you really are committing to to future versions of asm.js not using any divergent APIs or observable divergent behavior from JavaScript as used on the web?
Diverging from JS would require standardization, but it's too early to consider something like that. I don't know what our ultimate plan for threads will be or where asm.js will eventually end up; there are plenty more discussions to be had.
Thanks, that's a bit of helpful context. I appreciate that it's too early to say where exactly asm.js will go. I'm just afraid of private APIs or other divergence from JavaScript in order to mainstream asm.js. Sorry if that apprehension came across as overly negative.
I also want to add that the "it's just JS" thing is not somehow an argument of the shining nobility of asm.js. It's purely practical as what we believe is a viable approach to moving the web in the same direction that e.g. the PNaCl team has been trying to move it. I get so disheartened at these mud-flinging contests. Our companies want the same things for the web (and we <3 the PNaCl team and have friendly conversations with them!). We share the same goals. We just believe that asm.js is a more viable approach to getting the web there.
I'm pleased to hear that - my perception has been that Mozilla has been moving in a more isolated, NiH-ish direction of late (not just dart but e.g. h264 support in <video&rt;). Does this mean there's a chance of PNaCl support being added to firefox if it shows itself to be effective in practice?
Dart and PNaCl have been rejected by not only Mozilla but also upstream WebKit (Apple) and Microsoft. In other words, Google is the only proponent of these technologies. I have no idea how you could paint that as "isolated" or "NIH".
"use asm" is not a keyword. It can be ignored, as V8 does. This is possible because asm.js is JavaScript as defined by ECMA-262. It executes according to the semantics specified in that document.
I don't really want this to turn into a back-and-forth, but it's unfortunate that this has devolved into outright accusations of dishonesty.
Note that I framed it as "not exactly honest" rather than saying it's an overt lie. Because I don't consider it an overt lie, but it's hard not to read it as a bit equivocal to claim that asm.js as just JavaScript.
And really, I'm far more concerned with the future plans, particularly with regard to things like multi-threading APIs. I don't see how those can be incorporated in a way that supports asm.js as an easy target for existing code while not causing it to diverge from JavaScript as used in the browser.
To be clear, I really do think those of you working on asm.js have the best of intentions and really want to make something that works for the Web. However, I expect that supporting existing codebases and commonly used APIs is going to mean compromises. They'll start small and polyfills will work well enough, but I just don't see how asm.js doesn't eventually diverge in significant ways from normal JavaScript, or end up introducing special purpose hacks. Maybe I'm wrong, but I don't see my position as unrealistic.
It's an IR that currently is compatible with JS, but that's not necessarily the case longterm. And I personally don't see how it can retain that property while adding some of the things the platform needs (e.g. thread support that works for existing codebases). I asked dherman this elsewhere in the thread, and it seems like diverging from JS hasn't been ruled out. https://news.ycombinator.com/item?id=6023902
So, my concern here is that asm.js will either be forced to diverge from JS to make it generally useful, or it will need to add APIs to JS that are not appropriate outside of asm.js. If it gets to that place, then I feel that the compromises necessary for asm.js were a waste, and it would have clearly been better to just introduce a new IR that wasn't bound by the constraints of asm.js.
asm.js is a subset of javascript. Nothing more. If you implement the optimisations without needing the "use asm" then you just have the same benefits for non asm tagged code -- and all the benefits of asm.
The "use asm" is totally optional functionality wise.
