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.
Performance
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 framebuf
