
WebAssembly Stack Machine - brakmic
https://docs.google.com/document/d/1CieRxPy3Fp62LQdtWfhymikb_veZI7S9MnuCZw7biII/edit
======
CalChris
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
> 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
_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
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.

------
bcg1
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
The devil's in the details. Exception handling and garbage collection are
different enough that a straightforward adaptation won't cut it.

~~~
tdb7893
Could you build a JVM in WASM?

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

~~~
amaranth
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
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
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.

------
aspirin
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
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.

------
pythonlion
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
Java Applets, Flash, PNaCl, WebAssembly. Chose your poison.

------
shkaboinka
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
...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)

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

------
sofaofthedamned
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?

~~~
wingless
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.

~~~
amyjess
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.

