About

The language, the design, and the person behind it.

The Language

KernRift is a bare-metal systems programming language designed for kernel-first development. It compiles ahead of time to native machine code — no virtual machine, no interpreter, no runtime. Programs are static executables with no dynamic linker and no libc. The language aims to make low-level work — device memory, inline assembly, manual memory management, freestanding targets — feel first-class rather than bolted on.

The compiler is self-hosted. It is written entirely in KernRift and compiles itself. There is no Rust, no C, and no LLVM in the build. When the compiler compiles itself a second time, the output is bit-identical to the first — a property called a bootstrap fixed point, and a basic sanity check that the language and its compiler are internally consistent.

By default, krc produces a single file — a .krbo fat binary — containing native code for all 8 supported targets (Linux, macOS, Windows, and Android, each on x86_64 and ARM64), BCJ-filtered and LZ-Rift-compressed. A small runner called kr extracts the matching slice at startup and executes it. One build artifact, eight platforms, no cross-toolchain.

The IR Backend

KernRift has a target-independent SSA-based intermediate representation. The AST lowers to IR instructions; a liveness analysis computes which virtual registers are alive where; a Chaitin-style graph-coloring register allocator assigns physical registers; a small optimizer runs constant folding, dead code elimination, and common subexpression elimination; and per-target emitters (x86_64, AArch64) produce raw machine code. There is no external assembler and no linker in the loop — the compiler writes ELF / Mach-O / PE headers and machine bytes directly to disk.

The IR handles 90+ opcodes spanning arithmetic, logic, memory, control flow, function calls, syscalls, atomics, floats, and inline assembly. Target-specific details — Linux versus macOS versus Windows syscall conventions, the Mach-O entry ABI, Windows IAT calls, Android bionic ELF quirks — are handled at emission time from abstract opcodes. A --legacy flag falls back to the original direct codegen; --ir forces IR through even where the shipped-binary recipe falls back to legacy (e.g. ARM64 slices inside compile_fat).

Current size story: the IR path now produces smaller binaries than legacy on both x86_64 and ARM64. The recent function inliner folds pure single-expression callees into their call sites (DCE then drops the unused originals for executable targets), and the v2.8.21 register-allocator work — partial used-callee-save prologue plus a cross-register spill-reload peephole — eliminated most of the redundant MOVs that previously bloated x86 output. --emit=obj, --emit=asm, and --emit=ir seed every top-level function as live so original definitions still appear in the linker symbol table / asm listing / IR dump even when their internal call sites have been inlined.

The IR ARM64 backend now handles compile_fat itself correctly — the v2.8.7-era miscompile that forced a --legacy --arch=arm64 shipping recipe was fixed in R1. ARM64 slices in compile_fat go through IR by default; --legacy remains as an explicit opt-out, not a silent fallback.

Design Values

The Creator

KernRift is created by Pantelis Christou, an Electrical and Computer Engineering student. The project started as a way to learn how compilers and operating systems actually work from the bottom up — by building one, not by reading about one. It has grown since.

The language, the compiler, the IR backend, the runtime, the standard library, and this website are written and maintained by one person. Bug reports, questions, and contributions are welcome on GitHub.

Related Projects

KernRift is the foundation of a larger, ongoing effort to build an independent, vertically integrated computing stack from the physics level up to cognitive architectures. I am building these to explore alternatives to the modern computing monopoly. You can find the other pieces of this ecosystem on GitHub:

Contact

For collaborations, architecture discussions, or inquiries regarding KernRift and my other projects, feel free to reach out:

[email protected]