Coder Legion - Recent posts tagged compilers

Writing a Programming Language & Native x86-64 Compiler from Scratch in C: The Story of Yolish

Sun, 27 Sep 2026 03:56:49 +0000

Every programmer has, at some point, looked at their favorite programming language and thought:

“Why was it designed this way? How hard can it actually be to build one myself?”

Most developers who explore language design stop at simple arithmetic evaluators or toy interpreters. But when I was building Exploidus OS—a custom x86-64 reactive capability operating system—I ran into a fundamental architectural barrier:

Standard systems languages (like C) have zero concept of operating-system capability tokens. In C, if you have a pointer, you can dereference it. If you have an address space, any line of code can call any syscall unless restricted by complex external sandboxes.

I wanted a modern, expressive language that felt as ergonomic as Python or Rust, but was deeply capability-aware at the syntax level—able to compile directly to bare-metal x86-64 binaries without pulling in gigabytes of LLVM dependencies.

That ambition gave birth to Yolish—a fast, expressive, capability-aware programming language with a tree-walking interpreter, a bytecode virtual machine, and a direct x86-64 native compiler.

Here is how I designed Yolish, wrote its compiler from scratch in pure C, and what I learned building a complete language ecosystem.

1. Language Design: Ergonomics Meets Systems Control

When designing Yolish's syntax (.y), I wanted code to read cleanly without syntactic noise, while enforcing defensive systems programming invariants.

Immutability by Default

Variables in Yolish default to immutable constants using let, while mutable state must be explicitly declared using var:

let name  = "Yolish"   -- immutable constant
var count = 0          -- mutable state
count = count + 1

Pattern Matching with Ranges & Guards

Instead of archaic C-style switch statements with fallthrough bugs, Yolish features expressive pattern matching:

let grade = match score {
    90..100      => "A"
    80..90       => "B"
    n if n >= 60 => "C"
    _            => "F"
}

Structs and `impl` Blocks

Yolish rejects complex class hierarchies in favor of data-first structs and explicit method implementations:

struct Circle { radius }

impl Circle {
    fn area(self) {
        return y.math.pi * self.radius * self.radius
    }
}

let c = Circle { radius: 5 }
y.println(c.area())

2. Bridging Code to the Kernel: First-Class Capabilities

Because Yolish is the official userspace language for Exploidus OS, security cannot be an afterthought.

In Yolish, dangerous operations (network access, raw disk writes, peripheral I/O) are gated by declarative capability annotations:

@cap(net.read, fs.write)
fn sync_data(url, filepath) {
    let payload = y.net.get(url)
    y.fs.write(filepath, payload)
}

When compiled for Exploidus OS, the Yolish compiler inspects these annotations and validates them against the process's cryptographic capability table. If an unprivileged function attempts to make an unauthorized syscall, the operation is blocked before execution even reaches kernel space.

3. The Tri-Engine Architecture: Interpreter, Bytecode VM, and Native Compiler

Building a language engine involves tough tradeoffs. Tree-walking interpreters are easy to write but slow. Bytecode VMs are fast and portable. Native compilers deliver maximum speed but are deeply architecture-specific.

Instead of choosing one, Yolish implements all three:

Source Code (.y)
       |
    [Lexer] -> Tokens
       |
   [Parser] -> Abstract Syntax Tree (AST)
       |
       +---> Tree-Walking Interpreter  (`ys file.y` - Instant startup)
       |
       +---> Bytecode Compiler & VM    (`ys vm file.y` - High speed execution)
       |
       +---> Direct x86-64 Machine Code (`ys -c file.y` - Standalone binaries)

The Interactive Interpreter (ys file.y): Evaluates the AST directly. Perfect for quick scripts, one-liners, and the interactive REPL.
The Bytecode VM (ys vm file.y): Compiles the AST into an optimized instruction stream executed by a custom register/stack-based virtual machine.
The Native x86-64 Compiler (ys -c file.y): Generates real machine code instructions (MOV, ADD, CALL, RET, SSE2 float operations) directly into executable binary containers.

4. No LLVM, No Bloat: Direct Multi-Platform Binary Emission

Most modern compiler projects delegate code generation to LLVM. While LLVM is powerful, it is also a massive, multi-gigabyte dependency with slow compilation times.

I wanted the Yolish toolchain (ys) to be a single, self-contained C binary with zero external dependencies. You can clone the repo and compile the entire language toolchain with a single make command using standard gcc or clang in seconds.

To achieve this without LLVM, Yolish writes binary headers and machine code directly:

