3 ms·

WASM is a stack based "CPU" and arguably the future of the Web. So is Python's. I think also Java and Erlang, but don't quote me on that. A stack based CPU is v

by sph 3y ago

WASM is a stack based "CPU" and arguably the future of the Web. So is Python's. I think also Java and Erlang, but don't quote me on that. A stack based CPU is very easy to implement (or rather, registers are very complex hardware-wise) and a stack-based VM is relatively easy to optimise for a register CPU. Seems to me registers are a fancy hardware implementation detail, that software at higher abstraction can and should avoid unless maximum performance is required. It was surprising for me to learn recently that on modern x86 CPUs, named registers actually reference hidden, dynamically allocated physical registers, a bit like virtual memory is an indirection layer over physical memory. It's levels of indirection all the way down...

jasonwatkinspdx 3y ago
So the basic principle is that stack machines have smaller instructions, but require extra instructions to shuffle values around on the stack. This is why register machines won out with hardware, and stack machines are popular for virtual machine intermediate representations (that get compiled or JIT down to register code in the end on basically all machines today). If you wanna learn about how register renaming works, look into Tomasulo's algorithm. State of the art chips are a lot more complex, but that's a good historic introduction to the fundamental ideas.
runlaszlorun 3y ago
I’ve been wrestling with WASM bytecode and text format of and on for the last couple years for want of doing something assembly-ish but not wanting to write off doing it for the web. Personally, I’d say it’s at least as much of a register machine as a stack machine and ways in which it is one vs the other at times sure had me running in circles. I’ve seen plenty of quotes about how it’s not supposed to be a real assembly, how you’re not supposed to deal with its text format or bytecode, and how it and its documentation are for compiler writers not typical programmers. Which is exactly the take that I think is so wrong with our status quo of opaque, overly abstracted technologies that are highly optimized in their parts yet so disappointing in the whole. As a Forth substitute, I was sorely disappointed. I did learn a lot in my wanderings, and what WebAssembly is mostly is a an implementation to run a C architecture. Which is pretty much what it came from. Not that I’m against that, but I sure ran in circles trying to make it more Forth-like. And given it’s raison d’etre to be more performant vs Javascript it seems to be faster in some benchmarks while slower in others. I think this is more a testament about how optimized V8 and its brethren are then a slam on WebAssembly.
- sph 3y ago
  I was hyped for WASM as well, but the more I read the spec and standardisation process, the less I am bullish about this as a long-term piece of tech. I would be surprised if it is still around in 30 years (compared to stuff like UNIX, C or even Forth) It's closeness to Javascript and the fact that it's basically managed by companies that want to keep Web as complicated as possible so they can enjoy their monopoly on it, turns me off big time. And lastly, the only thing it has in common with Forth, is being stack-based. Computing has become an unsustainable pile of buggy abstractions on top of one another, and WASM is simply another layer on top this pile of dung, rather than a return to the basics. I get why it wants to give programmers nothing more than a rounded pair of scissors, but then for a glorified VM it's incredibly over-engineered. Art has never been created by a committee of commercial entities. I had in mind to write a OS that runs WASM natively, but these days I'd rather put a persistent, programmable Forth interpreter that gives you full access to the hardware at the lowest level, and build up from there.
DonHopkins 3y ago
Here's some ideas about WASM forth I wrote about previously: https://news.ycombinator.com/item?id=34374057 https://news.ycombinator.com/item?id=34374057 >This is a great article! I love his description of Forth as "a weird backwards lisp with no parentheses". >Reading the source code of "WAForth" (Forth for WebAssembly) really helped me learn about how WebAssembly works deep down, from the ground up. >It demonstrates the first step of what the article says about bootstrapping a Forth system, and it has some beautiful hand written WebAssembly code implementing the primitives and even the compiler and JavaScript interop plumbing. We discussed the possibility of developing a metacompiler in the reddit discussion. [...] Check out this beautiful hand written wasm code, a dynamic wasm based Forth compiler: https://github.com/remko/waforth/blob/master/src/waforth.wat https://github.com/remko/waforth/blob/master/src/waforth.wat It compiles new Forth words into teenie tiny little wasm modules, and hooks out through JavaScript in the browser to create and link them in to the main module, so it can call the code it just compiled. Wasm doesn't let you modify compiled code, but you can compile new code and link it in and execute it!
hayley-patton 3y ago
JVM, Python and WASM are more like the SECD [0], not a plain stack machine, by use of a local environment. BEAM (for Erlang) is a register machine. And the JVM and WASM get compiled to code for register machines, with the VM stack not present (in a concrete form) at runtime. > a stack-based VM is relatively easy to optimise for a register CPU. You get SSA for almost free (just phi the stacks at control joins), but after making SSA everything is the same regardless of stack- or register- VM. [0] https://academic.oup.com/comjnl/article/6/4/308/375725?login=false https://academic.oup.com/comjnl/article/6/4/308/375725?login...

