4 ms·

Well luckily you don't have to write it. Use a compiler that can generate it for you. It's not really designed for humans.

fijal 14y ago
It's a very bad target for compilers too. Guys should just get their stuff together and write a reasonable bytecode format for browsers that is fast to read and verify. Would also save quite a bit of transfer. PS. If intel told me to do such crap in their architecture manuals, I would be the last user of PPC out there. I suggest reading them, or JVM bytecode spec to see what is a good compiler target.
- devongovett 14y ago
  Yeah, that's the position of Google's NativeClient project. But it's not backwards compatible with older browsers, which is the reason for doing this how they are. asm.js will run in any browser supporting JS already, and will be faster in browsers supporting the optimizations. It's not perfect, but it works now.
  - deleted 14y ago
    [deleted]
- hermanhermitage 14y ago
  Whats your metric for "bad"? It seems like complaining about ELF format or the different assembly formats used by assemblers. Ok, there is no goto/jmp but apart from that its just a different assembly syntax which happens to also support expressions and not just diadic/triadic instructions. This is not a green field solution - which would require alignment from all browser vendors, but instead an attempt to explore within the confines of what already runs today.
- adamnemecek 14y ago
  When I was making a very argument in the last thread, it seemed like people for whatever reason just did not want to let JS go.
  - chc 14y ago
    You're mistaken. It is not that people "just did not want to let JS go," but that "let JS go" is so immensely hard at this point in time that it is sitting near "boil the ocean" on the practicality scale. We don't know how to do it, so it's not a meaningful suggestion. In order to convince people that it's even worth trying, you need to enunciate a) a practical plan for "letting JS go," and b) a case for why the advantages of that plan in the context of the modern browser landscape outweigh the advantages of the plan the Mozilla devs are going with. You didn't do that. To put it another way: If we were implementing Web browser scripting completely from scratch with no history to lean on, this is not how I would do it and probably not how Dave Herman would do it either. But we aren't in that situation. As it stands, there are lots of existing JavaScript implementations that browser makers are heavily invested in — and they are not going to throw that all out and implement a new, incompatible and much more restrictive standard just because I wave my magic wand. The idea behind asm.js is that it is the smallest change you can make to still get the desired effect, because change is hard. Even if you don't think asm.js is perfect, it's a huge step in the direction you want to go. Complaining that it doesn't teleport us all the way there seems like missing the point.
    - adamnemecek 14y ago
      I mean I get it but not acknowledging that sometime in the future, the band-aid will have to be torn off, and not talking about what would is the best way to do so is not helping either.
      - chc 14y ago
        Sure, that would be an interesting conversation to have. But that's not what anyone's doing. Complaining that asm.js piggybacks off JavaScript instead of being a bytecode for which no interpreters currently exist — which is what you and fijal seem to be doing — is not "talking about what would be the best way to do that." In case you've forgotten, your suggestion in the other thread was literally just "a standardized VM in the browser." When I tried to get you to elaborate on what that meant in practical terms, you couldn't explain how it would be any different from what we have with asm.js except that you want a bytecode syntax for the input instead of the syntax asm.js uses. If you want to talk about practical ways we might move beyond JavaScript someday, feel free. I think that's an interesting topic. That's why I think it's unfortunate that so far, people just seem to be complaining that asm.js doesn't involve bytecode. Personally, I think asm.js is an important step in the direction of a post-JavaScript world. It moves us away from dependence on JavaScript by helping to better enable alternative languages in the browser.
- chc 14y ago
  You are overstating your case. It is not ideal, but it is serviceable. It is most importantly better than what we have now. To call an indisputable improvement "very bad" pretty much strips the word "bad" of all meaning.
