6 ms·

Except, you didn't state that PNaCl subsets a specification of a compiler IR, well designed and meant to be compiled. asm.js subsets a language never meant for

Except, you didn't state that PNaCl subsets a specification of a compiler IR, well designed and meant to be compiled. asm.js subsets a language never meant for this, and tries to come up with something that will compile well. This approach certainly can work, but will have significantly more limitations 5 years from now than the other one. Not to mention, LLVM, and it's IR, certainly has more traction than "asm.js".

makomk 13y ago
Which version of LLVM IR are we talking about here? Since LLVM's IR is intended to be used as a compiler IR and not an executable bytecode format, it changes in backwards-incompatible ways on a regular basis. Google's PNaCL solves this by snapshotting a particular version of LLVM and using a subset of the IR of that version of LLVM. Last I heard, if they ever needed to support newer versions of LLVM the plan was to create a completely new, incompatible version of the PNaCL bitcode from it.
- DannyBee 13y ago
  Yes, LLVM is forwards compatible, not backwards compatible. While you are wrong, because it is in fact " an executable bytecode format", it does change in backwards-incompatible ways. However, it has not done so "on a regular basis" (to say otherwise is complete bullshit. I'm pretty sure the last major backwards incompatible change was version 3.0, which was 2 years ago). However, from where I sit, it's changed seriously less than asm.js in the past few years! We'll see how long asm.js actually stays backwards compatible without having real impact.
  - kevingadd 13y ago
    How would asm.js break backwards compatibility? It has to be executable javascript; it can't change execution semantics without changing JS execution semantics. It is the case that support for a wider set of features could be added, and that stuff wouldn't get AOT-compiled in older browsers, but nothing would break. It'd just be slower. 'seriously less than asm.js in the past few years' is a blatantly fallacious claim. asm.js, as a spec, is barely a year old (going by the date of dherman's first public commit to his github repository) and the first implementation is younger than that. Mozilla turned the implementation around in a few months with a handful of engineers.
    - DannyBee 13y ago
      "How would asm.js break backwards compatibility" See, e.g., pcwalton's own comments: "Most of the changes needed to fill in the few remaining holes in asm.js help everyone. SIMD and 64-bit integers, for example, are something the entire Web would benefit from, asm and non-asm writers alike." Such changes would almost certainly be backwards incompatible with what exists now. "'seriously less than asm.js in the past few years' is a blatantly fallacious claim." Errr, given asm.js has changed a lot in the year it's been around, and LLVM has not changed in any backwards compatible way in that time period, it's actually what you would call "trivially true", not "blatantly false".
      - kevingadd 13y ago
        New features like SIMD and 64-bit integers would not be asm.js features, they would be JavaScript features. If you read his comments more carefully you would realize this, since he mentions how they're being developed as JavaScript features... Again, asm.js has 'changed' but has not broken backwards compatibility, because it's just javascript and remains so.
        deleted 13y ago
        [deleted]
        DannyBee 13y ago
        This is a word game. You can't define away the problem of backwards compatibility by saying "well it wasn't us who changed in a backwards incompatible way, it was the underlying language we subset". You especially can't do this when the parent made the claim that PNaCL has exactly this issue.
