14 ms·

WebAssembly Stack Machine

116 points by brakmic 10y ago

bcg1 10y ago
If WASM runs on a stack machine, I wonder how hard it would be to map the instructions to JVM bytecodes? From the example in the document they look similar... It would be interesting to be able to take code compiled with Emscripten for example and run it as part of JVM applications, similar to what NestedVM can do.
- hackcasual 10y ago
  The devil's in the details. Exception handling and garbage collection are different enough that a straightforward adaptation won't cut it.
  - tdb7893 10y ago
    Could you build a JVM in WASM?
    - striking 10y ago
      WASM's Turing complete, so yes of course you could. (Maybe minus some features.) The question would then be, is the mapping straightforward or you do need to reimplement everything from scratch?
      - tdb7893 10y ago
        The horrifying thing about WASM is that you just know like 5 years from now someone will be posting some link here about how they ported the JVM to WASM and are using it to run old Java applets…
        lotyrin 10y ago
        I'd be surprised if it took that long.
        amelius 10y ago
        Yes, if there's a compiler that compiles from C/C++ to WASM, then it should be possible, I suppose.
        pjmlp 10y ago
        Or flash
        bbcbasic 10y ago
        ActiveX
        amaranth 10y ago
        There is already PyPy.js using asm.js, doppiojvm which is written in JavaScript, and some effort on getting OpenJDK and/or JamVM to work on asm.js. I don't think you'll have to wait 5 years.
        tdb7893 10y ago
        I imagine people will use it on the desktop apps and soon everything will just be running with WASM! It sounds like it has the potential to unify web development with development on all platforms if it is efficient enough. EDIT: I didn't think I would be excited about WebAssembly but I'm now really curious to see what happens with it.
        baq 10y ago
        the browser is a game engine with beefed up security, to quote servo. webassembly is the end game of scriptability of that engine. what you say about app development being unified is already true: see atom, steam and all others who embed webkit or similar to create a desktop UI.
      - amelius 10y ago
        How about threading? And a concurrent garbage collector? Would it be possible to code these things in WASM?
  - bcg1 10y ago
    What are the details that you mean? I just skimmed the spec and I don't see anything significant about exceptions or gc... it mostly seems focused on the WASM memory layout and the instruction set. The instruction set seems at least superficially similar to the java instruction set, and operates on a "linear memory" which could easily be implemented in java as a large array of int[] for 32 bit or long[] for 64 bit (although that scheme may need to be more complicated if it is to be shared across threads). Any instruction that doesn't have a direct analog in the jvm could be implemented as a static java method. Also WASM seems to use a static set of labels as branch targets rather than reading its instructions from the program memory (is that called harvard architecture?) which seems to suggest that you could translate WASM functions into java classes/functions to be loaded into the JVM. In any case I don't have time to implement all of that but it seems like it could be any interesting way to run non-java libraries on the JVM
CalChris 10y ago
The WA stack machine was added late in the game. Before that it was an AST but they got pushback from browser backend people and pivoted to a stack machine. https://github.com/WebAssembly/design/issues/755 https://github.com/WebAssembly/design/issues/755 AST was a good idea and parsing as validation was excellent. Having a general stack machine makes validation much more difficult. This is a bad decision (stacks vs AST or register) made for the wrong reason (code size). That's a 1990s design assumption when memory was expensive and bandwidth was dear. Now memory is cheap; bandwidth is phenomenal; and latency is expensive.
- muizelaar 10y ago
  > AST was a good idea and parsing as validation was excellent. Having a general stack machine makes validation much more difficult. Why? This document suggests that it's not that different. "The main new changes to verification are: - All branches to the end of a block must have the same arity and same types, including the implicit fall-through to end. - The true block of if-end constructs must leave the stack at the same height as when the if was entered. - The true and false blocks of if-else-end constructs must leave the stack at the same height with the same types."
  - CalChris 10y ago
    constructs must leave the stack at the same height with the same types That's easy to 'document' and harder to do. It's what the JVM did, again, in the 90s. Now the verifier chapter in the JVM spec is now about 160 pages long.
    - titzer 10y ago
      We learned our lessons from the JVM, and the verification algorithm for WASM is vastly simpler. It's even been formalized and fits in about 3/4 a page.
  - kuschku 10y ago
    > Why? Because you can also easily transform an AST back into code to reverse engineer? Reverse engineering code for a stack machine is quite a bit more annoying.