Linux ELF64: Directly formats ELF headers, program headers (PT_LOAD), .text sections, and Linux syscall dispatchers.
Windows PE32+: Generates valid Portable Executable (PE32+) headers, image import directories, and embeds Windows application icons.
macOS Mach-O: Generates 64-bit Mach-O load commands (LC_SEGMENT_64).

You can cross-compile for any major operating system with a single CLI flag:

ys -c app.y --target linux    # Emits static Linux ELF64 binary
ys -c app.y --target windows  # Emits Windows PE32+ .exe
ys -c app.y --target macos    # Emits macOS Mach-O binary

5. Runtime Architecture: Mark-and-Sweep Garbage Collection

A systems language with dynamic strings and closures needs safe, automatic memory reclamation.

Yolish implements a custom Mark-and-Sweep Garbage Collector (GC) written from scratch in C:

Root Scanning: Traverses the active call frame stack, global environment variables, and the VM operand stack to identify all actively reachable pointers.
Mark Phase: Recursively traverses heap-allocated objects (strings, dynamic arrays, closures, struct instances), setting the GC mark bit.
Sweep Phase: Scans the global heap allocation pool. Any block whose mark bit is zero was unreachable; it is freed back to the system memory pool, while surviving objects have their mark bits cleared for the next cycle.

Developers have full programmatic introspection into memory usage via gc.stats() and can trigger explicit collection via gc.collect().

6. A Tooling-First Philosophy

A great programming language is more than just a syntax parser; it is an entire developer experience.

Too many new languages fail because they require third-party formatters, linter plugins, and package wrappers before you can write a serious project.

From day one, Yolish was designed with a tooling-first philosophy:

Built-in Test Runner (ys test file.y): Write native test blocks alongside code and execute them without third-party frameworks.
Static Checker (ys check file.y): Performs static semantic analysis, flags undefined variables, and detects type mismatches before runtime.
Code Formatter (ys fmt file.y): Enforces an opinionated, canonical code style across codebases.
Interactive REPL (ys): Instant feedback loop with color-highlighted evaluation.

7. What Writing a Compiler in C Teaches You

Writing a programming language and compiler from scratch in pure C is one of the most humbling and rewarding journeys in software engineering:

Memory Discipline: Managing AST nodes, symbol tables, and lexical scopes in C forces you to understand every single byte you allocate. Memory leaks in a compiler slow down compilation; memory corruption in code generation crashes the output binary.
The Magic of Abstraction: When you write the code that translates a simple if (x > 10) into a CMP and JLE assembly jump, you demystify how computers actually think. You realize that high-level abstractions are not magic; they are just structured transformations of intent.
Simplicity Over Complexity: Features are easy to add to a grammar; keeping the language coherent, orthogonal, and bug-free across interpretation and native compilation is where the real engineering happens.

Conclusion & Open Source

Yolish started as a specialized language project for Exploidus OS, but has evolved into a versatile, cross-platform programming environment with its own native compiler, VM, and standard library.

The entire project is 100% open-source under the MIT license:

GitHub Repository: https://github.com/rahadbhuiya/Yolish
Supported Platforms: Linux, Windows, macOS, and Exploidus OS.

Download the binary, try out the REPL, write a script, and inspect the C compiler source!

Have you ever thought about designing a programming language? What is the one feature you wish your daily language had? Let's discuss in the comments below!

I built a programming language because C++ almost killed my drone

Fri, 17 Jul 2026 14:10:22 +0000

I'm 17. Last year I was writing drone firmware in C++ and Python. One afternoon my ultrasonic sensor returned null during a landing sequence. The code didn't check for it. The drone tried to divide by zero, the motor controller panicked, and my DJI Tello-sized quadcopter dropped from 3 meters onto concrete.

That was a $400 lesson in why runtime errors in robotics aren't just bugs. They're physics problems.

So I built a programming language.

The problem nobody talks about

When you're writing a web app and something crashes, you reload the page. When you're writing drone code and something crashes, the drone crashes. Into whatever's below it. Usually something expensive or fragile or alive.

C++ and Python dominate robotics. Both assume you'll handle edge cases yourself. Sensor returns null? That's your problem. Timing deadline missed? Good luck. No fallback path for when the lidar fails over water? Figure it out.

ROS (Robot Operating System) helps with some of this, but it's an entire infrastructure layer. What I wanted was something simpler: a language where the compiler catches the stuff that kills robots before you ever compile it.

Here's what I mean. In C++, you write:

float distance = sensor.read();
float speed = target_distance / distance;
motor.set(speed);

If distance is 0, you get a division by zero. If sensor.read() returns NaN, you get NaN propagation through your motor controller. The compiler doesn't care. It'll happily compile this and let your drone fall out of the sky.

In Fabric (the language I built), you'd write:

sensor distance: Sensor<f32, ±0.02>
actuator motor: Motor

loop {
    let speed = target_distance / distance
    motor.write(speed)
}

If you try to use distance without checking that the sensor returned a valid reading, the compiler throws an error. If distance could be zero and you didn't add a fallback path, the compiler throws an error. If your sensor has an uncertainty bound of ±0.02 and you're doing math that could amplify that uncertainty past a safety threshold, the compiler throws an error.

The compiler knows about physics. Not perfectly, but enough to catch the stuff that actually kills robots.

How it works under the hood

I wrote the whole thing in Rust. About 4,500 lines across 8 crates. Here's the pipeline:

.fab source → Lexer → Parser → AST → Type Checker → Fallback Graph → IPET Timing → CodeGen → .py / .c

Each step catches a different category of mistakes.

The type system tracks sensor uncertainty as a first-class concept. When you declare Sensor<f32, ±0.02>, that ±0.02 isn't decoration. It propagates through every math operation. Add two sensors with ±0.02 uncertainty and the result has ±0.04. Multiply by a constant and the uncertainty scales accordingly. If the final result's uncertainty exceeds what's safe for your actuator, the compiler catches it.

The fallback graph checks that every sensor has a plan B. Not just declared, but actually reachable. If your fallback function A calls fallback function B, and B calls A, that's a cycle. The compiler detects it. If sensor X has no fallback at all, the compiler refuses to build.

IPET timing analysis uses an Integer Linear Program to prove worst-case execution time at compile time. It builds a control flow graph, assigns cycle costs to each instruction (ARM Cortex-M4 model: ALU = 1 cycle, float division = 14 cycles, sensor read = 2 cycles), and solves for the maximum possible execution time across all code paths including loops.

I didn't come up with this technique. It's from Li & Malik's 1994 paper on implicit path enumeration. But I implemented it in Rust using a pure-Rust ILP solver called good_lp with the microlp backend. No external solver dependency. No C FFI. Just Rust solving linear programs.

The solver maximizes sum(cost_i * x_i) subject to flow conservation constraints. If the solver fails (which happens on really complex control flow), the system falls back to a conservative estimate instead of crashing.

The two-target code generation

Fabric compiles to two backends: Python for Webots simulation, and C for ARM Cortex-M hardware.

Python output generates a Webots controller class with sensor initialization, motor setup, fallback state tracking, and all the logic. You can test your drone code in simulation before touching hardware.

C output generates code that includes a hal.h hardware abstraction layer. Static sensor handles, #define TIMEOUT_MS for fallback deadlines, proper C types (float, int), and deadline enforcement using hal_get_time_ms().

Same source file, two completely different targets. No #ifdef in your code. No conditional compilation. The compiler handles the target-specific stuff.

What I'd do differently

The parser is hand-rolled. About 700 lines of Pratt parser with recursive descent for statements. I started with chumsky (a Rust parser combinator library) but their API changed between versions and the documentation was sparse when I needed it most. So I wrote my own.

It's fine. But it means every time I want to add a new syntax construct, I'm writing parser code by hand. A proper parser generator would've saved time in the long run, even with the initial investment.

The loop bound estimation is a heuristic. If your loop body has 1-3 statements, the compiler assumes it runs 10 times. 4-6 statements? 5 times. 7+? 3 times. This is obviously wrong for real programs. Proper static bound analysis would make the IPET results much more accurate. It's on my list.

The C output references a clamp() function that it never defines. If you actually try to compile the generated C code on hardware, you'll get a linker error. I know about it. I just haven't fixed it yet.

Why I'm publishing this

I put all 8 crates on crates.io. The lexer, parser, type checker, everything. The repo is at github.com/subhansh-dev/fabric.

Partly because I want other people to try it. If you're working on robotics or drones and you've been bitten by runtime errors, Fabric might save you some pain.

Mostly because I think the idea matters more than my implementation. The safety-critical systems world has had formal methods and static analysis for decades. But it's all locked behind expensive tools and enterprise licenses. I wanted to build something that a 17-year-old with a Raspberry Pi could use.

Is my implementation perfect? No. The IPET loop bounds are guesses. The C backend doesn't handle drone swarms. The match expression codegen references some variables it doesn't always generate. I know about all of these. They're bugs, not features, and I'll fix them.

But the core idea is sound: compile-time safety for robotics shouldn't require a $50,000 license for Simulink. Sometimes the right answer to "how do we prevent this bug" isn't "write better tests" or "add more runtime checks." Sometimes it's "make the compiler say no."

What's next

