Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebAssembly Stack Machine

docs.google.com

Post reply on HN
Print view View original

31–40 of 47 posts

Re: WebAssembly Stack Machine

#31

Post by amyjess »

wingless wrote: post #26
sofaofthedamned wrote: post #14

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?

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 solutio…

Adding to this, PNaCl relies heavily on Chrome's sandbox, so any third-party implementation of PNaCl would involve re-implementing large swaths of Chrome. It's not as portable as you'd think. WASM was designed from the ground up to not depend on any browser's implementation.

Re: WebAssembly Stack Machine

#32

Post by bbcbasic »

pjmlp wrote: post #11
tdb7893 wrote: post #8

Earlier quoted context omitted.

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…

Or flash

ActiveX

Re: WebAssembly Stack Machine

#33

Post by bcg1 »

hackcasual wrote: post #3
bcg1 wrote: post #2

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.

The devil's in the details. Exception handling and garbage collection are different enough that a straightforward adaptation won't cut it.

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

Re: WebAssembly Stack Machine

#34

Post by barrkel »

CalChris wrote: post #30
barrkel wrote: post #29

Earlier quoted context omitted.

I don't think it makes a big difference. It's not that difficult to reconstruct an AST from a stack machine that has the same stack types on every code path. It's mostly just a post-order serialization of the AST. push x push y add Evaluate this symbolically and you get (add x y) naturally. Writing a simple interpreter, I prefer register or stack machine over AST walker. It'll be faster, for one. And there's a chance…

WA doesn't get interpreted. It gets validated and passed over to the JIT (TurboFan). It comes over the wire so that validation has to be thorough (read that as expensive).

Hmm. I didn't say it was interpreted in any given browser implementation. I was judging the serialization format for what it is, vs reasonable alternatives. Analysis, transformation and interpretation are what you want out of this kind of encoding.

I also don't agree re expensive validation; I think you're wrong. Interface with APIs much more problematic than pure computation, which is not hard to validate. Interface safety is largely the same problem as with plain JS, as I see it. I don't see stack machine vs register machine making almost any difference at all.

Re: WebAssembly Stack Machine

#35

Post by azakai »

aspirin wrote: post #21

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?

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.

Re: WebAssembly Stack Machine

#36

Post by azakai »

muizelaar wrote: post #7
CalChris wrote: post #4

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 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 s…

> 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…

Sadly it is more complicated - but the document in the link was written before a bunch of problems were found (with things like unreachable code, which is indeed trickier in stack machines than ASTs).

(Those problems and their solutions haven't been documented yet AFAIK.)

Re: WebAssembly Stack Machine

#38

Post by sitkack »

munificent wrote: post #22
CalChris wrote: post #4

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 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 s…

> That's a 1990s design assumption when memory was expensive Memory is still expensive: * Spreading things out in memory more causes more cache misses, which lowers performance. * Using more memory increases page faults, which lowers performance. * I believe using more memory drains batteries faster on mobile devices, but I'm not sure exactly why. Maybe the effort spent shuttling stuff from virtual memory into real m…

Mobile probably turns off DRAM refresh for memory not allocated. RAM at rest still takes work to refresh.

Re: WebAssembly Stack Machine

#39

Post by utorrent_dev »

munificent wrote: post #22
CalChris wrote: post #4

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 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 s…

> That's a 1990s design assumption when memory was expensive Memory is still expensive: * Spreading things out in memory more causes more cache misses, which lowers performance. * Using more memory increases page faults, which lowers performance. * I believe using more memory drains batteries faster on mobile devices, but I'm not sure exactly why. Maybe the effort spent shuttling stuff from virtual memory into real m…

I agree. If you want things to be fast on a current Intel machine, keeping the code and data in cache means you can do ten times as much work before you have to do the next memory access.

There's also the issue of additional latency from tertiary caches, like the disk, when you are under memory pressure.

Re: WebAssembly Stack Machine

#40

Post by lisivka »

pythonlion wrote: post #13

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?

Java Applets, Flash, PNaCl, WebAssembly. Chose your poison.
Post reply on HN