10 ms·
A bare metal physical implementation of WASM. That's right, a WebAssembly CPU (2018)
- Mountain_Skies 5y agoPretty neat idea though it appears to have stagnated a couple years back.
- VHRanger 5y agoUh, so the code is all typescript, JS and HTML. Not sure how you'll get "bare metal" performance with those languages
- deleted 5y ago[deleted]
- eximius 5y agoTheir todo list has implementing it in hardware descriptor languages. It's not checked as done yet.
- tyingq 5y agoWell, and the last commit is Dec 14, 2018.
- outsomnia 5y ago> Roadmap > Understand the WebAssembly ISA
- whatshisface 5y agoOne day I will make the HN front page with a repo containing a todolist with one unchecked item. "TODO: Write a todo list cool enough to make the frontpage of HN."
- nesarkvechnep 5y agoDon't forget redux.
- fake-name 5y agoA.k.a - "I'm going to make a repo because we I have a neat idea" - .... 3 hours later ... - "I'm not sure this is even possible" And then it died.
- guiriduro 5y agoMaybe this is what ex-CEO Trevor Milton (of Nikola fame) was talking about when he boasted they had developed HTML5 supercomputers?
- deleted 5y ago[deleted]
- eximius 5y agoObligatory: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- guscost 5y agoThis is “inspired in part” by the same (excellent and a little scary) talk. Which makes you think, when would something like this have appeared if the talk had never happened?
- teeray 5y agoThis was my first thought when I saw the headline. What I once thought was satire was, in fact, prophecy.
- ksec 5y agoWe are lucky nuke didn't happen in 2020, but COVID. And there are people fleeing San Francisco for different reason.
- ofubd8kc 5y agoA 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 https://www.eecg.utoronto.ca/~jzhu/csc467/readings/ra-for-fr...
- jvanderbot 5y agoAh yes, I remember the embedded SoCs that started appearing in our coursework and labs that ran Java native. It just never seemed to be worth all the trouble to me. There are whole ecosystems that have to be supplanted, and for what? To help 'get into' a new domain?
- aseipp 5y agoI mean, you don't even have to go as far as register allocation to see the problems that make it all a big dead end. WebAssembly requires e.g. the call opcode parameter to actually be an index into the global function table, causing an indirection, which is about a trillion times worse than current CPUs which can just directly write the new PC to the register file at once. The spec is littered with stuff like this, for good reason. Considering WebAssembly is designed to be relatively easy to compile ahead of time, there's no reason to make the hardware worse when you could just ship "firmware" that compiles to an underlying ISA transparently, and reuse decades of existing knowledge. This would make the system behave more like the AS/400 and IBM iSeries, which abstracted away the underlying microarchitecture through its firmware.
- ksec 5y agoMissing 2018 in the title.
- kwdc 5y agoA 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.
- jillesvangurp 5y agoSun 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.
- deleted 5y ago[deleted]
- mst 5y agoThere were also ARM variants that could run a bunch of JVM bytecode natively - https://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wiki/Jazelle
- monocasa 5y agoIt was only really competitive against interpreters. It was aimed at a gate count niche that couldn't expect a JIT, for instance feature phones or JavaCards.
- Stephanemw 5y ago+1 on the features phones - I worked on quite a few of them that had Jazelle acceleration for J2ME. Solid 60fps on those 206MHz CPUs and the bottleneck was actually the display pipeline!
- jillesvangurp 5y agoThanks, that's what I was referring to.
- varjag 5y agoWASM isn't specifically meant to be JIT and there is no compelling reason to. One prime use is ahead of time native compilation from easy to translate intermediate representation.
- hodagi 5y agoI 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/ https://www.infoq.com/articles/tornadovm-java-gpu-fpga/ The transcompiler is forever.
- deleted 5y ago[deleted]