A bare metal physical implementation of WASM. That's right, a WebAssembly CPU (2018)
In this technical retrospective (2021), @Kinrany shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
Core Principles for Independent Builders:
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
CATEGORY Frugal Engineering →
HISTORICAL ERA Pandemic Bubble (2020–2022)
COMMUNITY SCORE ★ 125 points
TOTAL DISCUSSIONS 61 comments
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.
Sun at some point built a CPU that could run java bytecode "natively". That sounds nicer than it actually is when you realize that most practical optimizations happen at run time in Java.
WASM is very similar in that it typically gets executed by a jit and that compilers don't try to optimize too much ahead of time. WASM is optimized for loading quickly in a JIT. It also shares the issue that it needs to run on a very wide variety of hardware architectures. So it is not optimized for any particular one.
I was reminded of TornadoVM, a product for doing SIMD high-speed arithmetic processing on FPGAs by converting Java, Python, etc. to OpenCL. https://www.infoq.com/articles/tornadovm-java-gpu-fpga/
The transcompiler is forever.
Obligatory: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript