I'm Building a Multi-Target Compiler Backend from Scratch — No LLVM, No Crutches

I'm Building a Multi-Target Compiler Backend from Scratch — No LLVM, No Crutches

posted Originally published at dev.to 2 min read

Hi there, i'm Gideon. Three years of writing C++ from the ground up — ray tracers, video codecs, and now a compiler. No frameworks. No LLVM. Just me, the hardware manuals, and a lot of wrong turns.

This post starts a series where I document the build in real time. I'm currently in the parser stage. By the end, I want a compiler that emits x86-64 and SPIR-V from a C++-like language, with SIMD vectorization and security-hardened codegen baked in.

What I'm Actually Building

Not a programming language. A compiler backend toolkit — the part that turns intermediate representation into fast machine code across multiple targets.

The pipeline:

Source → Parser → AST → SSMOL (HIR) → MREL (LIR) → x86-64 / SPIR-V / ARM64 / RISC-V / WASM

MREL is my target-agnostic low-level IR. It knows about virtual registers, stack slots, and machine operations — but not physical register names. The backend handles that per-target.

Why Not Just Use LLVM?

LLVM is 4 million lines of code. It solves everyone's problem and no one's perfectly. I need:

  • Fine-grained control over SIMD width selection per target
  • Constant-time crypto primitive emission with secret register annotations
  • Security obfuscation passes (control flow flattening, opaque predicates)
  • A codebase I fully understand and can license

Building from scratch is slower. But I own every decision.

Where I Am Right Now

Parser stage. Hand-written recursive descent. C++-like syntax with:

  • Functions, structs, basic types
  • Ownership semantics (borrowed from my Rust phase, simplified)
  • Explicit SIMD types (v128, v256, v512)

The parser emits an AST that gets lowered to SSMOL — my high-level IR that knows about types, ownership, and semantics.

What's Next

  1. SSMOL → MREL lowering (types to sizes, structs to offsets, control flow to basic blocks)
  2. MREL → x86-64 backend (register allocation, instruction selection, ELF emission)
  3. One working program: compile, link, run main() that returns 42

Then SPIR-V compute kernels. Then the rest.

What I'll Write About

Each stage, when I hit it. The problems that took me three days to solve. The specs I wrote to keep myself honest. The wrong assumptions that cost me a week.

Not polished tutorials. Build logs from someone actually building.

Follow This Series If

  • You work in systems, compilers, or graphics
  • You're curious what "building from scratch" actually looks like
  • You want to see if I crash or ship

My Specs (For the Curious)

I write technical specifications to keep the design coherent across months of work. The MREL backend spec covers x86-64, ARM64, RISC-V, SPIR-V, and WebAssembly with calling conventions, opcode tables, and security passes. Link in bio.

Substack: (https://ayndlr.substack.com)

Closing

This is post 1 of however many it takes. Next post: parsing expressions with operator precedence and why I gave up on Pratt parsing.

Follow for the crash or the ship. Either way, it's real.

Part 1 of 2 in Building a Compiler

2 Comments

2 votes
0

More Posts

I’m a Senior Dev and I’ve Forgotten How to Think Without a Prompt

Karol Modelskiverified - Mar 19

Tuesday Coding Tip 02 - Template with type-specific API

Jakub Neruda - Mar 10

Tuesday Coding Tip 06 - Explicit template instantiation

Jakub Neruda - Apr 7

TypeScript Complexity Has Finally Reached the Point of Total Absurdity

Karol Modelskiverified - Apr 23

Your Tech Stack Isn’t Your Ceiling. Your Story Is

Karol Modelskiverified - Apr 9
chevron_left

Related Jobs

View all jobs →

Commenters (This Week)

3 comments
1 comment

Contribute meaningful comments to climb the leaderboard and earn badges!