3 ms·

I'd like to think one day that the non-web side of WASM could become a more deterministic and cross-platform-predictable LLVM IR. Right now it is too limited of

I'd like to think one day that the non-web side of WASM could become a more deterministic and cross-platform-predictable LLVM IR. Right now it is too limited of course but as GC and threading specs come along, I can hope one day it will reach parity. Granted it isn't as low level, but that has benefits for compiler backend implementers (they can choose how they target their arch) and compiler frontend implementers (they don't have to do different things per platform). Basically, imagine if Java bytecode was developed less around OO semantics, wasn't lumped in with its stdlib by the community, didn't have encumbered JCK and other tests, etc, etc. Edit: Changed "LLVM" to "LLVM IR" to clarify as requested.

wyldfire 9y ago
Your comment was confusing to read. I think it would be easier to understand if you replaced "LLVM" with "Intermediate Representation".
RussianCow 9y ago
To me, this is the most exciting prospect of WebAssembly by far: an IR that works natively across all major platforms, including the web. It's funny because it makes Gary Bernhardt's "The Birth & Death of JavaScript"[1] seem a lot less like a joke. [1]: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
rhelmer 9y ago
This use case is interesting to me too. I looked into this a few months ago and found that there is a page on non-web embeddings: http://webassembly.org/docs/non-web/ http://webassembly.org/docs/non-web/
mike_hearn 9y ago
I'm not sure your criticisms of Java bytecode are all that reasonable to be honest. You don't have to use the Java standard library to target bytecode. Scala, Ceylon, Clojure provide their own stdlibs. Indeed not doing this is one of Kotlin's competitive advantages. Although the JVM wants to think in terms of objects, this is only really mandated as a unit of linkage and garbage collection. You could equally criticise C runtimes for being too oriented around procedural programming semantics because they see the world in terms of top level functions and global variables. You can write non-OOP programs in Java bytecode and Eta is an example of using the Haskell Spineless Tagged G-Machine representation on top of the JVM. If your runtime doesn't have any concept of an object-like thing, then it gets rather hard to do garbage collection and certainly any kind of moving GC. Finally, the JCK is encumbered to protect the Java trademark. We can argue about whether that's really been so useful given Android, but the principle makes sense - it's about ensuring that if someone claims they run Java bytecode, they actually can run it. If WebAssembly isn't trademarked and protected in the same way then it'll be a repeat of HTML5, where a claim of support is essentially meaningless and everyone has to constantly consult giant feature/bug tables to figure out what subset of the spec works on your particular implementation. Now it may be that in the end everyone is OK with the word WebAssembly being more of a statement of intent than a precise claim, just like we muddle through with the word HTML5. And in reality we all know that only Mozilla, Microsoft, Google and maybe Apple will implement wasm or at least only these companies will have implementations anyone cares about. They will probably comply with whatever test suite is produced without needing legal/trademark incentives. Maybe.
- titzer 9y ago
  > Now it may be that in the end everyone is OK with the word WebAssembly being more of a statement of intent than a precise claim, just like we muddle through with the word HTML5. And in reality we all know that only Mozilla, Microsoft, Google and maybe Apple will implement wasm or at least only these companies will have implementations anyone cares about. They will probably comply with whatever test suite is produced without needing legal/trademark incentives. Maybe. There are already projects to implement WASM in other contexts beside the web--some even in production. The specification, which has been entirely mechanized with an implementation of a provably-correct interpreter in Isabelle, is designed to be implemented easily. We welcome other implementations of the core execution spec of WASM and other embeddings. I can only speak for myself as a co-founder, but I believe most people involved in the W3C groups hope the scenario laid out in this comment does not happen in reality.
  - mike_hearn 9y ago
    Yes, but all those things are true of other platforms as well. The JVM's type system has been proven correct. Everyone who writes specs designs them to be easily implemented (in their view) and everyone hopes the spec won't be forked by vendors or end up with widely deployed but buggy implementations. The worst case scenario for wasm or any spec author is that someone comes along and either implements it very poorly, or adds vendor extensions that effectively become de-facto standards. E.g. Chrome might add new opcodes or APIs that rely on other Chrome-only features. And then people start claiming they've got a wasm module, but it doesn't work properly or well enough on other implementations. That's what happened to the web, to Java and others, and is one reason why the TCK is "encumbered", as the OP put it. It's also why Android requires you to pass an encumbered test suite to be able to use the trademark/logo/get access to the Play Store etc. It's not like one path is inherently superior to another. Protecting a trademark by licensing the test suite and mandating it be passed is about risk management.
    - titzer 9y ago
      > The JVM's type system has been proven correct. I'm not sure which proof you are referring to, but the Java and Scala languages both have unsafe type systems: https://2016.splashcon.org/event/splash-2016-oopsla-java-and-scala-s-type-systems-are-unsound-the-existential-crisis-of-null-pointers https://2016.splashcon.org/event/splash-2016-oopsla-java-and... (Admittedly this is due to parametric types which are erased). The JVM bytecode verification algorithm is over 100 pages in the spec. > E.g. Chrome might add new opcodes or APIs that rely on other Chrome-only features. We aren't doing that currently. We plan to continue participating in the W3C processes which have worked well over the past 2+ years.

wyldfire 9y ago

Your comment was confusing to read. I think it would be easier to understand if you replaced "LLVM" with "Intermediate Representation".

RussianCow 9y ago

To me, this is the most exciting prospect of WebAssembly by far: an IR that works natively across all major platforms, including the web. It's funny because it makes Gary Bernhardt's "The Birth & Death of JavaScript"[1] seem a lot less like a joke. [1]: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

rhelmer 9y ago

This use case is interesting to me too. I looked into this a few months ago and found that there is a page on non-web embeddings: http://webassembly.org/docs/non-web/ http://webassembly.org/docs/non-web/

mike_hearn 9y ago

I'm not sure your criticisms of Java bytecode are all that reasonable to be honest. You don't have to use the Java standard library to target bytecode. Scala, Ceylon, Clojure provide their own stdlibs. Indeed not doing this is one of Kotlin's competitive advantages. Although the JVM wants to think in terms of objects, this is only really mandated as a unit of linkage and garbage collection. You could equally criticise C runtimes for being too oriented around procedural programming semantics because they see the world in terms of top level functions and global variables. You can write non-OOP programs in Java bytecode and Eta is an example of using the Haskell Spineless Tagged G-Machine representation on top of the JVM. If your runtime doesn't have any concept of an object-like thing, then it gets rather hard to do garbage collection and certainly any kind of moving GC. Finally, the JCK is encumbered to protect the Java trademark. We can argue about whether that's really been so useful given Android, but the principle makes sense - it's about ensuring that if someone claims they run Java bytecode, they actually can run it. If WebAssembly isn't trademarked and protected in the same way then it'll be a repeat of HTML5, where a claim of support is essentially meaningless and everyone has to constantly consult giant feature/bug tables to figure out what subset of the spec works on your particular implementation. Now it may be that in the end everyone is OK with the word WebAssembly being more of a statement of intent than a precise claim, just like we muddle through with the word HTML5. And in reality we all know that only Mozilla, Microsoft, Google and maybe Apple will implement wasm or at least only these companies will have implementations anyone cares about. They will probably comply with whatever test suite is produced without needing legal/trademark incentives. Maybe.

titzer 9y ago
> Now it may be that in the end everyone is OK with the word WebAssembly being more of a statement of intent than a precise claim, just like we muddle through with the word HTML5. And in reality we all know that only Mozilla, Microsoft, Google and maybe Apple will implement wasm or at least only these companies will have implementations anyone cares about. They will probably comply with whatever test suite is produced without needing legal/trademark incentives. Maybe. There are already projects to implement WASM in other contexts beside the web--some even in production. The specification, which has been entirely mechanized with an implementation of a provably-correct interpreter in Isabelle, is designed to be implemented easily. We welcome other implementations of the core execution spec of WASM and other embeddings. I can only speak for myself as a co-founder, but I believe most people involved in the W3C groups hope the scenario laid out in this comment does not happen in reality.
- mike_hearn 9y ago
  Yes, but all those things are true of other platforms as well. The JVM's type system has been proven correct. Everyone who writes specs designs them to be easily implemented (in their view) and everyone hopes the spec won't be forked by vendors or end up with widely deployed but buggy implementations. The worst case scenario for wasm or any spec author is that someone comes along and either implements it very poorly, or adds vendor extensions that effectively become de-facto standards. E.g. Chrome might add new opcodes or APIs that rely on other Chrome-only features. And then people start claiming they've got a wasm module, but it doesn't work properly or well enough on other implementations. That's what happened to the web, to Java and others, and is one reason why the TCK is "encumbered", as the OP put it. It's also why Android requires you to pass an encumbered test suite to be able to use the trademark/logo/get access to the Play Store etc. It's not like one path is inherently superior to another. Protecting a trademark by licensing the test suite and mandating it be passed is about risk management.
  - titzer 9y ago
    > The JVM's type system has been proven correct. I'm not sure which proof you are referring to, but the Java and Scala languages both have unsafe type systems: https://2016.splashcon.org/event/splash-2016-oopsla-java-and-scala-s-type-systems-are-unsound-the-existential-crisis-of-null-pointers https://2016.splashcon.org/event/splash-2016-oopsla-java-and... (Admittedly this is due to parametric types which are erased). The JVM bytecode verification algorithm is over 100 pages in the spec. > E.g. Chrome might add new opcodes or APIs that rely on other Chrome-only features. We aren't doing that currently. We plan to continue participating in the W3C processes which have worked well over the past 2+ years.