A bare metal physical implementation of WASM. That's right, a WebAssembly CPU (2018)

A stack-based WASM CPU for stack-based WASM bytecode will be slower than a traditional register based CPU for reasons that have been known at least since the 1970s-1980s, when stack-based CPUs for Smalltalk, Lisp, and C were tried.

This didn't stop Sun from trying again in the 1990s to make stack based CPUs for the JVM (picoJava, UltraJava, ...).

TL;DR: A WASM CPU will need a complicated stack cache to map stack positions to registers. This will involve more transistors, power, and latency than just letting compiler writers use the registers directly.

One of the earliest important papers is from 1982: "Register Allocation for Free: The C Machine Stack Cache."[1]

Lispers sometimes lament that current processors are 'C machines ill-suited to Lisp like the Symbolics Lisp processors of yore', but in reality, C is very much a stack language, too. A C compiler is soooooo much easier to write if you don't have to worry about register allocation, a hard problem.

I like that WASM is stack-based because it makes compilers for WASM much easier to write. But it makes the WASM JIT compiler much more complicated to write. But it's better that top talent at Google, Mozilla, etc. does the WASM JIT compiler so that the rest of us can focus on solving other problems.

The Lisp Machines of yore had instructions for tagged arithmetic, which can speed up, say, adding two dynamically typed variables. No need for a compiler to infer and enforce the datatypes of simple variables in advance, the processor checks the datatypes while it is executing the code and signals a type error if you try to add a float to a character. But modern JIT strategies, which can infer the datatypes of loop variables and emit native instructions lightning fast, might ultimately be better.

[1] https://www.eecg.utoronto.ca/~jzhu/csc467/readings/ra-for-free.pdf ↗

A webassembly CPU in a FPGA could be quite a thing. Not sure how fast, but perhaps the processor could be implemented as an accelerator of opcodes generated by having WASM transformed into something at a lower level. Direct execution might be too slow. Still, speed isn’t everything and first generation doesn't need to be for prime-time.

Bigger question is: is this useful? Does it have an actual application that can drive it forwards? A solid yes to that question shoves all the others to the side.

Useful might at first just mean "hey its going to run my blinky lights using WASM instead of arm/avr/etc!" If so, then you already have a winner as soon as it hits the FPGA bitstream flash. From there you can add support for all those pmods on your dev board and off you go.