- pcwalton 14y ago
  "It's a very bad target for compilers too." Emscripten is nowhere near the complexity of a SelectionDAG-based LLVM backend. In fact Emscripten is mostly written in JavaScript. The only comparatively tricky part is the Relooper, which is just a few pages of code. "Guys should just get their stuff together and write a reasonable bytecode format for browsers that is fast to read and verify." A nice-looking bytecode doesn't seem worth the loss of backwards compatibility. The encoding is ugly, but compatibility with existing browsers seems like such a huge win for something that really just amounts to a different encoding. "Would also save quite a bit of transfer." The effect on download size is minimal actually, compared to native code. And compared to gzipped LLVM bitcode, gzipped asm.js is tiny. http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-javascript.html http://mozakai.blogspot.com/2011/11/code-size-when-compiling...
  - skatepark 14y ago
    > A nice-looking bytecode doesn't seem worth the loss of backwards compatibility. The encoding is ugly, but compatibility with existing browsers seems like such a huge win for something that really just amounts to a different encoding. 10x slowdown doesn't seem worth keeping backwards compatibility. Why even bother? 2x in the best case is more reasonable, but wouldn't a 1x best case (NaCL) be even better, if you're willing to actually drop backwards compatibility?
- sultezdukes 14y ago
  Because "guys" can't. The browser world is laden with massive backward compatibility issues that will never, ever go away. Yeah, I would love something like NaCL, but that aint' happening, so baby steps.
fijal 14y ago
It's actually very likely I have to write it. I write compilers. Hence the hatred. I would seriously choose x86 ASM with all the backwards compatibility quirks going back to 80s any day.
- pcwalton 14y ago
  Well, if you're interested in compiling to something that runs in all browsers, you have to compile to JavaScript anyway. Given that, asm.js is strictly an improvement over the current state of affairs: the rails to stay on for high performance are well defined and (hopefully eventually) cross-browser. The alternative is to try to make a clean break from the past and forego backwards compatibility in the name of a cleaner encoding, so that compiler authors can generate object files with nicer syntax. That sort of thing been tried many times in the history of the Web and usually hasn't ended up succeeding. For example, take XHTML 2: despite the fact that XHTML 2 was hugely cleaner than HTML 4/XHTML 1, it never got any traction and was abandoned by the W3C. At the scale of the Web, practical considerations end up dominating engineering considerations.

fijal 14y ago

It's a very bad target for compilers too. Guys should just get their stuff together and write a reasonable bytecode format for browsers that is fast to read and verify. Would also save quite a bit of transfer. PS. If intel told me to do such crap in their architecture manuals, I would be the last user of PPC out there. I suggest reading them, or JVM bytecode spec to see what is a good compiler target.

devongovett 14y ago
Yeah, that's the position of Google's NativeClient project. But it's not backwards compatible with older browsers, which is the reason for doing this how they are. asm.js will run in any browser supporting JS already, and will be faster in browsers supporting the optimizations. It's not perfect, but it works now.
- deleted 14y ago
  [deleted]
