
WASM as a Platform for Abstraction - MichaelFBryan
http://adventures.michaelfbryan.com/posts/wasm-as-a-platform-for-abstraction/
======
pjmlp
WASM advocates keep rediscovering the benefits from bytecodes as portable
execution format, while presenting them as something great made possible only
by WASM.

Reading a bit of mainframe history would do some good it seems.

~~~
Shish2k
> Reading a bit of mainframe history would do some good it seems.

I wonder if anyone has a list of awesome mainframe features so that we know
what modern computing is going to "invent" next? :P

(See also: hot-swappable parts, virtualisation, containers, etc... I never got
to work with mainframes myself, just each time I dig into some new "industry
game-changer" tech, I learn that mainframes had it in the 60's)

~~~
pjc50
Someone was circulating the IBM 360 "principles of operation" recently, which
sounds like a good way to start.

The trick is identifying which parts were abandoned by mistake, and which
parts were abandoned because they were genuinely bad. Nobody wants 21st
century JCL.
[https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/...](https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieab200/iea3b2__Examples_of_JCL.htm)

~~~
magoghm
We already have a 21st century JCL: Kubernetes.

------
xuejie
While I do agree WASM makes a lot of sense for the Web, I personally am having
doubts regarding treating WASM as a general abstractions for native code as
used in the post. For this case, it might suit the job better to have a
bytecode that resembles more of underlying machine architecture, rather than a
still highly abstracted model like WASM. Please don't get me wrong, I do agree
WASM is already one step ahead of, say, JavaScript, but we can do better than
that.

The problem with WASM here, is that it really is a bloated model like JVM in
its early days, huge amount of work is needed to make it closer to native
speed, which is contradictory to the original slogan. What's more, people are
still planning to add tons of new features to it:
[https://webassembly.org/docs/future-
features/](https://webassembly.org/docs/future-features/). Before you tell me
those are opt-in features, the question I want to raise is: for an abstraction
of general platform, you would definitely want to have a widely accepted
standard so people know what features will be expected, one example is that
people know SSE will be available for 64-bit x86 code.

With all those opt-in features, I doubt if we can have a proper layer that
adapts well to different implementations with different supported features. We
might end up with the situation like Rust, where you can claim a secondary
compiler could exist, but in practice people are all using the same
compiler/implementation.

~~~
dmitriid
Besides, doesn't LLVM already have an IR which servers as one such higher-
level abstraction?

~~~
jahewson
Google created pretty much this, called it PNaCl and shipped it in Chrome. It
now has been retired in favor of WASM.

~~~
pjmlp
Because Mozilla went political and came up with asm.js as counter technology.

~~~
afiori
Or as some other (like, eg Google itself) would say:

> Because Mozilla went political and came up with asm.js as better technology.

~~~
pjmlp
I am pretty sure that asm.js would not happened if Chrome already had the
market share it enjoys nowadays.

WASM is still catching up to PNaCL in performance, hardly better.

------
wsxcde
The author has rediscovered the need for software fault isolation (SFI).
Bytecodes or IRs like WASM can also provide SFI but are overkill because they
provide more than just SFI.

If I were him, I'd have used this as an excuse to play with NativeClient.

\--

The original paper on SFI was by Robert Wahbe and colleagues:
[https://cs155.stanford.edu/papers/sfi.pdf](https://cs155.stanford.edu/papers/sfi.pdf).

Google's NativeClient is a modern take on SFI for x86:
[https://static.googleusercontent.com/media/research.google.c...](https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/34913.pdf).

~~~
jedisct1
Unfortunately, NativeClient has been abandoned.

------
mr__y
Yo dawg we herd you like abstractions so we put a VM in a container-runtime in
a hypervisor in your CPU so you can use JIT compilation while you use other
JIT compilation

------
cordite
The requirements

1\. People need to be able to upload new code while the system is still
running 2\. This application will be interacting with the real world (think
robots and automation), and we really don’t want a crash in user-provided code
to make the entire system stop responding

is suspiciously close to Erlang, except for the user-provided part.

------
ridiculous_fish
Lots of wasm questions:

In what sense can a wasm program "crash?" What sort of backtraces are
available in that event? How's the debugging story?

Is there a fast wasm runtime available for non-JIT platforms? Is there big-
endian support (still hanging on)?

~~~
kimundi
Wasm programs can only crash by triggering a "trap", which has the well
defined semantic of aborting the entire (wasm) function stack at that point.
It depends on the embedding host how much backtrace or debugging support you
get for this.

I'm not sure exactly what you mean with non-JIT platforms, As far as I know,
most wasm hosts that generate native code just compile the entire wasm module
at once, so its less like a JIT runtime and more like a regular compiler.

If you mean not compiling to native code at all, then you just have the
performance of a plain old stack machine bytecode interpreter. Not sure how
many there are currently and how well optimized they are though.

About big-endian - afaik little-endian is just the spec for storing to wasm's
linear memory - the actual representation of stack values can be arbitrary
(since you can not inspect their bytes directly).

------
bayesian_horse
You could also bring back genetic algorithms/genetic programming on top of
WASM ;-)

------
Animats
Strange. Something like node.js for running server side WASM programs, maybe.
But hard real time? That's a strange application for this. Why add the
additional layer?

~~~
rapsey
Where does it say hard real time?

~~~
Animats
Where it says: "While this section will be fairly specific to my use case
(creating some sort of programmable logic controller that people can upload
code to), it should be fairly easy to adapt to suit your application."