by sph 3y ago

jasonwatkinspdx 3y ago

So the basic principle is that stack machines have smaller instructions, but require extra instructions to shuffle values around on the stack. This is why register machines won out with hardware, and stack machines are popular for virtual machine intermediate representations (that get compiled or JIT down to register code in the end on basically all machines today). If you wanna learn about how register renaming works, look into Tomasulo's algorithm. State of the art chips are a lot more complex, but that's a good historic introduction to the fundamental ideas.

runlaszlorun 3y ago

I’ve been wrestling with WASM bytecode and text format of and on for the last couple years for want of doing something assembly-ish but not wanting to write off doing it for the web. Personally, I’d say it’s at least as much of a register machine as a stack machine and ways in which it is one vs the other at times sure had me running in circles. I’ve seen plenty of quotes about how it’s not supposed to be a real assembly, how you’re not supposed to deal with its text format or bytecode, and how it and its documentation are for compiler writers not typical programmers. Which is exactly the take that I think is so wrong with our status quo of opaque, overly abstracted technologies that are highly optimized in their parts yet so disappointing in the whole. As a Forth substitute, I was sorely disappointed. I did learn a lot in my wanderings, and what WebAssembly is mostly is a an implementation to run a C architecture. Which is pretty much what it came from. Not that I’m against that, but I sure ran in circles trying to make it more Forth-like. And given it’s raison d’etre to be more performant vs Javascript it seems to be faster in some benchmarks while slower in others. I think this is more a testament about how optimized V8 and its brethren are then a slam on WebAssembly.

sph 3y ago
I was hyped for WASM as well, but the more I read the spec and standardisation process, the less I am bullish about this as a long-term piece of tech. I would be surprised if it is still around in 30 years (compared to stuff like UNIX, C or even Forth) It's closeness to Javascript and the fact that it's basically managed by companies that want to keep Web as complicated as possible so they can enjoy their monopoly on it, turns me off big time. And lastly, the only thing it has in common with Forth, is being stack-based. Computing has become an unsustainable pile of buggy abstractions on top of one another, and WASM is simply another layer on top this pile of dung, rather than a return to the basics. I get why it wants to give programmers nothing more than a rounded pair of scissors, but then for a glorified VM it's incredibly over-engineered. Art has never been created by a committee of commercial entities. I had in mind to write a OS that runs WASM natively, but these days I'd rather put a persistent, programmable Forth interpreter that gives you full access to the hardware at the lowest level, and build up from there.

DonHopkins 3y ago

Here's some ideas about WASM forth I wrote about previously: https://news.ycombinator.com/item?id=34374057 https://news.ycombinator.com/item?id=34374057 >This is a great article! I love his description of Forth as "a weird backwards lisp with no parentheses". >Reading the source code of "WAForth" (Forth for WebAssembly) really helped me learn about how WebAssembly works deep down, from the ground up. >It demonstrates the first step of what the article says about bootstrapping a Forth system, and it has some beautiful hand written WebAssembly code implementing the primitives and even the compiler and JavaScript interop plumbing. We discussed the possibility of developing a metacompiler in the reddit discussion. [...] Check out this beautiful hand written wasm code, a dynamic wasm based Forth compiler: https://github.com/remko/waforth/blob/master/src/waforth.wat https://github.com/remko/waforth/blob/master/src/waforth.wat It compiles new Forth words into teenie tiny little wasm modules, and hooks out through JavaScript in the browser to create and link them in to the main module, so it can call the code it just compiled. Wasm doesn't let you modify compiled code, but you can compile new code and link it in and execute it!

hayley-patton 3y ago

JVM, Python and WASM are more like the SECD [0], not a plain stack machine, by use of a local environment. BEAM (for Erlang) is a register machine. And the JVM and WASM get compiled to code for register machines, with the VM stack not present (in a concrete form) at runtime. > a stack-based VM is relatively easy to optimise for a register CPU. You get SSA for almost free (just phi the stacks at control joins), but after making SSA everything is the same regardless of stack- or register- VM. [0] https://academic.oup.com/comjnl/article/6/4/308/375725?login=false https://academic.oup.com/comjnl/article/6/4/308/375725?login...