hermanhermitage 14y ago
Whats your metric for "bad"? It seems like complaining about ELF format or the different assembly formats used by assemblers. Ok, there is no goto/jmp but apart from that its just a different assembly syntax which happens to also support expressions and not just diadic/triadic instructions. This is not a green field solution - which would require alignment from all browser vendors, but instead an attempt to explore within the confines of what already runs today.
adamnemecek 14y ago
When I was making a very argument in the last thread, it seemed like people for whatever reason just did not want to let JS go.
- chc 14y ago
  You're mistaken. It is not that people "just did not want to let JS go," but that "let JS go" is so immensely hard at this point in time that it is sitting near "boil the ocean" on the practicality scale. We don't know how to do it, so it's not a meaningful suggestion. In order to convince people that it's even worth trying, you need to enunciate a) a practical plan for "letting JS go," and b) a case for why the advantages of that plan in the context of the modern browser landscape outweigh the advantages of the plan the Mozilla devs are going with. You didn't do that. To put it another way: If we were implementing Web browser scripting completely from scratch with no history to lean on, this is not how I would do it and probably not how Dave Herman would do it either. But we aren't in that situation. As it stands, there are lots of existing JavaScript implementations that browser makers are heavily invested in — and they are not going to throw that all out and implement a new, incompatible and much more restrictive standard just because I wave my magic wand. The idea behind asm.js is that it is the smallest change you can make to still get the desired effect, because change is hard. Even if you don't think asm.js is perfect, it's a huge step in the direction you want to go. Complaining that it doesn't teleport us all the way there seems like missing the point.
  - adamnemecek 14y ago
    I mean I get it but not acknowledging that sometime in the future, the band-aid will have to be torn off, and not talking about what would is the best way to do so is not helping either.
    - chc 14y ago
      Sure, that would be an interesting conversation to have. But that's not what anyone's doing. Complaining that asm.js piggybacks off JavaScript instead of being a bytecode for which no interpreters currently exist — which is what you and fijal seem to be doing — is not "talking about what would be the best way to do that." In case you've forgotten, your suggestion in the other thread was literally just "a standardized VM in the browser." When I tried to get you to elaborate on what that meant in practical terms, you couldn't explain how it would be any different from what we have with asm.js except that you want a bytecode syntax for the input instead of the syntax asm.js uses. If you want to talk about practical ways we might move beyond JavaScript someday, feel free. I think that's an interesting topic. That's why I think it's unfortunate that so far, people just seem to be complaining that asm.js doesn't involve bytecode. Personally, I think asm.js is an important step in the direction of a post-JavaScript world. It moves us away from dependence on JavaScript by helping to better enable alternative languages in the browser.
chc 14y ago
You are overstating your case. It is not ideal, but it is serviceable. It is most importantly better than what we have now. To call an indisputable improvement "very bad" pretty much strips the word "bad" of all meaning.
pcwalton 14y ago
"It's a very bad target for compilers too." Emscripten is nowhere near the complexity of a SelectionDAG-based LLVM backend. In fact Emscripten is mostly written in JavaScript. The only comparatively tricky part is the Relooper, which is just a few pages of code. "Guys should just get their stuff together and write a reasonable bytecode format for browsers that is fast to read and verify." A nice-looking bytecode doesn't seem worth the loss of backwards compatibility. The encoding is ugly, but compatibility with existing browsers seems like such a huge win for something that really just amounts to a different encoding. "Would also save quite a bit of transfer." The effect on download size is minimal actually, compared to native code. And compared to gzipped LLVM bitcode, gzipped asm.js is tiny. http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-javascript.html http://mozakai.blogspot.com/2011/11/code-size-when-compiling...
- skatepark 14y ago
  > A nice-looking bytecode doesn't seem worth the loss of backwards compatibility. The encoding is ugly, but compatibility with existing browsers seems like such a huge win for something that really just amounts to a different encoding. 10x slowdown doesn't seem worth keeping backwards compatibility. Why even bother? 2x in the best case is more reasonable, but wouldn't a 1x best case (NaCL) be even better, if you're willing to actually drop backwards compatibility?
sultezdukes 14y ago
Because "guys" can't. The browser world is laden with massive backward compatibility issues that will never, ever go away. Yeah, I would love something like NaCL, but that aint' happening, so baby steps.

fijal 14y ago

It's actually very likely I have to write it. I write compilers. Hence the hatred. I would seriously choose x86 ASM with all the backwards compatibility quirks going back to 80s any day.

pcwalton 14y ago
Well, if you're interested in compiling to something that runs in all browsers, you have to compile to JavaScript anyway. Given that, asm.js is strictly an improvement over the current state of affairs: the rails to stay on for high performance are well defined and (hopefully eventually) cross-browser. The alternative is to try to make a clean break from the past and forego backwards compatibility in the name of a cleaner encoding, so that compiler authors can generate object files with nicer syntax. That sort of thing been tried many times in the history of the Web and usually hasn't ended up succeeding. For example, take XHTML 2: despite the fact that XHTML 2 was hugely cleaner than HTML 4/XHTML 1, it never got any traction and was abandoned by the W3C. At the scale of the Web, practical considerations end up dominating engineering considerations.