2024-12-29
After two years of late nights and weekends, Onramp can finally compile Doom. Check it out:
The above is running on an out-of-the-box x86_64 Alpine Linux. It has no compilers, no libc headers, no build tools of any kind. The only things I’ve added are the source code to Onramp and Doom and a DOOM.WAD file (the art assets for the game.)
Onramp bootstraps itself out of pure handwritten source code. It starts from a simple virtual machine in commented hexadecimal x86_64 machine code. In the VM bytecode I wrote a tiny linker; in object code I wrote an assembler; in assembly I wrote a small C compiler; and so on up to a C17 compiler, assembler, linker, libc and other tools.
Onramp does not support graphics so I wrote a command-line frontend to Doom called doom-cli. It renders with Unicode block sextant characters and ANSI terminal color escape sequences. It heuristically determines key repeat delay to simulate key release events.
Onramp bytecode is, for now, extremely slow. CoreMark on Onramp runs about 500x slower than when natively compiled and optimized with GCC. I estimate the VM adds a 10x-20x performance penalty and the poor bytecode emitted by the Onramp compiler causes the remaining 25x-50x. This is not a major limitation since Onramp is intended for non-interactive bootstrapping. Still, I have plans to improve the compiler output later.
When I first got Doom compiling with Onramp, it ran at about 2 FPS on the fastest VM, taking around 460 ms per frame. About 200 ms was doomgeneric’s code to convert the paletted framebuffer to full color, and another 200 ms was in my doom-cli code to convert the framebuffer to unicode characters. Only 60 ms was the original Doom code rendering its entire frame. It is astonishing how efficient the Doom source code is, even when compiled with an awful compiler on a primitive VM some 30 years after Doom was written. John Carmack and co are undeniably geniuses.
Onramp’s bootstrap sequence is similar in concept to the stage0 project. The difference is that Onramp is as platform independent as possible.
The goal is to have an entire implementation of C that sits on top of a simple virtual machine, one that can be trivially implemented by anyone on anything. To bootstrap C on a new platform, you just need to implement an Onramp VM in a few hundred lines of whatever language is available on that platform. If nothing is available (or nothing can be trusted), the VM is simple enough to be written directly in machine code.
The bootstrap process does not rely on any binaries aside from those that already exist on the platform, in this case the kernel and coreutils. This makes the entire process auditable.
Onramp currently still depends on a hosted environment with a filesystem. It doesn’t have to be anything like UNIX, but it does need a concept of named files and folders with arbitrary contents. This is of course a major “trusting trust” vulnerability. (It also currently needs a POSIX shell because the Onramp shell tool is not done yet.)
A long-term goal is to implement the filesystem within Onramp. It should be possible to boot directly into an Onramp VM, compile a native kernel and chainboot into it. The stage0/live-bootstrap team have already accomplished this for a few present-day architectures. With Onramp I hope to greatly reduce the platform dependence, supporting architectures both future and past with minimal porting effort.
Rob Landley once tried to make the minimum possible system that could rebuild itself within itself. He got it down to four tarballs:
With just one more tarball, this system could actually boot from source. We would have a full compilation environment bootstrappable from a minimal set of pure source tarballs. This is another long-term goal of Onramp.
Doom is the first major milestone for Onramp. The next step is getting it to build TinyCC and other compilers, which might actually make Onramp useful for something. There aren’t too many missing features but a big one is floating point support. This will be a bit of a challenge because it needs to be software emulated.
Why software emulated? The short answer is, Onramp is a tool for xenocomputing. I want humanity to preserve and share documentaries like Planet Earth with far future archaeologists and alien civilizations. To do that, we need to make it possible to run contemporary codecs and compression algorithms on hardware we can’t even conceive of. I believe the best way to accomplish this is to give them the original source for our decoders as well as the tools to compile and run them on anything. Onramp is one of these tools.
Would aliens have access to unsigned binary arithmetic? Almost certainly! Would they have IEEE 754 floating point? Highly improbable, so we have to emulate it. This principle has guided the design of Onramp.
With a bit more effort, Onramp should soon be able to compile and run things like ffmpeg and DOSBox. This would allow us to preserve and transmit huge parts of our culture and computing history far into the future.