5 ms·

Someday someone is gonna make a bunch of money selling CPUs implementing a WASM VM ("death of javascript") and/or lambda calc (Reduceron) in hardware.

_nhynes 7y ago
Wasm itself doesn’t have any environment functions that would allow things like managing page tables or networking. I think that what you might see is a RISC-V JIT with a ring-0 Wasm runtime compiled to native. Kind of like https://github.com/nebulet/nebulet https://github.com/nebulet/nebulet, probably
- neftaly 7y ago
  Oh there's still a lot of work to do before it's possible, but things like WASM pthreads, gc, etc are moving along.
- FullyFunctional 7y ago
  The interesting thing about WASM is that it's an amazing representation[1] to translate from; certainly much more attractive than binary translation from a legacy ISA (maintaining the illusion of the original ISA carry a substantial tax). As thus, it allows you freedom to innovate something radically different, like TRIPS/EDGE radical. I'd much rather translate from that than create the compiler backend and the entire toolchain. [1] It's not perfect alas, as there are still many things the compiler knows that is lost in translation, such as the complete static alias sets of memory operations, true range limits on values, etc. For some of this we burn power today trying to (re-) discover at run-time (like the memory disambiguator).
yjftsjthsd-h 7y ago
We really are just reinventing Java, aren't we? (Perhaps better, with hindsight) https://en.wikipedia.org/wiki/Java_processor https://en.wikipedia.org/wiki/Java_processor
- henry_bone 7y ago
  I think this too, when I read about WASM. It seems to be tackling the same problem that java was created to solve. Namely, a platform independent VM for running applications (applets) in the browser. I, for one, would appreciate an explanation of how WASM differs from the original JVM, if someone has a moment.
  - FullyFunctional 7y ago
    Controversial opinion alert! Java Bytecode is an awful design. It's obvious if you study it that it was never designed as a compiler intermediate. Instead it was a fairly trivial byte code machine for which JITting was an afterthought. The bytecode "verification" is such a difficult problem that it lead to multiple articles and originally had a sequence of security holes. The JVM is also very far from language independent. Good luck making an efficient mapping for any language that doesn't look like Java. WASM in contrast is designed explicitly for JITting, in fact, one-pass JITting is possible. The data structures maps well to the compiler backend. The representation is restricted in ways to avoid requiring expensive analysis, most notoriously, no arbitrary branching.
  - zamadatix 7y ago
    If you're looking for technical details about the virtual machines themselves it's easier to just read their documentation. If you're looking for what WASM does differently resulting in the JVM not being a good fit it's mostly around browser integration. WASM runs as part of the browser, designed so that the same VM running the JavaScript portions of a page can run the WASM portions without enormous modification. It's also more tightly coupled with the data model of the browser but it doesn't have full direct access to everything, still better than ferrying everything to a second VM. As for why people are so excited to use it outside of the browser it probably has to do with the level of support and investment around engines like V8 and that it's not designed for a particular language.
  - AndrewDucker 7y ago
    JVM bytecode is significantly higher level, and comes with support for type reflection, garbage collection, etc. Whereas WASM doesn't include any of that. Which makes it simpler and more lightweight, but means that anything which needs that functionality has to do it itself.
opportune 7y ago
If I were starting a new chip company I would be working on FPGA coprocessors. You get the economies of scale of producing a single chip but a lot of extra efficiency/sales by marketing it as customizable hardware (which most large buyers of chips increasingly want). It’s a transitional step between the current mass market mode of chip productions selling one size fits all, and the way the market is heading towards task specialized hardware.
BubRoss 7y ago
Wasm isn't an instruction set and it doesn't replace javascript because it must communicate through javascript, so I wouldn't count on it.

_nhynes 7y ago

Wasm itself doesn’t have any environment functions that would allow things like managing page tables or networking. I think that what you might see is a RISC-V JIT with a ring-0 Wasm runtime compiled to native. Kind of like https://github.com/nebulet/nebulet https://github.com/nebulet/nebulet, probably

neftaly 7y ago
Oh there's still a lot of work to do before it's possible, but things like WASM pthreads, gc, etc are moving along.
FullyFunctional 7y ago
The interesting thing about WASM is that it's an amazing representation[1] to translate from; certainly much more attractive than binary translation from a legacy ISA (maintaining the illusion of the original ISA carry a substantial tax). As thus, it allows you freedom to innovate something radically different, like TRIPS/EDGE radical. I'd much rather translate from that than create the compiler backend and the entire toolchain. [1] It's not perfect alas, as there are still many things the compiler knows that is lost in translation, such as the complete static alias sets of memory operations, true range limits on values, etc. For some of this we burn power today trying to (re-) discover at run-time (like the memory disambiguator).

yjftsjthsd-h 7y ago

We really are just reinventing Java, aren't we? (Perhaps better, with hindsight) https://en.wikipedia.org/wiki/Java_processor https://en.wikipedia.org/wiki/Java_processor

henry_bone 7y ago
I think this too, when I read about WASM. It seems to be tackling the same problem that java was created to solve. Namely, a platform independent VM for running applications (applets) in the browser. I, for one, would appreciate an explanation of how WASM differs from the original JVM, if someone has a moment.
- FullyFunctional 7y ago
  Controversial opinion alert! Java Bytecode is an awful design. It's obvious if you study it that it was never designed as a compiler intermediate. Instead it was a fairly trivial byte code machine for which JITting was an afterthought. The bytecode "verification" is such a difficult problem that it lead to multiple articles and originally had a sequence of security holes. The JVM is also very far from language independent. Good luck making an efficient mapping for any language that doesn't look like Java. WASM in contrast is designed explicitly for JITting, in fact, one-pass JITting is possible. The data structures maps well to the compiler backend. The representation is restricted in ways to avoid requiring expensive analysis, most notoriously, no arbitrary branching.
- zamadatix 7y ago
  If you're looking for technical details about the virtual machines themselves it's easier to just read their documentation. If you're looking for what WASM does differently resulting in the JVM not being a good fit it's mostly around browser integration. WASM runs as part of the browser, designed so that the same VM running the JavaScript portions of a page can run the WASM portions without enormous modification. It's also more tightly coupled with the data model of the browser but it doesn't have full direct access to everything, still better than ferrying everything to a second VM. As for why people are so excited to use it outside of the browser it probably has to do with the level of support and investment around engines like V8 and that it's not designed for a particular language.
- AndrewDucker 7y ago
  JVM bytecode is significantly higher level, and comes with support for type reflection, garbage collection, etc. Whereas WASM doesn't include any of that. Which makes it simpler and more lightweight, but means that anything which needs that functionality has to do it itself.

opportune 7y ago

If I were starting a new chip company I would be working on FPGA coprocessors. You get the economies of scale of producing a single chip but a lot of extra efficiency/sales by marketing it as customizable hardware (which most large buyers of chips increasingly want). It’s a transitional step between the current mass market mode of chip productions selling one size fits all, and the way the market is heading towards task specialized hardware.

BubRoss 7y ago

Wasm isn't an instruction set and it doesn't replace javascript because it must communicate through javascript, so I wouldn't count on it.