pcwalton 13y ago
> Except, you didn't state that PNaCl subsets a specification of a compiler IR, well designed and meant to be compiled. > > asm.js subsets a language never meant for this, and tries to come up with something that will compile well. LLVM IR was also never designed to be a portable, platform-independent, well-specified bytecode. It's designed to be a compiler IR. This shows up in numerous places: TargetData, download size, undefined behavior, and so on. Google has worked around some of these (TargetData) and has not worked around others (undefined behavior—which is really scary for a proposed Web standard). The fact is, both PNaCl and asm.js are taking a language not designed to be used as a portable, platform-independent representation and making changes to make it work. You can argue about which is "further from the ideal", but I think that's subjective and not productive, involving predicting the future. I certainly don't think there will be any fundamental limitations 5 years from now. > This approach certainly can work, but will have significantly more limitations 5 years from now than the other one. I don't see this at all. As I said before, JavaScript is not some immutable thing. We can evolve it. Most of the changes needed to fill in the few remaining holes in asm.js help everyone. SIMD and 64-bit integers, for example, are something the entire Web would benefit from, asm and non-asm writers alike. > Not to mention, LLVM, and it's IR, certainly has more traction than "asm.js". Not on the Web, which is the important thing here.
- DannyBee 13y ago
  "LLVM IR was also never designed to be a portable, platform-independent, well-specified bytecode." This is completely and utterly false in every way. This is exactly what it was meant to be, and is. Maybe you mean "it does not turn non-portable languages, like C, into portable ones". This does not change whether it is a portable, platform independent, well-specified bytecode. This is even covered in the FAQ. To your specific examples TargetData is meant to deal with languages that have unavoidable target specific dependencies, like C. It is unnecessary in portable languages. Download size is completely unrelated to a portable, platform-independent, well-specified bytecode, and is probably the absolutely most trivial thing to fix in the world if it was necessary. I'm not sure why one would even bring this up. Undefined behavior is not necessarily bad. Most languages specify some amount of undefined behavior. This is done on purpose, to enable certain classes of optimizations. Is your claim that asm.js has no undefined behavior? emscripten certainly does, even in asm.js mode. My guess is that you meant that asm.js has a bunch of properties that are statically verifiable, and it validates conformance at compile time. That is great, but not really the same as "no undefined behavior". At a glance, asm.js has undefined behavior. For example: "As JavaScript functions, they produce the undefined value, but asm.js code is not allowed to make use of this value" A program that attempted to make use of it would exhibit undefined behavior. It would be noncomforming to the asm.js spec, in the same way that a program in LLVM IR that uses undefined behavior is noncomforming to the language specification. Again, you may mean that you statically verify this, which is great, but that does not mean the spec does not deal have undefined behavior. It just means you try to validate conformance at compile time (and note, the asm.js spec itself explains why it can't possibly accomplish no actual undefined behavior at runtime: ' In particular, reading out of bounds from a typed array produces undefined, and calling FFI functions may produce arbitrary JavaScript values.') "I certainly don't think there will be any fundamental limitations 5 years from now." If you didn't believe this, i'm sure y'all wouldn't be working on asm.js. :) However, I strongly disagree. What you are doing is not the first time someone has tried to do something like this (see, e.g., the SIMPLE IR and other IR's the McCat compiler used to use), and it won't be the last. Your claim essentially comes down to "this time for sure!". Sorry, but living in the world of compilers, i've seen and heard this too many times. The truth is there are no magic bullets in compiler technology, and asm.js isn't one either. It's a set of tradeoffs. I don't believe this chosen set of tradeoffs come without fundamental limitations. I guess we'll see whether you are right. "> Not to mention, LLVM, and it's IR, certainly has more traction than "asm.js". Not on the Web, which is the important thing here." You can always define a target audience that likes your stuff more. So let's go this way: Researchers, compiler developers, and a very large contingent of companies care very strongly about LLVM and improving it. I certainly wouldn't disagree with "worse is better" often wins, particularly on the web.

makomk 13y ago

Which version of LLVM IR are we talking about here? Since LLVM's IR is intended to be used as a compiler IR and not an executable bytecode format, it changes in backwards-incompatible ways on a regular basis. Google's PNaCL solves this by snapshotting a particular version of LLVM and using a subset of the IR of that version of LLVM. Last I heard, if they ever needed to support newer versions of LLVM the plan was to create a completely new, incompatible version of the PNaCL bitcode from it.

DannyBee 13y ago
Yes, LLVM is forwards compatible, not backwards compatible. While you are wrong, because it is in fact " an executable bytecode format", it does change in backwards-incompatible ways. However, it has not done so "on a regular basis" (to say otherwise is complete bullshit. I'm pretty sure the last major backwards incompatible change was version 3.0, which was 2 years ago). However, from where I sit, it's changed seriously less than asm.js in the past few years! We'll see how long asm.js actually stays backwards compatible without having real impact.
- kevingadd 13y ago
  How would asm.js break backwards compatibility? It has to be executable javascript; it can't change execution semantics without changing JS execution semantics. It is the case that support for a wider set of features could be added, and that stuff wouldn't get AOT-compiled in older browsers, but nothing would break. It'd just be slower. 'seriously less than asm.js in the past few years' is a blatantly fallacious claim. asm.js, as a spec, is barely a year old (going by the date of dherman's first public commit to his github repository) and the first implementation is younger than that. Mozilla turned the implementation around in a few months with a handful of engineers.
  - DannyBee 13y ago
    "How would asm.js break backwards compatibility" See, e.g., pcwalton's own comments: "Most of the changes needed to fill in the few remaining holes in asm.js help everyone. SIMD and 64-bit integers, for example, are something the entire Web would benefit from, asm and non-asm writers alike." Such changes would almost certainly be backwards incompatible with what exists now. "'seriously less than asm.js in the past few years' is a blatantly fallacious claim." Errr, given asm.js has changed a lot in the year it's been around, and LLVM has not changed in any backwards compatible way in that time period, it's actually what you would call "trivially true", not "blatantly false".
    - kevingadd 13y ago
      New features like SIMD and 64-bit integers would not be asm.js features, they would be JavaScript features. If you read his comments more carefully you would realize this, since he mentions how they're being developed as JavaScript features... Again, asm.js has 'changed' but has not broken backwards compatibility, because it's just javascript and remains so.
      - deleted 13y ago
        [deleted]
      - DannyBee 13y ago
        This is a word game. You can't define away the problem of backwards compatibility by saying "well it wasn't us who changed in a backwards incompatible way, it was the underlying language we subset". You especially can't do this when the parent made the claim that PNaCL has exactly this issue.

pcwalton 13y ago

> Except, you didn't state that PNaCl subsets a specification of a compiler IR, well designed and meant to be compiled. > > asm.js subsets a language never meant for this, and tries to come up with something that will compile well. LLVM IR was also never designed to be a portable, platform-independent, well-specified bytecode. It's designed to be a compiler IR. This shows up in numerous places: TargetData, download size, undefined behavior, and so on. Google has worked around some of these (TargetData) and has not worked around others (undefined behavior—which is really scary for a proposed Web standard). The fact is, both PNaCl and asm.js are taking a language not designed to be used as a portable, platform-independent representation and making changes to make it work. You can argue about which is "further from the ideal", but I think that's subjective and not productive, involving predicting the future. I certainly don't think there will be any fundamental limitations 5 years from now. > This approach certainly can work, but will have significantly more limitations 5 years from now than the other one. I don't see this at all. As I said before, JavaScript is not some immutable thing. We can evolve it. Most of the changes needed to fill in the few remaining holes in asm.js help everyone. SIMD and 64-bit integers, for example, are something the entire Web would benefit from, asm and non-asm writers alike. > Not to mention, LLVM, and it's IR, certainly has more traction than "asm.js". Not on the Web, which is the important thing here.

DannyBee 13y ago
"LLVM IR was also never designed to be a portable, platform-independent, well-specified bytecode." This is completely and utterly false in every way. This is exactly what it was meant to be, and is. Maybe you mean "it does not turn non-portable languages, like C, into portable ones". This does not change whether it is a portable, platform independent, well-specified bytecode. This is even covered in the FAQ. To your specific examples TargetData is meant to deal with languages that have unavoidable target specific dependencies, like C. It is unnecessary in portable languages. Download size is completely unrelated to a portable, platform-independent, well-specified bytecode, and is probably the absolutely most trivial thing to fix in the world if it was necessary. I'm not sure why one would even bring this up. Undefined behavior is not necessarily bad. Most languages specify some amount of undefined behavior. This is done on purpose, to enable certain classes of optimizations. Is your claim that asm.js has no undefined behavior? emscripten certainly does, even in asm.js mode. My guess is that you meant that asm.js has a bunch of properties that are statically verifiable, and it validates conformance at compile time. That is great, but not really the same as "no undefined behavior". At a glance, asm.js has undefined behavior. For example: "As JavaScript functions, they produce the undefined value, but asm.js code is not allowed to make use of this value" A program that attempted to make use of it would exhibit undefined behavior. It would be noncomforming to the asm.js spec, in the same way that a program in LLVM IR that uses undefined behavior is noncomforming to the language specification. Again, you may mean that you statically verify this, which is great, but that does not mean the spec does not deal have undefined behavior. It just means you try to validate conformance at compile time (and note, the asm.js spec itself explains why it can't possibly accomplish no actual undefined behavior at runtime: ' In particular, reading out of bounds from a typed array produces undefined, and calling FFI functions may produce arbitrary JavaScript values.') "I certainly don't think there will be any fundamental limitations 5 years from now." If you didn't believe this, i'm sure y'all wouldn't be working on asm.js. :) However, I strongly disagree. What you are doing is not the first time someone has tried to do something like this (see, e.g., the SIMPLE IR and other IR's the McCat compiler used to use), and it won't be the last. Your claim essentially comes down to "this time for sure!". Sorry, but living in the world of compilers, i've seen and heard this too many times. The truth is there are no magic bullets in compiler technology, and asm.js isn't one either. It's a set of tradeoffs. I don't believe this chosen set of tradeoffs come without fundamental limitations. I guess we'll see whether you are right. "> Not to mention, LLVM, and it's IR, certainly has more traction than "asm.js". Not on the Web, which is the important thing here." You can always define a target audience that likes your stuff more. So let's go this way: Researchers, compiler developers, and a very large contingent of companies care very strongly about LLVM and improving it. I certainly wouldn't disagree with "worse is better" often wins, particularly on the web.