21–30 of 47 posts
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?
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…
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 memory on page faults?
* On embedded devices, using more memory means you need to have more RAM, which increases the per-device manufacturing cost.
* Using more memory to represent code increases memory pressure, which leads to more GC cycles.
Earlier quoted context omitted.
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?
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…
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?
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
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?
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.
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?
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.
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…
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.
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…
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.
EDIT: I didn't think I would be excited about WebAssembly but I'm now really curious to see what happens with it.
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…
push x
push y
add
Writing a simple interpreter, I prefer register or stack machine over AST walker. It'll be faster, for one. And there's a chance of interpreting it directly with a loop and switch, without a deserialization step.
Many simple analyses of an AST have an equivalent stack machine form. If the analysis can be done as a post-order traversal (like type-checking, constant folding etc.) you're good to go.
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…
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…