Building a Minimalistic Virtual Machine

A small personal computing stack, with a plethora of examples ready to go. Built by two they/them hackers who live on a boat and basically have bootstrapped everything about their vessel, their computing, their engineering, etc. It's very, VERY old-school hacker-y.

They would've made excellent phreaks back in the good ol' days.

I have a lot of respect for uxn and credit it as an inspiration, but the goals of each project are different. UXN is a 16-bit system with 64KB of RAM accessible. It will also probably always remain interpreted. These design restrictions are seen as tools to foster creativity.

UVM is a 32/64-bit VM. It's currently interpreted, but I've designed the instruction set with JIT compilation in mind. I have a PhD in compiler design and I'm fairly confident that I can make a fast JIT for UVM in a relatively short amount of time, when I feel the design is mature/stable enough.

At the moment, UVM is relatively immature, but I want it to be a small/minimalistic VM that you can still build "real" or modern software in that takes good advantage of the capabilities and performance of your machine.

Another difference is that IMO, UVM is more approachable. UXN's assembly language is fairly esoteric IMO. It doesn't look like any other assembly language I've ever seen. That doesn't make it bad, but it does potentially make it harder to learn and harder to leverage an existing base of programming skills. UVM's assembly is designed to not be surprising if you've ever programmed in assembly and know the basic ideas about how a stack machine works. I also have a WIP C compiler that's already usable to write simple programs. See my little snake game for a fun toy example: https://github.com/maximecb/uvm/blob/main/ncc/examples/snake...

Assembly syntax example: https://github.com/maximecb/uvm/blob/main/vm/examples/factor...

I'll point to the fact that there is almost no boilerplate necessary to start drawing some pixels on a 2D canvas, which IMO makes it a fun platform to develop for. Like I said, it's immature, but I'll iron out all the bugs I can find and keep making it better.

Thank you for sharing.

My ancient ruby code and nodejs code all broke because I didn't pin dependencies. As a result I've got software that is unrunnable.

More software shall be unrunnable as time goes on, I don't know many trends that prevent software from being unbuildable and unrunnable due to change except maybe repeatable builds and hermetic builds.

Given platform toolchains complexity and libc versions and complexity of static Vs dynamic linking, I suspect preserving software is very difficult.

It seems doing + - ×÷ on numbers is not the difficult part of computers but arranging information into the right places in order to do it.

Logistics and package management are difficult to get right.

I think Java got something right. Bytecode is longlasting. Can rewrite the JVM for new platforms and architectures.

I am writing my own language and it is implemented as an assembly interpreter and a compiler for that interpreter. This lets me get development speedier.

What the hard thing I think is more interesting than bytecode or virtual machines is INTEROP.

The Amd64 SysV Binary interface of registers for C calling interface and the System call Interface of Linux.

Mozilla abandoned XPCOM extensions, part of the reason was performance of the interop between JavaScript and C++.

If I could run a virtual machine and interop with modern code that would mean the software was useable for longer.

I feel WASM has the opportunity to create a truly audiovisual API for interacting with computers.