KernRift

Self-Hosting Compiler

KernRift compiles itself. The compiler is ~304K tokens of KernRift across 25 source files, plus 19 stdlib modules. It achieves a bootstrap fixed point — compiling itself twice produces bit-identical binaries, verified on all 8 platform targets (Linux x86_64/ARM64, macOS ARM64/x86_64, Windows x86_64/ARM64, Android ARM64/x86_64) with 1236 tests passing on every CI run. No LLVM, no Rust, no C, no external assembler — just KernRift all the way down.

Bare Metal & Kernel Targets

Beyond the eight hosted slices, krc cross-compiles for embedded targets and for the Linux kernel. These paths emit machine code directly — still no LLVM, no assembler, no linker.

ESP32. The emitted image is parsed and loaded by the chip's mask ROM straight from flash — no second-stage bootloader and no flash XIP, so the program is entirely RAM-resident: 127 KiB IRAM for code and 192 KiB DRAM for data, bss and stack, with 4 KiB reserved for the stack. Verified on an ESP32-D0WD-V3: the image boots and runs, and a single flipped payload byte is rejected by the ROM with csum err, confirming the checksum path is genuinely enforced. IRAM is 32-bit-access-only on this part, so byte-addressable data must live in DRAM — the compiler enforces that at compile time rather than letting it fault on the board.

Current limits, stated plainly. The RISC-V 32 and Xtensa backends support integer code, control flow, string literals, static and stack data, inline assembly, function pointers and MMIO device blocks. In freestanding mode they do not yet support struct values (IR_ALLOC is unimplemented on that path — structs do work on hosted riscv32) or floating point. Both backends are 32-bit throughout and reject u64/i64 outright, which matters because u64 is the language default — embedded code uses uint32. Freestanding targets have no OS, so programs return from fn main() -> uint32 rather than calling exit(). Hosted x86_64 and ARM64 have no such restrictions.

v2.9.0: Bare-Metal Boot on x86_64 & ARM64

Six sub-projects take the compiler from "provably safe under static analysis" to programs that actually boot — under QEMU. --target=none is a new freestanding target (distinct from --freestanding on hosted arches): no libc, no host OS, every OS-bound construct refused at compile time, with print/println/f-strings/alloc routed through pluggable write/alloc providers (16550 UART, PL011, a bump heap) instead.

Everything bare-metal here is QEMU, on one machine, emulated. No real hardware, no vendor firmware. Secure Boot is measured incompatible — an MS-key OVMF refuses the identical artifact that runs unsigned. The boot gate (tests/target_none/boot_gate.sh) has 59 legs, 0 fail, 0 skip, and runs in CI on every push, including on a native ARM64 runner.

Also in v2.9.0: defect fixes that change behaviour — call_ptr silently dropped arguments 7+ and their side effects (now refused on both x86 backends); an unresolved extern fn produced a running binary with a wrong answer (now a hard error); --reset-vector=1-style =value flags were silently ignored, producing the wrong artifact class (now refused); and --debug silently emitted no array bounds checks on arm64 legacy codegen (now refused on that path).

Benchmarks vs. C and Rust

KernRift produces the smallest binaries and compiles 14-19× faster than gcc -O2 and 36-48× faster than rustc -O2. Runtime is now mixed against gcc -O2 rather than uniformly behind it: krc is 4.6× faster on sort (59 ms vs 272 ms), within 11% on mandelbrot and within 1.5× on sieve and matmul, but still 4-5× behind on sha256 and fib, where helper calls and call structure dominate. There is no auto-vectorization. That spread is the honest trade for a compiler that builds itself in under half a second. All measurements on AMD Ryzen 9 7900X, Linux 6.17, gcc 13.3, rustc 1.93, krc 2.8.33.

Compile Time

Binary Size

Runtime (median of 3)

krc's IR backend uses a graph-coloring register allocator (12 colors on x86_64, 23 on AArch64, 12 on RISC-V, 9 on Xtensa, Briggs/George copy coalescing with per-vreg colour ceilings, partial used-callee-save prologue, cross-register spill-reload peephole) plus constant folding / DCE / CSE / LICM, an AST-level function inliner with cost-aware rotation-shape detection, and codegen peepholes for LEA-immediate / LEA[base+idx×scale] / 3-operand IMUL / CMP-with-immediate / 32-bit ROR recognition / FFMA fusion. No auto-vectorization. v2.8.33 gave x86_64 a dedicated XMM register class, so f64 values live in xmm2-xmm15 instead of round-tripping through general-purpose registers on every operation — mandelbrot dropped 3.2×, from 1771 ms to 551 ms, closing the gap with gcc -O2 from 3.6× behind to 1.11×. It also widened the integer colour files (x86_64 6→12, AArch64 10→23) and, on Xtensa, 4→9, worth 1.90× on an int8 neural-network workload measured on ESP32 silicon. Compile time and binary size remain where krc excels most; runtime now ranges from beating gcc -O2 to roughly 5× behind it depending on the workload. Measurements on AMD Ryzen 9 7900X, gcc 13.3, rustc 1.93.

Self-Compilation Across Platforms

Self-compile = krc rebuilding its own ~304K-token source. Single-arch produces a native binary for the host architecture; fat binary bundles all 8 platform slices into one BCJ+LZ-Rift-compressed .krbo. v2.8.23 fixed three per-function memory leaks in the IR emitter and made the liveness scratch buffer reusable across basic blocks, dropping peak RSS ~96-99% vs v2.8.22 and making fat self-compile feasible on a 4 GB Raspberry Pi 400 (was OOM-bound). Peak RSS is the high-water mark of the compiler process; the resident set never grows beyond it during the run.

All five rows are fresh v2.8.29 measurements (median of 3; time is the compiler's self-reported compile time, peak RSS is the process high-water mark). The device numbers fell sharply from the previous table because those rows predated the compiler’s optimization work — the Redmi Note 8 Pro dropped from 27.5 s to 2.76 s single-arch, the Pi 400 from 32.4 s to 4.53 s. The desktop is the only row that rose (0.40 s → 0.50 s): it was already current, and the compiler source grew ~16% when the RISC-V, Xtensa, ESP32 and LKM backends landed, so there is simply more of it to self-compile.

How Other Compilers Compare (Self-Build)

krc is not directly comparable to production compilers — it has a linear IR with constant-folding / DCE / CSE / LICM, an AST inliner with rotation-shape cost model, codegen peepholes (LEA-imm, LEA[base+idx×scale], 3-operand IMUL, CMP-imm, 32-bit ROR, w32-clean mask elim, FFMA fusion), and a graph-coloring register allocator with Briggs/George copy coalescing, but no auto-vectorizer and no external linker in the loop. The comparison shows where a short, self-contained compiler sits on the build-time spectrum. TCC is the closest analog. External data is from public benchmarks on comparable hardware; see linked sources.

~63,500 lines, ~1.12 MB self-compiled binary. 1236 tests. Bootstrap fixed point verified on all 8 targets (Linux, macOS, Windows, Android × x86_64, ARM64). Fat binary: 8 slices, BCJ+LZ-Rift compressed.