Inspiration The idea of a truly sovereign toolchain—a language that does not rely on any other language—has always been the ultimate challenge in systems programming. I was inspired to build TECH to explore what happens when a compiler reaches a fixed point: when the compiler can compile itself, and the output is bit-for-bit identical to the seed.

The central mantra, "Every line is a compressed declaration of intent," pushed me to design a language where the compiler doesn't just parse syntax—it actively recognizes intent. Instead of unrolling loops syntactically, TECH introduces the semantic EXPAND operator (...). This operator allows the compiler to count iterations arithmetically and collapse recognized shapes (like matrix multiplication) into single, native pattern instructions, turning high-level abstraction into bare-metal efficiency.

What I Built TECH is a complete, self-hosting technological ecosystem. It includes:

A Self-Hosting Compiler & VM: The entire toolchain (compiler, VM, and optimizer) is written in TECH itself. The compiler reaches a fixed point (s1 = s2 = s3) and is bit-equivalent to the original C seed.

A Unique Language: Features compile-time dimensional analysis unit M , L , T unit M,L,T (rejecting mass = length at compile time), a first-class semantic loop operator, and a fully specified type system with no type inference.

A Modular OS Kernel: A 12-module kernel written entirely in TECH, featuring a preemptive scheduler, audit logs, and filesystem drivers.

UNVM Subsystems: A multi-domain computation graph supporting quantum statevector simulation, AI autodiff, chemical molecular dynamics (Lennard-Jones), and signal processing (radix-2 FFT).

Native Backends: A tiered JIT with three native backends (x86-64, AArch64, RISC-V) that produce identical deterministic outputs.

How I Built It The bootstrapping process was the core engineering challenge. It began with a minimal C seed (stage0/vm.c), which acts as the "CPU" to interpret the .tbc bytecode. This seed compiled the TECH compiler (compiler.tech), which then compiled itself repeatedly until it reached a fixed point:

text stage0 C compiler → compiles compiler.tech → s1.tbc s1.tbc → compiles itself → s2.tbc s2.tbc → compiles itself → s3.tbc (s1 == s2 == s3) I implemented the optimization tiers (L0 to L4) incrementally:

L0/L1: Computed-goto interpreter and inline caching.

L2: A register-based IR with a 1,439-line linear scan register allocator (written in TECH).

L4: Pattern detection for buffer fusion. When running the matmul kernel, the compiler recognizes the shape:

C [ i ⋅ N + j ]

+

A [ i ⋅ N + k ] ⋅ B [ k ⋅ N + j ] C[i⋅N+j]+=A[i⋅N+k]⋅B[k⋅N+j]

It emits a single CALL_PATTERN instruction, allowing the AVX-512 SIMD kernel to push ~4.1 G int64 mul-add/s, hitting the ~12 GB/s single-core streaming limit of the hardware.

Challenges Faced Building a self-hosting compiler exposed the harsh realities of bootstrapping, where there are no safety nets.

Silent 0-Byte Compiles: The compiler has sharp edges. Placing a WHILE inside a MATCH/CASE body or using a void builtin (like print) as an expression results in a silent 0-byte .tbc file with no diagnostic. This forced a rigorous contract discipline—every CASE must delegate to a helper function.

String Pitfalls: I discovered that str + str silently yields 0. All text assembly had to be re-routed through buf<> byte buffers to avoid wrong values.

JIT Heap Corruption: In larger applications (like the 12,000-line OncoPattern suite), the Tier-1 JIT caused a realloc(): invalid pointer error. Using AddressSanitizer, I traced it to a missing capacity check in the FPUSH macro at vm.c:2768—the fast-path was writing past the operand-stack allocation. The fix was to insert the bounds check, but the discovery highlighted the fragility of high-performance interpreter code.

Semantic Loops: Ensuring that PARALLEL FLOW is byte-identical to sequential FLOW required rigorous testing. Parallelism is defined by the sequential reference; if the parallel run differs, it is treated as a bug, forcing deterministic static work partitioning.

What I Learned I learned that achieving a fixed point is not just a programming trick—it is a form of trust. By verifying that s1 == s2 == s3 and matching the C seed output, I eliminated a layer of reliance on external tools.

I also learned that hardware physics dictates optimization. At L4, the interpreter moved data at ~12 GB/s, which is the memory bus limit of the Xeon processor. The raw rep movsb variant couldn't improve this—it taught me that sometimes optimization is about identifying the bottleneck and stopping, rather than adding more code.

Finally, maintaining a self-hosted register allocator (1,439 lines of TECH) taught me that a language doesn't need to be complex to be powerful. With 52 base instructions, semantic loops, and compile-time dimension checking, TECH proved that a small, well-defined ISA can support everything from molecular dynamics simulations to an OS kernel.

Built With

  • allocation
  • arm64
  • assembly
  • avx-512
  • bootstrapping
  • bytecode
  • compiler
  • computing
  • construction
  • jit
  • kernel
  • linear
  • machine
  • matching
  • operating
  • pattern
  • processing
  • quantum
  • risc-v
  • self-hosting
  • simd
  • system
  • tech
  • virtual
  • x86-64
Share this project:

Updates