sofaofthedamned 10y ago
I'm confused about all of this - is WebAssembly related to the Google Native Client stuff they did and are now deprecating? Is there a write-up of how it works?
- hood_syntax 10y ago
  http://webassembly.org/ http://webassembly.org/ should have the information you want.
- bobajeff 10y ago
  No other than that it's meant to be used in much the same way and has some of the same developers working on it. This might help you: https://github.com/WebAssembly/design/blob/master/FAQ.md https://github.com/WebAssembly/design/blob/master/FAQ.md
  - sofaofthedamned 10y ago
    Thank you, very useful.
- Marat_Dukhan 10y ago
  Google Native Client is not deprecated, it is still supported in Chrome, and in many ways exceeds the capabilities of WebAssembly. WebAssembly is very different, and in Chrome it is implemented on top of TurboFan, V8's code generator, rather than Native Client.
  - sofaofthedamned 10y ago
    Thank you. It's interesting to see the original idea of NC growing and becoming cross-browser.
- wingless 10y ago
  First there was NaCl which was a subset of x86 code leveraging x86 features to sandbox the execution. This x86 subset was produced by a special toolchain and could be verified before running. Then PNaCl came along with a platform-independent bitcode format based on LLVM IR, which was translated to host's native code in the browser. Then WASM (also platform-independent) came along striving to be a multi-vendor solution. Unlike the other two WASM directly targets the JavaScript engine. It started out as a serialization format for JavaScript AST.
pythonlion 10y ago
I just wanted to say Im really excited about this project. I hope it will come together and make software universal as the web we have today (if I understand it right). Anyways, how can I contribute?
- lisivka 10y ago
  Java Applets, Flash, PNaCl, WebAssembly. Chose your poison.
aspirin 10y ago
It makes me sad to see the AST go. I was thinking of writing my own WASM compiler just for fun, purely as an AST transformer. Its funny how most of the WASM tools still use s-experssions as the text format. How does that even work, now that the AST is history?
- azakai 10y ago
  Yes, the s-expression format has become awkward. There are differences between the s-expression format in the test suite, what browsers will show, and what tools support. You can think of the old s-expression format as a language that compiles into wasm, a language that is an AST and that happens to have the same types and operations etc. as wasm.