I'm working on adding hardware-in-the-loop testing support. The idea is that Fabric could instrument your actual hardware and compare runtime sensor readings against the compile-time uncertainty bounds. If reality diverges from what the compiler predicted, you get a warning before your next flight.

Also working on proper static loop bound analysis. The current heuristic is fine for demos but useless for real deployments. I'm looking at abstract interpretation techniques to actually prove bounds instead of guessing.

If any of this sounds interesting, check out the repo. Open an issue. Try it on your own robot. Break it and tell me how.

That's how this gets better.

Fabric is MIT licensed. The crates are published on crates.io. The docs are in the README because I'm 17 and haven't written proper docs yet.

gh repo link :- https://github.com/subhansh-dev/fabric

Gloria JIT v4.4.0 — Bare-Metal Control, Memory Primitives, and Structured Flow

Mon, 01 Jun 2026 22:29:15 +0000

What is Gloria JIT?

Gloria JIT is a low-level programming language and compiler that is part of the ForgeZero ecosystem. It is written in Go and compiles source code directly to x86-64 machine code — no LLVM, no GCC, no Clang in the middle.

The goal is straightforward: give the programmer direct, unmediated control over the machine. No intermediate representation handed off to a third-party backend. No optimizer making decisions you didn't ask for. The compiler emits raw bytes, and those bytes run.

This makes Gloria JIT an interesting project for anyone curious about how compilers actually work, or for developers who want to explore bare-metal programming without the abstraction layers that most toolchains introduce.

v4.4.0 expands the language significantly, adding structured control flow, direct memory and I/O access, and a bare-metal output path for VGA framebuffer writing.

`while` Loops — Structured Control Flow

Before this release, repeated execution required manual branching. v4.4.0 adds proper while loops.

A loop runs as long as its condition is non-zero. Inside the loop body you can use standard assignment and mutation operators (=, +=, -=), and built-in calls are permitted as well. This is a meaningful step toward the kind of control flow you'd expect from a general-purpose language.

Memory Primitives — `peek` and `poke`

Two new built-in functions expose direct memory access:

peek(address) — reads a 16-bit value from the given address
poke(address, value) — writes a 16-bit value to the given address

Both accept either immediate values or runtime variables as arguments.

This is the kind of primitive that exists in very few high-level languages, but is essential for bare-metal work — writing to hardware registers, inspecting memory-mapped I/O, or building your own allocator from scratch. Handle with care.

x86-64 Port I/O

For environments that use port-mapped I/O (common in older PC hardware and embedded x86 systems), two new built-ins are available:

in8(port) — reads a single byte from the given I/O port (zero-extended)
out8(port, value) — writes a byte to the given I/O port

This enables direct hardware interaction at a level that most programming languages simply do not expose.

VGA Framebuffer Output

print(string) now supports a bare-metal execution path that writes directly to the VGA text buffer at memory address 0xB8000.

For context: on x86 PCs, this address is where text-mode video memory lives. Writing bytes there places characters directly on screen — no operating system, no drivers, no system calls involved. This is how early PC software (and modern bootloaders) produce output.

Details of the implementation:

Default text color is green (0x0A)
Register R15 is reserved as a cursor offset and is preserved across calls
Escape sequences \n and \t are resolved at compile time into the appropriate control characters

To support testing without real hardware, two utilities are included: patchVGA() swaps the real framebuffer address for a heap-allocated buffer, and dumpVGA() renders that buffer to stdout via a direct syscall, with zero heap allocations.

Register Constants

To reduce ambiguity in the backend IR and make generated code easier to reason about, named constants have been introduced for all general-purpose x86-64 registers:

regRAX(0), regRCX(1), regRDX(2), regRBX(3),
regRSP(4), regRBP(5), regRSI(6), regRDI(7),
regR8(8) ... regR15(15)

Internal Changes

A few backend improvements shipped alongside the language features:

emitLowLevelPrint now accepts a kernelMode flag to switch between syscall-based output and direct VGA writes
emitPushReg and emitPopReg now cover the full register set including R8–R15
New operations: emitMovMemToReg64, emitMovRegToMem64
parseStringLiteral handles escape sequences at compile time rather than at runtime
emitBareMetalPrint introduced for the VGA output path

Where This Is Heading

With v4.4.0, Gloria JIT operates in two modes simultaneously: as a userspace compiler with kernel-aware syscall output, and as a bare-metal code generator capable of running without an operating system underneath it.

The next focus areas are optimization passes and IR stability. If you're interested in how compilers work from the ground up — or in low-level x86 programming without giving up a proper language — this is worth following.

Gloria JIT is part of the ForgeZero project. Follow along on [AlexVoste](https://github.com/forgezero-cli/forgezero