Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Files

  • p0.py - Parser
  • t0.py - Tokenizer
  • backend/ - Target-specific code generators
    • x86_64.py - x86_64 Linux
    • riscv.py - RISC-V 64 Linux
    • arm.py - AArch64 Linux
    • c.py - C backend
    • wasm.py - WebAssembly browser
    • common.py - Backend protocol definition
  • tests/ - Test programs
  • bootstrap/ - Self-hosted bootstrap compiler (in udewy itself)
    • main.udewy - CLI entry point
    • t0.udewy, t1.udewy, p0.udewy - Preprocessor, tokenizer, parser
    • runtime/ - Host I/O, subprocess, fs, diagnostics, paths, strbuf
    • backend/ - One file per backend (x86_64, riscv, arm, c, wasm)

Bootstrap Compiler

The bootstrap/ directory contains a self-hosted compiler written in udewy itself. It is feature-equivalent to the Python implementation and supports all five backends (x86_64, riscv, arm, c, wasm32). The x86_64 and C backends are fully self-hosting: the bootstrap can compile itself targeting either.

Backend-agnostic core

Most of the bootstrap is not tied to a single backend. The preprocessor (t0.udewy, t1.udewy), tokenizer, parser (p0.udewy), and the shared backend protocol (backend/common.udewy) are ordinary udewy code that emits through the abstract Backend interface. Each concrete backend file (backend/x86_64.udewy, backend/wasm.udewy, etc.) implements that interface for one target.

The only backend-specific coupling in day-to-day compiler logic is whatever the selected backend must provide at codegen time (syscalls vs browser host functions vs C extern lowering). The compiler algorithm is the same across targets.

Host I/O behind capabilities

Operating-system interactions (reading and writing files, spawning subprocesses, printing diagnostics, exiting) go through stdlib/stdlib.udewy, which imports a host I/O capability module for the active compile target:

  • stdlib/capabilities/host_io_x86_64.udewy
  • stdlib/capabilities/host_io_riscv.udewy
  • stdlib/capabilities/host_io_arm.udewy
  • stdlib/capabilities/host_io_wasm32.udewy
  • stdlib/capabilities/host_io_c.udewy

The bootstrap runtime/ helpers (fs.udewy, process.udewy, diag.udewy, paths.udewy) sit on top of that shared host_* API. Adding a new backend means implementing host I/O for that target, not rewriting the parser.

Why the bootstrap includes WASM

The wasm32 backend is part of the bootstrap so udewy programs including the compiler itself can be hosted and demonstrated directly in the browser.

  • main.udewy is the normal CLI entry point (native or hosted C).
  • web_compiler.udewy is a wasm32-only library entry point: a JavaScript host feeds source bytes in, the bootstrap runs t1 + p0 + the wasm backend, and WAT bytes come back out for assembly in the browser. The playground under udewy/tests/web/ is the UI that drives it.

Longer term, browser hosting might move up to full Dewy instead of living in the trusted-base rung; at that point we would ship Dewy-compiled compiler artifacts for the web rather than depending on udewy's wasm backend forever. For now, having wasm in the bootstrap is a practical way to demo the language and the self-hosted compiler on the web.

Usage

# Compile the bootstrap to a native binary (via the Python compiler)
python -m udewy --target x86_64 -c udewy/bootstrap/main.udewy
# Now use the bootstrap to compile programs
./__dewycache__/udewy/bootstrap/main --target wasm32 -c udewy/tests/test_hello.udewy
# Self-host: bootstrap compiles itself
./__dewycache__/udewy/bootstrap/main --target x86_64 -c udewy/bootstrap/main.udewy