6 ms·

In all the ways that matter, asm.js is a bytecode with a funny encoding and peculiar semantics related to that. Denying it doesn't really help. We're all wishi

by lucian1900 13y ago

In all the ways that matter, asm.js is a bytecode with a funny encoding and peculiar semantics related to that. Denying it doesn't really help. We're all wishing for a sane bytecode for a change. It's not just syntax.

BrendanEich 13y ago
You didn't respond to the "now you have two problems" point. Keeping asm.js a subset of JS avoids all the back-compat-locking/future-hostile-lowering problems. And engines have only one parser to make super-fast. (Already there.) This is a significant win. What your "sane" means is mostly aesthetics. asm.js already has int32 and uint32 conversions and casts. There is no big semantic gap for vanilla C/C++ source to JS. Typed array views help a lot here; JS's built-in operators and a few helpers in ES6 (Math.imul, polyfillable) do the rest. The non-vanilla gaps of note are mostly gaps in JS (e.g., int64, uint64, SIMD), which we're filling in ES7 for many reasons. Shared memory threads are indeed a gap to confine to a checked subset, not push into JS along with data races (VM-level and usercode-level -- this is fatal). We're working on that too, but it's not a "bytecode" issue _per se_. If you continue to believe that "it's not just syntax", and you have something in the way of semantics other than the above in mind, please state it explicitly.
- lucian1900 13y ago
  I was thinking of int types, SIMD, shared memory with an explicit model, and arbitrary jumps. It's nice that some of those are getting fixed. I would also like to see a bytecode with structures (and alignment control), nice code generation and execution and some form of virtual memory for resources. What I don't understand is why Mozilla didn't define a bytecode and a to-JS compiler for it. Browsers without support would have been just as slow, but there would have been much more room for evolution. I'm almost expecting Mozilla to pull a Trojan any day now: define a bytecode that compiles to asm.js and declare asm.js deprecated.
  - BrendanEich 13y ago
    int types are in JS and have been since 1995, due to the bitwise logical and shift ops. arbitrary jumps are a deoptimizer and verifier hazard (Java's verifier had O(n^4) complexity DoS attack demo'd by Michael Franz and his group at UCI). Do not want. SIMD is coming and wanted in hand-coded JS too, not a bytecode issue per se. > What I don't understand is why Mozilla didn't define a bytecode and a to-JS compiler for it. Browsers without support would have been just as slow, but there would have been much more room for evolution. You mix speed ("just as slow" -- wait, we're fast at asm.js input, faster on startup than PNaCl -- did you read the post?) with "room for evolution". I just argued above that having two syntaxes hurts evolution. Please separate speed from evolution and address my argument. Mozilla is in no position, philosophically or market-share-wise, to "pull a Trojan". Also, my argument stands no matter who is making it. No ad hominem fallacies, please!
    - lucian1900 13y ago
      > int types are in JS and have been since 1995, due to the bitwise logical and shift ops. That's like saying int64 is a subset of float64 because you can use two floats to encode it. > arbitrary jumps are a deoptimizer and verifier hazard True, this would be one of the decisions to be made when designing a bytecode format. > You mix speed ("just as slow" -- wait, we're fast at asm.js input, faster on startup than PNaCl -- did you read the post?) You misunderstood. 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. And for browsers that do have support, both asm.js and a hypothetical bytecode would behave the same. The major differences with a bytecode would be requiring two "executables" and a better semantic model. Also, I'm not necessarily defending PNaCl itself, nor did I even bring it up. > No ad hominem fallacies, please! I'm not sure where you got that, the Trojan comment was meant positively. I think it would be nice if Mozilla introduced a bytecode (superset of asm.js semantics), once asm.js itself was accepted.
      - BrendanEich 13y ago
        > 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/ 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

BrendanEich 13y ago

You didn't respond to the "now you have two problems" point. Keeping asm.js a subset of JS avoids all the back-compat-locking/future-hostile-lowering problems. And engines have only one parser to make super-fast. (Already there.) This is a significant win. What your "sane" means is mostly aesthetics. asm.js already has int32 and uint32 conversions and casts. There is no big semantic gap for vanilla C/C++ source to JS. Typed array views help a lot here; JS's built-in operators and a few helpers in ES6 (Math.imul, polyfillable) do the rest. The non-vanilla gaps of note are mostly gaps in JS (e.g., int64, uint64, SIMD), which we're filling in ES7 for many reasons. Shared memory threads are indeed a gap to confine to a checked subset, not push into JS along with data races (VM-level and usercode-level -- this is fatal). We're working on that too, but it's not a "bytecode" issue _per se_. If you continue to believe that "it's not just syntax", and you have something in the way of semantics other than the above in mind, please state it explicitly.

lucian1900 13y ago
I was thinking of int types, SIMD, shared memory with an explicit model, and arbitrary jumps. It's nice that some of those are getting fixed. I would also like to see a bytecode with structures (and alignment control), nice code generation and execution and some form of virtual memory for resources. What I don't understand is why Mozilla didn't define a bytecode and a to-JS compiler for it. Browsers without support would have been just as slow, but there would have been much more room for evolution. I'm almost expecting Mozilla to pull a Trojan any day now: define a bytecode that compiles to asm.js and declare asm.js deprecated.
- BrendanEich 13y ago
  int types are in JS and have been since 1995, due to the bitwise logical and shift ops. arbitrary jumps are a deoptimizer and verifier hazard (Java's verifier had O(n^4) complexity DoS attack demo'd by Michael Franz and his group at UCI). Do not want. SIMD is coming and wanted in hand-coded JS too, not a bytecode issue per se. > What I don't understand is why Mozilla didn't define a bytecode and a to-JS compiler for it. Browsers without support would have been just as slow, but there would have been much more room for evolution. You mix speed ("just as slow" -- wait, we're fast at asm.js input, faster on startup than PNaCl -- did you read the post?) with "room for evolution". I just argued above that having two syntaxes hurts evolution. Please separate speed from evolution and address my argument. Mozilla is in no position, philosophically or market-share-wise, to "pull a Trojan". Also, my argument stands no matter who is making it. No ad hominem fallacies, please!
  - lucian1900 13y ago
    > int types are in JS and have been since 1995, due to the bitwise logical and shift ops. That's like saying int64 is a subset of float64 because you can use two floats to encode it. > arbitrary jumps are a deoptimizer and verifier hazard True, this would be one of the decisions to be made when designing a bytecode format. > You mix speed ("just as slow" -- wait, we're fast at asm.js input, faster on startup than PNaCl -- did you read the post?) You misunderstood. 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. And for browsers that do have support, both asm.js and a hypothetical bytecode would behave the same. The major differences with a bytecode would be requiring two "executables" and a better semantic model. Also, I'm not necessarily defending PNaCl itself, nor did I even bring it up. > No ad hominem fallacies, please! I'm not sure where you got that, the Trojan comment was meant positively. I think it would be nice if Mozilla introduced a bytecode (superset of asm.js semantics), once asm.js itself was accepted.
    - BrendanEich 13y ago
      > 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/ 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