erichocean 10y ago
I'd prefer it was an SSA representation, like SPIR-V in Vulkan, or LLVM IR. Missed opportunity IMO.
shkaboinka 10y ago
I believe that switching to a stack machine is short-sighted and a big mistake: The AST format could open up new possibilities for software, some of which are observable in Lispy languages like Scheme (I won't list them here). Instead, we're looking at locking the software world back into this 1960's model for another 50 years out of a misguided concern for optimization over power. It's like foregoing the arch because it's more work to craft, and instead coming up with a REALLY efficient way to fit square blocks together. Congratulations, we can build better pyramids, but will never grasp the concept of a cathedral. To really grasp my point, I BEG you all to watch the following two videos in full and think hard about what Alan Kay & Douglass Crockford have to say about new ideas, building complex structures, and leaving something better for the next generation: https://youtu.be/oKg1hTOQXoY https://youtu.be/oKg1hTOQXoY https://www.youtube.com/watch?v=PSGEjv3Tqo0 https://www.youtube.com/watch?v=PSGEjv3Tqo0 As Alan Kay states, what is simpler: something that's easier to process, but for which the software written on top of it is massive; or one that takes a bit more overhead, but allows for powerful new ways to model software and reduce complexity? I believe that an AST model is a major start in inventing "the arch" that's been missing in software, and with something that will proliferate the whole web ... how short-sighted it would be to give that up in favor of "optimizing" the old thing. Imagine if instead of JavaScript, the language of the web had been Java? Lambdas would not be mainstream; new ways of doing OOP would not be thought of; and all the amazing libraries that have been written because of the ad-hoc object modeling that JavaScript offers. Probably one of the messiest and inefficient languages ever written, yet one of the most powerful ever given. C'mon, let's do it a step more by making it binary, homoiconic, and self-modifying. Thanks.
- shkaboinka 10y ago
  ...and if you're brave enough, think about how Christopher Alexander's philosophy of "unfolding wholeness" applies so much more to an AST than to the stack-machines of the 1960's: https://youtu.be/98LdFA-_zfA https://youtu.be/98LdFA-_zfA

116 points by brakmic 10y ago

bcg1 10y ago

If WASM runs on a stack machine, I wonder how hard it would be to map the instructions to JVM bytecodes? From the example in the document they look similar... It would be interesting to be able to take code compiled with Emscripten for example and run it as part of JVM applications, similar to what NestedVM can do.

hackcasual 10y ago
The devil's in the details. Exception handling and garbage collection are different enough that a straightforward adaptation won't cut it.
- tdb7893 10y ago
  Could you build a JVM in WASM?
  - striking 10y ago
    WASM's Turing complete, so yes of course you could. (Maybe minus some features.) The question would then be, is the mapping straightforward or you do need to reimplement everything from scratch?
    - tdb7893 10y ago
      The horrifying thing about WASM is that you just know like 5 years from now someone will be posting some link here about how they ported the JVM to WASM and are using it to run old Java applets…
      - lotyrin 10y ago
        I'd be surprised if it took that long.
        amelius 10y ago
        Yes, if there's a compiler that compiles from C/C++ to WASM, then it should be possible, I suppose.
      - pjmlp 10y ago
        Or flash
        bbcbasic 10y ago
        ActiveX
      - amaranth 10y ago
        There is already PyPy.js using asm.js, doppiojvm which is written in JavaScript, and some effort on getting OpenJDK and/or JamVM to work on asm.js. I don't think you'll have to wait 5 years.
        tdb7893 10y ago
        I imagine people will use it on the desktop apps and soon everything will just be running with WASM! It sounds like it has the potential to unify web development with development on all platforms if it is efficient enough. EDIT: I didn't think I would be excited about WebAssembly but I'm now really curious to see what happens with it.
        baq 10y ago
        the browser is a game engine with beefed up security, to quote servo. webassembly is the end game of scriptability of that engine. what you say about app development being unified is already true: see atom, steam and all others who embed webkit or similar to create a desktop UI.
    - amelius 10y ago
      How about threading? And a concurrent garbage collector? Would it be possible to code these things in WASM?
- bcg1 10y ago
  What are the details that you mean? I just skimmed the spec and I don't see anything significant about exceptions or gc... it mostly seems focused on the WASM memory layout and the instruction set. The instruction set seems at least superficially similar to the java instruction set, and operates on a "linear memory" which could easily be implemented in java as a large array of int[] for 32 bit or long[] for 64 bit (although that scheme may need to be more complicated if it is to be shared across threads). Any instruction that doesn't have a direct analog in the jvm could be implemented as a static java method. Also WASM seems to use a static set of labels as branch targets rather than reading its instructions from the program memory (is that called harvard architecture?) which seems to suggest that you could translate WASM functions into java classes/functions to be loaded into the JVM. In any case I don't have time to implement all of that but it seems like it could be any interesting way to run non-java libraries on the JVM

CalChris 10y ago

The WA stack machine was added late in the game. Before that it was an AST but they got pushback from browser backend people and pivoted to a stack machine. https://github.com/WebAssembly/design/issues/755 https://github.com/WebAssembly/design/issues/755 AST was a good idea and parsing as validation was excellent. Having a general stack machine makes validation much more difficult. This is a bad decision (stacks vs AST or register) made for the wrong reason (code size). That's a 1990s design assumption when memory was expensive and bandwidth was dear. Now memory is cheap; bandwidth is phenomenal; and latency is expensive.

muizelaar 10y ago
> AST was a good idea and parsing as validation was excellent. Having a general stack machine makes validation much more difficult. Why? This document suggests that it's not that different. "The main new changes to verification are: - All branches to the end of a block must have the same arity and same types, including the implicit fall-through to end. - The true block of if-end constructs must leave the stack at the same height as when the if was entered. - The true and false blocks of if-else-end constructs must leave the stack at the same height with the same types."
- CalChris 10y ago
  constructs must leave the stack at the same height with the same types That's easy to 'document' and harder to do. It's what the JVM did, again, in the 90s. Now the verifier chapter in the JVM spec is now about 160 pages long.
  - titzer 10y ago
    We learned our lessons from the JVM, and the verification algorithm for WASM is vastly simpler. It's even been formalized and fits in about 3/4 a page.
- kuschku 10y ago
  > Why? Because you can also easily transform an AST back into code to reverse engineer? Reverse engineering code for a stack machine is quite a bit more annoying.

sofaofthedamned 10y ago

I'm confused about all of this - is WebAssembly related to the Google Native Client stuff they did and are now deprecating? Is there a write-up of how it works?

hood_syntax 10y ago
http://webassembly.org/ http://webassembly.org/ should have the information you want.
bobajeff 10y ago
No other than that it's meant to be used in much the same way and has some of the same developers working on it. This might help you: https://github.com/WebAssembly/design/blob/master/FAQ.md https://github.com/WebAssembly/design/blob/master/FAQ.md
- sofaofthedamned 10y ago
  Thank you, very useful.
Marat_Dukhan 10y ago
Google Native Client is not deprecated, it is still supported in Chrome, and in many ways exceeds the capabilities of WebAssembly. WebAssembly is very different, and in Chrome it is implemented on top of TurboFan, V8's code generator, rather than Native Client.
- sofaofthedamned 10y ago
  Thank you. It's interesting to see the original idea of NC growing and becoming cross-browser.
wingless 10y ago
First there was NaCl which was a subset of x86 code leveraging x86 features to sandbox the execution. This x86 subset was produced by a special toolchain and could be verified before running. Then PNaCl came along with a platform-independent bitcode format based on LLVM IR, which was translated to host's native code in the browser. Then WASM (also platform-independent) came along striving to be a multi-vendor solution. Unlike the other two WASM directly targets the JavaScript engine. It started out as a serialization format for JavaScript AST.

pythonlion 10y ago

I just wanted to say Im really excited about this project. I hope it will come together and make software universal as the web we have today (if I understand it right). Anyways, how can I contribute?

lisivka 10y ago
Java Applets, Flash, PNaCl, WebAssembly. Chose your poison.

aspirin 10y ago

It makes me sad to see the AST go. I was thinking of writing my own WASM compiler just for fun, purely as an AST transformer. Its funny how most of the WASM tools still use s-experssions as the text format. How does that even work, now that the AST is history?

azakai 10y ago
Yes, the s-expression format has become awkward. There are differences between the s-expression format in the test suite, what browsers will show, and what tools support. You can think of the old s-expression format as a language that compiles into wasm, a language that is an AST and that happens to have the same types and operations etc. as wasm.

erichocean 10y ago

I'd prefer it was an SSA representation, like SPIR-V in Vulkan, or LLVM IR. Missed opportunity IMO.

shkaboinka 10y ago

I believe that switching to a stack machine is short-sighted and a big mistake: The AST format could open up new possibilities for software, some of which are observable in Lispy languages like Scheme (I won't list them here). Instead, we're looking at locking the software world back into this 1960's model for another 50 years out of a misguided concern for optimization over power. It's like foregoing the arch because it's more work to craft, and instead coming up with a REALLY efficient way to fit square blocks together. Congratulations, we can build better pyramids, but will never grasp the concept of a cathedral. To really grasp my point, I BEG you all to watch the following two videos in full and think hard about what Alan Kay & Douglass Crockford have to say about new ideas, building complex structures, and leaving something better for the next generation: https://youtu.be/oKg1hTOQXoY https://youtu.be/oKg1hTOQXoY https://www.youtube.com/watch?v=PSGEjv3Tqo0 https://www.youtube.com/watch?v=PSGEjv3Tqo0 As Alan Kay states, what is simpler: something that's easier to process, but for which the software written on top of it is massive; or one that takes a bit more overhead, but allows for powerful new ways to model software and reduce complexity? I believe that an AST model is a major start in inventing "the arch" that's been missing in software, and with something that will proliferate the whole web ... how short-sighted it would be to give that up in favor of "optimizing" the old thing. Imagine if instead of JavaScript, the language of the web had been Java? Lambdas would not be mainstream; new ways of doing OOP would not be thought of; and all the amazing libraries that have been written because of the ad-hoc object modeling that JavaScript offers. Probably one of the messiest and inefficient languages ever written, yet one of the most powerful ever given. C'mon, let's do it a step more by making it binary, homoiconic, and self-modifying. Thanks.

shkaboinka 10y ago
...and if you're brave enough, think about how Christopher Alexander's philosophy of "unfolding wholeness" applies so much more to an AST than to the stack-machines of the 1960's: https://youtu.be/98LdFA-_zfA https://youtu.be/98LdFA-_zfA