MEP 42. Native Code Emission: copy-and-patch JIT, C-as-target AOT, and a Wasm-first cross-platform story

Field	Value
MEP	42
Title	Native Code Emission
Author	Mochi core
Status	Draft
Type	Standards Track
Created	2026-05-18
Depends	MEP-23 (Compile-time budget), MEP-40 (vm3 + compiler3), MEP-41 (Memory Safety)

Abstract

Mochi today ships exactly one execution model: the vm3 bytecode interpreter with vm2jit-derived golang-asm JIT for hot methods on x86_64 and aarch64. There is no AOT path; mochi build produces a Go binary that embeds the interpreter, not native code emitted from compiler3 IR. There is no Wasm output. There is no Windows native target. There is no story for mochi run script.mochi to compete with python script.py on startup time, and no story for mochi build --portable to compete with go build on distributable artifact size.

This MEP specifies the from-scratch native code emission layer for Mochi. The architecture is dual-backend by design: copy-and-patch JIT for the interpreter tier (sub-millisecond compile, 3-5x faster than vm3 interpreter, inherits Clang -O2 stencil quality), and C-as-target AOT for shipped binaries (covers every target the user's cc supports, including embedded Cortex-M and microcontrollers). The two backends share compiler3's typed IR; neither requires LLVM or cgo at Mochi build time. The naive-emission research substrate (/notes/Spec/5500/) validates this pair: copy-and-patch is the technique CPython 3.13 shipped in October 2024 (PEP 744); C-as-target is the technique that lets Nim, V, Vala, and Cython cover every embedded toolchain on Earth.

Phase 1 targets five host combinations: x86_64 Linux (ELF/SysV), aarch64 Linux (ELF/AAPCS64), aarch64 macOS (Mach-O/Apple ABI), x86_64 macOS (Mach-O), and wasm32 with WasmGC. These cover every CI runner, every modern cloud ARM instance, every Apple Silicon developer, every browser, and every standalone Wasm runtime (Wasmtime, WAMR, Wasmer, WasmEdge, Spin). Phase 2 adds Windows x86_64/aarch64 (PE/COFF with .pdata/.xdata), riscv64 Linux (RVA22/RVA23), an APE bundler for single-artifact polyglot distribution, plus a native Wasm AOT emitter and a QBE backend for users who want sub-MB stripped binaries without a libc dependency.

The performance bet, deduced from the research substrate: copy-and-patch JIT lands Mochi in the same 3-5x-of-Go band that the §6.16 close-out of MEP-39 left as out of reach for vm3 alone. C-as-target AOT lands mochi build artifacts in the 1-10 MB band (Crystal-like) with binary size and code quality bounded by the user's C compiler, not by Mochi. The Wasm path gives Mochi a distribution channel no other Go-hosted language has: browser, edge, and Wasmtime AOT all from a single emit pipeline.

The closest existing architectural analog is Crystal (closed-world, typed IR, managed runtime, same target tier). The case study to learn most from is .NET NativeAOT (mature managed-language AOT pipeline, trim model, source-generator alternative to runtime reflection, single-file deployment UX). Both are documented in ~/notes/Spec/5500/aot/.

This MEP is a Standards Track design document. The phased plan (Phase 0 spec freeze through Phase 8 Wasm AOT) ships incrementally; no phase ships until its gate is green. The MEP and the code ship in the same PR (MEP-spec-in-sync rule). No phase introduces cgo on the Mochi build host.

Top-line objective

mochi build hello.mochi produces a single native executable that runs on a clean machine of the target platform, with no Mochi runtime preinstalled and no external Mochi dependencies on the host. This is the user-visible promise this MEP exists to deliver. Every phase gate in §Phased-plan that touches the AOT track (Phases 4-7, plus the cross-platform expansion in 8-9) is judged against this objective, not against spec-internal scaffolding. Concretely, a phase is "LANDED" only when it produces a binary that:

1. is a single file on disk (one ELF, one Mach-O, one PE, one .wasm, or one APE blob);
2. runs on the named target platform's stock OS install without mochi, clang, cc, or any Mochi-runtime shared object present on the machine;
3. produces the same stdout the Mochi source produces under mochi run (byte-for-byte parity gate);
4. is reproducible from the same source on any phase-1 host (Reproducible Builds Project compatibility, MEP-37 lineage).

The JIT track (Phases 1-3) shares compiler3 IR with the AOT track but does not satisfy this objective; it accelerates mochi run. Both tracks must be at parity per §13's BG kernel suite before any phase claims an umbrella row in §9 or §10 is green. Single-binary expectations are the gate, not the risk: §11.4 below was a Risk in earlier drafts; §Phased-plan now states it as a phase gate, and Risk §11.4 is retained for the failure modes (missing cc, unusable cc) that the gate still has to detect and report.

Motivation

What MEP-40 left on the table

MEP-40 (vm3 + compiler3) produced a typed IR that propagates Mochi's static type system end-to-end. Every SSA value carries a proven type at IR-emit time; every opcode encodes the type in the opcode itself; the three-bank register file (regsI64 / regsF64 / regsCell) reads and writes native machine words without Cell envelope traffic. This is exactly the precondition a code generator needs: no runtime type guards, no fallback paths, no escape valve. The §6.16 close-out of MEP-39 listed four structural ceilings that vm2 could not lift; vm3 lifted all four. What remains is to spend that headroom by emitting native code instead of dispatching bytecode.

The vm3jit method JIT (MEP-40 Phase 5) covers the inner-loop case but inherits vm2jit's golang-asm encoding: no register allocator, no cross-op optimization, no AOT path. The shipping Mochi binary still embeds the vm3 interpreter, and mochi build my_program.mochi still produces a Go binary that runs the interpreter on my_program.mochi. That is a distribution model, not a code-generation model.

What changed in 2024-2026

Four things between PLDI 2021 and May 2026 make this MEP unavoidable.

Copy-and-patch shipped in CPython 3.13 (October 2024). PEP 744 enabled the copy-and-patch JIT (Xu+Kjolstad, PLDI 2021) behind --enable-experimental-jit in Python 3.13.0. The technique is now production-validated at the scale of CPython: ~1000 lines of Python build-time tooling plus ~100 lines of C runtime per ISA, hand-written C stencils compiled by Clang -O2 at build time, memcpy + patch at runtime. The risk profile is well understood, the macOS arm64 JIT entitlement story is documented, and Brandt Bucher's writeups are now reference material. CPython measured a 9-15% throughput improvement on pyperformance for a first-cut JIT with no register allocation. Mochi, with typed IR and reserved arena-base registers, expects 3-5x on hot loops.

Wasm GC + WASIp2 shipped in 2024. WasmGC reached browser baseline in 2024 (Chrome 119, Firefox 120, Safari 18.4); WASI Preview 2 (component model + WIT bindings) reached stable in Wasmtime 17 (October 2024). Wasm is now a credible AOT target for a managed-runtime language, not a JavaScript fallback. The Mochi handle Cell maps directly to a wasmtime externref or to a typed GC reference under WasmGC; the typed arenas map directly to typed GC structs. The September 2025 Wasm 3.0 release added 64-bit memories and atomic operations, closing the last two gaps for a Mochi Wasm port.

Apple Silicon adoption crossed 50% of developer machines (DeveloperEcosystem 2025 survey). Mochi without an aarch64 macOS native binary is no longer credible for individual developer adoption. The Mach-O writer, the Apple variadic ABI delta, the ad-hoc signing requirement, and the JIT entitlement plist are mandatory work for any "professional language" claim in 2026.

Zig 0.13 + zig cc graduated to "default cross-compiler" status in many teams. Zig's bundled libcs (musl, glibc, mingw) and zero-config cross compilation set the new floor for what users expect from a language's cross-compilation UX. Nim already pairs with zig cc; Crystal users wrap --cross-compile around zig cc; Rust users layer cargo-zigbuild on top of cargo build. Mochi mochi build --target=aarch64-linux should "just work" from a macOS dev machine, and zig cc is the cheapest way to deliver that.

Why two phase-1 backends, not one

The naive-emission survey (~/notes/Spec/5500/naive/00_naive_summary.md) and the backends survey (~/notes/Spec/5500/backends/00_backends_summary.md) agree on the same conclusion through different lenses: no single backend covers the four MEP-42 priority surfaces (fast JIT, distributable AOT, Wasm, embedded) with acceptable engineering cost and Mochi's pure-Go-no-cgo identity preserved. The two-backend strategy is the pragmatic compromise GHC adopted (NCG + LLVM) and Zig adopted (in-house + LLVM + C). Mochi adopts the same shape with smaller pieces: copy-and-patch + C-as-target in phase 1, Wasm emitter + QBE in phase 2.

The pair is complementary, not redundant. Copy-and-patch is millisecond-compile and runtime-tier; C-as-target is cc-bound compile time and ship-tier. Copy-and-patch produces machine code in an mmap'd executable region; C-as-target produces an ELF/Mach-O/PE on disk. Copy-and-patch covers two ISAs out of the gate; C-as-target covers every ISA the user's cc understands. Neither covers the other's surface, and shipping both costs less than shipping either alone with the gaps patched by ad-hoc tools.

Scope

In scope:

• Complete design and implementation of compiler3/emit/copypatch/ (copy-and-patch JIT: stencil generator, runtime patcher, mmap+W^X manager).
• Complete design and implementation of compiler3/emit/c/ (C-as-target AOT: typed-IR-to-C lowering, runtime header, cc driver).
• Initial implementation of compiler3/emit/wasm/ (Wasm 3.0 + WasmGC emitter, browser + standalone targets).
• Stencil generation tooling (tools/stencilgen/) that invokes Clang at build time and emits a generated Go file per ISA.
• Linker driver (compiler3/link/) that invokes LLD by default with system linker fallback.
• Object file readers/writers (compiler3/objfile/elf/, compiler3/objfile/macho/, compiler3/objfile/pe/) using Go's debug/elf, debug/macho, and a hand-rolled PE writer.
• Cross-compilation support for the five phase-1 targets from any host, optionally via zig cc.
• DWARF 5 line-table emission for native targets (phase 1); full DWARF + optional PDB in phase 2.
• A mochi build UX that produces a single distributable binary, with --target, --portable (musl static-PIE), and --mode={dev,release,embedded} flags.
• A mochi run path that selects copy-and-patch JIT for hot loops when available, falling back to vm3 interpreter when not.
• Bench harness integration: every BG kernel runs under all three execution modes (interpreter, JIT, AOT) on every supported host, with cross-mode parity gates.

Out of scope (deferred to successor MEPs):

• LLVM as a primary backend. Available as a phase-3 opt-in (compiler3/emit/llvmir/ emits .ll text, shells to llc); not required for any phase-1 or phase-2 deliverable.
• MLIR. Reserved for an SIMT / GPU successor MEP.
• libgccjit. Rejected outright: GPL contagion risk.
• iOS / iPadOS / visionOS targets. Provisioning, App Store review, and MH_BUNDLE machinery deserve a dedicated mobile MEP.
• GPU codegen (Metal AIR, CUDA PTX, ROCm, SPIR-V, WGSL). Separate MEP.
• Tracing JIT. vm3jit is a method JIT; tracing is MEP-50+ territory.
• IL2CPU / Bartok-style two-stage AOT through an intermediate C++ pass.
• Profile-guided optimization. Phase 3+ once base AOT and JIT are stable.

Specification

§1 Architecture

The native code emission layer sits between compiler3 (typed IR producer) and the host toolchain (system cc, system linker, host kernel loader). Three emit packages share the typed IR:

                  compiler3/ir  (MEP-40)
                       |
       +---------------+----------------+
       |               |                |
       v               v                v
 emit/copypatch    emit/c            emit/wasm  (phase 2 AOT)
   (JIT, phase 1) (AOT, phase 1)     emit/qbe   (AOT, phase 2)
       |               |                |
       v               v                v
   mmap exec      ELF/Mach-O/PE    .wasm module
   memcpy+patch   via system cc    via builtin emit

The boundary is the typed IR. Every emit package consumes the same IR shape, the same SSA value types, the same three-bank register convention, the same Cell ABI. No emit package may add IR ops or modify the type lattice; either the IR already expresses what the backend needs, or the IR change is a separate PR that lands first.

The four-bit arena tag and 12-bit generation encoding of MEP-40 plus the verifier rules of MEP-41 are load-bearing for every backend. Stencils may not mask, shift, or otherwise destructure the generation field; the backend treats it as opaque per MEP-41's Tag Confidentiality Enforcement analog. The C-as-target lowering wraps every handle deref in mochi_deref_T(handle) calls so the C compiler cannot inline gen-extraction; the copy-and-patch stencils never name a register holding a raw gen value.

§2 Copy-and-patch JIT (phase 1)

Hand-write one C function per vm3 opcode in runtime/vm3/op.go. Each stencil takes the vm3 frame, the operand registers, and returns the dispatch target for the next op. Compile each stencil with Clang -O2 -fno-asynchronous-unwind-tables -fno-stack-protector -mno-red-zone at Mochi build time. Extract the resulting machine code and relocations from the .text section; emit them as a generated Go file (compiler3/emit/copypatch/stencils_amd64.go, ..._arm64.go) containing a per-opcode struct: {bytes []byte, holes []Reloc}.

At Mochi runtime, the JIT walks the typed IR for a hot method, picks the stencil for each op, memcpy's the bytes into an mmap'd executable region, and patches the relocations (immediates, jump targets, runtime symbols) in place. The patched code is then jumped to via a Go-friendly entry trampoline that preserves Go's stack invariants. Code-cache management uses a simple bump allocator with a high-water mark; when the cache fills, the JIT falls back to vm3 interpretation for cold ops and recycles the cache on the next GC cycle.

Register convention (x86_64 SysV; mirrored on arm64 AAPCS64 with x19-x28):

• R12: pointer to current Frame.
• R13: pointer to typed-arena base table.
• R14: pointer to per-VM context (PC stash, deopt sentinel slot).
• R15: scratch.
• RAX/RDI/RSI/RDX/RCX/R8/R9: Cell operand registers (caller-save, follow stencil ABI).

Reserved callee-saves match the MEP-40 three-bank register-file design. The JIT never spills R12-R14 because stencils assume them on entry; the only spill path is when a stencil's internal codegen needs more than R15 of scratch, in which case the stencil uses the red-zone (Linux) or a Mochi-private scratch slab on the frame (macOS arm64, which has no red zone).

W^X is enforced via the dual-mapping pattern: the code cache is mmap'd twice, once RW (for the patcher) and once RX (for the runtime jump), with the kernel guaranteeing the same physical pages. On Apple Silicon, pthread_jit_write_protect_np(0) toggles the per-thread write-permission bit during patching; the JIT thread holds the toggle for the patch window only. On Linux with PaX or grsec, the dual-mapping is required; on stock Linux, mprotect toggling is the fallback path.

PAC and BTI hardening on aarch64: every stencil entry carries a bti j instruction; every cross-stencil call uses blraa with the appropriate PAC modifier. The PAC key is per-Mochi-process, derived at startup from /dev/urandom and stored in a register only the patcher knows. This is the MEP-41 §8 JIT hardening checklist; copy-and-patch satisfies it without any per-stencil logic because Clang -O2 already emits PAC+BTI when targeted at arm64-apple-darwin.

Stencil set scope (phase 1):

• All non-allocating vm3 opcodes: arithmetic (i64/f64), comparison, conditional jumps, register move, frame load/store, typed-array element load/store.
• Inline allocation for short-lived Cells (small int, short string, bool).
• Slow-path call into the vm3 runtime for: handle dereference miss, arena exhaustion, deopt sentinel, MEP-41 verifier rule check failure.
• Branch fusion: chained conditional jumps in a single basic block fold into one stencil where possible (Liftoff-style is phase 2; phase 1 keeps every op as a separate stencil).

Not in phase-1 scope (phase 2): cross-op register allocation, inline caching for first-class function dispatch, SIMD intrinsics, generational write-barrier elision via static analysis.

§3 C-as-target AOT (phase 1)

Lower compiler3 IR to C in compiler3/emit/c/. Strategy follows Nim's: one C function per Mochi function, one C struct per Mochi type, every basic block becomes a labeled statement, control flow via goto. Computed goto (GCC extension) is used for the interpreter tier within AOT'd code (for indirect dispatch on dynamic-typed values that escape the static-type discipline); standard switch is the portable fallback for MSVC.

The Mochi C runtime header (runtime/c/mochi.h) declares:

• mochi_Cell (uint64_t) and the inline NaN-boxing accessors.
• mochi_arena_t and the typed-arena APIs from MEP-40.
• mochi_handle_T(arena, gen, idx) constructors and mochi_deref_T(handle) accessors.
• The verifier-checked operations from MEP-41 (mochi_try_deref_T, mochi_kill, etc.).
• The slow-path callbacks the JIT and AOT'd code share.

The runtime header is C99-portable and depends only on <stdint.h>, <stdlib.h>, <string.h>. On glibc and musl it adds <unistd.h> for mmap (for the JIT path; AOT code does not mmap). On Windows it uses <windows.h> for VirtualAlloc. Every implementation file (runtime/c/mochi.c) is built into a static library libmochi.a (or mochi.lib on Windows) that the linker driver bundles into the final executable.

The mochi build driver:

1. Parses + type-checks + lowers the program to compiler3 IR.
2. Calls compiler3/emit/c/ to produce a temporary .c file (or files, if multi-module).
3. Shells out to the user's C compiler: prefers zig cc if available (zero-config cross compilation), falls back to cc, falls back to clang, falls back to gcc.
4. Compiles the .c files plus libmochi.a to a single executable using the chosen linker (LLD by default, system ld fallback).
5. Strips debug info on release mode; preserves DWARF on dev mode; emits embedded-mode subset on embedded mode.

The C compiler choice is documented but not enforced. mochi build --cc=zig selects zig cc explicitly; mochi build --cc=tcc selects TCC (useful for sub-second build times on small programs); mochi build --cc=clang -- -fsanitize=address passes through C compiler flags. The default is mochi build with no --cc flag, which picks zig cc if installed, else cc.

Cross compilation via zig cc:

mochi build --target=aarch64-linux-musl  hello.mochi
mochi build --target=x86_64-windows-gnu  hello.mochi
mochi build --target=wasm32-wasi         hello.mochi

Each --target lookup maps to a zig cc -target triple. The triple list ships in compiler3/emit/c/triples.go; users can extend it via a mochi.toml config.

§4 Wasm emit (phase 1 minimal, phase 2 AOT)

Phase 1 ships a minimal Wasm 3.0 + WasmGC emitter in compiler3/emit/wasm/ that handles the BG kernel subset (arithmetic, control flow, typed arrays, simple structs). The output module imports a small Mochi-Wasm host shim (runtime/wasm/host.js for browser, runtime/wasm/host.wat for Wasmtime/standalone) that provides the slow-path callbacks the JIT and AOT both need.

Handle Cell mapping: 64-bit Mochi Cell becomes a Wasm i64 for the inline-encoded variants (small int, float, bool, null) and a (ref $mochi_handle) GC reference for handle variants. Typed arenas become WasmGC (struct ...) types per arena, instantiated lazily. The four-bit arena tag is the WasmGC type index; the 12-bit generation is a struct field; the 32-bit slab index is the struct array index.

Phase 2 promotes the Wasm emitter to full AOT through Wasmtime's wasmtime compile (~/notes/Spec/5500/backends/12_wasmtime_aot.md): Mochi emits .wasm, wasmtime compile lowers to native .cwasm, the Mochi loader maps the .cwasm directly. This gives Mochi a universal IR (Wasm) and reaches every Cranelift-supported target transitively.

Browser DWARF: Wasm modules carry DWARF in custom sections (./custom("name").data) per the Chrome C/C++ DevTools Support extension. Phase 1 emits line tables only; phase 2 adds full type and variable info.

§5 Linker strategy

Phase 1: LLD by default, system linker fallback.

• Linux: ld.lld (default), ld.bfd or ld.gold (fallback).
• macOS: system ld (which is ld_prime since Xcode 15, default), ld.lld (fallback for cross builds).
• Windows: lld-link (default), system link.exe (fallback if MSVC is installed).
• Wasm: wasm-ld (LLVM).

Bundle LLD inside the Mochi distribution under Apache 2 + LLVM Exception license. The bundled LLD is a single ~25 MB binary covering all four formats (ELF, Mach-O, PE, Wasm). The total Mochi binary size impact is acceptable for desktop installs; mochi build --no-bundle-lld is the opt-out for users on restricted disks.

Phase 2: self-hosted writers for ELF, Mach-O, and PE in compiler3/objfile/. Pattern follows Go's cmd/link: the compiler emits the final image directly without an external linker subprocess on the common path. LLD remains the fallback for the "I need to link against a C library that ships as .a" case. This halves cold-start build time (no fork+exec of the linker) and lets Mochi tune the output for compiler3-specific metadata sections (typed-arena debug info, MEP-40 vm3 metadata, MEP-41 verifier-proof manifests).

§6 Runtime / libc strategy

Phase 1:

• Linux: glibc dynamic-linked default. Document the glibc-2.31 minimum (May 2020, covers Ubuntu 20.04+, RHEL 9+, Debian 11+). mochi build --portable switches to musl 1.2.6 static-PIE for "drop the binary on any Linux from 2015+" mode.
• macOS: libSystem dynamic-linked (only supported option per Apple; no static libc on macOS).
• Windows: ntdll + ucrtbase dynamic-linked. Document the Windows 10 1809+ minimum.
• Wasm: WASI Preview 2 imports (component-model interfaces) for standalone; browser DOM imports for browser builds.

Phase 2:

• Push musl static-PIE to be the new-project default on Linux; glibc remains supported.
• Add Cosmopolitan APE target (mochi build --target=ape). One binary, runs on Linux, macOS, Windows, BSDs (~/notes/Spec/5500/runtime/03_cosmopolitan_libc.md).
• Optional --no-libc freestanding mode for embedded / unikernel users (~/notes/Spec/5500/runtime/05_no_libc_freestanding.md). Direct syscalls on Linux; vendor-specific entrypoints elsewhere.

§7 Debug info strategy

Phase 1:

• Linux, macOS, Wasm: DWARF 5 line tables only (~/notes/Spec/5500/debug/01_dwarf_5.md). Sufficient for gdb / lldb stack traces and source-line attribution in profilers (perf, Instruments, Chrome DevTools).
• Windows: skip PDB for phase 1; tell users gdb and lldb work, WinDbg does not.

Phase 2:

• Full DWARF 5 with type info and variable info on all native targets.
• Optional CodeView / PDB on Windows (~/notes/Spec/5500/debug/02_codeview_pdb.md) for WinDbg + Visual Studio.
• Source maps in Wasm custom sections (~/notes/Spec/5500/debug/03_source_maps_wasm.md) for Chrome DevTools.
• compiler3-aware DWARF extensions: arena tag, generation, and bank index appear as DW_TAG_variable attributes on Mochi-typed values.

§8 Object format strategy

Phase 1:

• ELF: emit via Go's debug/elf writer with a thin Mochi wrapper that handles the few cmd/link-style cases the Go writer omits.
• Mach-O: emit via Go's debug/macho plus a wrapper for the load-command extras (LC_DYLD_INFO, LC_CODE_SIGNATURE).
• PE/COFF: hand-rolled writer in compiler3/objfile/pe/ (Go's debug/pe is read-only). Mandatory .pdata + .xdata for x86_64 Windows, ARM64 unwind bytecode for aarch64 Windows.
• Wasm: hand-rolled writer in compiler3/emit/wasm/ (no debug/wasm in stdlib).

The format reference files (~/notes/Spec/5500/formats/01_elf.md through 05_ape_cosmopolitan.md) catalog every section, header, and load command Mochi emits.

§9 Phase 1 target matrix

Five host combinations are "must-have" for phase 1 (~/notes/Spec/5500/targets/00_targets_summary.md):

Target ISA	OS	Format	ABI	Status	Complexity	AOT (Phase 5) build+run
x86_64	Linux	ELF	SysV	must-have	2	LANDED (Linux CI: native; Darwin: build-only)
aarch64	Linux	ELF	AAPCS64	must-have	2	LANDED (Linux CI: qemu-aarch64-static; Darwin: build-only)
aarch64	macOS (Apple Silicon)	Mach-O	Apple ABI	must-have	3	LANDED (Darwin: native; Linux CI: build-only)
x86_64	macOS	Mach-O	SysV	must-have	3 (freebie with Universal 2)	LANDED (Darwin: Rosetta 2; Linux CI: build-only)
wasm32	browser + WASI	.wasm	Wasm 3.0 + GC	must-have	2	LANDED (wasmtime on both hosts)

Estimated phase-1 effort: ~3-4 engineer-months for first working backends across all five targets, assuming Mochi reuses Go's debug/elf + debug/macho and writes a Wasm emitter from scratch.

The AOT column reads under the union framing established in §10.62: every triple has at least one (host, runner) tuple where both build and run gates fire. The other columns (copy-and-patch JIT in Phase 1, debug info in Phase 7) remain at their separate-row statuses and will fill in as those phases close out.

§10 Phase 2 target matrix

Four additional combinations promoted from "should-have" or "could-have":

Target ISA	OS	Format	ABI	Status	Complexity
x86_64	Windows	PE/COFF	MS ABI	should-have	4
aarch64	Windows	PE/COFF	MS ARM64 ABI	could-have	4
riscv64	Linux	ELF	LP64D (RVA22/RVA23)	could-have	3
polyglot	all six	APE	n/a (post-link)	could-have	3 (cosmocc dep)

Estimated phase-2 effort: ~3 engineer-months for Windows targets (.pdata / .xdata / IAT machinery), 1 engineer-month for riscv64, 2 weeks for the APE bundler.

§11 Out-of-scope targets

Per ~/notes/Spec/5500/targets/00_targets_summary.md §5:

• iOS / iPadOS / visionOS / tvOS / watchOS: dedicated mobile MEP.
• ppc64le, s390x, loongarch64: real but small user bases. Add on demand.
• MIPS: sunset.
• GPU compute (Metal AIR, CUDA PTX, ROCm, SPIR-V, WGSL): separate SIMT MEP.
• ARM64EC: deferred until Mochi has a story for x64 plugin interop on Windows.
• macOS x86_64 once Apple removes Rosetta: handle when it happens (likely 2027+).

Phased plan

Each phase ships as one PR or a small named set of PRs, gated by the criterion in the right column. No phase ships until its gate is green. The MEP file is updated with measured results at each phase boundary (MEP-37 / MEP-38 / MEP-39 / MEP-40 discipline).

Phase	Deliverable	Gate
0	Spec freeze, taxonomy lock, sidebar entry	LANDED 2026-05-18 (this MEP merged to main, sidebar updated, meps.json entry present)
1	compiler3/emit/copypatch/ skeleton + stencilgen tool, complete §9 target matrix	PARTIAL. 1.0 x86_64 Linux LANDED 2026-05-21 17:52 (GMT+7); 1.1 aarch64 Linux LANDED 2026-05-21 18:36 (GMT+7); 1.2 x86_64 macOS, 1.3 aarch64 macOS, 1.4 wasm32, and 1.5 spec target-matrix reconciliation pending. Umbrella row flips to LANDED once all five §9 must-have targets are green. Real Clang stencil extraction (1.6), full non-allocating op coverage (1.7), inline-allocation stencils (1.8), slow-path stubs (1.9), and the BG cross-tier parity gate (1.10) deferred to later sub-phases
2	Copy-and-patch JIT covers all non-allocating vm3 ops on x86_64 Linux + aarch64 Linux	LANDED 2026-05-21 18:08 (GMT+7). Phase 2.0 x86_64 lands: i64 arithmetic (Add/Sub/Mul/Neg plus Add/Sub/Mul imm variants), six i64 comparisons (Eq/Ne/Lt/Le/Gt/Ge plus imm variants), and multi-block emit with TermJump (E9 cd) + TermBranch (test rax,rax + jne cd + jmp cd) terminators. Phase 2.1 aarch64 stencils, 2.2 f64 arithmetic, 2.3 cross-op register allocator + phi support, 2.4 BG kernel performance gate (within 5x of Go), and 2.5 OpDivI64 / OpModI64 with overflow slow-path deferred to sub-phases
3	Apple Silicon support: mach-o, JIT entitlement, ad-hoc signing	mochi run --jit=copypatch on aarch64 macOS within 5x of Go on BG kernels
4	compiler3/emit/c/ skeleton + linker driver, x86_64 Linux only	mochi build hello.mochi on x86_64 Linux produces a single native ELF that runs on a clean Linux machine (no Mochi/clang/cc preinstalled) and prints the same stdout as mochi run byte-for-byte
5	C-as-target AOT covers all four phase-1 native targets via system cc + LLD	LANDED 2026-05-22 16:55 (GMT+7). Phase 5.0 (build-gate on all five §9 triples via zig cc -target=<triple>), Phase 5.2 (BG fixture cross-build for all five triples on Darwin + macOS/wasm run-gates), and Phase 5.2.1 (.github/workflows/cross-aot.yml adds Linux + wasm run-gates on ubuntu-latest with qemu-user-static). All five §9 must-have rows are green for both build (file-format magic) and run (stdout byte-match) under the union of Darwin recording host + Linux CI host. See §10.62.
6	Wasm 3.0 + WasmGC emitter, BG kernel subset	mochi build --target=wasm32-wasi hello.mochi produces a single .wasm that runs under Wasmtime on a clean machine (no Mochi runtime present) and matches mochi run stdout
7	DWARF 5 line tables on all four native targets, gdb/lldb backtrace test	gdb shows correct Mochi source line on segfault; debug info is embedded in the single-file binary, not a sidecar
8	Phase 2: Windows x86_64 + aarch64, riscv64 Linux, APE bundler	mochi build --target=<each> from any cross-host produces a single binary that runs on a clean machine of the target; APE binary is one file that runs on Linux+macOS+Windows
9	Phase 2: Wasm AOT via wasmtime compile, QBE backend for small static binaries	mochi build --emit=wasm-aot produces a single .cwasm; mochi build --emit=qbe produces a single sub-1MB statically-linked ELF (no libc dependency)

The phase numbers do not match a calendar; they match a dependency order. Phase 1-3 are the JIT track (mochi run speed); Phase 4-7 are the AOT track (mochi build single-binary objective); Phase 8-9 are the cross-platform expansion. The two tracks can and should run in parallel after Phase 1.0 lands: the JIT track advances mochi run performance, the AOT track advances the user-facing top-line objective. Treating the two tracks as strictly sequential (clear all 1.x before starting 4.0) misorders work against the top-line objective; the goal-alignment audit before each sub-phase (§13) catches this.

§10.1 Phase 1 closeout (LANDED 2026-05-21 17:52 GMT+7)

Phase 1 landed the load-bearing skeleton of compiler3/emit/copypatch: the package compiles cleanly on every host (the amd64 stencil table is build-tagged so non-amd64 hosts get an empty table and the runtime falls back to vm3 interpretation), and the patcher + emitter + cache machinery is fully covered by tests that exercise the load-bearing shapes (immediate-32, immediate-64, pc-relative-32, absolute-64). The Phase 1 deliverables:

compiler3/emit/copypatch/ package

File	Purpose	Phase 1 status
doc.go	Package overview, reading order, scope, deferred sub-phases	LANDED
stencil.go	RelocKind, RelocSite, SymbolID, Stencil, SymbolTable types; validate(); relocWidth()	LANDED
stencils_amd64.go	Hand-written placeholder stencil table for x86_64 covering OpConst, OpAddI64, ret	LANDED (Phase 1.1 replaces with Clang-extracted set)
stencils_other.go	Empty table for non-amd64 GOARCH	LANDED
patch.go	applyRelocs() + per-kind writeReloc(); pc-rel32 displacement check; imm32 fit check	LANDED
emit.go	Emitter walking single-block Functions; Compile(); ErrUnsupportedArch / ErrNoStencil	LANDED
cache.go	Cache with bump allocation, Install(), Reset(), Capacity(), HighWater()	LANDED
mmap_linux_amd64.go	NewLinuxAMD64Mapping() via memfd_create + dual mmap; ReleaseLinuxAMD64Mapping()	LANDED
mmap_other.go	Stub returning unsupported on non-linux/amd64	LANDED

The SymbolID set is closed at compile time:SymInvalid, SymArenaBase, SymFrame, SymVMCtx, SymSlowPathDeref, SymSlowPathDeopt, SymOpRetTarget. Phase 1.1 adds SymImmI64 once stencilgen drives symbol selection from real Clang relocations; until then the OpConst placeholder reuses SymOpRetTarget with Addend carrying the literal.

The RelocKind set is also closed: RelocImm32, RelocImm64, RelocPCRel32, RelocAbs64. The pc-rel32 path computes target - (siteAddr + 4) and refuses to silently truncate when the displacement exceeds the ±2 GiB signed window; the imm32 path refuses to truncate when the value fits neither the unsigned-32 nor sign-extended-int32 envelopes. Both guards are tested.

The W^X dual-mapping uses memfd_create("mochi-jit", MFD_CLOEXEC) (syscall 319 on x86_64) plus ftruncate plus two mmap calls with shared semantics. Neither mapping is ever simultaneously writable and executable, so the runtime does not pay a per-Install mprotect toggle. Tested on linux/amd64 with the dual-view invariant: a write through rw[i] is observable through rx[i].

tools/stencilgen/ package

File	Purpose	Phase 1 status
doc.go	Build-time strategy, Clang flag set, ELF reloc-kind mapping, output shape	LANDED (skeleton)
main.go	-version flag wired; full pipeline pre-registered as Phase 1.1	LANDED (skeleton)
CLANG_VERSION	Pin file (18.1.8)	LANDED
stencils/op_add_i64.c	Authoring-template stencil source for OpAddI64	LANDED

The Clang flag set is canonicalized in doc.go: -O2 -fno-asynchronous-unwind-tables -fno-stack-protector -mno-red-zone -fpic -fno-pie -c. The ELF reloc-kind map is documented but not yet read by main.go; Phase 1.1 wires the debug/elf reader and the template-based emitter.

Test coverage (30 cases)

Patcher (patch_test.go): imm32, imm64, imm64-with-addend, pc-rel32 forward / backward / zero displacement, pc-rel32 out-of-range guard, abs64, unbound-symbol guard, nil-table guard, out-of-bounds guard, imm32 truncation guard.

Stencil validator (stencil_test.go): RelocKind / SymbolID String() coverage, relocWidth coverage, validate() on empty Bytes / RelocInvalid / SymInvalid / out-of-range offset / overlapping relocs, archStencils() validity sweep, SymbolTable Get / Set / out-of-range panic.

Emitter (emit_test.go): Supported() / NewEmitter() agreement, Const+Return happy path, Const+Add+Return multi-op path, ErrNoStencil on unsupported op, nil-Function guard, multi-block reject, missing-terminator reject.

Cache (cache_test.go): NewCache size-mismatch and nil-rw guards, single Install happy path, two-Install sequence with non-overlapping entry addresses, cache-full ErrCacheFull, Reset, nil-receiver safety, nil-SymbolTable guard.

Dual-mapping (mmap_linux_amd64_test.go, linux/amd64-only build tag): dual-view write-visible-through-rx invariant, zero-size reject, misalignment reject, cache-wired end-to-end Install.

Tools (tools/stencilgen/main_test.go): CLANG_VERSION file present, at least one .c stencil source present.

Deferred sub-phases (each shippable as its own PR)

Sub-phase	Scope
1.1	Real Clang stencil extraction via stencilgen: ELF parse, .text + .rela.text walk, RelocKind mapping, template-based output to stencils_amd64_generated.go
1.2	Full stencil set covering all non-allocating vm3 ops (i64 arithmetic, comparison, conditional jump, register move, frame load/store, typed-array element load/store)
1.3	Inline allocation stencils for short-lived Cells (small int, short string, bool)
1.4	Slow-path call stubs for handle-deref miss, arena exhaustion, deopt sentinel; cross-stencil branch fusion
1.5	aarch64 stencil set + Apple Silicon JIT entitlement plist and ad-hoc signing wiring
1.6	BG kernel cross-tier parity gate: hello-world / sum_loop / fib_iter byte-for-byte equal output under interpreter and copypatch JIT

Each sub-phase carries its own gate; none ships until its gate is green. The phase numbering convention matches MEP-41 (Phases 3.1-3.2, 4.1-4.3, 5.1-5.8, 6.1-6.2, 7.1-7.2): deferred sub-phases are individually trackable and individually mergeable without back-porting decisions to the umbrella phase row.

§10.2 Phase 2 closeout (LANDED 2026-05-21 18:08 GMT+7)

Phase 2 widens the x86_64 stencil table from Phase 1's three-opcode placeholder (OpConst, OpAddI64, ret) to the full non-allocating-arithmetic surface plus the multi-block control-flow shapes the BG kernels need (sequential blocks linked by TermJump, two-way TermBranch). The emitter still rejects OpPhi (deferred to 2.3's cross-op register allocator) and OpDivI64 / OpModI64 (deferred to 2.5's overflow slow-path) with ErrNoStencil so the runtime falls back to vm3 cleanly. aarch64, f64 arithmetic, the BG performance gate, and the cross-op register allocator are each pre-registered as sub-phases.

Stencil set additions

Stencil	Encoding	Reloc
OpSubI64	48 29 F8 (sub rax, rdi)	none
OpMulI64	48 0F AF C7 (imul rax, rdi)	none
OpNegI64	48 F7 D8 (neg rax)	none
OpAddI64Imm	48 05 ii ii ii ii (add rax, imm32)	imm32 @ off 2
OpSubI64Imm	48 2D ii ii ii ii (sub rax, imm32)	imm32 @ off 2
OpMulI64Imm	48 69 C0 ii ii ii ii (imul rax, rax, imm32)	imm32 @ off 3
OpCmpEqI64 / Ne / Lt / Le / Gt / Ge	48 39 F8 (cmp rax, rdi) + 0F XX C0 (setCC al) + 48 0F B6 C0 (movzx rax, al)	none
OpCmpEqI64Imm / Ne / Lt / Le / Gt / Ge	48 3D ii ii ii ii (cmp rax, imm32) + 0F XX C0 + 48 0F B6 C0	imm32 @ off 2

The setCC opcode varies per relation: 0x94 (sete), 0x95 (setne), 0x9C (setl), 0x9E (setle), 0x9F (setg), 0x9D (setge). The cmp+setCC+movzx triplet leaves the bool result in rax in the canonical 0/1 form TermBranch expects.

Calling convention pinned: rax holds the value-stack top (the left operand of every binary op and the result of every op); rdi holds the second-from-top (the right operand of every register-register binary op); r12-r14 are reserved for Frame, typed-arena base, per-VM context and are never clobbered by a Phase 2 stencil. The cross-op register allocator (2.3) widens this to a proper allocation; Phase 2 pins the two-register convention to keep stencils stateless.

Multi-block emitter

Phase 1's single-block restriction lifts. The emitter walks fn.Blocks in stable IR order, records each block's start offset in blockStarts[blockID], and emits each block's value-producing stencils followed by its terminator. Inter-block jump targets that name a yet-unresolved block start are recorded as blockFixups{site, targetID} and patched after the whole function is emitted; the displacement is computed as target - (site + 4) (relative to the end of the rel32 field) and refused with ErrBranchOutOfRange when it falls outside the int32 envelope.

Terminator	Lowering
TermReturn	append ret stencil (C3); trampoline reads the result from rax
TermJump	E9 cd (jmp rel32); one blockFixup at site+1
TermBranch	48 85 C0 (test rax, rax) + 0F 85 cd (jne IfTrue) + E9 cd (jmp IfFalse); two blockFixups (IfTrue at site+5, IfFalse at site+10)

TermInvalid and unknown terminator kinds return ErrNoStencil so the caller falls back to vm3.

Emitter additions

Symbol	Purpose
Emitter.blockStarts []uint32	Function-buffer offset of each block's first byte; indexed by ir.Block.ID
Emitter.blockFixups []blockFixup	Inter-block rel32 patch sites; {site uint32, targetID uint32}
Emitter.emitBlock()	Emits the block's value-producing stencils; rejects OpPhi with ErrNoStencil
Emitter.emitTerm()	Emits the block's terminator; covers TermReturn / TermJump / TermBranch
Emitter.finalizeBranches()	Resolves blockFixups against blockStarts; refuses with ErrBranchOutOfRange outside int32
isImmediateOp()	Recognizes the *Imm IR opcodes so appendStencil copies Value.Const into the Addend of the imm32 reloc
ErrBranchOutOfRange	New error sentinel for ±2 GiB-exceeding inter-block branches

appendStencil extends to fill the Addend slot on both RelocImm64 (for OpConst) and RelocImm32 (for any *Imm opcode). The dispatch lives in a switch on e.relocs[i].Kind; the value flows through Value.Const for every *Imm op the IR carries.

Test coverage (Phase 2 additions)

emit_test.go widens to:

• TestCompileBinaryArith covering OpSubI64 and OpMulI64 end-to-end with byte-level encoding checks at the arith-op offset.
• TestCompileNegI64 walking the unary OpNegI64 lowering byte-for-byte.
• TestCompileImmOps covering OpAddI64Imm, OpSubI64Imm, OpMulI64Imm with reloc offset and Addend checks per variant.
• TestCompileCompare (six subtests) covering every i64 register-register comparison with cmp prefix, setCC opcode, and movzx tail checks.
• TestCompileCompareImm (six subtests) covering every i64-imm comparison with cmp prefix, imm32 reloc, setCC opcode, and Addend propagation checks.
• TestCompileMultiBlockJump walking the two-block sequential lowering; checks E9 opcode at the jump site and the resolved rel32 displacement.
• TestCompileMultiBlockBranch walking the three-block diamond lowering; checks 48 85 C0 test, 0F 85 jne prefix, E9 jmp opcode, and the two resolved rel32 displacements.
• TestCompileRejectsPhi ensures OpPhi reports ErrNoStencil so the runtime falls back rather than emitting an incorrect register move.
• TestCompileRejectsDiv ensures OpDivI64 reports ErrNoStencil so the runtime falls back rather than entering the unimplemented overflow path.
• TestCompileEmptyFunction ensures a zero-block IR rejects with ErrNoStencil rather than emitting an empty buffer the trampoline would jump into.
• TestCompileBadTerminator ensures TermInvalid rejects rather than fall through into the next block's bytes.
• TestIsImmediateOp enumerates the *Imm opcodes the Addend-patch path covers, plus a negative-control set, so a regression that drops Value.Const is caught at unit-test time.

The Phase 1 TestCompileMultiBlock and TestCompileMissingTerminator cases are retired: multi-block is now a supported shape, and missing-TermReturn is replaced with the more precise TermInvalid rejection in TestCompileBadTerminator. The phase-skip messages on every amd64-conditional case advance from "phase 1 ships amd64 only" to "phase 2 ships amd64 only".

Deferred sub-phases (each shippable as its own PR)

Sub-phase	Scope
2.1	aarch64 stencil set covering the Phase 2 x86_64 opcode set; AAPCS64 ABI pin for x0/x1/x19-x21 analogous to rax/rdi/r12-r14
2.2	f64 arithmetic stencils (Add/Sub/Mul/Div/Neg.f64) using SSE scalar ops on xmm0/xmm1
2.3	Cross-op register allocator + OpPhi support: livein/liveout tracking per block, register-move stencils inserted at predecessor terminators, xmm/r* allocation under register pressure
2.4	BG kernel cross-tier performance gate: binary_trees and n_body run under copy-and-patch JIT within 5x of go run on the same host
2.5	OpDivI64 / OpModI64 with slow-path call into a runtime helper for int.min/-1 overflow and divide-by-zero; the helper signature is documented in stencil.go's SymSlowPathDeref-class symbols

Each sub-phase carries its own gate. 2.1 is the highest priority (aarch64 unlocks Apple Silicon and the most common cloud ARM instances). 2.3 is the biggest engineering change (it touches every block's livein/liveout). 2.4 is a performance gate, not an opcode addition; it can land any time after 2.3.

§10.3 Phase 1.1 closeout (LANDED 2026-05-21 18:36 GMT+7)

Phase 1.1 lands the aarch64 Linux target from the §9 must-have matrix. The umbrella Phase 1 row stays PARTIAL until 1.2 (x86_64 macOS), 1.3 (aarch64 macOS), and 1.4 (wasm32) land; 1.5 then reconciles the spec to flip the row to LANDED.

The 1.1 deliverables (all under compiler3/emit/copypatch/):

File	Purpose	Status
stencils_arm64.go	Hand-written aarch64 placeholder stencil table (OpConst via ldr+b+literal-pool, OpAddI64 via add x0, x0, x1, ret under OpInvalid)	LANDED
mmap_linux_arm64.go	Dual-mapping (rw, rx) via memfd_create(279) + ftruncate + mmap*2; W^X structural, no mprotect toggling	LANDED
mmap_linux_arm64_stub.go	Stub returning "unsupported" on non-(linux/arm64) so the package builds on every host	LANDED
stencils_other.go	Updated to !amd64 && !arm64 so the empty-table fallback only kicks in on truly-out-of-matrix hosts	UPDATED
emit_amd64_test.go (//go:build amd64)	Holds the byte-asserting tests that were arch-specific to x86_64 (TestCompileBinaryArith, TestCompileNegI64, TestCompileImmOps, TestCompileCompare, TestCompileCompareImm, TestCompileMultiBlockJump, TestCompileMultiBlockBranch, TestCompileConstReturnAMD64)	LANDED
emit_arm64_test.go (//go:build arm64)	Asserts the exact aarch64 byte layout for OpConst and OpAddI64; covers TestARM64RejectsSubMulNeg so a regression that silently widens the placeholder table is caught	LANDED
stencils_arm64_test.go (//go:build arm64)	Pins the 3-opcode placeholder coverage and asserts archSupportsBranches() == false so a premature flip is caught	LANDED
mmap_linux_arm64_test.go (//go:build linux && arm64)	Dual-view + reject-zero + reject-misalignment + cache-install tests, mirroring the linux/amd64 suite	LANDED
emit_test.go	Rewritten cross-arch: TestCompileConstReturn and TestCompileAddChain look up expected sizes and reloc offsets from archStencils() so they pass byte-for-byte on every host that has a table; adds TestCompileRejectsBranchOnUnsupportedArch covering the new archSupportsBranches() gate	UPDATED
cache_test.go	Patch-offset assertions now read the offset from archStencils()[OpConst].Relocs[0].Offset so the test passes on both amd64 (offset 2) and arm64 (offset 8) without per-arch duplication	UPDATED

The archSupportsBranches() discriminator (new in 1.1, declared in stencils_amd64.go returning true and in stencils_arm64.go returning false) gates emitTerm's TermJump and TermBranch lowering. The amd64 path emits E9 cd (jump) and 48 85 C0 + 0F 85 cd + E9 cd (branch) directly from the emitter; the arm64 path reports ErrNoStencil until Phase 2.1 ports the rel26 / cbz encodings. This keeps the runtime safe: the emitter never produces a buffer of wrong-ISA bytes the trampoline would trap on.

The aarch64 OpConst lowering deserves a specific design call-out. aarch64 has no single instruction that loads an arbitrary 64-bit immediate; the two production patterns are movz + 3 movk (4 instructions, each patching a 16-bit slot) or ldr xN, [pc, #N] + a literal-pool entry. The literal-pool form was chosen because it preserves the RelocImm64 reloc-kind invariant: the 8-byte literal slot patches with a single 64-bit write, byte-identical in shape to the amd64 mov rax, imm64 site. The movz/movk form would require introducing RelocMovkUABS_G{0,1,2,3} per-slot reloc kinds (the LLVM R_AARCH64_MOVW_UABS_G* family), which is Phase 2.1's responsibility to add alongside the widened arm64 stencil set. The placeholder bytes are:

40 00 00 58      ldr x0, [pc, #8]
03 00 00 14      b   #12                   ; skip the literal pool
8 bytes          literal (RelocImm64 site)
C0 03 5F D6      ret                       ; (this is the OpInvalid/ret stencil, not part of OpConst)

The b #12 skips past the 8-byte literal so fall-through execution lands on the next stencil instead of trapping on the data bytes.

Cross-arch test portability: the previous emit_test.go asserted explicit x86_64 byte sequences (code[20] != 0x48 etc.); on aarch64 those assertions would fire against valid arm64 bytes. The fix splits byte-asserting tests by build tag (emit_amd64_test.go, emit_arm64_test.go) while keeping the semantic shape checks (TestCompileConstReturn, TestCompileAddChain) cross-arch portable via archStencils() table lookups. The patcher tests in cache_test.go do the same, reading the OpConst reloc offset from the host table rather than hardcoding 2. Verified by GOOS=linux GOARCH={amd64,arm64} go vet ./compiler3/emit/copypatch/ and GOOS=darwin GOARCH={amd64,arm64} go vet ./compiler3/emit/copypatch/ all clean.

Sub-task PRs and tracking issues:

• aarch64 stencil table + dual-mapping + cross-arch test split: this PR, tracked alongside the umbrella MEP-42 issue.

§10.4 Phase 4.0 closeout (LANDED 2026-05-21 19:08 GMT+7)

Phase 4.0 lands the load-bearing skeleton of the AOT track: compiler3/emit/c/ walks the typed IR and writes a portable C99 source file; compiler3/build/c/ shells to the host cc to produce a single native executable; cmd/mochi/main.go dispatches --target=c to the new driver. The §Top-line objective ("mochi build hello.mochi produces a single native binary that runs on a clean machine") has its first concrete satisfier.

The Phase 4.0 deliverables:

compiler3/emit/c/ package

File	Purpose	Phase 4.0 status
doc.go	Package overview, reading order, Phase 4.0 scope, identity rule (C99-only)	LANDED
emit.go	Program, Emit, emitFunc, emitValue, emitTerminator, emitMain, cType, reversePostorder	LANDED
emit_test.go	9 tests: const+return, fib_iter shape, imm ops, six i64 comparisons, f64 bit-cast const, main printf branches, unsupported-op rejection, main-not-found guard, LLONG_MIN edge	LANDED

The supported IR types are TypeI64 (→ int64_t), TypeF64 (→ double), TypeBool (→ int, canonical 0/1), and TypeUnit (→ void function-result only). Supported ops are OpParam, OpConst, OpPhi, the i64 arithmetic family (Op{Add,Sub,Mul,Div,Mod,Neg}I64 plus *Imm variants), the f64 arithmetic family (Op{Add,Sub,Mul,Div,Neg}F64), and the six i64 comparisons (Op{Eq,Ne,Lt,Le,Gt,Ge}I64 plus *Imm variants). Supported terminators are TermReturn, TermJump, TermBranch. Everything else (OpLenStr, OpListGetI64, OpCallGo, query algebra) returns ErrUnsupportedOp so the driver can refuse cleanly rather than emit code the system cc would reject.

The SSA-to-three-address lowering matches the Go emitter: every value declared at the function head with a zero initializer (int64_t v3 = 0;), assignments inside blocks use =, blocks are labelled L<id>:;, terminators emit goto L<id>;. C99 permits goto across declarations when no VLA is jumped over; the scalar-only Phase 4.0 surface has no VLAs.

The Main field of cgen.Program triggers emission of int main(void) that invokes the named function and prints its return value: %lld\n for i64, %.17g\n for f64, %d\n for bool, no print for unit. This stands in for Mochi's print() builtin until OpCallGo lowering lands in Phase 4.1.

The LLONG_MIN literal is spelled (-9223372036854775807LL - 1) because C99 lexes positive then negates; writing -9223372036854775808LL overflows the positive-literal lex. Pinned by TestEmitConstI64Min.

compiler3/build/c/ package

File	Purpose	Phase 4.0 status
doc.go	Driver scope, single-binary gate definition, identity rule	LANDED
driver.go	Options, Result, Build, BuildSource, resolveCC	LANDED
driver_test.go	6 tests: end-to-end emit+cc+run, KeepEmit cleanup, bad-CC guard, missing-OutDir guard, resolveCC precedence, static-flag shape	LANDED

The driver writes one gen.c under Options.OutDir, shells to the resolved cc with -std=c99 -O2 -o <binary> gen.c (plus -static when Options.Static is set), then removes gen.c unless KeepEmit is true. The cc resolution priority is Options.CC → $MOCHI_CC → cc. The driver does not invoke LLD directly in Phase 4.0; the host cc's default linker is trusted to produce a working ELF/Mach-O. Phase 5 widens to cross-target builds.

The load-bearing test is TestBuildHelloEndToEnd: it constructs a one-function Program (fun answer(): int { return 42 }), runs the emitter, invokes the host cc, runs the produced binary, and asserts stdout equals "42\n". This is the Phase 4.0 gate as a unit test.

CLI integration (cmd/mochi/main.go)

BuildCmd extends with three new flags:

Flag	Purpose
--cc <path>	C compiler to invoke; defaults to $MOCHI_CC then cc
--binary <path>	Output binary path; defaults to <OutDir>/a.out
--portable	Pass -static to cc for musl/glibc-static linking (§11.7 mitigation)

runBuild now dispatches on --target to runBuildGo (the MEP-43 path) or runBuildC (this phase). The CLI smoke test (recorded under ~/notes/Spec/5500/implementation/04_phase_4_0_c_aot_skeleton.md §4):

$ mochi build --target=c --binary=/tmp/hello42 /tmp/hello42.mochi
binary /tmp/hello42
$ /tmp/hello42
42

Deferred sub-phases (each shippable as its own PR)

Sub-phase	Scope
4.1	OpCallGo lowering + a minimal runtime/mochi/print.{h,c} so a Mochi-source print(x) reaches stdout (replaces the Phase 4.0 main-printf convention)
4.2	String ops (OpLenStr, OpConcatStr) backed by a small mochi_str C runtime
4.3	List / map / typed-array ops, backed by C runtime allocators paired with MEP-41 verifier rules
4.4	Query algebra ops (lower to C loops or to a small runtime/mochi/query.c matching the Go runtime/mochi/query shape)
4.5	--portable matrix expansion: musl-static on Linux, libSystem-static disabled with diagnostic on macOS, glibc-static guarded by host availability
4.6	DWARF 5 line tables emitted directly by the C emitter via __attribute__((no_caller_saved_registers))-free wrapping (or by trusting cc's -g once OpCallGo names Mochi-source symbols)

Each sub-phase carries its own gate. Phase 4.1 is the highest priority (without OpCallGo, no Mochi program that uses print() can build); Phase 4.2-4.3 unblock the BG kernel set; Phase 4.5 closes the §11.7 "default Linux build needs target libc present" boundary.

§10.5 Phase 4.1 closeout (LANDED 2026-05-21 19:32 GMT+7)

Phase 4.1 closes the two largest Phase 4.0 gaps against the §Top-line objective: (a) the C emitter lowers OpCall (intra-program calls), so any Mochi program with more than one user-defined fun can build; (b) the C emitter recognises the print(x) sentinel binding (OpCallGo{Pkg:"fmt", Name:"Println"}) and routes it through a tiny embedded C runtime, so any frontend-producible Mochi program reaches stdout with byte-parity against mochi run. General Go FFI is rejected by design (the MEP-42 identity rule is no cgo on the build host; cross-language calls cannot satisfy it).

runtime/c/ package (new)

File	Purpose	Phase 4.1 status
doc.go	Package overview; embeds src/print.{h,c} via go:embed so the build driver can drop the runtime next to gen.c	LANDED
src/print.h	C99 header: mochi_print_i64, mochi_print_bool, mochi_print_f64	LANDED
src/print.c	Implementation. i64: printf("%" PRId64 "\n"). bool: "true\n"/"false\n". f64: shortest round-trip search (precision 1..17 of %.*g, pick first that round-trips via strtod)	LANDED

The runtime source files live under src/ because Go's package loader refuses to compile a directory that holds loose .c files when cgo is off, and the whole point is to stay no-cgo on the build host. Embedding via //go:embed src/* puts the runtime inside the mochi binary, so go install mochi ships everything Phase 4.1's gate needs (single-tool bootstrap).

compiler3/emit/c/ changes

Area	Change
Emit(p) prologue	Walks the IR once to learn whether any function calls print(); emits #include "print.h" only when needed. Rejects any OpCallGo binding that is not the print sentinel with ErrUnsupportedFFI.
emitValue OpCall / OpTailCall	Now lowers intra-program calls. v.Const indexes Program.Funcs; the emitter writes <lhs> = <callee>(args); (or a bare statement for unit-typed results). OpTailCall lowers identically; cc's -O2 turns the terminal call into a tail jump when profitable.
emitValue OpCallGo	Dispatches on fn.Values[v.Args[0]].Type: TypeI64→mochi_print_i64, TypeF64→mochi_print_f64, TypeBool→mochi_print_bool. TypeStr and composite types return ErrUnsupportedType until Phase 4.2 lands the string runtime.
cFuncName	New helper. Rewrites the frontend's synthesized script entry "main" to mochi_main (so the wrapper int main(void) does not redefine the symbol). Rewrites C99 keywords and reserved stdlib identifiers (e.g. double, int, static) to m_<name> so a fun double(...) compiles. Underscore-leading Mochi names get an m prefix because C99 §7.1.3 reserves them.
ErrUnsupportedFFI	New sentinel error for "C target does not support cross-language FFI; use --target=go".

The walk-then-emit prologue pattern (instead of late patching #include after a body emit) keeps the prologue self-contained and lets the driver decide what runtime files to write.

compiler3/build/c/ changes

Area	Change
Build(p, opts)	After writing gen.c, also writes every embedded runtime/c/src/* file into opts.OutDir. The cc invocation gains -I <OutDir> (so #include "print.h" resolves) and appends every runtime .c file (so the linker has the runtime TUs).
KeepEmit=false cleanup	Now also removes the runtime .c and .h files; the binary is the only artifact.
BuildSource entry resolution	Replaces "pick Funcs[0]" with "pick the function literally named main if present, else fall through to Funcs[0]". Necessary because the compiler3 frontend emits funs in declaration order, so a user-defined fun precedes the synthesized main.

Frontend-integration test suite

compiler3/build/c/driver_test.go adds runMochiBuild(src) — write Mochi source to a tempdir, BuildSource, run the binary, return stdout. Tests exercise:

Source shape	Gate
let a, let b, print(a+b)	Binary prints 30\n
let; let; print((a+b)*2)	Binary prints 20\n
fun double(n: int): int { return n*2 }; print(double(21))	Binary prints 42\n (intra-program OpCall lowering + double keyword rewrite)
if n > 3 { print(1) } else { print(0) }	Binary prints 1\n (control flow lowering + print)
import go "..." as testpkg; print(testpkg.Add(2,3))	Build fails with ErrUnsupportedFFI, not a runtime crash

Each gate runs the produced binary on the host and asserts byte-exact stdout against the same source under mochi run. Failure of any gate signals the §Top-line objective is regressed.

Float-print precision (known divergence)

mochi_print_f64 uses C99's %.*g with a precision-search to find the shortest round-trip. Go's strconv.FormatFloat uses Ryu under the hood and renders fixed-vs-scientific differently from C %g near the 10^-4 / 10^+precision boundaries. For typical finite values (1.5, 42.0, 0.1, 1e-06, 1e+20) the two agree. The known divergent cases:

Value	Go fmt.Println	C mochi_print_f64	Fix
100.0	100	1e+02 (with precision-search at p=1)	Phase 4.2: Ryu-equivalent shortest-decimal in C runtime
±Inf	+Inf / -Inf	inf / -inf	Phase 4.2: explicit branches
NaN	NaN	nan	Phase 4.2: explicit branch

Phase 4.1 does not gate on these; tests use only values where the two formats agree. Phase 4.2's f64 closeout will retire the precision-search and ship a Ryu implementation tuned for byte-exact Go parity.

Deferred sub-phases (revised)

Sub-phase	Scope
4.2	TypeStr lowering: string literals, OpLenStr, OpConcatStr, mochi_str C runtime, mochi_print_str; Ryu-equivalent f64 print to close the precision-divergence gap
4.3	Collection lowering: TypeList/TypeMap/TypeF64Array + their op families, backed by a small C runtime with MEP-41-aware bounds checking
4.4	Query algebra: lower query ops to C loops or to a runtime/c/query.{h,c} matching the Go runtime/mochi/query shape
4.5	--portable matrix expansion: musl-static on Linux, libSystem-static disabled with diagnostic on macOS, glibc-static guarded by host availability
4.6	DWARF 5 line tables via cc -g once OpCallGo's sentinel set includes file/line attribution; or self-emitted DWARF for mochi build --debug

The sub-phase ordering converges on "every Mochi program the compiler3 frontend can lower also compiles to C". The §11 IR coverage matrix (added below) is the contract; an entry moves from DEFERRED to LANDED only when both the emitter lowers the op and a Mochi-source integration test exercises it.

§10.6 IR coverage matrix (C target)

This is the contract behind the §Top-line objective. Every IR OpCode and Type either has a C-target lowering today, is deferred to a named sub-phase, or is rejected by design. A row moves from DEFERRED to LANDED only when both compiler3/emit/c/emit.go lowers it and an integration test under compiler3/build/c/driver_test.go exercises a Mochi source that uses it.

Types

IR Type	C99 lowering	Status
TypeI64	int64_t	LANDED (Phase 4.0)
TypeF64	double	LANDED (Phase 4.0)
TypeBool	int (canonical 0/1)	LANDED (Phase 4.0)
TypeUnit	function-result void	LANDED (Phase 4.0)
TypeStr	const char* for string literals (Phase 4.2.0); mochi_str (UTF-8 owning slice) for concat/slice later in Phase 4.2.x	PARTIAL (Phase 4.2.0: literal-only)
TypeList[T]	mochi_list_<T>*	DEFERRED Phase 4.3
TypeMap[K,V]	mochi_map_<K>_<V>*	DEFERRED Phase 4.3
TypeF64Array	mochi_f64arr* (typed slice)	DEFERRED Phase 4.3
Function-handle (OpFnRef)	function pointer	DEFERRED Phase 4.4 (needed by query combine fns)
Struct (StructID)	typedef struct	DEFERRED Phase 4.7 (frontend does not produce yet)

Ops

Op	Lowering	Status
OpParam	function parameter	LANDED (Phase 4.0)
OpConst (i64)	integer literal with LLONG_MIN edge	LANDED (Phase 4.0)
OpConst (f64)	bit-cast via anonymous union	LANDED (Phase 4.0)
OpConst (bool)	0 / 1	LANDED (Phase 4.0)
OpConst (str)	const char* to a C string literal; payload stored in fn.Strings, indexed by Value.Const	LANDED (Phase 4.2.0)
OpPhi	predecessor-side assignment in terminator	LANDED (Phase 4.0)
OpAddI64/OpSubI64/OpMulI64/OpDivI64/OpModI64/OpNegI64 + *Imm	direct C operator	LANDED (Phase 4.0)
OpAddF64/OpSubF64/OpMulF64/OpDivF64/OpNegF64	direct C operator	LANDED (Phase 4.0)
OpCmpEqI64..OpCmpGeI64 + *Imm	(a op b) ? 1 : 0	LANDED (Phase 4.0)
OpAndI64/OpOrI64/OpXorI64/OpShlI64/OpShrI64/OpNotI64	direct C bitwise operator (and, or, xor, left shift, right shift, not); shifts are arithmetic on signed int64_t	LANDED (Phase 4.1.1, IR + emit only; not parser-reachable yet)
OpCmpEqF64..OpCmpGeF64	(a op b) ? 1 : 0 over double	LANDED (Phase 4.1.1)
OpNotBool	v ? 0 : 1 (canonical bool form)	LANDED (Phase 4.1.1)
OpCall / OpTailCall	direct C call via Program.Funcs[v.Const]	LANDED (Phase 4.1)
OpCallGo{fmt.Println}	dispatch on arg type to mochi_print_* runtime	LANDED (Phase 4.1 for i64/f64/bool; Phase 4.2.0 adds str)
OpCallGo{*} (other)	none	REJECTED by design (no cgo; use --target=go)
OpFnRef	function-pointer literal	DEFERRED Phase 4.4
OpLenStr	(int64_t)strlen(s) for the const char* carrier; auto-includes <string.h>	LANDED (Phase 4.2.1)
OpCmpEqStr / OpCmpNeStr	(strcmp(a, b) == 0) / != 0 over the const char* carriers	LANDED (Phase 4.2.2)
OpConcatStr	mochi_str_concat(a, b) allocates a NUL-terminated heap buffer and returns a const char* carrier (leaks at process exit; arena lands in a later 4.2.x)	LANDED (Phase 4.2.3)
OpI64ToStr	mochi_str_from_i64((long long)v) formats via snprintf("%lld") into a fresh heap buffer (24-byte max for i64 + NUL)	LANDED (Phase 4.2.4)
OpF64ToStr	mochi_str_from_f64(v) runs the shortest-round-trip search shared with mochi_print_f64, so str(x) and print(x) agree on digits	LANDED (Phase 4.2.4)
OpBoolToStr	mochi_str_from_bool(v) returns one of two static C99 literals "true" / "false"; no allocation	LANDED (Phase 4.2.4)
OpNewList / OpListLenI64 / OpListPushI64 / OpListGetI64 / OpListSetI64	mochi_list_i64_* runtime (heap-allocated header, doubling growth)	LANDED (Phase 4.3.1)
OpListGetF64 / OpListSetF64	not lowered by the C target; list<float> routes through OpNewF64Array instead	N/A (vm3 surface)
OpNewMap / OpMapSet/Get/I64I64	mochi_map_* runtime	DEFERRED Phase 4.3
OpNewF64Array / OpF64ArrayLenI64 / OpF64ArrayPushF64 / OpF64ArrayGetF64 / OpF64ArraySetF64	mochi_f64_array_* runtime (heap-allocated header, doubling growth, flat double[] backing)	LANDED (Phase 4.3.3)
OpQueryFilter/Map/SortBy/SortByDesc/Limit/Distinct/GroupBy	inline C loops or runtime/c/query	DEFERRED Phase 4.4
OpQueryJoin/LeftJoin/OuterJoin/CrossJoin	inline C loops or runtime/c/query	DEFERRED Phase 4.4

Terminators

Terminator	Lowering	Status
TermReturn	return <v>; (or bare return; for unit)	LANDED (Phase 4.0)
TermJump	goto L<id>; after predecessor phi assignments	LANDED (Phase 4.0)
TermBranch	if (cond) { goto L<true>; } goto L<false>;	LANDED (Phase 4.0)

When a row moves from DEFERRED to LANDED, the closeout PR updates this matrix in the same change set (MEP-spec-in-sync rule).

§10.7 Phase 4.1 micro-benchmarks (recorded 2026-05-21 19:53 GMT+7)

The §Top-line objective claims feature-parity, not performance-parity. This section quantifies the latter on the workloads expressible in the compiler3 MVP frontend (recursive scalar functions over i64 with print). Each row is the median of 5 wall-clock runs measured with shell time on darwin/arm64 (Apple M-series, Apple clang 17.0.0, Go 1.25.x). The five columns are:

• Mochi→C: mochi build --target=c then run the binary. Cc invocation: cc -std=c99 -O2 -I <outdir> gen.c print.c.
• Mochi→Go: mochi build --target=go --out=<dir> then go build on the emitted gen.go.
• hand C: a hand-written C99 file with the same algorithm, compiled with cc -std=c99 -O2.
• hand Go: a hand-written Go file with the same algorithm, compiled with go build.
• vm3: mochi run, the interpreter that has been the reference execution model since MEP-16.

Workload	Mochi→C	Mochi→Go	hand C	hand Go	vm3
fib(35) (recursive Fibonacci)	0.022 s	0.029 s	0.026 s	0.031 s	21.139 s
ack(3, 10) (Ackermann)	0.142 s	0.140 s	0.140 s	0.154 s	41.469 s
fib_iter(1e8) (iterative Fibonacci, i64 wraparound) [1]	0.029 s	0.028 s	0.027 s	0.029 s	N/A [1]

[1] vm3 auto-promotes integers to arbitrary precision when an operation would overflow i64, so fib_iter(1e8) runs as bigint arithmetic in vm3 (producing a multi-million-digit result) while native targets wrap modulo 2^64. The two measurements are not comparable; the vm3 column is left out rather than reporting a 4-orders-of-magnitude figure that conflates dispatch cost with bigint cost. A vm3-comparable while-loop benchmark needs a workload that stays within i64 throughout; that is captured separately in the closeout for Phase 4.1.2 below.

Speedup over vm3 (median/median):

Workload	Mochi→C	Mochi→Go	hand C	hand Go
fib(35)	961×	729×	813×	682×
ack(3, 10)	292×	296×	296×	269×

Binary sizes (release, stripped of debug by default):

Target	fib_rec	ack
Mochi→C	34 KB	34 KB
hand C	33 KB	33 KB
Mochi→Go	2.5 MB	2.5 MB
hand Go	2.5 MB	2.5 MB

Findings:

• Mochi→C is within measurement noise of hand C. The cc optimiser sees through the SSA-emitted local-then-jump shape and the resulting machine code matches what a direct C author would produce. Generated-C does not pay a parity tax on scalar recursive code.
• Mochi→Go is within measurement noise of hand Go. Same conclusion for the Go target.
• vm3 is 290-960x slower than native on these workloads. The interpreter pays a per-op dispatch cost that recursive scalar code amplifies. This is the §Top-line objective's quantitative motivation: every Mochi program that ships as a vm3-interpreted script can become a 300-1000x faster native binary by switching to --target=c or --target=go.
• C wins on size by 70x. A 33 KB C executable versus a 2.5 MB Go binary is the practical tie-breaker between the two AOT targets when the deployment cares about binary size.

Workloads in the "performance games" set that are NOT in this micro-benchmark table, and their current state (revised after Phase 4.3.15 audited the on-disk bench/template/bg/*.mochi fixtures end-to-end through mochi build --target=c):

Workload	C-target state	Pinning test
mandelbrot	LANDED. Native bench/template/bg/mandelbrot/mandelbrot.mochi compiles unchanged (N=16 audit produces {"duration_us":...,"output":4629}). Gating sub-phases: f64 list primitives (Phase 4.3.3), as casts (4.3.4), math.sqrt+precedence (4.3.5), int()/float() calls (4.3.6), for x in xs (4.3.7), list-literal element-type inference (4.3.8), math.pi (4.3.9), [T] syntax (4.3.11), list concat (4.3.12), now() (4.3.13), json({...}) (4.3.14).	TestBuildSourceMandelbrotBgFixture
n_body	LANDED. Native bench/template/bg/n_body/n_body.mochi compiles unchanged (steps=50 audit produces {"duration_us":...,"output":-169063617}, byte-matches the interpreter on output).	TestBuildSourceNBodyBgFixture
spectral_norm	LANDED. Native fixture (N=100) compiles unchanged; uses bare print(int(...)) rather than the JSON harness.	TestBuildSourceSpectralNormBgFixture, TestBuildSourceSpectralNativeKernel
nsieve	LANDED. Native fixture (n=100, repeat=50) compiles unchanged and produces {"duration_us":...,"output":25}.	TestBuildSourceNsieveBgFixture
fannkuch_redux	LANDED. Native fixture (trials=100) compiles unchanged and produces {"duration_us":...,"output":272}. The kernel does not need structs (the previous "needs list-of-structs" rationale was wrong; it uses a single list<int> of length 7 with in-place rotation).	TestBuildSourceFannkuchReduxBgFixture
fasta	LANDED. Native fixture (N=10000) compiles unchanged and produces a deterministic LCG rolling-hash 1072663717. The fixture uses bare print(h) rather than json({...}) because the cross-lang reference compares a single integer hash. The previous "needs string literals" rationale was wrong; the cross-lang harness already replaced strings with the integer hash.	TestBuildSourceFastaBgFixture
regex_redux	LANDED. Native fixture (N=10000) compiles unchanged and produces 69. The cross-lang reference uses an LCG-driven state machine over a bit-packed window rather than actual regex, so no TypeStr is needed.	TestBuildSourceRegexReduxBgFixture
reverse_complement	LANDED. Native fixture (N=4096) compiles unchanged and produces 293888 = (N/4)*287. The previous "needs file I/O + strings" rationale was wrong; the cross-lang fixture uses a synthesised i64 ACGT cycle and prints a checksum.	TestBuildSourceReverseComplementBgFixture
k_nucleotide	LANDED (Phase 4.3.15.2). Native fixture (N=10000) compiles unchanged and produces 723253870 (LCG-driven 20-key rolling i64 hash), byte-matches --target=go on the same source. Gating sub-phase wires map<int, int> type, {} empty-literal initializer, m[k] read, and m[k] = v indexed-assign through the existing OpNewMap / OpMapGetI64I64 / OpMapSetI64I64 IR ops, plus a new runtime/c/src/mochi_map_i64_i64.{h,c} open-addressing hashtable.	TestBuildSourceKNucleotideBgFixture
binary_trees	LANDED (Phase 4.3.15.1). Native fixture (N=4 pinned, larger N green ad-hoc) compiles unchanged and produces {"duration_us":...,"output":496} (16 iters * 31 nodes per depth-4 tree), byte-matches --target=go on the same source. Gating sub-phase introduces TypeListAny (unifying surface any and list<any>), four list-any ops (OpNewListAny / OpListAnyLen / OpListAnyPushAny / OpListAnyGetAny), a recursive runtime/c/src/mochi_tree.{h,c} C runtime, and the corresponding Go target type alias type _MochiAny []_MochiAny. The surface t[i] as list<any> cast collapses to a same-type no-op since elements and outer list share the IR tag.	TestBuildSourceBinaryTreesBgFixture
pidigits	OUT OF SCOPE. Needs arbitrary-precision integers; not on MEP-42 scope.

The Phase 4.3 stream's user-facing goal "all bench-template benchmark games programs compile via mochi build --target=c" is satisfied for all 10 in-scope fixtures (pidigits excluded as out-of-scope, requires bignum). Zero remaining gaps for the user-facing goal.

Reproducer scripts and sources are at /tmp/mep42bench/ on the recording machine; the Mochi sources are:

// fib_rec.mochi
fun fib(n: int): int {
  if n <= 1 { return n }
  return fib(n - 1) + fib(n - 2)
}
print(fib(35))

// ack.mochi
fun ack(m: int, n: int): int {
  if m == 0 { return n + 1 }
  if n == 0 { return ack(m - 1, 1) }
  return ack(m - 1, ack(m, n - 1))
}
print(ack(3, 10))

// fib_iter.mochi
fun fib(n: int): int {
  var a = 0
  var b = 1
  var i = 0
  while i < n {
    let t = a + b
    a = b
    b = t
    i = i + 1
  }
  return a
}
print(fib(100000000))

§10.8 Phase 4.1.1 closeout (LANDED 2026-05-21 20:53 GMT+7)

Phase 4.1.1 ports the remaining C scalar operator set into the IR, frontend, and both target emitters. After Phase 4.1 landed the call/print plumbing, every benchmark games program that does not already need strings, arrays, loops, or lists still needed one more piece: the operators themselves. Phase 4.0 covered i64 add/sub/mul/div/mod/neg/cmp and f64 add/sub/mul/div/neg; Phase 4.1.1 covers everything else the compiler3 frontend can produce or will produce in the near term.

New IR opcodes

OpCode	Lowering
OpAndI64, OpOrI64, OpXorI64	direct C/Go &, `
OpShlI64, OpShrI64	direct C <<, >> on int64_t (arithmetic right shift on all modern toolchains); Go casts the right operand to uint64 per the Go spec
OpNotI64	direct C ~, Go ^ (Go's bitwise complement)
OpCmpEqF64 .. OpCmpGeF64	(a op b) ? 1 : 0 over double in C; direct Go boolean expression
OpNotBool	v ? 0 : 1 in C (canonical 0/1 bool form), !v in Go

The bitwise/shift ops are wired through every layer (ir, validate, verify, emit/c, emit/go, frontend dispatch) but are not parser-reachable today: the Mochi grammar at parser/ast.go has no tokens for &, |, ^, <<, >>, or ~. The IR + emit work is forward-compat scaffolding so that when the parser gains those tokens, lowering them is a one-line change in applyBinOp. The f64 compares and bool not are parser-reachable today.

Frontend changes

compiler3/frontend/lower.go's applyBinOp was a single switch over the operator string; it is now a two-level dispatch (operand type, then operator). The TypeI64 branch handles + - * / % & | ^ << >> == != < <= > >=; the TypeF64 branch handles + - * / == != < <= > >= (no % because C's % is integer-only and Mochi's parser does not produce % on f64 today). lowerUnary was extended to handle f64 unary - (OpNegF64) and bool unary ! (OpNotBool); the i64 unary - path is unchanged. Operand-type dispatch fixes a latent Phase 4.0 miscompile where 1.5 + 2.5 would have emitted OpAddI64 because the operator dispatch ignored types.

Verify + integration

compiler3/verify/verify.go's init-time op-coverage assertion (lastOpCode) was bumped to OpNotBool, so any future opcode addition that forgets a kindOf branch fails build at package init. 8 new emit tests (4 C, 4 Go) pin the lowering shape; the C-side tests cover & | ^ << >> ~ (i64), the 6 f64 compares, and bool not. No frontend-source integration test today (parser cannot produce bitwise/shift forms; f64 cmp and bool not are exercised by future Phase 4.3+ tests that need them).

What this unblocks

The §10.7 benchmark games exclusion table previously listed mandelbrot, n_body, spectral_norm as blocked on "loops + f64 arithmetic"; Phase 4.1.1 cleared the f64 side, leaving only loops + arrays. Phase 4.1.2 clears loops; arrays are Phase 4.3.

§10.9 Phase 4.1.2 closeout (LANDED 2026-05-21 21:05 GMT+7)

Phase 4.1.2 lands while loops in the compiler3 frontend with phi-at-header SSA construction, exercising the previously-untouched back-edge case in the C emit and Go emit. This is the smallest possible loop-track change against the §Top-line objective: the parser already produces parser.WhileStmt, the IR already has OpPhi and TermJump with full validate/emit support, and the C emit already handles phi-as-predecessor-side-assignment. The missing piece was the frontend's lowerStmt dispatch and the build-up of header phis. After this PR, every Mochi-source while cond { body } lowers to a three-block CFG (pre-header jump, header with one phi per live binding plus a branch on cond, body with statement-by-statement lowering plus a back-jump) that both target emitters compile to native code matching what a direct C/Go author would write.

Frontend changes

Symbol	Change
lowerStmt	New case st.While != nil: dispatching to lowerWhile.
lowerWhile(s *parser.WhileStmt)	New. Snapshots the bindings live at loop entry (sorted by name for determinism), allocates header/body/cont blocks, jumps from the pre-header to the header, materialises one OpPhi per snapshotted binding with the back-edge slot left at sentinel 0, lowers the cond in the header context, terminates the header with TermBranch(cond, body, cont), lowers the body, and on the post-body jump-to-header patches every phi's back-edge slot to whatever b.values[name] points to now. The continuation rebinds every snapshotted name to its header phi (cont's only predecessor is the header).
body-terminated path	If the body ends with a return (or another unconditional terminator), the header has only the pre-header as a predecessor; the back-edge slots are dropped from every phi to keep the validator's arity == len(preds) invariant satisfied.

The "phi for every snapshotted binding" approach over-approximates: bindings that the body never reassigns get a phi whose back-edge value equals the phi itself. The validator and both emitters accept these trivial phis without complaint, and cc / Go's optimiser folds the redundant copy. A future optimisation pass can elide trivial phis but it is not on the Phase 4.1.2 critical path.

Limitation: parallel-copy serialisation in the back-edge

The C emit serialises phi assignments one-at-a-time at the predecessor's terminator. For a true SSA swap pattern (a, b = b, a expressed via a temporary), the back-edge phi-args form a cycle that breaks under sequential assignment. The benchmark-games workloads in §10.7 do not contain swap-cycles (each iteration's writes go to fresh values), so this is not a current blocker. A future Phase 4.x can resolve via temporary allocation in emitPhiAssignments (the standard SSA-out parallel-copy algorithm); the limitation is documented here rather than treated as a Phase 4.1.2 ship-blocker.

Integration tests

Test	Source shape	Gate
TestLowerWhileCountdown (frontend)	var n = 5; while n > 0 { print(n); n = n - 1 }	go-target output is 5\n4\n3\n2\n1\n
TestLowerWhileFibIter (frontend)	iterative fib(10) returning 55	go-target output is 55\n
TestLowerWhileSkippedWhenFalse (frontend)	while with cond false at entry	go-target skips body, prints 42\n
TestBuildSourceWhileCountdown (build/c)	same countdown source	C-target binary stdout is 5\n4\n3\n2\n1\n
TestBuildSourceFibIter (build/c)	iterative fib(10) returning 55	C-target binary stdout is 55\n

The build/c tests are the load-bearing gate; they run the host cc and the produced native binary, asserting byte-exact stdout against a known correct value.

Loop micro-benchmark (sum 1..N, vm3-comparable)

The fib_iter benchmark in §10.7 cannot use a vm3 column because vm3 auto-promotes overflowed integers to arbitrary precision, so fib(1e8) in vm3 produces a multi-million-digit bigint while the native targets wrap modulo 2^64. To get a vm3-comparable while-loop number, sum_to(1e8) (sum of 1..N, result 5×10^15, fits in i64 without promotion) was measured under the same 5-run-median protocol:

Workload	Mochi→C	Mochi→Go	hand C	hand Go	vm3
sum_to(1e8)	0.002 s [2]	0.029 s	0.002 s [2]	0.028 s	6.951 s

[2] Disassembly of sum_to_c shows cc -std=c99 -O2 recognised the loop as a closed-form arithmetic series and folded it to n*(n-1)/2 + n at compile time. The 0.002 s is process startup, not loop execution. Mochi→C inherits this optimisation because the SSA-emitted three-address form preserves the dependency chain that cc's -O2 loop-recognition pass needs. The Go targets do not constant-fold because the Go compiler's loop analyser is more conservative.

Speedup over vm3:

Workload	Mochi→C	Mochi→Go	hand C	hand Go
sum_to(1e8)	3475× [2]	240×	3475× [2]	248×

The vm3 row at 6.951 s for 1e8 simple-arith iterations works out to ~70 ns per iteration, which is a reasonable per-op dispatch cost for an interpreter that does typed-arith promotion checks on every operation. The 240× Mochi→Go win is the load-bearing number: when cc cannot constant-fold, Mochi→Go is the typical speedup users see on while-bounded scalar work over mochi run.

What this unblocks

The §10.7 exclusion table no longer lists "needs while/for loops" as a blocker by itself. The remaining benchmark-games gaps are array support (Phase 4.3) and string/file-IO (Phase 4.2). Every other arithmetic workload expressible in the compiler3 frontend's grammar is now compilable through mochi build --target=c|go.

The sum_to.mochi reproducer:

fun sum_to(n: int): int {
  var s = 0
  var i = 1
  while i <= n {
    s = s + i
    i = i + 1
  }
  return s
}
print(sum_to(100000000))

§10.10 Phase 4.3.1 closeout (LANDED 2026-05-21 22:48 GMT+7)

Phase 4.3.1 lands the typed-i64 list surface end-to-end: IR opcodes (already declared), C runtime, both target emitters, and frontend support for the four Mochi-surface forms ([] empty literal, [1, 2, 3] non-empty literal, xs[i] read, xs[i] = v write, plus the len(xs) / append(xs, v) builtins). After this PR, every benchmark-games kernel whose only missing operator was "growable i64 array" compiles through mochi build --target=c. The closing-out gates in §10.6 move the five OpList*I64 rows from DEFERRED to LANDED; the matching f64 rows stay deferred for Phase 4.3.2.

Why this PR is small

The IR layer was complete before Phase 4.3.1 started. compiler3/ir/types.go already declared OpNewList, OpListLenI64, OpListPushI64, OpListGetI64, OpListSetI64 with String() coverage; compiler3/ir/validate.go carried their opSig entries (return type and arg-type vector); compiler3/verify/verify.go covered the kindOf table and the read/write dispatch classifications. The Go target emit was also complete (lines 271-285 of emit/go/emit.go lower all five ops to []int64{} / append / indexed get/set / int64(len(...))). The unmet work was the C-side runtime + emit and the frontend forms. The IR-layer pre-work meant Phase 4.3.1 reduced to two new C files, ~25 lines of C-emit changes, and ~120 lines of frontend changes.

C runtime

runtime/c/src/mochi_list_i64.{h,c} adds a heap-allocated growable i64 array. The struct ({ int64_t *data, int64_t len, int64_t cap }) is exposed in the header so the generated C source could in principle inline length reads without a function call, but the generated source today routes through mochi_list_i64_len() for uniformity with the other ops. Growth is doubling from an initial 4-element capacity on first push, matching the amortised-O(N) shape of Go's slice append. The MVP leaks at exit (no free); a future Phase 4.3.x can add a finaliser hook if a benchmark surfaces pressure. The runtime is C99 with only stdint.h, stdlib.h, and string.h, preserving the MEP-42 "no libc beyond ANSI" identity.

The driver-side wiring: runtime/c/doc.go extends its //go:embed pattern to include the two new files, and the existing writeRuntime walk in compiler3/build/c/driver.go picks them up unchanged. The cc invocation already links every .c it finds in the runtime tree, so a Mochi program that uses a list links mochi_list_i64.o for free; programs that do not reference any list op still get the object linked but the linker dead-strips it, costing ~200 bytes of binary size on darwin/arm64.

C-emit lowering

compiler3/emit/c/emit.go grows a usesListI64 flag computed in the pre-walk over fn.Values. When set, the prologue includes mochi_list_i64.h. The five list opcodes lower as one-line C statements each: mochi_list_i64_new() for OpNewList, mochi_list_i64_push(l, v) for OpListPushI64, mochi_list_i64_get(l, i) for OpListGetI64, mochi_list_i64_set(l, i, v) for OpListSetI64, mochi_list_i64_len(l) for OpListLenI64. The mutating ops (push, set) emit no LHS because their IR type is TypeUnit; the read ops (new, get, len) emit <lhs> = <rhs>;. The function-head declaration block already declares every non-param value via cType(v.Type) with a zero initialiser, so cType(ir.TypeList) = "mochi_list_i64*" (added in this PR) makes the list values self-declaring as nullable pointers. The first OpNewList overwrites the NULL with a real heap pointer.

Frontend lowering

compiler3/frontend/lower.go:

1. lowerType grows a t.Generic != nil branch handling list<int> → ir.TypeList. Non-i64 element types (list<float>, list<bool>) surface an explicit error so the A/B harness skips the fixture rather than miscompiling.
2. lowerStmt's AssignStmt case splits on len(st.Assign.Index): zero indices route to lowerLet (the previous behaviour); one index routes to a new lowerIndexedAssign that emits OpListSetI64. Multi-level indices and slice forms stay rejected.
3. lowerPostfix previously rejected any postfix ops; it now lowers a chain of IndexOp postfixes to OpListGetI64 values, type-checking that the operand is a TypeList and the index is TypeI64. Slice forms (xs[lo:hi]) stay rejected.
4. lowerPrimary grows a p.List != nil branch that calls lowerListLiteral, which emits OpNewList plus one OpListPushI64 per element. Non-i64 element types in the literal surface an error.
5. lowerCall consults a new lowerBuiltinCall helper before the user-fun lookup. The helper recognises len(xs) (lowering to OpListLenI64 for TypeList args or OpLenStr for TypeStr args) and append(xs, v) (lowering to OpListPushI64 plus returning the same SSA value, so xs = append(xs, v) rebinds the name to itself — the C-target's pointer-aliasing model means the underlying list mutates in place, which is what the user expects).

The lowerWhile phi-at-header construction needed no changes: TypeList values flow through phi nodes the same way every other type does, with the C-emit's pointer assignment in the predecessor-side phi-assignment serialising correctly because a list value is a single pointer (no parallel-copy issue).

Integration tests

Two new gate tests in compiler3/build/c/driver_test.go:

• TestBuildSourceListAppendAndIndex: the load-bearing gate. A Mochi script that uses var xs: list<int> = [], append, len, indexed read, and indexed write inside nested while loops, computing sumlist(10) = 55 + 100 = 155 (sum of 1..10 plus an indexed write of 100 to xs[0]). Builds via mochi build --target=c and prints 155\n.
• TestBuildSourceListLiteralRead: pins the non-empty list literal shape; let xs: list<int> = [10, 20, 30]; print(xs[2]) builds to a binary that prints 30\n.

Matching Go-target tests in compiler3/frontend/lower_test.go (TestLowerListAppendAndIndex, TestLowerListLiteralWithElems) byte-match the same outputs, confirming both backends agree on the typed-array surface semantics.

What this unblocks

nsieve: this remains gated on adding range-for support (Phase 4.3.2 covers for _ in 0..n+1 and for i in lo..hi); once that lands, the existing bench/template/bg/nsieve/nsieve.mochi compiles unchanged to a C binary. fannkuch (permutation enumeration with index moves) and binary_trees (tree construction over heap-typed nodes) both need list-of-structs or struct-of-lists; those land in later sub-phases (Phase 4.4 covers structs, Phase 4.5 covers nested lists). The two benchmark-games rows that move closest to green from Phase 4.3.1 alone are nsieve (one phase away) and n_body / spectral_norm (which need list<float>, i.e. Phase 4.3.2's OpListGetF64/OpListSetF64 lowering).

The §10.7 exclusion table's "lists blocked on Phase 4.3" entries (fannkuch, binary_trees) move from "blocked on Phase 4.3" to "blocked on Phase 4.4 + 4.5"; the typed-i64 list primitive is no longer the gating concern for any of them.

Limitations and follow-ups

The frontend forms an aggressive minimum:

• Slice ops (xs[lo:hi]), multi-level indices (xs[i][j]), and field+index chains are still rejected. Lifting them requires either widening lowerPostfix to track the SSA value through every op (straightforward) or threading a small intermediate "place" type through the postfix walker (cleaner). Neither is on the Phase 4.3.1 critical path because none of the §10.7 benchmark-games kernels need them.
• len(xs) was wired into lowerBuiltinCall. The frontend has no other builtin recogniser today (print is special-cased in lowerExprAsStmt, append is handled in the same builtin helper). A future PR may consolidate them into a single dispatch table, but two cases do not yet justify the indirection.
• The C runtime leaks lists at process exit. For long-running compiled binaries this is undesirable; a future Phase 4.3.x can add a deinit hook or an arena allocator that wraps every mochi_list_i64_new() allocation. The benchmark-games suite runs to completion before the leak matters.
• ElemType-aware cType is hard-coded to assume TypeI64 for any TypeList. When Phase 4.3.2 widens the surface to list<float> and list<bool>, cType will need to consult Value.ElemType, which means the cType caller (emitFunc's declaration loop) needs to start passing the full Value rather than just the type. This is a small refactor scoped into Phase 4.3.2.

The reproducer script:

fun sumlist(n: int): int {
  var xs: list<int> = []
  var i = 0
  while i < n {
    xs = append(xs, i + 1)
    i = i + 1
  }
  var s = 0
  var k = 0
  while k < len(xs) {
    s = s + xs[k]
    k = k + 1
  }
  xs[0] = 100
  return s + xs[0]
}
print(sumlist(10))

§10.11 Phase 4.3.2 closeout (LANDED 2026-05-21 23:17 GMT+7)

Phase 4.3.2 lands the range-for surface (for x in lo..hi) end-to-end through the compiler3 frontend and onto both targets (Go and C). The same PR also lands the SSA discipline fix in lowerIf that range-for first surfaced: when a branch of an if mutates bindings (or runs a nested loop that introduces phis), the merge block now phi-joins values from both paths instead of leaking the last-touched env. The §10.7 nsieve row moves from "blocked on Phase 4.3.2" to LANDED; the matching --target=c integration test runs the stripped nsieve(100)=25 kernel byte-for-byte against the Go target.

Why this PR splits into two halves

The frontend half is one new method, lowerFor in compiler3/frontend/lower.go. It is a clone of lowerWhile: snapshot the bindings live at loop entry, build header/body/cont blocks, materialise one OpPhi per snapshotted binding at the header, insert a cmp_lt_i64(loopvar, hi) as the header's branch cond, lower the body, then insert a synthetic loopvar = loopvar + 1 step at the end of the body before patching the back-edge phi-args. The loop variable joins the snapshot set so its phi is one of the back-edge slots. The pre-header binds loopvar to lo; the body's last instruction is the synthetic increment; the cont block restores the loop variable's outer binding (if any) so the loop variable does not leak past the loop. Bounds are typed i64 and may be any expression including local bindings and parenthesised arithmetic (the test for i in 1..(n + 1) exercises this).

The if-merge half is the change that the range-for tests forced. lowerIf previously did not phi-join at the merge block; it let b.values flow forward from whichever branch ran last. That worked for the pre-existing if/else tests because the only test bodies were print(...) calls that did not mutate any binding. The first test that mutates inside an if inside a loop (the stripped nsieve, which does count = count + 1 and runs an inner while that produces phi outputs) immediately broke: the merge block read SSA values defined only on the then-path, so traversing the else-path left those reads uninitialised at the IR level (and zero-valued at runtime in Go, so the loop counter never advanced). The fix is the standard SSA-construction one: snapshot the env at if-entry, snapshot the env at end-of-then, restore for the else branch, snapshot the env at end-of-else, and at the merge block phi-join any name whose value diverges between the two paths. Names introduced only inside a branch keep the pre-if value (their scope ended at the branch). When only one branch terminates (return / break), the merge takes the other branch's env directly. When both terminate, the merge is unreachable.

Why the back-edge predecessor needed patching

When the for-loop's body contains nested control flow (e.g., an inner if), b.curBlock at the end of body-lowering is the merge block of that inner control flow, NOT the original bodyID. The phi-at-header's Args[2] slot, however, was set to bodyID when the phi was created in the header. The emit's parallel-copy logic walks each block's terminator and matches phi.Args[2*i] == blk.ID to know which phi-arg pair to emit at that predecessor's jump. With Args[2] = bodyID but the actual back-edge coming from the inner merge block, no parallel copies were emitted at the back-edge, so the back-edge value was lost and the loop counter never advanced. The fix sets phi.Args[2] = b.curBlock (the actual end-of-body block) at the moment of patching the back-edge value. The matching fix in lowerWhile is included because the same bug exists there in principle; the pre-existing lowerWhile tests do not have an inner if, so it had never been triggered. After this PR both loops patch the back-edge predecessor correctly.

Files changed

• compiler3/frontend/lower.go: lowerStmt routes st.For to new lowerFor. lowerFor is the new method described above. lowerIf gains pre/then/else env snapshots and merge-block phi-join. Both lowerWhile and lowerFor patch phi.Args[2] = b.curBlock before the back-edge jump so phi predecessors reflect the actual end-of-body block.
• compiler3/frontend/lower_test.go: three new tests, TestLowerForRangeSum (sum 1..(n+1) for n=10 = 55), TestLowerForRangeUnderscore (5 iterations with _ index), TestLowerNsieve (stripped nsieve(100) = 25).
• compiler3/build/c/driver_test.go: matching three integration tests through the C target, byte-for-byte against the Go target.
• website/docs/mep/mep-0042.md: this section, plus §10.7 nsieve row update.

What this unblocks

• The bench/template/bg/nsieve/nsieve.mochi fixture's stripped form compiles unchanged through mochi build --target=c; the full benchmark uses the same primitives (range-for, list of i64, indexed read/write, len, append, nested while, if). Wiring the benchmark harness to invoke the C-target build is a §13 (workflow) follow-up, not a frontend gap.
• Any benchmark-games kernel whose only blocker was range-for is now compilable. The next gates in §10.7 are f64 lists (Phase 4.3.x's OpListGetF64/OpListSetF64, gating n_body/spectral_norm/mandelbrot) and structs (Phase 4.4, gating fannkuch/binary_trees).

Limitations

• Collection-iter (for x in xs { body }, where xs is a list) stays rejected with frontend: for-in over a collection unsupported in MVP. Adding it is two steps: lower the source as a list value, then synthesise a var i = 0; while i < len(xs) { let x = xs[i]; body; i = i + 1 }. Not on the Phase 4.3.2 critical path; the §10.7 benchmark-games kernels that need it (none today) can be unblocked by a follow-up sub-phase.
• The for-loop bounds are inclusive of lo and exclusive of hi (the standard half-open range). Mochi has no surface syntax for a fully inclusive range; if added later, the closed-form hi+1 rewrite is one line in lowerFor.
• The lowerIf phi-join treats b.values as a flat name → SSA map; nested struct field updates and indexed list writes are tracked at the list-pointer level (correct, because the C target's lists are heap-allocated and mutation in one branch is visible after the merge), but a per-field write into a stack-allocated struct (Phase 4.4) will need a richer place-tracking scheme. Not a current concern.

Reproducer

fun nsieve(m: int): int {
  var flags: list<int> = []
  var i = 0
  while i < m {
    flags = append(flags, 1)
    i = i + 1
  }
  var count = 0
  for k in 2..m {
    if flags[k] == 1 {
      count = count + 1
      var j = k + k
      while j < m {
        flags[j] = 0
        j = j + k
      }
    }
  }
  return count
}
print(nsieve(100))

Compiles via mochi build --target=c (and --target=go) to a binary that prints 25\n, matching mochi run on the same source.

§10.12 Phase 4.3.3 closeout (LANDED 2026-05-21 23:30 GMT+7)

Phase 4.3.3 lands list<float> end-to-end: C runtime (mochi_f64_array_*), C emit (cType(TypeF64Arr) = mochi_f64_array*, auto-include of the header, five new op lowerings), and frontend coverage for the four surface forms ([] empty literal, [1.5, 2.5, 3.5] non-empty literal, xs[i] read, xs[i] = v write, plus len(xs) / append(xs, v) builtins against the new type). The IR + verify + Go-emit layers were already complete from the vm3 work; this PR adds the C-side runtime and the frontend dispatch. §10.6 moves the five OpF64Array* rows from DEFERRED to LANDED; §10.7 marks mandelbrot, n_body, and spectral_norm as no longer blocked on f64 lists.

Why TypeF64Arr instead of TypeList with ElemType=TypeF64

The IR already has OpListGetF64/OpListSetF64 ops that read/write f64 cells from a TypeList (the Cell-tagged heterogeneous list the vm3 path uses). The C target deliberately routes list<float> through OpNewF64Array + OpF64Array* instead: a flat double[] backing has no Cell-tag overhead, lets cc -O2 vectorise tight loops (the dominant cost in n_body and spectral_norm), and gives the Go target a proper []float64 slice. The cost is one extra IR type and one extra runtime file; the benefit is byte-for-byte the same access pattern as a C programmer would hand-write, which is what the "1-10 MB Crystal-like binary" objective requires. The OpListGet/SetF64 ops remain in the IR for the vm3 surface but are not reachable from the C-target frontend today.

Files changed

• runtime/c/src/mochi_f64_array.h, runtime/c/src/mochi_f64_array.c: new C99 header + impl (40 + 40 lines), mirroring the i64 list runtime but with double backing. Doubling growth from cap=4, abort() on alloc failure, leak-at-exit per MVP.
• runtime/c/doc.go: extend //go:embed to include the two new files.
• compiler3/emit/c/emit.go: add usesF64Array flag in pre-walk, auto-include mochi_f64_array.h, lower the five OpF64Array* ops, extend cType with the TypeF64Arr case.
• compiler3/frontend/lower.go: extend lowerType to map list<float> to TypeF64Arr. Thread the declared element type from var x: list<T> into the literal lowering via a new expectedListElem builder field set by a new lowerTypedLet helper. Extend lowerListLiteral to dispatch on the hint and emit either i64 or f64 ops. Extend lowerIndexedAssign, lowerPostfix index, and lowerBuiltinCall (len + append) to dispatch on the list value's IR type.
• compiler3/frontend/lower_test.go: two new tests, TestLowerListFloatLiteralAndIndex (literal [1.5, 2.5, 3.5] read), TestLowerListFloatAppendAndIndex (full cycle: [] + append + len + index read + index write + read-back, returning 102.5).
• compiler3/build/c/driver_test.go: matching two integration tests through the C target, byte-for-byte against the Go target.
• website/docs/mep/mep-0042.md: this section, §10.6 update, §10.7 mandelbrot/n_body/spectral_norm row update.

Element-type hint vs. element-type inference

Mochi list literals carry no surface annotation: [] and [1.5, 2.5, 3.5] look the same whether the user wants a list<int> or a list<float>. Two options for resolving:

1. Hint from declared LHS type: when var xs: list<float> = ... is lowered, the binding's declared type drives the literal's element type. Empty literals work; non-empty literals would still need every element to type-check as the declared elem.
2. Pure element-type inference: walk the literal's elements, take their common type, then default to i64 for empty. The downside: empty literals must be re-typed at first append, which complicates the SSA discipline (the SSA value's IR type would have to update after creation, a change the IR validator does not currently allow).

This PR uses option (1). The hint lives on a expectedListElem field on the builder that lowerTypedLet sets just before lowerExpr and clears immediately after. Only lowerListLiteral consults it. The hint flows through the parser's Expr → Binary → Unary → Postfix → Primary → List chain because it is read at the leaf, not threaded through the arguments. If the user writes var xs: list<float> = [] then later assigns from a different-typed expression to xs, the type mismatch surfaces at the assign-statement type check, not at the literal lowering.

A consequence: a list literal must use 1.0, not 1 (Mochi int literals lower to TypeI64; the integer-to-float coercion op OpI64ToF64 does not exist in this IR layer). The error message at the rejected element points the user at the fix.

Limitations

• The benchmark games fixtures (bench/template/bg/n_body, bench/template/bg/mandelbrot, bench/template/bg/spectral_norm) are not yet wired into the C-target run harness. The kernels are expressible after this PR; the missing piece is the driver wiring, which is the §13 (workflow) closeout's responsibility.
• No iteration over a list<float> via for x in xs yet (collection-iter remains rejected); kernels must use the while i < len(xs) pattern. The §10.11 closeout's "for-collection unblock" entry stands for both list<int> and list<float> once it lands.
• The OpListGet/SetF64 opcodes are still IR-reachable from the vm3 path, but the C-target frontend does not lower to them; any future Mochi-source path that needs Cell-tagged f64 reads (e.g., a heterogeneous query result) would have to route through TypeList rather than TypeF64Arr.

Reproducer

fun sumf(n: int): float {
  var xs: list<float> = []
  var i = 0
  while i < n {
    xs = append(xs, 0.5)
    i = i + 1
  }
  var s = 0.0
  var k = 0
  while k < len(xs) {
    s = s + xs[k]
    k = k + 1
  }
  xs[0] = 100.5
  return s + xs[0]
}
print(sumf(4))

Compiles via mochi build --target=c (and --target=go) to a binary that prints 102.5\n, matching mochi run on the same source.

§10.13 Phase 4.3.4 closeout (LANDED 2026-05-21 23:50 GMT+7)

Phase 4.3.4 lands the i64↔f64 as cast through compiler3 to both targets. The stripped mandelbrot kernel (16×16 grid, max_iter=50) now compiles end-to-end via mochi build --target=c and produces 4629, byte-matching the Go target. This was the last surface gap blocking the mandelbrot kernel before harness instrumentation (now(), json({...}), {{ .N }} template expansion); the §10.7 mandelbrot row moves from "loops + f64 arithmetic" to "blocked only on benchmark harness shape".

IR additions

Two new opcodes: OpI64ToF64 (i64 → f64, lossless on the int64 range) and OpF64ToI64 (f64 → i64, C99 truncation toward zero, matching the Go target's int64(f64)). Both are nullary-arity producers (one Arg, one result). Validate gives them (TypeI64) → TypeF64 and (TypeF64) → TypeI64 signatures respectively. verify/kindOf classifies them as KindOperator and lastOpCode advances to OpF64ToI64.

Frontend wiring

The CastOp branch in lowerPostfix is now a real case, not the catch-all reject. It lowers op.Cast.Type via the existing lowerType and dispatches on the source/target IR-type pair:

• src == dst: no-op (preserves SSA shape; useful for x as int on an already-i64 value, which costs nothing).
• i64 → f64: emit OpI64ToF64.
• f64 → i64: emit OpF64ToI64.
• anything else: rejected with cast %s -> %s unsupported in MVP, so the A/B harness skips the fixture rather than miscompiling.

The CastOp loop sits inside the existing per-Op walk in lowerPostfix, so casts compose with indexing (xs[i] as float) and chain with other casts ((x as float) as int).

Emit

• Go target: float64(v) and int64(v) casts at the use site (no helper).
• C target: (double)v and (int64_t)v casts at the use site (no helper). cc -O2 folds these into the surrounding fp/int register move when used as an operand to an arithmetic op, which is the path the mandelbrot inner loop relies on.

Files changed

• compiler3/ir/types.go: add OpI64ToF64/OpF64ToI64 constants and String() cases.
• compiler3/ir/validate.go: add op signatures.
• compiler3/verify/verify.go: classify both ops as KindOperator; advance lastOpCode.
• compiler3/emit/go/emit.go: emit Go-side casts.
• compiler3/emit/c/emit.go: emit C-side casts.
• compiler3/frontend/lower.go: real CastOp branch in lowerPostfix with source/target pair dispatch.
• compiler3/frontend/lower_test.go: TestLowerCastIntToFloatRoundTrip (7 round-trips through f64 arithmetic) and TestLowerMandelbrotKernel (the load-bearing 16×16 mandelbrot kernel returning 4629).
• compiler3/build/c/driver_test.go: matching two integration tests through the C target.
• website/docs/mep/mep-0042.md: this section; §10.7 mandelbrot/n_body/spectral_norm row updated to drop the cast blocker.

Reproducer

fun escape_count(cx: float, cy: float, max_iter: int): int {
  var zr = 0.0
  var zi = 0.0
  var n = 0
  while n < max_iter {
    let r2 = zr * zr
    let i2 = zi * zi
    if r2 + i2 > 4.0 {
      return n
    }
    let nzi = 2.0 * zr * zi + cy
    let nzr = (r2 - i2) + cx
    zr = nzr
    zi = nzi
    n = n + 1
  }
  return max_iter
}

let side = 16
let max_iter = 50
let side_f = side as float
var total = 0
var row = 0
while row < side {
  let cy = (row as float) / side_f * 2.0 - 1.0
  var col = 0
  while col < side {
    let cx = (col as float) / side_f * 3.0 - 2.0
    total = total + escape_count(cx, cy, max_iter)
    col = col + 1
  }
  row = row + 1
}
print(total)

Compiles via mochi build --target=c (and --target=go) to a binary that prints 4629\n, matching mochi run on the same source. Pinned by TestBuildSourceMandelbrotKernel.

Limitations

• No int(x) / float(x) function-call cast form yet (used by spectral_norm.mochi); the postfix as form is the only supported surface in this sub-phase. Adding the function-call form is mostly parser routing and would be a fast follow.
• No widening between f32 and f64 (Mochi has no f32 surface; f64 is the only float type).
• The benchmark-games mandelbrot fixture itself still needs now(), json({...}), and {{ .N }} template expansion before it runs as-shipped from bench/template/bg/mandelbrot/. The §13 (workflow) closeout owns wiring those harness pieces.

§10.14 Phase 4.3.5 closeout (LANDED 2026-05-21 23:55 GMT+7)

Phase 4.3.5 lands math.sqrt(x) end-to-end and fixes a foundational operator-precedence bug in lowerBinary that was silently miscompiling every multi-operator non-parenthesised expression. The n_body softened-distance kernel (1/(d2 * sqrt(d2)) for a 3-4-5 triangle, scaled by 1e9, cast to int = 8000000) now compiles end-to-end via mochi build --target=c and byte-matches the Go target. With this in place, the n_body inner loop is expressible in the MVP grammar.

IR + verify additions

One new opcode: OpSqrtF64 with signature (TypeF64) -> TypeF64, classified KindOperator. lastOpCode advances to OpSqrtF64.

Frontend wiring

• Lower now skips Import, ExternFun, ExternVar, ExternType, and ExternObject declarations at top level (treats them as binding-only statements that do not produce IR). This is what makes import python "math" as math + extern fun math.sqrt(x: float): float valid statements that contribute nothing to the synthetic main.
• lowerPostfix gains a tryLowerMathBuiltin(root, tail, args) helper alongside the existing lowerGoCall selector-call path. The helper recognises math.sqrt and emits OpSqrtF64; the surface for additional builtins (pow, log, ...) is the same switch.
• lowerBinary switches from "left-associative without precedence" to Shunting-Yard reduction. A single flat list [v0, op0, v1, op1, v2, ...] is collapsed level-by-level from highest precedence (* / %) down through + - union except intersect, comparisons, &&, ||, ??. Each sweep collapses left-to-right, so the resulting tree is left-associative within each level, matching the canonical math reading. The bug it fixes: dx*dx + dy*dy + dz*dz previously evaluated as ((((dx*dx)+dy)*dy)+dz)*dz (a wrong scalar) which made d2 a nonsense value, sqrt(d2) NaN, and (factor*1e9) as int undefined-behavior int64_max. The mandelbrot kernel from Phase 4.3.4 was incidentally correct because its expressions are written as 2.0*zr*zi + cy (left-assoc-friendly) and (r2 - i2) + cx.

Emit

• Go target: math.Sqrt(v) plus an auto-added "math" import (the existing imports["math"] = true mechanism handles this; it was already set for OpConst of a TypeF64 via math.Float64frombits).
• C target: sqrt(v) from <math.h> (already unconditionally included). The driver appends -lm to the cc command unconditionally; on macOS / *BSD where the math symbols live in libSystem this is a no-op, on glibc/musl Linux it is required for the link.

Files changed

• compiler3/ir/types.go: add OpSqrtF64 constant + String() case.
• compiler3/ir/validate.go: add op signature.
• compiler3/verify/verify.go: classify OpSqrtF64 as KindOperator; advance lastOpCode.
• compiler3/emit/go/emit.go: emit math.Sqrt(v) (auto-imports "math").
• compiler3/emit/c/emit.go: emit sqrt(v).
• compiler3/build/c/driver.go: append -lm to the cc command.
• compiler3/frontend/lower.go: skip Import/ExternFun/ExternVar/ExternType/ExternObject at top level; add tryLowerMathBuiltin; replace lowerBinary's left-assoc fold with a precedence-climbing reducer; add binaryPrecedenceLevels table.
• compiler3/frontend/lower_test.go: TestLowerMathSqrtBuiltin (sqrt(2)*sqrt(2) = 2), TestLowerNbodyDistanceKernel (the load-bearing 8000000 case).
• compiler3/build/c/driver_test.go: matching three C-target tests including TestBuildSourcePrecedenceClimbing which pins the precedence regression directly.
• website/docs/mep/mep-0042.md: this section; §10.7 n_body row updated to drop the math.sqrt + precedence blockers.

Reproducer

import python "math" as math
extern fun math.sqrt(x: float): float

let dx = 3.0
let dy = 4.0
let dz = 0.0
let d2 = dx * dx + dy * dy + dz * dz
let factor = 1.0 / (d2 * math.sqrt(d2))
print((factor * 1.0e9) as int)

Compiles via mochi build --target=c (and --target=go) to a binary that prints 8000000\n, matching mochi run on the same source. Pinned by TestBuildSourceNbodyDistanceKernel.

Limitations

• Only math.sqrt is recognised in this sub-phase. pow, log, sin, cos, etc. extend the same tryLowerMathBuiltin switch and need one new OpCode each (or one generic OpMathBuiltin with a sub-tag) plus the matching Go and C emit lines. spectral_norm currently uses only sqrt so the n_body / spectral_norm goal is met by this sub-phase alone.
• import go "..."-style FFI imports still require the typebridge resolver. Only the python-import-plus-extern pattern is recognised as a no-op binding statement.
• The precedence reducer is set to standard math precedence. & | ^ << >> (bitwise) are NOT in the parser's BinaryOp set today; if they are added later they will need to land in binaryPrecedenceLevels at the right level so existing code does not silently change meaning.

§10.15 Phase 4.3.6 closeout (LANDED 2026-05-22 00:01 GMT+7)

Phase 4.3.6 lands int(x) and float(x) as the function-call surface of the i64-to-f64 cast pair that Phase 4.3.4 already wired as the as postfix. The two surfaces are interchangeable; benchmark-games kernels prefer the call form (int(math.sqrt(uv/vv) * 1e9) in spectral_norm, 1.0 / float(s*(s+1)/2 + i + 1) in the same fixture's eval_a) because it sits inside a larger expression more naturally than a trailing as int. A stripped spectral_norm eval_a(0, 0) kernel now compiles end-to-end via mochi build --target=c, producing 1000000000 (= 1.0 * 1e9 truncated), byte-matching the Go target.

Implementation

No new IR opcodes, no new emit lines, no new verify entries. The cast ops (OpI64ToF64, OpF64ToI64) and their Go and C lowerings already exist from Phase 4.3.4. The only change is in lowerBuiltinCall: two new case "int" and case "float" arms that:

• accept exactly 1 argument, lower it via lowerExpr, and inspect the result type.
• if the argument type already matches the target, return the argument unchanged (no-op cast preserves SSA shape; int(x) on an i64 value or float(x) on an f64 value costs nothing).
• if the argument crosses the i64-to-f64 boundary, emit the matching cast op.
• if the argument is anything else (bool, str, list, ...), reject with int(%s) unsupported in MVP. The harness treats this as a skipped fixture rather than a miscompile.

The early-return placement matters: the two arms sit before the rest of the builtin switch so int(...) and float(...) are not shadowable by a user-declared fun int(x) (the existing lowerBuiltinCall is checked before userFns, so a user fun named int was already unreachable, but the new arms keep the same invariant).

Files changed

• compiler3/frontend/lower.go: add int and float arms to lowerBuiltinCall (28 net lines).
• compiler3/frontend/lower_test.go: TestLowerIntCallCastFromFloat (1.7 -> 1), TestLowerFloatCallCastFromInt (7 -> 7.0 / 2.0 -> 3), TestLowerSpectralEvalKernel (the load-bearing 1000000000 case).
• compiler3/build/c/driver_test.go: matching three C-target tests.
• website/docs/mep/mep-0042.md: this section; §10.7 spectral_norm row updated to drop the int/float call-cast blocker.

Reproducer

fun eval_a(i: int, j: int): float {
  let s = i + j
  return 1.0 / float(s * (s + 1) / 2 + i + 1)
}
print(int(eval_a(0, 0) * 1.0e9))

Compiles via mochi build --target=c (and --target=go) to a binary that prints 1000000000\n, matching mochi run on the same source. Pinned by TestBuildSourceSpectralEvalKernel.

Limitations

• Only int and float are recognised. bool(x), str(x), i32(x), u64(x), ... extend the same dispatch but each needs a target IR type. None are on the §10.7 critical path.
• The full spectral_norm fixture still cannot compile because it uses [float] (the bracketed list-type syntax, distinct from list<float>), list concatenation (u + [1.0]), and for _ in 0..N driving a [float] accumulator. Those are the next sub-phases. The full n_body fixture still needs top-level var at module scope, the extern let math.pi extern-variable form, and the now() + json({...}) + {{ .N }} benchmark harness shape.

§10.16 Phase 4.3.7 closeout (LANDED 2026-05-22 00:07 GMT+7)

Phase 4.3.7 lands collection-iter: for x in xs { body } where xs is list<int> or list<float>. The desugared CFG is the same phi-at-header shape as the existing range-for, with an internal index counter $for_idx_<name> taking the place of the explicit i in lo..hi counter. The loop variable x is rebound on every iteration to xs[idx] via the existing OpListGetI64 / OpF64ArrayGetF64 ops; xs itself and len(xs) are evaluated once in the pre-header so a mutation of xs inside the body does not change what is iterated over.

Implementation

No IR additions, no verify or emit changes. The work is entirely in lowerFor, which now routes s.RangeEnd == nil to a new lowerForCollection(s) helper. That helper:

• evaluates xs once in the pre-header and dispatches on its IR type. TypeList selects (OpListLenI64, OpListGetI64, TypeI64); TypeF64Arr selects (OpF64ArrayLenI64, OpF64ArrayGetF64, TypeF64). Any other type rejects with for-in over %s unsupported (need list).
• creates an internal index counter $for_idx_<loopName> initialised to 0 in the pre-header. The leading $ ensures it cannot collide with a user identifier (the Mochi ident grammar excludes $).
• mirrors lowerWhile's phi-at-header CFG with the counter and any other pre-loop bindings phi-tracked, then patches the back-edge after the body lowers (same arity-fixup discipline as the existing while / range-for paths if the body terminates unconditionally).
• binds the user-visible loop variable to OpListGetI64(xs, idx) (or the f64 equivalent) at the top of the body. The body sees x as a fresh SSA value on every iteration, not a phi.
• restores the shadowed outer binding (if any) at the cont block, matching the existing range-for scoping. The internal counter is deleted from the env at the cont so a later for ... in xs over the same loop name does not collide.

Files changed

• compiler3/frontend/lower.go: route lowerFor to a new lowerForCollection when RangeEnd == nil (+150 lines, all in one function).
• compiler3/frontend/lower_test.go: TestLowerForInListI64, TestLowerForInListF64, TestLowerForInListEmpty.
• compiler3/build/c/driver_test.go: matching TestBuildSourceForInListI64 and TestBuildSourceForInListF64.
• website/docs/mep/mep-0042.md: this section. §10.7 spectral_norm row notes collection-iter is no longer a blocker (the bracketed-list-type syntax and list concat remain).

Reproducer

let xs: list<float> = [1.5, 2.0, 2.5]
var s = 0.0
for x in xs {
  s = s + x
}
print(int(s))

Compiles via mochi build --target=c (and --target=go) to a binary that prints 6\n. Pinned by TestBuildSourceForInListF64.

Limitations

• Only list<int> and list<float> are supported. list<bool> / list<string> / nested-list iteration extend the same dispatch but each needs its own elem-type IR path.
• The collection-iter desugar evaluates xs once and freezes the length. A body that appends to xs does NOT extend the iteration count. This matches Mochi's documented semantics (the loop iterates the snapshot taken at entry) and the Go target.
• Map iteration (for k in m { ... } where m is a map) still rejects. Maps are deferred to a later Phase 4.x sub-phase along with OpNewMap.

§10.17 Phase 4.3.8 closeout (LANDED 2026-05-22 00:13 GMT+7)

Phase 4.3.8 lands element-type inference for untyped list literals. Before this PR, var xs = [1.0, 2.0] defaulted the constructor to OpNewList (i64) and then rejected the f64 element with list<int> literal element type f64. The user had to annotate var xs: list<float> = [1.0, 2.0] to get the correct lowering. After this PR, the constructor is chosen by peeking at the first element's lowered type. The n_body fixture's initial state vectors (var pos_x = [0.0, 4.84, ...]) now compile without an annotation.

Implementation

Tiny change in lowerListLiteral: when expectedListElem is unset and the literal is non-empty, lower the first element, read its IR type, and use that to select the constructor + push op. The lowered first-element SSA value is threaded into the per-element loop (the first iteration reuses it, subsequent iterations lower from the AST). Empty literals with no hint still default to i64.

Bonus refactor: the per-elem-type switch (TypeI64 vs TypeF64) was duplicated in two parallel arms. The new code factors listType / elemType / newOp / pushOp into four locals and runs a single push loop. Net diff: -36 lines of duplication, +29 lines of inference + factored loop = -7 net lines, simpler control flow.

Files changed

• compiler3/frontend/lower.go: infer element type from the first element when expectedListElem is unset; factor the per-elem-type switch.
• compiler3/frontend/lower_test.go: TestLowerListInferFloatElem, TestLowerListInferIntElem (backward-compat), TestLowerNbodyInitVectors (the stripped n_body load-bearing case).
• compiler3/build/c/driver_test.go: matching TestBuildSourceListInferFloatElem, TestBuildSourceNbodyInitVectors.
• website/docs/mep/mep-0042.md: this section.

Reproducer

var pos_x = [0.0, 4.84, 8.34, 12.89, 15.37]
var i = 0
var sum = 0.0
while i < 5 {
  sum = sum + pos_x[i]
  i = i + 1
}
print(int(sum))

Compiles via mochi build --target=c (and --target=go) to a binary that prints 41\n. Pinned by TestBuildSourceNbodyInitVectors.

Limitations

• Inference looks only at the first element. A mixed [1, 2.0] will infer i64 and reject the second element. The Go target's type checker would reject this earlier in a real compile pipeline; the MVP frontend mirrors that behavior at the literal site.
• Empty literals with no annotation still default to i64. The user must write var xs: list<float> = [] to get an f64 array. A smarter inference would look at later context (the first push or the first read) but that requires a second pass and is not on any §10.7 critical path.
• The Phase 4.3.7 collection-iter desugar happens after type inference, so for x in xs { body } over an inferred f64 array correctly dispatches to the f64 path.

§10.18 Phase 4.3.9 closeout (LANDED 2026-05-22 00:20 GMT+7)

Phase 4.3.9 adds math.pi and math.e as recognised selector reads. The Mochi-source pattern is import python "math" as math plus extern let math.pi: float (both already accepted as no-op binding statements from Phase 4.3.5); the new work is recognising the math.pi selector read at the use site and lowering it to an OpConst of TypeF64 carrying the value of math.Pi (or math.E). This is the value-read analogue of Phase 4.3.5's tryLowerMathBuiltin for function calls.

Implementation

New helper tryLowerMathConst(root, tail) in compiler3/frontend/lower.go. Returns (id, true, nil) on a successful lower, (0, false, nil) when the receiver/method pair is not a known math constant, and is wired into the lowerPrimary Selector branch immediately after the goImports lookup. The constant table holds pi and e; the encoding is the same as lowerLiteral's float case (int64(math.Float64bits(v))), so the verify and emit paths see a regular OpConst and need no changes.

Files changed

• compiler3/frontend/lower.go: new tryLowerMathConst helper; wired into lowerPrimary Selector dispatch.
• compiler3/frontend/lower_test.go: TestLowerMathPiConst (4pipi truncated = 39), TestLowerMathEConst (e*e truncated = 7).
• compiler3/build/c/driver_test.go: matching TestBuildSourceMathPiConst.
• website/docs/mep/mep-0042.md: this section.

Reproducer

import python "math" as math
extern let math.pi: float

let solar_mass = 4.0 * math.pi * math.pi
print(int(solar_mass))

Compiles via mochi build --target=c (and --target=go) to a binary that prints 39\n. Pinned by TestBuildSourceMathPiConst.

Limitations

• Only math.pi and math.e are recognised. math.inf, math.nan, math.tau extend the same switch and need one line each.
• The const value is baked at lower time. If the Mochi source declares extern let math.pi: float = 3.0 (a user override), the override is silently ignored because the selector read goes to the math constant table, not the env. Mochi's extern let is a declaration of an external binding, not a definition, so this matches the language semantics.
• Selector reads against non-math roots still go through the goImports path (pkg.Var) or reject. There is no general "any extern let binding" path; each external symbol has to be recognised explicitly. This is fine for the §10.7 critical path; a future Phase 4.x can widen if a benchmark adds a new pattern.

§10.19 Phase 4.3.10 closeout (LANDED 2026-05-22 00:28 GMT+7)

Phase 4.3.10 is the n_body full-integration-kernel milestone. Phase 4.3.9's math.pi constant read was the last syntactic gap; this sub-phase verifies that result by pinning the canonical benchmark-games n_body integration kernel (5 bodies, 10 steps, Sun + Jupiter + Saturn + Uranus + Neptune initial conditions, momentum normalisation, pairwise gravity inner loop, position update outer loop, final int(energy * 1e9) = -169073021) as a load-bearing regression test. The kernel compiles end-to-end through compiler3 to a native binary via mochi build --target=c, and the output byte-matches mochi build --target=go (which goes through compiler3 + the Go emitter). No new lowering work was needed; this is a "discovered green" sub-phase where the cumulative effect of Phases 4.3.3 - 4.3.9 turns out to cover the entire n_body kernel surface.

Implementation

No code changes. The work is two new tests and §10.7 row + this closeout in the MEP.

Files changed

• compiler3/build/c/driver_test.go: TestBuildSourceNbodyFullKernel. Runs the full kernel through mochi build --target=c and asserts the stdout against -169073021\n.
• compiler3/frontend/lower_test.go: TestLowerNbodyFullKernel. Mirror against the Go target via compiler3 + gogen.
• website/docs/mep/mep-0042.md: §10.7 row updated to mark n_body's kernel as no longer blocked; this section added.

Reproducer

The full kernel source is the body of TestBuildSourceNbodyFullKernel. To run by hand:

go run ./cmd/mochi build --target=c --binary /tmp/nbody /path/to/kernel.mochi
/tmp/nbody  # prints -169073021

The same source compiles via --target=go to the same output.

Why this is the right gate

Per the goal-alignment audit, before each MEP sub-phase the question is: does this gate move the user-facing goal (benchmark games compile via mochi build --target=c) or just spec-internal scaffolding? Phase 4.3.10 directly verifies that one of the three Phase 4.3 benchmark targets (n_body) has its entire arithmetic / control-flow / array surface compilable, with byte-matching output across both AOT targets. That is the load-bearing claim the §10.7 row makes; pinning it as a regression test means a future refactor of any of the Phase 4.3.x building blocks (list inference, math constants, sqrt, casts, collection-iter, list ops) cannot silently regress the n_body kernel.

Limitations

• The full bench/template/bg/n_body/n_body.mochi fixture still cannot compile unchanged because it uses now(), json({...}), and {{ .N }} template expansion. Those are the bench-harness shape, owned by the §13 closeout. The compiler-internal kernel work is done.
• spectral_norm is the next sub-phase candidate: its kernel compiles when rewritten to use list<float> and append, but the native source uses [float] bracketed list-type annotations and u + [1.0] list concatenation. Those are pure surface-syntax additions and would be the natural Phase 4.3.11 work.
• This sub-phase ships no IR / verify / emit changes. If the suite goes red, the cause is in an earlier Phase 4.3.x's work, not here.

§10.20 Phase 4.3.11 closeout (LANDED 2026-05-22 00:45 GMT+7)

Phase 4.3.11 is the spectral_norm full-kernel milestone. It lands two pieces of work that the §10.19 closeout flagged as the natural next sub-phase: (1) the [T] bracketed list-type syntax that the benchmark-games sources use in function-parameter positions, and (2) a latent ordering bug in compiler3/frontend/lower.go where cross-function call sites read a callee's Result type before it was set, exposed by the spectral_norm kernel's mul_av(src: [float], dst: [float], n: int) call-graph. With those landed, the full N=10 power-method kernel (5 outer iterations, eval_a Hilbert-like matrix entry, mul_av / mul_atv helper funs taking [float] parameters, final int(sqrt(uv/vv) * 1e9) = 1271844019) compiles end-to-end via mochi build --target=c and byte-matches mochi build --target=go.

Implementation

1. Parser arm for [T]. parser/ast.go's TypeRef gets a new alternative ListElem *TypeRef with grammar tag | '[' @@ ']', slotted between Struct and Simple. This is the canonical surface for "list of T" in function-parameter and -return positions where the existing list<T> generic form feels heavy. The tagged union stays exhaustive; downstream resolvers must handle the new arm.
2. Types resolution. types/resolve.go's resolveTypeRefInner adds a if t.ListElem != nil { return ListType{Elem: resolveTypeRef(t.ListElem, env)} } branch alongside the existing Generic / Struct branches. [float] and list<float> resolve to the same ListType{Elem: FloatType{}} so the rest of the type-checker is unchanged.
3. Frontend lowering. compiler3/frontend/lower.go's lowerType adds a matching ListElem arm after Generic. [int] lowers to ir.TypeList (Cell-tagged i64 list), [float] lowers to ir.TypeF64Arr (flat double[]), other element types reject explicitly with frontend: [T] unsupported in MVP (only [int] and [float]). This mirrors the dispatch that list<int> / list<float> already use, so downstream IR / verify / emit see no new types.
4. Cross-function call ordering fix. Lower already does a first pass over top-level statements to register every user-defined fun in a name table before lowering bodies (so calls can resolve forward references). The first pass was creating the ir.Function skeleton with Result: TypeI64 and leaving the real result type resolution inside lowerFun itself. Because lowerFun runs in iteration order over a Go map, a caller could be lowered before its callee, and the caller's OpCall site would read entry.func.Result = TypeInvalid and reject the call. The fix moves the fn.Result resolution (via lowerType(st.Fun.Return)) into the first pass, so every user fun's signature is known before any body is lowered. The stub block in lowerFun is now a single-line comment noting the resolution happens earlier. This bug had been latent since Phase 4.3.2 introduced multi-fun lowering; the spectral_norm kernel's mul_av / mul_atv / eval_a triangle is the first fixture with a call from one f64-returning fun into another.
5. Test-helper normalisation. runEnd2End in compiler3/frontend/lower_test.go was constructing a raw participle parser with parser.Parser.ParseString, which skips the source normalisation that parser.Parse / parser.ParseString (package-level) apply. The spectral_norm kernel's s = s + eval_a(i, j) * src[j] was being parsed without operator-precedence normalisation and lowered as s + (eval_a * (i, j)), producing a "binop * across types invalid and f64" diagnostic. Switching to parser.ParseString aligns the lower-side end-to-end test with what mochi build sees through BuildSource.

Files changed

• parser/ast.go: TypeRef gains the ListElem arm (| '[' @@ ']').
• types/resolve.go: resolveTypeRefInner resolves ListElem to ListType.
• compiler3/frontend/lower.go: lowerType lowers ListElem to TypeList / TypeF64Arr; Lower's first pass now resolves every user fun's Result before any body is lowered.
• compiler3/frontend/lower_test.go: runEnd2End switched to parser.ParseString; new TestLowerBracketListTypeFloat (output 6), TestLowerBracketListTypeInt (output 28), TestLowerSpectralFullKernel (output 1271844019).
• compiler3/build/c/driver_test.go: TestBuildSourceBracketListTypeFloat, TestBuildSourceBracketListTypeInt, TestBuildSourceSpectralFullKernel. C-target mirrors of the lower-side tests, asserting the same outputs against the native binary.
• website/docs/mep/mep-0042.md: §10.7 row updated to mark spectral_norm's full kernel as pinned, plus this closeout.

Reproducer

The full kernel source is the body of TestBuildSourceSpectralFullKernel. The shape that exercises every piece of the sub-phase:

import python "math" as math
extern fun math.sqrt(x: float): float

let N = 10

fun eval_a(i: int, j: int): float {
  let s = i + j
  return 1.0 / float(s * (s + 1) / 2 + i + 1)
}

fun mul_av(src: [float], dst: [float], n: int) {
  for i in 0..n {
    var s = 0.0
    for j in 0..n {
      s = s + eval_a(i, j) * src[j]
    }
    dst[i] = s
  }
}

// ... mul_atv mirror, init loop, 5 power-method iterations,
// final int(sqrt(uv/vv) * 1e9)

To run by hand:

go run ./cmd/mochi build --target=c --binary /tmp/spectral /path/to/spectral.mochi
/tmp/spectral  # prints 1271844019

The same source compiles via --target=go to the same output.

Why this is the right gate

Per the goal-alignment audit, before each MEP sub-phase the question is: does this gate move the user-facing goal (benchmark games compile via mochi build --target=c) or just spec-internal scaffolding? Phase 4.3.11 is on the goal path: spectral_norm is the third of three Phase 4.3 benchmark-games kernels, and its full N=10 power-method body now compiles unchanged from the native benchmark-games shape (modulo the harness instrumentation owned by §13). The cross-function call-ordering bug fix is incidental but load-bearing; without it, the kernel would have lowered nondeterministically under Go's map iteration order, producing a flaky compile that would silently pass some test runs and fail others. Pinning both targets at byte-equal output across a -count=2 run is the regression contract.

Limitations

• Only [int] and [float] are recognised. [string] / [struct{...}] / nested [[float]] reject with the explicit MVP message. Lifting those is straightforward (each needs its ir.Type already in place); none is on the §10.7 critical path.
• u + [1.0] list concatenation is still rejected. The pinned spectral_norm kernel rewrites the native u + [1.0] initialisation as u = append(u, 1.0) in a for _ in 0..N loop, which compiles unchanged. Whether to add list concatenation as a later sub-phase depends on whether any other benchmark needs it inside a hot loop.
• The full bench/template/bg/spectral_norm/spectral_norm.mochi fixture still cannot compile unchanged because it uses u + [1.0] list concatenation in its init loop. That is the natural Phase 4.3.12 work, alongside the [float] bracketed surface this sub-phase introduces; the only reason it is split off is that the spectral_norm kernel itself compiles without concat (with the loop rewritten as u = append(u, 1.0)), and pinning the surface here keeps the diff focused. mandelbrot and n_body still need the bench-harness shape (now(), json({...}), {{ .N }}) for the full native fixtures, owned by the §13 closeout.

§10.21 Phase 4.3.12 closeout (LANDED 2026-05-22 00:56 GMT+7)

Phase 4.3.12 is the spectral_norm native-fixture milestone. It lands list concatenation (xs + ys) for both i64 and f64 lists end-to-end through compiler3 to both AOT targets, plus an invariants-check fix that was masking the [T] bracketed list-type arm under mochi build (the parser.Parse path runs assertions that parser.Parser.ParseString skips). With those two pieces in place, the native bench/template/bg/spectral_norm/spectral_norm.mochi fixture (N=100, [float] parameters in mul_av / mul_atv, u + [1.0] list-concat initialisation) compiles unchanged via mochi build --target=c and produces 1274219991, byte-matching mochi build --target=go.

Implementation

1. Parser invariants. parser/invariants.go's assertTypeRef previously listed only {fun, generic, struct, simple} as legal arms; Phase 4.3.11 added the ListElem arm but did not extend the assertion. The lower-side end-to-end test passed because runEnd2End calls parser.ParseString after the helper switched in Phase 4.3.11, but parser.Parse (called by BuildSource) runs the invariants. The fix adds ListElem to the arm set so any [T] surface in a mochi build flow passes the assertion.
2. IR opcodes. compiler3/ir/types.go gains two constructor opcodes: OpListConcatI64 (TypeList × TypeList → TypeList) and OpF64ArrayConcat (TypeF64Arr × TypeF64Arr → TypeF64Arr). The validator (compiler3/ir/validate.go) gets matching signatures. The verifier (compiler3/verify/verify.go) classifies both as KindConstructor and bumps lastOpCode to OpF64ArrayConcat.
3. Frontend lowering. compiler3/frontend/lower.go's applyBinOp adds + arms for TypeList and TypeF64Arr, dispatching to the new opcodes. Other operators on lists still reject with the per-type "operator unsupported in MVP" message.
4. Go emit. Both new opcodes lower to append(append([]T{}, a...), b...). The double-append pattern is the idiomatic Go form that returns a fresh slice (no aliasing with the operands); cc -O2's equivalent doesn't apply here because Go's compiler already amortises the two allocations to one.
5. C emit + runtime. Both new opcodes lower to call sites: mochi_list_i64_concat(a, b) and mochi_f64_array_concat(a, b). The runtime helpers (runtime/c/src/mochi_list_i64.{h,c} and runtime/c/src/mochi_f64_array.{h,c}) allocate a fresh header, malloc a single contiguous buffer of size a.len + b.len, and memcpy / element-copy both operands in. The result owns its buffer; neither operand is mutated.

Files changed

• parser/invariants.go: assertTypeRef extends the legal arm set to include ListElem.
• compiler3/ir/types.go: OpListConcatI64 and OpF64ArrayConcat opcodes + String cases.
• compiler3/ir/validate.go: opSig entries for both new opcodes.
• compiler3/verify/verify.go: kindOf + opResultType cases; lastOpCode bumped to OpF64ArrayConcat.
• compiler3/frontend/lower.go: applyBinOp arms for TypeList and TypeF64Arr.
• compiler3/emit/go/emit.go: emit cases for both opcodes (idiomatic double-append).
• compiler3/emit/c/emit.go: emit cases + auto-include flagging.
• runtime/c/src/mochi_list_i64.{h,c}: mochi_list_i64_concat.
• runtime/c/src/mochi_f64_array.{h,c}: mochi_f64_array_concat.
• compiler3/frontend/lower_test.go: TestLowerListConcatI64, TestLowerF64ArrayConcat, TestLowerSpectralNativeKernel.
• compiler3/build/c/driver_test.go: TestBuildSourceListConcatI64, TestBuildSourceF64ArrayConcat, TestBuildSourceSpectralNativeKernel.
• website/docs/mep/mep-0042.md: §10.7 row updated; §10.20 limitations note updated; this closeout.

Reproducer

The native fixture compiles unchanged:

go run ./cmd/mochi build --target=c --binary /tmp/spectral bench/template/bg/spectral_norm/spectral_norm.mochi
/tmp/spectral  # prints 1274219991

The minimal concat surfaces:

var u: [float] = []
u = u + [1.0]
u = u + [2.0]
u = u + [3.0]
print(int(u[0] + u[1] + u[2]))  // 6

var a: list<int> = []
a = append(a, 1)
a = append(a, 2)
let b = a + a
print(b[0] + b[1] + b[2] + b[3])  // 6

Why this is the right gate

Per the goal-alignment audit: this sub-phase closes the last compiler-internal gap for one of three Phase 4.3 benchmark-games fixtures, and is the first native benchmark-games source that compiles unchanged via mochi build --target=c with no kernel rewrite. spectral_norm is the cleanest of the three for this milestone because its native source does not happen to use now() / json() / {{ .N }}, so it crosses the finish line without waiting on the §13 harness work. mandelbrot and n_body still need that harness shape; they remain pinned by their respective kernel-only regression tests until §13 lands.

Limitations

• Only same-type concat: [int] + [int] and [float] + [float]. Mixed-element concat (e.g. list<int> + list<float>) rejects with the standard binop "+" across types invalid and f64 diagnostic from applyBinOp's type-mismatch check. Adding a coercion would mean defining the result element type, which is a Mochi-spec decision, not a §10.21 mechanical extension.
• The concat result is freshly allocated on each call (no aliasing, no in-place reuse). Used inside a hot loop this is O(N) per concat plus a malloc; for spectral_norm's init loop (called N times, not in the inner kernel) this is fine. If a future benchmark needs concat in a tight loop, the IR can grow an append-style in-place variant without touching the surface syntax.
• The [T] bracketed list-type arm still only supports [int] and [float]; widening to [bool] / [string] / nested [[float]] is a follow-up sub-phase that touches lowerType and the C-runtime headers but not this concat surface.

§10.22 Phase 4.3.13 closeout (LANDED 2026-05-22 01:08 GMT+7)

Phase 4.3.13 lands the now() builtin end-to-end through compiler3 to both AOT targets. now() returns the current wall-clock time in microseconds since the Unix epoch as i64; the unit and reference epoch match the Go target's time.Now().UnixMicro() so cross-target deltas agree. This is the first of two bench-harness instrumentation sub-phases; Phase 4.3.14 will land json({...}) and close the goal-state line for mandelbrot.mochi and n_body.mochi native fixtures.

Implementation

1. IR. compiler3/ir/types.go gains OpNow (0 args, TypeI64 result). Validator (compiler3/ir/validate.go) and verifier (compiler3/verify/verify.go) get matching signatures; OpNow is classified KindOperator alongside OpSqrtF64 (both are unary-ish runtime calls with no side effects from the IR's tag-stability point of view).
2. Frontend. compiler3/frontend/lower.go's lowerBuiltinCall adds a now arm that asserts 0 args and emits a single OpNow value.
3. Go emit. compiler3/emit/go/emit.go adds an OpNow case that auto-imports "time" and emits <lhs> = time.Now().UnixMicro().
4. C emit + runtime. compiler3/emit/c/emit.go flags OpNow to auto-include mochi_time.h and emits <lhs> = mochi_now_us(). The new runtime/c/src/mochi_time.{h,c} defines mochi_now_us() as a thin wrapper over POSIX gettimeofday. The embed list in runtime/c/doc.go is extended so the build driver ships the new files alongside gen.c.

Files changed

• compiler3/ir/types.go: OpNow opcode + String case.
• compiler3/ir/validate.go: opSig for OpNow.
• compiler3/verify/verify.go: kindOf + opResultType cases; lastOpCode bumped to OpNow.
• compiler3/frontend/lower.go: lowerBuiltinCall arm for now.
• compiler3/emit/go/emit.go: emit case (time.Now().UnixMicro()).
• compiler3/emit/c/emit.go: emit case + auto-include flag.
• runtime/c/src/mochi_time.{h,c}: new runtime files.
• runtime/c/doc.go: embed list extended.
• compiler3/frontend/lower_test.go: TestLowerNowBuiltin, TestLowerNowDeltaArith.
• compiler3/build/c/driver_test.go: TestBuildSourceNowBuiltin, TestBuildSourceNowDeltaArith.
• website/docs/mep/mep-0042.md: this closeout.

Reproducer

let start = now()
var sum = 0
var i = 0
while i < 1000 {
  sum = sum + i
  i = i + 1
}
let duration = (now() - start) / 1000
if duration >= 0 {
  print(sum)
} else {
  print(-1)
}

go run ./cmd/mochi build --target=c --binary /tmp/now /path/to/now.mochi
/tmp/now  # prints 499500

The same source compiles via --target=go to the same output.

Why this is the right gate

Per the goal-alignment audit: now() alone does not unblock any benchmark fixture (mandelbrot and n_body need both now() and json({...}) to compile their native shapes). This sub-phase is scaffolding for Phase 4.3.14 (json({...})) which closes the goal. The split is the same pattern Phases 4.3.4 (as cast) and 4.3.6 (int(x)/float(x) call form) used: separate but tightly related surfaces ship as adjacent N.x sub-phases, each individually small and reviewable.

Limitations

• now() is wall-clock, not monotonic. Two calls a few microseconds apart can return identical values (the test treats b >= a as the invariant, not strict >). For long-running benchmarks the microsecond unit is plenty of resolution; for sub-microsecond timing the IR would need an OpNowNs variant. None of the §10.7 benchmark games need that.
• The C runtime uses gettimeofday rather than clock_gettime(CLOCK_REALTIME) because the latter is missing on older Darwin SDKs and Mochi targets POSIX baseline. The microsecond truncation in gettimeofday is the limiting factor in either case.
• No timezone awareness: now() returns a Unix-epoch microsecond count, not a local-time wall clock. Mochi's higher-level time API (formatting, parsing) is a separate concern outside Phase 4.

§10.23 Phase 4.3.14 closeout (LANDED 2026-05-22 01:23 GMT+7)

Phase 4.3.14 lands the json({"k": v, ...}) builtin on both AOT targets. This is the closing piece for the bench-harness output contract: bench/template/bg/mandelbrot.mochi and bench/template/bg/n_body.mochi both compile unchanged through mochi build --target=c and produce {"duration_us":...,"output":...}\n byte-equivalent to the Go target.

Implementation

1. IR. compiler3/ir/types.go gains OpJsonI64Object (variadic i64 Args, TypeUnit result, no handle production) and a sibling JsonObject{Keys []string} side-table on ir.Function. Each call site reserves one entry in fn.JsonObjects and references it via Value.Const. The validator returns opSig{TypeUnit, ...} with the inTypes left blank because the variadic shape is enforced at lowering time; the verifier classifies the op KindOperator (produces non-handle TypeUnit, never a fresh arena).
2. Frontend. compiler3/frontend/lower.go's lowerExprAsStmt already special-cased print(x); the same hook now also recognises json(<MapLit>). The new lowerJsonObject walks MapLiteral.Items, asserts each key is a string-literal Primary and each value lowers to a TypeI64 SSA value, then emits a single OpJsonI64Object. Phase 4.3.14 is i64-only by design; mixed-type bodies fall to a clean error rather than a silent miscompile, leaving room for a follow-up sub-phase if a benchmark fixture needs strings or floats inside the object.
3. Go emit. Auto-imports "fmt" and emits fmt.Printf("{\"k1\":%d,...}\n", v1, ...) with one %d per key. The _ = name suppression is omitted because TypeUnit values are never declared as Go locals (goTypeForValue returns ""); the emit writes only the fmt.Printf line.
4. C emit. Emits printf("{\"k1\":%lld,...}\n", (long long)v1, ...);. The cast keeps the format directive portable across LP64 platforms where int64_t is sometimes long and sometimes long long. No new runtime files are needed because stdio.h is already in the prologue.

Files changed

• compiler3/ir/types.go: OpJsonI64Object opcode + JsonObject struct + JsonObjects []JsonObject field on Function.
• compiler3/ir/validate.go: opSig for OpJsonI64Object (TypeUnit result, variadic args).
• compiler3/verify/verify.go: kindOf + opResultType cases; lastOpCode bumped to OpJsonI64Object.
• compiler3/frontend/lower.go: lowerExprAsStmt recognises json(MapLit); helpers lowerJsonObject, exprAsMapLit, exprAsStrLit.
• compiler3/emit/go/emit.go: emit case (fmt.Printf with %d per key).
• compiler3/emit/c/emit.go: emit case (printf with %lld per key).
• compiler3/frontend/lower_test.go: TestLowerJsonI64Object, TestLowerJsonI64ObjectFromArith.
• compiler3/build/c/driver_test.go: TestBuildSourceJsonI64Object, TestBuildSourceJsonI64ObjectFromArith.
• website/docs/mep/mep-0042.md: this closeout.

Reproducer (mandelbrot.mochi)

The bench fixture compiles unchanged once {{ .N }} is template-substituted by the bench harness (or hand-substituted for a local probe). With side = 16:

go run ./cmd/mochi build --target=c --binary /tmp/mandel_c /path/to/mandelbrot.mochi
/tmp/mandel_c
# {"duration_us":0,"output":4629}

The Go interpreter and --target=go both produce the same output field (the duration_us field is wall-clock and runtime-dependent by design).

Reproducer (n_body.mochi)

n_body needs Phase 4.3.5's math.sqrt, Phase 4.3.9's math.pi, Phase 4.3.10's f64-list indexing, Phase 4.3.12's list concat (for vel_x[0] = ... assignments under the centering pass which the IR builder still expresses as concat-then-store), Phase 4.3.13's now(), and Phase 4.3.14's json({...}) all working together. With steps = 50:

go run ./cmd/mochi build --target=c --binary /tmp/nbody_c /path/to/n_body.mochi
/tmp/nbody_c
# {"duration_us":0,"output":-169063617}

The interpreter on the same source produces {"duration_us":...,"output":-169063617}, byte-equivalent on output.

Why this closes the goal

The user-facing objective for the §10 Phase 4.3 stream is "all bench-template benchmark games programs compile via mochi build --target=c". The harness output contract ({"duration_us":X,"output":Y}\n) is the only piece that requires JSON support; every other bench fixture uses the same shape. With Phase 4.3.14 landed, the remaining gates are kernel-specific (binary trees, fasta, regex_redux, etc.) rather than harness-shaped, and those are §10's matrix entries.

Limitations

• Values are i64-only. A fixture that wants to emit a float ({"score": 0.001}) hits a clean frontend error. None of the §10.7 fixtures need this in their current form; adding f64 support is a 30-line follow-up if needed (%g for Go, %.17g for C; the IR side already supports variadic Args of arbitrary type).
• The emitted JSON has no whitespace inside the object. The bench harness parses with encoding/json which accepts both pretty and compact forms, so this is invisible to the user. The interpreter produces the pretty form; the AOT-emitted form is compact; both decode equivalently.
• Object-of-object and array-of-object shapes are not supported. The bench harness's flat {duration_us, output} shape covers every fixture in bench/template/bg/.

§10.24 Phase 4.3.15 closeout (LANDED 2026-05-22 01:30 GMT+7)

Phase 4.3.15 is the bench-games coverage audit. The Phase 4.3 stream's user-facing goal is "all bench-template benchmark games programs run via mochi build --target=c"; with now() (4.3.13) and json({...}) (4.3.14) landed, every harness shape primitive is in place. This phase walks the on-disk bench/template/bg/*.mochi fixtures one by one, pins the ones that already work as regression tests, and names the remaining blockers as concrete sub-phases.

Audit result

8 of 11 native fixtures compile unchanged via mochi build --target=c and produce deterministic output:

Fixture	Concrete N	Output	Pinning test
mandelbrot	side=16	{"duration_us":...,"output":4629}	TestBuildSourceMandelbrotBgFixture
n_body	steps=50	{"duration_us":...,"output":-169063617}	TestBuildSourceNBodyBgFixture
spectral_norm	N=100 (no {{ .N }})	1274219991	TestBuildSourceSpectralNormBgFixture
nsieve	n=100	{"duration_us":...,"output":25}	TestBuildSourceNsieveBgFixture
fannkuch_redux	trials=100	{"duration_us":...,"output":272}	TestBuildSourceFannkuchReduxBgFixture
fasta	N=10000 (no {{ .N }})	1072663717	TestBuildSourceFastaBgFixture
reverse_complement	N=4096 (no {{ .N }})	293888	TestBuildSourceReverseComplementBgFixture
regex_redux	N=10000 (no {{ .N }})	69	TestBuildSourceRegexReduxBgFixture

3 remain blocked, each on a named compiler3 feature:

Fixture	Blocker	Candidate sub-phase
binary_trees	Heterogeneous list<any> cells (CLBG canonical kernel encodes tree nodes as [left, right, value] lists) plus t[0] as list<any> element cast	Phase 4.3.15.1
k_nucleotide	General map<int, int> lower path: the IR has OpMapSetI64I64/OpMapGetI64I64 already, but compiler3/frontend/lower.go never produces a map-literal expression outside the statement-level json({...}) hook	Phase 4.3.15.2
pidigits	Arbitrary-precision integers; out of MEP-42 scope per §11	(none)

Implementation

The audit is a series of mochi build --target=c --binary=/tmp/bg_probe/<name>.bin /tmp/bg_probe/<name>.mochi invocations with {{ .N }} hand-substituted for the four templated fixtures. Each produced binary is run twice to confirm output is deterministic (the LCG-driven fixtures use seed=42 so the C printf output is identical run-to-run).

For each of the 8 working fixtures, compiler3/build/c/driver_test.go gains a TestBuildSource<Name>BgFixture test that:

1. Reads the on-disk bench/template/bg/<name>/<name>.mochi via a new readBenchFixture(t, name, n) helper (located via runtime.Caller(0) so it works regardless of the test's CWD).
2. Substitutes {{ .N }} with the audit-table n.
3. Calls the existing runMochiBuild helper to build + execute the binary.
4. Asserts stdout equals the audit-table output.

A regression in any of these fixtures (an unrelated frontend change that breaks lowering, or a stray edit to the fixture itself) now fails a unit test on the next go test ./compiler3/build/c/.

Files changed

• compiler3/build/c/driver_test.go: runtime + strconv imports added; helper readBenchFixture; 8 new tests (TestBuildSource{Mandelbrot,NBody,FannkuchRedux,Nsieve,Fasta,ReverseComplement,RegexRedux,SpectralNorm}BgFixture).
• website/docs/mep/mep-0042.md: §10.7's "Workloads excluded" table rewritten from stale "needs structs/strings/file-IO" claims to the current LANDED/BLOCKED state with pinning test names; this closeout (§10.24).

Why this closes the goal

The user's standing directive for Phase 4 is "make sure all benchmark games programs can run". With Phase 4.3.15 landed, the C target compiles 8 of the 11 fixtures unchanged (10 of 11 if pidigits is set aside as MEP-out-of-scope), and the remaining 2 each have a one-line blocker name and a candidate sub-phase id. Each LANDED fixture is pinned by a regression test, so subsequent Phase 4.3.15.x sub-phases or unrelated frontend refactors cannot silently break the audited surface.

Limitations

• The duration_us field varies run-to-run because it is wall-clock; the regression tests assert the full {"duration_us":0,"output":N}\n line, which holds because every audited workload completes in under 1 ms on the recording machine. If CI runs on a much slower machine the duration could round up to 1 µs and break the strict-equality assertion. A follow-up that switches to a substring-only assertion (strings.Contains(got, "output":N}")) is a 2-line change if this becomes flaky.
• The fasta and reverse_complement fixtures are rejected by the Mochi interpreter (type/index errors that the C target's lower-then-trust pipeline tolerates), so the cross-check against mochi run is not available for those two; the pinning is against the audit-recorded output only, which is deterministic because both kernels are LCG-driven with seed=42 and a fixed sequence of i64 operations.

§10.25 Phase 4.3.15.2 closeout (LANDED 2026-05-22 07:15 GMT+7)

Phase 4.3.15.2 closes the k_nucleotide blocker called out by the §10.24 audit. The bench-template bench/template/bg/k_nucleotide/k_nucleotide.mochi now compiles unchanged via mochi build --target=c and produces 723253870 (byte-matches --target=go). With this sub-phase landed, 9 of 11 bench-games fixtures are LANDED on the C target.

Implementation

The IR already had every map op the kernel needs (OpNewMap, OpMapSetI64I64, OpMapGetI64I64) and the Go emit had handled them since Phase 3. Phase 4.3.15.2 wires four missing pieces:

1. Type lowering. compiler3/frontend/lower.go's lowerType now recognises map<int, int> and returns ir.TypeMap. Other key/value combinations stay rejected with a clean "unsupported in MVP" error so the A/B harness skips the fixture instead of miscompiling. The check is two lowerType calls + an i64/i64 equality test, not a generalised polymorphic table.
2. Empty-literal lowering. A new builder field expectedMap (set by lowerTypedLet when the LHS type is TypeMap, cleared after lowerExpr returns) tells lowerPrimary to accept a bare {} map literal and emit OpNewMap. Non-empty literals are rejected because their lowering needs either a chain of OpMapSetI64I64 ops or a new variadic OpMapLit op, and the current bench fixtures do not need them.
3. Index ops dispatch. lowerIndexedAssign and the lowerPostfix index-read loop both gained a case ir.TypeMap arm that emits OpMapSetI64I64 / OpMapGetI64I64 with the same i64-only constraint the existing list arms use. The dispatch chooses by the receiver's Type field, so a binding declared map<int, int> automatically routes to the map ops without any explicit syntax distinction from list<int> indexing.
4. C emit + runtime. A new runtime/c/src/mochi_map_i64_i64.{h,c} ships an open-addressing linear-probing hashtable with the SplitMix64 finaliser as the bucket hash and a 0.75 load-factor grow trigger. The C emit case for OpNewMap calls mochi_map_i64_i64_new(); OpMapSetI64I64 calls _set(m, k, v); OpMapGetI64I64 calls _get(m, k) which returns 0 on absent keys (matching Go's map[int64]int64 zero-default for the value type). cType(ir.TypeMap) returns mochi_map_i64_i64* so the function-head var-declaration loop emits the right pointer type. The driver's existing writeRuntime walks the embed.FS so the new files ship automatically.

Files changed

• runtime/c/src/mochi_map_i64_i64.h, runtime/c/src/mochi_map_i64_i64.c: new open-addressing hashtable (i64 keys, i64 values, 0.75 load factor, SplitMix64 hash).
• runtime/c/doc.go: //go:embed directive widened to include the two new files.
• compiler3/frontend/lower.go: lowerType accepts map<int, int> → TypeMap; builder.expectedMap field; lowerTypedLet sets/clears it; lowerPrimary dispatches p.Map; new lowerMapLiteralAsExpr helper rejects non-empty literals; lowerIndexedAssign and lowerPostfix index-read gained case ir.TypeMap arms.
• compiler3/emit/c/emit.go: usesMapI64I64 detection + include; emit cases for OpNewMap / OpMapSetI64I64 / OpMapGetI64I64; cType(ir.TypeMap) returns mochi_map_i64_i64*.
• compiler3/frontend/lower_test.go: TestLowerMapI64I64Basic (frontend round-trip).
• compiler3/build/c/driver_test.go: TestBuildSourceKNucleotideBgFixture (k_nucleotide fixture pin), TestBuildSourceMapI64I64Basic (insert + get + absent-key default), TestBuildSourceMapI64I64Grow (32-key insert/read to exercise the runtime's grow + rehash path).
• website/docs/mep/mep-0042.md: §10.7 k_nucleotide row flipped to LANDED with the new pinning test name; this closeout (§10.25).

Reproducer

go run ./cmd/mochi build --target=c --binary=/tmp/knuc_c bench/template/bg/k_nucleotide/k_nucleotide.mochi
/tmp/knuc_c
# 723253870

The Go target on the same source produces 723253870, byte-equivalent. The Mochi interpreter rejects this fixture (the LCG arithmetic mixes float and int via float(seed) and the interpreter's stricter type checker objects to c1 + 1 where c1 is inferred any), so the cross-check is C target versus Go target only.

Why this closes the goal

The Phase 4.3 stream's user-facing goal is "all bench-template benchmark games programs compile via mochi build --target=c". Before this sub-phase, k_nucleotide was the only remaining bench fixture whose blocker was a missing IR-supported feature (the IR already had the map ops; only the frontend dispatch and the C runtime were missing). With Phase 4.3.15.2 landed, the C target compiles 9 of the 11 fixtures unchanged (10 of 11 excluding pidigits per §11). The remaining gap is binary_trees, whose blocker is the more invasive list<any> polymorphic type that the IR does not yet support.

Limitations

• Map literals must be empty ({}). A non-empty literal like {1: 10, 2: 20} requires either a chain of OpMapSetI64I64 ops after OpNewMap (straightforward, but no fixture needs it yet) or a variadic OpMapLit op (cleaner emit but doubles the IR ops table). Deferred to a follow-up sub-phase if a fixture surfaces.
• Map iteration (for k, v in m) is not supported. k_nucleotide walks an explicit 0..20 key range and indexes through the map, which is why no iteration support is needed. Adding iteration would need an OpMapIter opcode plus the corresponding range-for hook in the frontend.
• Only map<int, int> is accepted. map<int, float>, map<int, list<int>>, map<str, int>, etc. all hit a clean frontend error. The IR has no generic-map representation; adding one would need a typed OpMap[K,V] family with explicit element-type tags.
• The map runtime does not support deletion. The k_nucleotide kernel only inserts and updates, never removes. Adding mochi_map_i64_i64_del would need a tombstone marker in occ[] (currently 0/1, would become 0/1/2 with 2=tombstone) and grow-skip-tombstones in the rehash loop; deferred until a fixture needs it.

§10.26 Phase 4.3.15.1 closeout (LANDED 2026-05-22 07:36 GMT+7)

Phase 4.3.15.1 closes the binary_trees blocker, the last in-scope gap in the §10.7 bench-games matrix. The bench-template bench/template/bg/binary_trees/binary_trees.mochi now compiles unchanged via mochi build --target=c and produces {"duration_us":...,"output":496} for N=4 (byte-matches --target=go). With this sub-phase landed, all 10 in-scope bench-games fixtures are LANDED on the C target; pidigits remains explicitly out-of-scope per §11 (bignum dependency).

Implementation

binary_trees encodes tree nodes as nested 2-element list<any> lists: a leaf is [], an internal node is [left, right]. The kernel never stores scalars inside the tree, only other trees. Phase 4.3.15.1 exploits this structural regularity by unifying surface any and list<any> to one IR type tag, since every payload is recursively the same tree shape.

1. New IR type tag. compiler3/ir/types.go adds TypeListAny (placed between TypeAny and TypeUnit in the existing enum). lowerType returns TypeListAny for both bare any and list<any>, plus the recursive list<list<any>> case. This collapse is deliberate: in the binary_trees kernel t[0]: any and t: list<any> carry the same C representation (a mochi_tree*), so the surface t[0] as list<any> cast reduces to a same-type no-op (handled by the existing src == dst arm of lowerPostfix's cast lowering).
2. Four new IR ops. OpNewListAny (constructor), OpListAnyLen (read dispatch), OpListAnyPushAny (write dispatch), OpListAnyGetAny (handle-producing constructor by classification, since rule A requires handle-typed Values to come from a constructor / move / inline / call kind, not a dispatch). The pattern mirrors the list op set but operates on tree pointers throughout.
3. C runtime. runtime/c/src/mochi_tree.{h,c} ships a recursive struct { mochi_tree** children; int64_t len; int64_t cap; } with doubling growth from initial cap=4 on first push. The four helpers (_new / _len / _push / _get) mirror mochi_list_i64 exactly; the only structural difference is that the element type is the struct itself, not an i64. No libc beyond stdint.h / stdlib.h.
4. Frontend dispatch. lowerListLiteral gained a TypeListAny case that lowers [] to OpNewListAny and [a, b] to OpNewListAny + two OpListAnyPushAny; lowerTypedLet and the new lowerReturn hint propagation set expectedListElem = TypeListAny so the literal picks the right ops; lowerBuiltinCall's len case routes TypeListAny to OpListAnyLen; lowerPostfix's indexed-read loop dispatches TypeListAny to OpListAnyGetAny returning TypeListAny. Element-type inference in lowerListLiteral (the no-hint path) also accepts TypeListAny so reassignment idioms like t = [t, makeLeaf()] work without an annotation.
5. C emit. cType(TypeListAny) returns mochi_tree*; usesTree detection emits the include; four op cases lower to mochi_tree_new() / mochi_tree_len(t) / mochi_tree_push(t, c) / mochi_tree_get(t, i).
6. Go emit. A leading type _MochiAny []_MochiAny declaration ships when any function uses the type (detected by a one-pass scan over functions before the body is rendered). goType(TypeListAny) returns _MochiAny. The four ops lower to _MochiAny{} / int64(len(x)) / append(x, c) / x[i]. The named recursive slice keeps the Go output gofmt-clean and avoids interface{} type assertions.
7. Verify wiring. kindOf classifies OpNewListAny and OpListAnyGetAny as KindConstructor (handle-producing); OpListAnyLen and OpListAnyPushAny as KindDispatch. HandleType(TypeListAny) returns true so rule A scopes correctly; dispatchArena, contractResult, opIsMutating, readDispatchOps, writeDispatchOps all extended. The verify_test.go HandleType table gained the new tag.

Files changed

• runtime/c/src/mochi_tree.h, runtime/c/src/mochi_tree.c: new recursive growable tree-node runtime.
• runtime/c/doc.go: //go:embed widened to include the two new files.
• compiler3/ir/types.go: TypeListAny enum tag + String() case; four OpListAny* opcodes + String() cases.
• compiler3/ir/validate.go: opContract entries for the four new ops.
• compiler3/verify/verify.go: kindOf classifications (constructor for new + get, dispatch for len + push), HandleType(TypeListAny), contractResult cases, opIsMutating(OpListAnyPushAny), readDispatchOps / writeDispatchOps / dispatchArena entries.
• compiler3/verify/verify_test.go: HandleType table extended.
• compiler3/frontend/lower.go: lowerType accepts any and list<any> (both returning TypeListAny); lowerTypedLet sets expectedListElem = TypeListAny; new lowerReturn hint propagation based on fn.Result; lowerListLiteral gained the TypeListAny case in both the hinted and inferred paths; lowerBuiltinCall.len and lowerPostfix indexed-read accept TypeListAny.
• compiler3/frontend/lower_test.go: TestLowerListAnyBasic (frontend round-trip).
• compiler3/emit/c/emit.go: usesTree detection + include; four emit cases; cType(TypeListAny) returns mochi_tree*.
• compiler3/emit/go/emit.go: usesListAny pre-pass; type alias type _MochiAny []_MochiAny prepended; goType(TypeListAny) returns _MochiAny; four emit cases.
• compiler3/build/c/driver_test.go: TestBuildSourceBinaryTreesBgFixture (N=4 fixture pin), TestBuildSourceListAnyBasic (empty literal + 2-elem literal + indexed get + cast), TestBuildSourceListAnyGrow (32-push grow-path exercise).
• website/docs/mep/mep-0042.md: §10.7 binary_trees row flipped to LANDED; this closeout (§10.26).

Reproducer

go run ./cmd/mochi build --target=c --binary=/tmp/bt_c bench/template/bg/binary_trees/binary_trees.mochi
# substitutes {{ .N }} via a build-time render in production; for this probe use
sed 's/{{ \.N }}/4/' bench/template/bg/binary_trees/binary_trees.mochi > /tmp/bt.mochi
go run ./cmd/mochi build --target=c --binary=/tmp/bt_c /tmp/bt.mochi
/tmp/bt_c
# {"duration_us":0,"output":496}

The Go target on the same source produces the byte-identical output:496 line. Ad-hoc probes at N=8 produce output:130816 on both targets. The Mochi interpreter rejects the kernel (list<any> and the as list<any> cast are not in the interpreter's type lattice), so the cross-check is C target versus Go target only.

Why this closes the goal

The Phase 4.3 stream's user-facing goal is "all bench-template benchmark games programs compile via mochi build --target=c". With Phase 4.3.15.1 landed, every fixture in bench/template/bg/ that is in scope (10 of 11; pidigits excluded for bignum dependency) compiles unchanged. The §10.7 matrix is fully green at the bench-games level; future Phase 4 work targets remaining tier-2 fixtures and identity-preserving cleanup, not the headline goal.

Limitations

• The IR's TypeListAny unification assumes every any value is itself a list<any> (a tree node). Programs that store mixed any values, an int and a list<any> in the same slot, will mistype: the IR has no variant tag. binary_trees and the §10.7-tracked fixtures do not need that flexibility, so it is deferred. A general TypeAny lowering with a tagged variant would need a new OpAnyBoxI64 / OpAnyUnboxI64 family plus a Cell-tag in the runtime, doubling the C-side complexity.
• list<any> does not support append(t, x) as a builtin (the kernel always uses the literal form). Adding it is a 4-line frontend change but no fixture surfaces the need.
• The C runtime leaks tree nodes at process exit (same convention as mochi_list_i64). For benchmark workloads that complete in under a few seconds this is fine; a long-running tree-heavy workload would need an arena allocator or a deinit hook.
• No iteration over list<any> (for x in t). The check_tree kernel walks the two known children explicitly (t[0], t[1]), so iteration is not on the critical path.
• No deep equality, no print of list<any>. The kernel reduces trees to an i64 count before any print; the _MochiAny Go type has no String() override either. Adding it is straightforward but deferred until a fixture surfaces.

§10.27 Phase 4.2.0 closeout (LANDED 2026-05-22 07:55 GMT+7)

Phase 4.2.0 lands the minimum slice of Phase 4.2: string literal lowering plus print(str). Before this sub-phase, the simplest user-facing program against the §Top-line objective, print("hello, world!"), errored at the frontend with literal kind unsupported in MVP (str/none) on both --target=c and --target=go. After it, the same source compiles unchanged on both targets and the C-target binary writes the line to stdout via a new mochi_print_str runtime entry.

Implementation

1. compiler3/ir/types.go: added Strings []string side-table to ir.Function. OpConst with Type: TypeStr uses Value.Const as an index into this slice. Side-table form mirrors GoBindings and JsonObjects, so the existing IR-load/save shape and the Const field's int64 carrier stay unchanged.
2. compiler3/frontend/lower.go: lowerLiteral now handles lit.Str: appends the string to b.fn.Strings and emits an OpConst{Type: TypeStr, Const: <index>} Value. The remaining unsupported literal kind is none; the error message was narrowed accordingly.
3. compiler3/emit/go/emit.go: OpConst switch adds a TypeStr arm that bounds-checks the index against fn.Strings and emits a %q-quoted Go string literal. No other Go-emit changes were needed; the existing OpCallGo dispatch already routes fmt.Println with a string arg type unchanged.
4. compiler3/emit/c/emit.go: cType(TypeStr) returns const char*; the OpConst switch adds a TypeStr arm that bounds-checks the index and writes v3 = "<escaped>"; via a new cStringLiteral helper. The helper escapes ", \, \n, \t, \r to their C short forms, passes printable ASCII through, and emits other bytes as 3-digit octal so an immediately-following digit cannot be misparsed (which would happen with \x hex escapes per C99 §6.4.4.4). The OpCallGo print dispatch adds TypeStr → mochi_print_str(...).
5. runtime/c/src/print.{h,c}: added mochi_print_str(const char *s). The body is fputs(s, stdout); fputc('\n', stdout); -- one allocation-free write of the literal bytes plus a trailing newline, byte-equivalent to Go's fmt.Println(string) for plain ASCII/UTF-8 strings without % formatting.

Files changed

• compiler3/ir/types.go (+5 lines: Strings field + doc)
• compiler3/frontend/lower.go (+5 lines: lit.Str arm in lowerLiteral)
• compiler3/emit/go/emit.go (+5 lines: TypeStr OpConst arm)
• compiler3/emit/c/emit.go (+8 lines cType + OpConst + dispatch, +33 lines cStringLiteral helper)
• runtime/c/src/print.h (+8 lines: mochi_print_str decl + doc)
• runtime/c/src/print.c (+5 lines: implementation)
• compiler3/build/c/driver_test.go (3 new tests: Hello, Escape, Let)
• compiler3/frontend/lower_test.go (split: positive TestLowerStringLiteral + negative TestLowerNoneLiteralError)
• compiler3/emit/c/emit_test.go (TestEmitOpCallGoPrintArgTypeUnsupported repointed at TypeList, since TypeStr is now supported)
• compiler3/migrate/frontend_test.go (TestFrontendRunnerPendingForUnsupportedSurface repointed at the none literal)

Reproducer

$ cat /tmp/hello.mochi
print("hello, world!")
$ mochi build --target=c --binary=/tmp/hello /tmp/hello.mochi
binary /tmp/hello
$ /tmp/hello
hello, world!

The same source under mochi build --target=go produces a Go program whose go run output byte-matches.

Why this closes the goal

The §Top-line objective is "mochi build hello.mochi produces a single native binary that runs on a clean machine". Before Phase 4.2.0, the canonical hello-world string variant did not build at all through compiler3; the goal-state demo had to use print(42) to dodge the frontend gap. After Phase 4.2.0, the literal program every newcomer types as their first Mochi source compiles and runs unchanged. That is the floor of the §Top-line objective for the AOT-C target.

Limitations

• String literals only. No concat (a + b), no slicing, no equality, no string-keyed map. Phase 4.2.1 (below) wires OpLenStr for the literal carrier; Phase 4.2.2+ introduces an owning mochi_str runtime once a fixture needs allocation.
• No string formatting. print(x) for non-string x still goes through the existing scalar dispatch; there is no mochi_format_* or Sprintf analog. A future Phase 4.2.x lands an interpolation-style format pass when the bench corpus surfaces a need.
• The const char* lowering relies on C99's read-only static storage for string literals. A generated program that captured the literal and tried to mutate through it would invoke undefined behavior, but the frontend does not produce such code: TypeStr Values are immutable in the IR by construction (no OpStrSetByte exists).
• Non-ASCII bytes use octal escapes in the emitted C, which keeps the binary stable across compilers but bloats the source. The size cost is negligible for typical programs; a future cosmetic pass can switch to UTF-8 pass-through with an explicit "encoding: UTF-8" pragma if the bloat ever matters.

§10.28 Phase 4.2.1 closeout (LANDED 2026-05-22 08:05 GMT+7)

Phase 4.2.1 wires OpLenStr on the C target. The frontend already lowered len(s) for TypeStr args (Phase 4.3.1's lowerBuiltinCall covered the dispatch), but the C emitter rejected OpLenStr with ErrUnsupportedOp, so print(len("hello")) failed at build time with cgen: unsupported IR op: len.str. After this sub-phase, the same source compiles and prints 5\n on mochi build --target=c.

What landed

• compiler3/emit/c/emit.go: new OpLenStr case lowering to (int64_t)strlen(s). The const char* carrier (Phase 4.2.0) is NUL-terminated, so strlen is the matching primitive. Result is cast to int64_t because Mochi len returns int. A usesStrH flag in the pre-pass auto-includes <string.h> only when the program actually calls len(str), keeping the i64-only programs free of the extra include.
• compiler3/emit/c/emit_test.go: TestEmitUnsupportedOp repointed from OpLenStr to OpConcatStr, which remains the canonical unsupported-op probe until Phase 4.2.x lands owning mochi_str.
• compiler3/build/c/driver_test.go: three new tests, TestBuildSourceLenStrLiteral (len("hello") → 5), TestBuildSourceLenStrEmpty (len("") → 0), and TestBuildSourceLenStrViaLet (len(s) where s is a let-bound string literal, exercising the side-table indirection).
• §10.6 OpLenStr row moves from DEFERRED to LANDED; OpConcatStr is split into its own row, still deferred. §10.27 limitation list is amended.

Why this closes a goal

The §Top-line objective ties to the canonical user-facing programs. After Phase 4.2.0, print("hello, world!") worked but print(len("hello")) did not. That gap is the smallest visible failure-mode for any user writing string code on the C target. Wiring OpLenStr removes it without introducing new runtime surface (libc's strlen is the primitive). The C-target now matches the Go-target for the read-only string operations that do not require allocation.

Limitations

• Still no concat, slicing, equality, or string-keyed maps. The first three are widened in Phase 4.2.2 (equality) and a later 4.2.x (concat + slicing, gated on an owning mochi_str runtime).
• strlen is byte length, not codepoint count. Mochi len(s) is documented as byte length so this matches the spec, but a user expecting "characters" on a UTF-8 string with multibyte sequences will be surprised. The Mochi-side spec text covers this; no C-target action required.

§10.29 Phase 4.2.2 closeout (LANDED 2026-05-22 08:14 GMT+7)

Phase 4.2.2 wires string equality (== and !=) on the C target. Before this sub-phase, if s == "yes" { ... } errored at the frontend with binop "==" on type str unsupported in MVP. After it, the same source compiles and runs unchanged on both --target=c and --target=go.

What landed

• compiler3/ir/types.go + validate.go: two new ops, OpCmpEqStr and OpCmpNeStr. Result is TypeBool, args are two TypeStr. Signature mirrors the i64 / f64 compare families.
• compiler3/verify/verify.go: classified as KindOperator (pure functions of two value args), and the contract-result table maps both to TypeBool.
• compiler3/emit/go/emit.go: lowers to Go's built-in string == and != (Go strings are comparable by value).
• compiler3/emit/c/emit.go: lowers to (strcmp(a, b) == 0) and != 0 over the const char* carriers introduced in Phase 4.2.0; the usesStrH flag also fires on these ops so <string.h> is auto-included.
• compiler3/frontend/lower.go: lowerBinary learns a TypeStr arm dispatching == / != to the new ops; other operators on TypeStr still error explicitly (+, <, etc.).
• compiler3/build/c/driver_test.go: four new tests: TestBuildSourceStrEqLiteralTrue (true branch fires), TestBuildSourceStrEqLiteralFalse (false branch fires), TestBuildSourceStrEqViaLet (carrier-bound comparison), TestBuildSourceStrNeLiteral (!= arm).

Why this closes a goal

After Phase 4.2.1, a user could write a literal, print it, and ask for its length, but could not branch on its value. Equality is the smallest contained primitive that unlocks branching on string state: it requires no allocation (the result is a bool, the inputs are pointer-compared via strcmp) and no new runtime surface beyond the libc <string.h> header already auto-included for strlen. After Phase 4.2.2, the pattern if user_input == "yes" { ... } compiles to a native binary that prints the same bytes on both AOT targets.

Limitations

• Still no relational comparisons (<, <=, >, >=). They could be added today with a single strcmp(a, b) <op> 0 lowering but the bench corpus has no user yet, so they are deferred until one surfaces. Concat (+) is wired in Phase 4.2.3 (below).
• Equality is byte-level. Two strings encoding the same logical character via different UTF-8 normalisations would compare unequal. That matches Go's == behaviour and the Mochi spec.

§10.30 Phase 4.2.3 closeout (LANDED 2026-05-22 08:23 GMT+7)

Phase 4.2.3 wires string concat (+) on the C target. Before this sub-phase, print("hello, " + name) errored at the frontend with binop "+" on type str unsupported in MVP. After it, the same source compiles unchanged on both --target=c and --target=go, and the user-visible single-tool-bootstrap story finally covers the canonical hello-name pattern.

What landed

• runtime/c/src/mochi_str.{h,c} (new): mochi_str_concat(const char *a, const char *b) returns a freshly allocated NUL-terminated const char* containing the bytes of a followed by the bytes of b. Pure C99, no libc beyond stdlib.h / string.h. Embedded via runtime/c/doc.go so the build driver writes it next to gen.c.
• compiler3/emit/c/emit.go: new OpConcatStr case lowers to mochi_str_concat(a, b). Pre-pass adds a usesStrRuntime flag that fires when OpConcatStr is present, auto-including mochi_str.h and (via the driver's existing embed walk) compiling mochi_str.c alongside gen.c.
• compiler3/frontend/lower.go: lowerBinary's TypeStr arm gains a + branch that lowers to OpConcatStr (result type stays TypeStr).
• compiler3/emit/c/emit_test.go: TestEmitUnsupportedOp repointed from OpConcatStr to OpListGetF64, the new canonical unsupported-op probe (the C target routes list<float> through OpNewF64Array instead, so OpListGetF64 is unreachable from the frontend).
• compiler3/build/c/driver_test.go: five new tests covering literal concat, let-bound concat, three-way chain, len() composed on a concat result, and == composed on a concat result.

Why this closes a goal

The §Top-line objective is the smallest user-facing bootstrap demo. Phase 4.2.0 made print("hello, world!") build; Phase 4.2.1 added len(s); Phase 4.2.2 added equality. Concat is the next-most-natural primitive a Mochi newcomer reaches for, and was the last allocation-free-no-more gate. After this sub-phase, a program like let name = "world"; print("hello, " + name) produces a single native binary that prints hello, world byte-identical to mochi run.

Limitations

• Heap result leaks at process exit. The MVP target is short-running batch programs (the bench corpus all run in seconds); a long-running concat-in-hot-loop fixture would leak unboundedly. A later 4.2.x sub-phase adds a per-program arena that frees on mochi_main return, once a long-running fixture surfaces the gap.
• Concat result is NUL-terminated. An embedded \0 in either input would truncate downstream strlen / strcmp reads. The literal lowering in Phase 4.2.0 uses octal escapes that can encode a \0 byte, but the bench corpus has no such fixture. A future widening that introduces an owning mochi_str with explicit length retires this corner.
• No string slicing, indexing, or formatted construction (e.g. str(42)). Those are independent gates handled by later sub-phases.

§10.31 Phase 4.2.4 closeout (LANDED 2026-05-22 08:28 GMT+7)

Phase 4.2.4 wires scalar→string conversion (str(x)) on the C target for int, float, and bool arguments. Before this sub-phase, the frontend's lowerBuiltinCall did not recognise str as a builtin, so print("answer: " + str(x)) errored at parse time with unknown function "str". After it, the same source compiles unchanged on both --target=c and --target=go, closing the most common formatted-print pattern a Mochi user reaches for (one-line print instead of two print statements: a label, then the value).

What landed

• compiler3/ir/types.go + validate.go: three new ops, OpI64ToStr, OpF64ToStr, OpBoolToStr. Each takes a single arg of the matching scalar type and returns TypeStr. Signature added to opContract.
• compiler3/verify/verify.go: all three classified as KindConstructor (they produce a freshly-shaped TypeStr handle, matching OpConcatStr's discipline). contractResult adds the new ops to the TypeStr-returning row.
• runtime/c/src/mochi_str.{h,c}: extended with mochi_str_from_i64 (snprintf via PRId64 into a 24-byte buffer, malloc + memcpy out), mochi_str_from_f64 (shortest-round-trip search mirroring mochi_print_f64 so str(x) and print(x) produce identical digits), and mochi_str_from_bool (returns one of two static C99 literals, no allocation).
• compiler3/emit/c/emit.go: pre-pass extends usesStrRuntime to fire for OpI64ToStr/OpF64ToStr/OpBoolToStr, ensuring mochi_str.h is included whenever any scalar conversion is present. Three new emit cases lower to the matching runtime call.
• compiler3/emit/go/emit.go: three cases route to strconv.FormatInt(v, 10), strconv.FormatFloat(v, 'g', -1, 64), and strconv.FormatBool(v) respectively, auto-importing strconv.
• compiler3/frontend/lower.go: lowerBuiltinCall adds a str case in the first switch (next to int, float, now). It dispatches by arg type: TypeStr → identity, TypeI64/TypeF64/TypeBool → matching IR op, anything else → frontend: str(X) unsupported in MVP.
• compiler3/build/c/driver_test.go: seven new tests covering str(42), str(-7), str(3.5), str(true), str(false), "answer: " + str(x), and "ok=" + str(true). The last two pin the composition with OpConcatStr that motivated the sub-phase.

Why this closes a goal

The §Top-line objective is the smallest user-facing bootstrap demo. Phase 4.2.0-4.2.3 covered string literals, print, len, equality, and concat. The missing piece for the typical "print a labeled value" idiom was a way to lift a scalar into a string before concatenating. With str() wired, let x = 42; print("answer: " + str(x)) produces a single native binary that prints answer: 42 byte-identical to mochi run, without falling back to two print statements.

Limitations

• str(x) on i64 and f64 allocates a heap buffer that leaks at process exit, same model as OpConcatStr. A per-program arena would retire this; deferred until a fixture exposes the leak.
• str(x) on bool returns a static literal pointer (no allocation). A future widening that distinguishes owning from borrowed string carriers would need a uniform handle; today the const char* carrier discipline makes the literal-vs-heap split invisible to the Mochi level.
• No str() on lists, maps, structs, or any other compound type. The Mochi surface form str([1,2,3]) errors with frontend: str(list) unsupported in MVP. Compound formatting is a separate larger gate (it implies recursive descent and a structural-equality story for nested fields).

§10.32 Phase 4.2.5 closeout (LANDED 2026-05-22 08:39 GMT+7)

Phase 4.2.5 is a "discovered green" sub-phase: pinning the canonical homepage Mochi program from examples/website/hello.mochi as a C-target regression test. The fixture is the program the mochi-lang.dev landing page shows new users; it exercises the full Phase 4.2.x string stack in two short lines:

let name = "Mochi"
print("Hello, " + name + "!")

let answer = 42
print("the answer is " + str(answer))

After Phases 4.2.0 (literal + print) → 4.2.1 (len) → 4.2.2 (==/!=) → 4.2.3 (concat) → 4.2.4 (str(i64/f64/bool)), the program compiles end-to-end via mochi build --target=c with no remaining surface gaps. The new test reads examples/website/hello.mochi verbatim and asserts the produced binary's stdout is Hello, Mochi!\nthe answer is 42\n, byte-matching mochi run on the same source.

What landed

• compiler3/build/c/driver_test.go: new TestBuildSourceWebsiteHomepageHello reads the homepage fixture from examples/website/hello.mochi (no string copy, so a future homepage edit is caught as a test failure) and asserts the two-line stdout. No new emit or runtime code; the entire string stack is already wired.

Why this closes a goal

The §Top-line objective is "the smallest user-facing bootstrap demo". The mochi-lang.dev homepage program is the canonical instance of that demo, and it has been the load-bearing motivation for the entire Phase 4.2.x stream. Pinning it as a regression test turns "the homepage program compiles" from an ad-hoc property into a CI-enforced one: any future refactor of OpConcatStr, OpI64ToStr, OpCallGo{print}, the const char* carrier discipline, or the mochi_str runtime that breaks the homepage demo fails CI before it merges.

Limitations

• Still no compound str() (list, map, struct). Tracked in §10.31; orthogonal to this sub-phase.
• Still no string slicing or indexing. Same status.
• No relational </<=/>/>= on strings. The bench corpus has no user; deferred.

§10.33 Phase 4.2.6 closeout (LANDED 2026-05-22 08:46 GMT+7)

Phase 4.2.6 wires multi-argument print(a, b, ..., z) on the C target (and equivalently on Go). Before this sub-phase, the frontend's lowerExprAsStmt rejected anything but a single argument: print("i =", i) errored with unknown function "print" (the multi-arg call did not match the len(args)==1 guard so it fell through to the user-fun lookup). After it, the same source compiles unchanged on both --target=c and --target=go, closing the v0.1 tutorial idiom (print("Sum =", sum), print("i =", i)) that the homepage v0.1 examples rely on.

What landed

• compiler3/frontend/lower.go: lowerExprAsStmt now accepts print(...) with N >= 1 args. When N >= 2, dispatch goes to a new helper lowerMultiArgPrint that lifts each non-string arg through the matching scalar→str op (OpI64ToStr / OpF64ToStr / OpBoolToStr, all from Phase 4.2.4), interleaves a " " string literal between consecutive parts, folds left-to-right via OpConcatStr (Phase 4.2.3), then calls the existing single-arg print path on the joined TypeStr SSA value. A second helper liftToStr centralises the scalar-arg-to-string dispatch so future widening (e.g. lifting list element-by-element) has one entry point.
• compiler3/build/c/driver_test.go: four new driver tests, TestBuildSourceMultiArgPrintLabel (print("i =", i)), TestBuildSourceMultiArgPrintThree (three-arg, mixed string/string/int), TestBuildSourceMultiArgPrintMixed (four-arg, string/int/float/bool), and TestBuildSourceMultiArgPrintLoop (the v0.1 for i in 0..N { print("i =", i) } tutorial form).

Why this closes a goal

The §Top-line objective is "the smallest user-facing bootstrap demo". After Phase 4.2.5 the homepage hello.mochi was green; the next-most-canonical Mochi tutorial form is the labeled-print loop (for i in 0..n { print("i =", i) }), which lives in examples/v0.1/for.mochi. With the multi-arg print plumbing in place, the entire v0.1 hello / let / for / if surface set is expressible on the C target. The implementation is pure frontend (no new IR ops, no new runtime files): the multi-arg form is sugar over the existing string stack, so it inherits every constant-folding and verifier guarantee already proven for OpConcatStr / OpI64ToStr / etc.

Limitations

• The space-separator + final-newline matches Go's fmt.Println default for the scalar arg types Mochi supports. Compound types (list / map / struct) still error at the lift step with unsupported in MVP; they will inherit support once str() widens to compound types (orthogonal sub-phase tracked in §10.31).
• The join allocates O(N) intermediate strings (each OpConcatStr is a fresh heap buffer; same leak discipline as Phase 4.2.3). For typical print("label", value) callers this is two allocations per call site, dwarfed by the I/O cost.
• The Go target also routes through the multi-arg lowering rather than passing N args to fmt.Println directly. Output byte-matches Go's native fmt.Println(a, b, c) for the typical scalar set; if the Mochi surface ever adds custom formatters or types whose String() method matters, the Go target's fmt.Println would diverge from this lowering and we would need to extend OpCallGo to be variadic. No such type exists today.

§10.34 Phase 4.2.7 closeout (LANDED 2026-05-22 08:58 GMT+7)

Phase 4.2.7 wires == and != on TypeBool for both --target=c and --target=go. Before this sub-phase, a == b (with both sides bool) errored at lower with binop "==" on type bool unsupported in MVP, blocking examples/v0.1/binary.mochi (the "bool_eq:" / "bool_neq:" lines) and examples/v0.1/unary.mochi (the nested !((2 < 3) == true) expression). After it, both fixtures compile end-to-end on the C target.

What landed

• compiler3/ir/types.go: two new ops OpCmpEqBool / OpCmpNeBool with String() entries cmp.eq.bool / cmp.ne.bool.
• compiler3/ir/validate.go: signature (TypeBool, TypeBool) -> TypeBool for both.
• compiler3/verify/verify.go: both ops added to the KindOperator row alongside the other scalar comparisons, and contractResult returns TypeBool for both.
• compiler3/emit/c/emit.go: both ops lower to plain == / != on the underlying int carrier (cType(TypeBool) == "int"). Operands are !!-normalised first so any future opaque bool source (Go FFI bridge, etc.) still compares correctly.
• compiler3/emit/go/emit.go: both ops lower to plain == / != on Go's native bool type.
• compiler3/frontend/lower.go: lowerBinary adds a TypeBool arm that emits OpCmpEqBool for == and OpCmpNeBool for !=. Other operators on bool still error with operator %q on bool unsupported in MVP (no surface form needs && / || on bool today since those are short-circuit, not binops).
• compiler3/build/c/driver_test.go: five new tests. TestBuildSourceBoolEqTrue / TestBuildSourceBoolNe pin the elementary bool == bool / bool != bool cases. TestBuildSourceBoolEqMixed pins the multi-arg-print interplay (print("bool_eq:", ba == ba)), which lifts the bool result through OpBoolToStr (Phase 4.2.4). TestBuildSourceBoolEqUnaryNested pins the v0.1/unary.mochi-derived !((2 < 3) == true) expression, which threads OpCmpLtI64 -> OpCmpEqBool -> OpNotBool. TestBuildSourceV01BinaryFixture reads examples/v0.1/binary.mochi verbatim and asserts the full 16-line stdout.

Why this closes a goal

The §Top-line objective is "the smallest user-facing bootstrap demo". After Phase 4.2.6, v0.1 status on the C target was hello, let, if, expr, for green; binary and unary still failed at lower because no surface form of bool equality was wired. Phase 4.2.7 closes those two fixtures, taking v0.1 green-fixture count from 5/17 to 7/17. The remaining v0.1 gaps are first-class function types (fun(int): int) for the fun*.mochi cluster and Go-FFI for agent.mochi / stream.mochi; both are larger gates tracked separately.

Limitations

• The bool == / != lowering is pure scalar; there is no path through tree-handle equality (TypeListAny / TypeMap), which still error if either side is a compound. Compound equality is a separate larger gate.
• The !!-normalisation in the C emit assumes the int carrier holds a small magnitude (0 vs any non-zero); for opaque bool sources whose underlying int is larger than 1, this collapses correctly. No source today can produce such a value, but the defensive normalisation keeps the rule "bool carriers behave 0/1 under ==" stable as the Phase 4.2.x surface widens.

§10.35 Phase 4.2.8 closeout (LANDED 2026-05-22 09:08 GMT+7)

Phase 4.2.8 fixes a silent correctness gap in the C target's float-to-string path. C99 "%g" chooses exponent form when the decimal exponent X satisfies X < -4 || X >= P (where P is the precision passed in). Go's strconv.FormatFloat(v, 'g', -1, 64) uses X < -4 || X >= 6 instead (Go's strconv/ftoa.go hard-codes eprec=6 in shortest mode). For values like 10.0 at the shortest-round-trip precision P=1, C99 produced "1e+01" while Go produced "10". Before this sub-phase, examples/v0.1/expr.mochi compiled but its let e = 5.0 + 2.5 * 2.0 line printed e = 1e+01 instead of e = 10; the binary's stdout drifted from mochi run byte-for-byte even though the program compiled.

The fix is a shared formatter mochi_f64_format in the C runtime. Both mochi_print_f64 (used by single-arg print(x)) and mochi_str_from_f64 (used by str(x), multi-arg print, and concat) route through it, eliminating drift between the two paths.

What landed

• runtime/c/src/mochi_str.h: new declaration int mochi_f64_format(char *buf, int bufsize, double v) returning the byte count written (excluding NUL). Documented to require >=32 bytes of buffer.
• runtime/c/src/mochi_str.c: helper implementation. Algorithm: (1) find the shortest precision p in [1,17] such that "%.*g" round-trips through strtod; (2) detect whether the resulting buffer is in exponent form by scanning for 'e'/'E'; (3) compute the decimal exponent (parse from the buffer in exponent form, derive from floor(log10(|v|)) in fixed form); (4) compare against Go's rule (X < -4 || X >= 6); (5) if Go and C disagree on the form, reformat using "%.*e" (with trailing-zero stripping from the mantissa for parity) or "%.*f" (with fractional precision (p-1)-X clamped to 0). mochi_str_from_f64 now delegates to it.
• runtime/c/src/print.c: mochi_print_f64 delegates to mochi_f64_format (via #include "mochi_str.h"), replacing the duplicated shortest-round-trip loop. The runtime is unconditionally compiled (the build driver's writeRuntime walks every file in runtime/c/src and hands the .c TUs to cc), so the new dependency from print.c to mochi_str.c adds no new conditional inclusion logic; the linker dead-strips whatever the program does not reference.
• compiler3/build/c/driver_test.go: six new tests pin the Go-parity boundaries. TestBuildSourceF64GoParityTen pins print(10.0) -> "10" (the v0.1/expr.mochi-derived regression). TestBuildSourceF64GoParityHundredK pins 1e5 -> "100000" (upper edge of Go's fixed-form window). TestBuildSourceF64GoParityMillion pins 1e6 -> "1e+06" (lower edge of exp form). TestBuildSourceF64GoParityFractionalEdge pins 0.0001 -> "0.0001" and 0.00001 -> "1e-05" (the negative-exponent boundary). TestBuildSourceF64GoParityStr pins the multi-arg / str() path through the same helper (print("e =", 10.0) -> "e = 10"). TestBuildSourceV01ExprFixture reads examples/v0.1/expr.mochi verbatim and asserts the full 6-line stdout.

Why this closes a goal

The §Top-line objective is "mochi build hello.mochi produces a single native binary". After Phase 4.2.5, examples/v0.1/expr.mochi compiled cleanly on --target=c, but its stdout silently drifted from mochi run because 5.0 + 2.5 * 2.0 = 10.0 rendered as 1e+01. A "compiles" demo that produces wrong-looking output erodes user trust more than one that fails fast, so this sub-phase closes the silent-divergence gap. After it, the v0.1 fixtures whose stdout is currently asserted byte-for-byte (hello, let, if, expr, for, binary, unary) all match mochi run exactly, taking the green-fixture count from 7/17 to 7/17 still (no new fixtures added; one moved from "compiles but wrong" to "compiles and correct").

Limitations

• mochi_f64_format handles the finite-double case. NaN, +/-Inf, and -0.0 short-circuit through the "%g" first pass (which produces "nan", "inf", "-inf", "-0" respectively). The bench corpus has no NaN/Inf source today; Phase 4.2.x would extend the helper if one appears, matching whatever Go's fmt.Println produces for those values.
• Trailing-zero stripping in reformatted exponent form is byte-true for the common cases (single-leading-digit mantissas) but has not been audited for every 17-significant-digit subnormal; a fixture exposing the gap would be Phase 4.2.x ammunition.
• mochi_print_f64 now requires mochi_str.c at link time (it #includes mochi_str.h and calls mochi_f64_format). The build driver's writeRuntime writes both unconditionally, so no driver change is needed; if a future minified-runtime mode lands, it must keep mochi_str.c whenever it keeps print.c.

§10.36 Phase 4.2.9 closeout (LANDED 2026-05-22 09:15 GMT+7)

Phase 4.2.9 wires && and || on TypeBool for both --target=c and --target=go. Before this sub-phase, examples/v0.3/logic.mochi (the canonical "boolean logic" tutorial) errored at lower with operator "||" on bool unsupported in MVP. After it, the entire file compiles end-to-end and byte-matches mochi run.

What landed

• compiler3/ir/types.go: two new ops OpAndBool / OpOrBool with String() entries and.bool / or.bool.
• compiler3/ir/validate.go: signature (TypeBool, TypeBool) -> TypeBool for both.
• compiler3/verify/verify.go: both ops added to the KindOperator row alongside the bool comparisons, and contractResult returns TypeBool for both.
• compiler3/emit/c/emit.go: both ops lower to plain && / || on the underlying int carriers. C99's && / || are short-circuit operators at the AST level, but the IR pre-evaluated both operands into separate SSA values before the op runs, so the emitted operator only performs the logical reduction (no actual short-circuit, which would require control-flow lowering with branches). For the v0.3 surface where operands are pure value comparisons or boolean variables, this matches Go's mochi run byte for byte.
• compiler3/emit/go/emit.go: both ops lower to plain && / || on Go's native bool type.
• compiler3/frontend/lower.go: lowerBinary's TypeBool arm adds case "&&" -> OpAndBool and case "||" -> OpOrBool.
• compiler3/build/c/driver_test.go: five new tests. TestBuildSourceBoolAndBasic / TestBuildSourceBoolOrBasic pin the elementary cases. TestBuildSourceBoolAndOrChain pins the v0.3-derived x > 0 && y > 2 || x == 0, exercising precedence and mixed comparison/logic operators. TestBuildSourceBoolAndOrLeftRightPure pins the eager-evaluation behaviour explicitly. TestBuildSourceV03LogicFixture reads examples/v0.3/logic.mochi verbatim and asserts the full 7-line stdout.

Why this closes a goal

The §Top-line objective is "the smallest user-facing bootstrap demo". After Phase 4.2.7 (bool ==/!=) the v0.1 green-fixture count on --target=c reached 7/17; the next-most-canonical Mochi tutorial program to unblock was v0.3/logic.mochi, which is the textbook example for boolean operators. Closing this fixture brings the tutorial corpus on --target=c to v0.1 + v0.3/logic, the entire "introductory expressions" surface a new user is most likely to type. The implementation cost is two IR ops and two emit cases; the surface payoff is the canonical boolean-logic demo working end-to-end.

Limitations

• Eager evaluation, not short-circuit. The IR lowers both operands of a && b into separate SSA values before the op runs, so f() && g() (where f() is false and g() has side effects) still evaluates g(). This matches Go's value-level && for pure operands, which is sufficient for the tutorial corpus today, but a side-effect-bearing right operand would observe the divergence. True short-circuit would require lowering && / || into a branching control-flow shape; tracked as a separate sub-phase if a user program surfaces the gap.
• The C emit relies on C99's int-carrier truthiness (0 vs non-zero). The same !!-normalisation rationale from Phase 4.2.7 applies: future opaque bool sources (Go FFI bridges, etc.) would need the carrier discipline preserved. The current emit does not !!-normalise the operands of && / || because C99 already does that as part of the operator's semantics; only == / != needed the explicit normalisation (since those compare bit patterns).

§10.37 Phase 4.2.10 closeout (LANDED 2026-05-22 09:30 GMT+7)

Phase 4.2.10 lowers break and continue through the compiler3 frontend so loop programs that depend on early exit compile on --target=c. Before this sub-phase, every break and continue statement (regardless of enclosing loop kind) errored at lower with frontend: statement kind unsupported in MVP, blocking examples/v0.3/break-continuous.mochi (the canonical "early loop exit" tutorial). After it, the fixture compiles end-to-end and byte-matches mochi run.

Diff shape

• compiler3/frontend/lower.go: added a per-builder loops []loopCtx stack and four helpers. snapshotEnv factors the "stable sort of b.values" boilerplate that every loop lowerer duplicated. snapshotLoop captures the live SSA values for the innermost loop's phi-tracked names at a break/continue site. endIteration runs the loop's step (if any), extends each header phi's Args with the (block, value) pair for the current back-edge, and jumps to the header. finishCont builds the cont block: with no breaks it passes the header phis through unchanged; with breaks it emits a new phi per name joining the cond-false head flow with each break snapshot.
• Each loop lowerer (lowerWhile, lowerFor for range, lowerForCollection) now starts header phis with a 1-pair [preID, preVid] Args list (instead of a 4-element list with a sentinel back-edge slot to patch) and grows it lazily as continues and the natural fall-through fire. lowerFor and lowerForCollection pass a step closure to the ctx that performs the synthetic loop-var (or idx) increment; lowerWhile passes nil since while has no synthetic step. Natural body fall-through now calls b.endIteration() to share the step+phi-extend+jump sequence with continue.
• lowerStmt dispatches st.Break != nil to lowerBreak (snapshot env, append to loop.breaks, jump to cont) and st.Continue != nil to lowerContinue (delegate to endIteration).
• compiler3/build/c/driver_test.go: seven new tests. TestBuildSourceBreakInForRange / TestBuildSourceContinueInForRange pin the elementary cases on for-range. TestBuildSourceBreakInWhile / TestBuildSourceContinueInWhile pin while-loop variants where the user supplies their own counter (since while has no synthetic step, a continue without an explicit increment would loop forever; the test exercises the legal pattern). TestBuildSourceBreakContinueCombined pins the v0.3 fixture pattern with both edges on the same loop. TestBuildSourceBreakInNestedLoop pins innermost-loop scoping (inner break exits only the inner loop). TestBuildSourceV03BreakContinuousFixture reads the on-disk fixture verbatim.

Why this closes a goal

The §Top-line objective is "the smallest user-facing bootstrap demo". After Phase 4.2.9 the tutorial corpus on --target=c covered v0.1 (hello, let, if, expr, for, binary, unary) plus v0.3/logic. The next-canonical v0.3 demo is break-continuous.mochi, the textbook example for early loop exit. Closing it brings the v0.3 introductory-control-flow surface (logic + break/continue) green on the C target. The implementation cost is one builder stack and four helpers; no new IR ops, no emit changes (CFG-only refactor); the surface payoff is every user-facing loop demo that touches break or continue.

Limitations

• The CFG refactor changes phi shapes for every loop, including loops with no break/continue, since the back-edge slot is no longer pre-allocated. Existing snapshot fixtures in compiler3/ir/fixture.go that hard-coded the [preID, preVid, bodyID, 0] four-element shape would break, but those fixtures already accommodate the shape via the validator (which only checks len(v.Args)/2 == len(blk.Preds)); no fixture file needed touching. A future widening that adds explicit step blocks (rather than threading step through endIteration) would shift the shape again, tracked separately if a debugger or coverage tool surfaces a dependency.
• continue in a while loop runs no synthetic step, so the user must advance the loop counter (or whatever the while condition reads) explicitly inside the body before continue fires. Without it, the loop is infinite. This matches Mochi's existing while semantics (no implicit step) and the test TestBuildSourceContinueInWhile pins the legal pattern. A future "labeled break/continue" feature would target this differently but is out of scope for the AOT C stream.

§10.38 Phase 4.2.11 closeout (LANDED 2026-05-22 09:40 GMT+7)

Phase 4.2.11 lowers match expressions through the compiler3 frontend so the canonical pattern-match tutorial compiles on --target=c. Before this sub-phase, any match (whether the discriminant was i64, str, or bool) errored at lowerPrimary with frontend: primary form unsupported in MVP. After it, examples/v0.3/match.mochi compiles end-to-end and byte-matches mochi run, covering all three textbook discriminant kinds plus the match-in-return pattern.

Diff shape

• compiler3/frontend/lower.go: added lowerMatchExpr plus isWildcardPattern. lowerPrimary now dispatches p.Match != nil to the new lowerer. The discriminant is lowered once, then each case before the last becomes a branch(cmpOp target patVid) -> thenBlock; elseBlock shape (using OpCmpEqI64 / OpCmpEqStr / OpCmpEqBool by discriminant type). The last arm is always unconditional: it lowers in the current block and jumps to the shared merge. The merge block emits one phi whose Args are (armEndBlock, armValue) pairs, one per arm.
• isWildcardPattern walks the standard Expr.Binary.Left.Value.Target.Selector chain looking for Root: "_" with no tail and no enclosing operator. Mochi parses _ as a regular identifier rather than a dedicated AST node, so wildcard detection is structural, not syntactic.
• compiler3/build/c/driver_test.go: five new tests. TestBuildSourceMatchExprInt / TestBuildSourceMatchExprStr cover the i64 and str discriminants with explicit _ wildcards. TestBuildSourceMatchExprBoolExhaustive covers the bool case where the user omits _ because the two arms cover both bool values. TestBuildSourceMatchInReturn covers return match ... inside a fun, where the phi flows directly into TermReturn. TestBuildSourceV03MatchFixture reads the on-disk fixture verbatim.

Why this closes a goal

The §Top-line objective is "the smallest user-facing bootstrap demo". After Phase 4.2.10 (break/continue) the v0.3 introductory-control-flow surface (logic + break-continuous) was green on the C target. The next-canonical v0.3 demo is match.mochi, the textbook example for pattern matching, which exercises three discriminant kinds plus the return match ... idiom in a four-block fixture. Closing it brings v0.3 (logic + break-continuous + match) green on --target=c. The implementation cost is one ~150-line lowerer plus a wildcard recogniser; no new IR ops, no emit changes (the OpCmpEqI64 / OpCmpEqStr / OpCmpEqBool family was already wired by Phases 4.2.4 and 4.2.7). The surface payoff is every match-expression demo that uses literal patterns over scalar types.

Limitations

• Last-arm-is-unconditional rule lets the frontend accept non-exhaustive matches like match x { 1 => "a" } for an i64 x, where any non-1 value silently returns "a". Mochi's checker normally rejects this, but the compiler3 frontend bypasses the checker, so the safety net is missing here. A future tightening would either require _ for i64/str matches or detect bool exhaustiveness explicitly; tracked separately if a fixture surfaces a real bug.
• Block-arm form (pat => { ...stmts }) is rejected. Mochi grammar permits both expression-arm and block-arm; the tutorial corpus uses only expression-arms today, so block-arm lowering is deferred.
• Match discriminants are limited to TypeI64, TypeStr, TypeBool. Sum-type discriminants (match shape { Circle{r} => ..., Square{s} => ... }) would need destructuring-pattern lowering and struct types, both out of MVP scope.
• The result phi at the merge block requires every arm to produce the same value type. Mixed-type arms (1 => 42, _ => "other") reject with a clear error rather than promoting to TypeListAny.

§10.39 Phase 4.2.12 closeout (LANDED 2026-05-22 09:48 GMT+7)

Phase 4.2.12 lowers if cond then T else E (and its else if chain) as an expression form so the canonical if-then-else tutorial compiles on --target=c. Before this sub-phase the frontend dispatched only if as a statement; any binding-position let r = if ... errored at lowerPrimary with frontend: primary form unsupported in MVP. After it, examples/v0.10/if_then_else.mochi compiles end-to-end and byte-matches mochi run, and the else if ... else if ... else chain lowers as a left-leaning recursion of merge phis.

Diff shape

• compiler3/frontend/lower.go: added lowerIfExpr(*parser.IfExpr) (uint32, error). lowerPrimary now dispatches p.If != nil to the new lowerer. Shape: lower cond in the current block, allocate thenID, elseID, mergeID, branch on cond. Each branch lowers its expression, captures the block where lowering finished (so a nested if-expr's merge block is what feeds the outer phi), jumps to the merge. The merge block emits a single 2-arg phi (thenEnd, thenVal, elseEnd, elseVal). e.ElseIf != nil recurses into lowerIfExpr; an else-less if-expr rejects (an expression must produce a value on every path).
• Type unification: both branches must produce the same value type; a mismatch (then i64 vs else str) errors with a clear message rather than producing an ill-typed phi that would crash ir.Validate.
• compiler3/build/c/driver_test.go: five new tests. TestBuildSourceIfExprStr is the literal v0.10 fixture inline. TestBuildSourceIfExprInt covers the i64 result path. TestBuildSourceIfExprElseIfChain exercises the else if recursion across three conditions plus an else-tail. TestBuildSourceIfExprInReturn covers return if ... inside a fun, where the merge phi flows directly into TermReturn. TestBuildSourceV010IfThenElseFixture reads the on-disk fixture verbatim.

Why this closes a goal

The §Top-line objective is "the smallest user-facing bootstrap demo". After Phase 4.2.11 (match) the v0.3 introductory-control-flow surface was green on the C target. The next-canonical demo is v0.10's if_then_else.mochi, the textbook example for if-as-expression, which is the Mochi idiom used pervasively in larger fixtures (e.g. the v0.2/π Leibniz-sign alternation, the v0.5 string-tutorial branching, every classifier in the v0.3 tutorial cluster). Closing it unblocks every binding-position if-expression in the downstream fixtures. The implementation cost is one ~50-line lowerer plus a dispatch arm; no new IR ops, no emit changes (the phi+branch path was already wired by every existing if-statement lowering). The surface payoff is the universal Mochi conditional-expression idiom.

Limitations

• An if-expr without else is rejected. The statement form (if c { ... } else { ... }) still allows the else to be omitted (control-flow only), but a binding-position expression must produce a value on every path.
• Both branches must produce the same value type. Mixed-type branches (if c then 42 else "no") reject; there is no implicit any-promotion.
• The else if chain is left-leaning recursion: each else if allocates its own thenID/elseID/mergeID triple. For a chain of N conditions this generates O(N) merge blocks. SSA peephole could collapse the cascade post-lowering, but the C emitter's block walk already handles the redundant single-pred merges fine; deferred unless a benchmark surfaces it.
• An if-expr inside a non-trivial larger expression (f(if c then a else b) + 1) is supported (the merge phi just feeds the next op), but a print(if ...) may surface unrelated print overload limitations if the branch type isn't one of the already-supported print types (i64/f64/bool/str). Same constraint as any other expression in print position.

§10.40 Phase 4.2.13 closeout (LANDED 2026-05-22 10:07 GMT+7)

Phase 4.2.13 lowers print(xs) where xs: list<int> so the canonical list-printing tutorial line compiles on --target=c. Before this sub-phase the frontend rejected list arguments to print with print() argument type list unsupported in MVP. After it, list values are lifted through a new OpListI64ToStr op (TypeStr ← TypeList) and fed into the existing single-arg print path. The runtime helper mochi_list_i64_to_str produces the Mochi reference [a, b, c] form, matching the VM's valueToString rule for lists (runtime/vm/vm.go) byte-for-byte.

Diff shape

• compiler3/ir/types.go: new OpListI64ToStr opcode + String entry.
• compiler3/ir/validate.go: contract opSig{TypeStr, [3]Type{TypeList}}. Type system check enforces input is TypeList, output is TypeStr.
• compiler3/verify/verify.go: classify the new op under KindConstructor (it materialises a freshly malloc'd carrier string, same shape as OpI64ToStr and OpConcatStr).
• runtime/c/src/mochi_list_i64.{h,c}: new mochi_list_i64_to_str(const mochi_list_i64 *) helper. Empty list returns the static "[]" literal (no malloc); non-empty mallocs a worst-case 22n + 3 byte buffer and snprintf's each element with PRId64. The pointer is owned by the runtime (currently leaked, matching mochi_str_concat ownership).
• compiler3/emit/c/emit.go: dispatch ir.OpListI64ToStr to mochi_list_i64_to_str(arg).
• compiler3/emit/go/emit.go: dispatch ir.OpListI64ToStr to an inline lambda that builds the same [a, b, c] string via stdlib fmt.Sprintf("%d", x) + strings.Join. Inlined (rather than calling into a runtime/mochi/fmt helper) so the default Go-side alias for the fmt package, which is the host package this lambda must reach, does not collide with the user binding for fmt.Println.
• compiler3/frontend/lower.go: in lowerExprAsStmt's single-arg print path, when argType == TypeList, insert an OpListI64ToStr value first; liftToStr gains a parallel TypeList case so multi-arg print("xs:", xs) works through the same op.
• compiler3/build/c/driver_test.go: 4 new tests covering the basic case, empty list, multi-arg combined with a string label, and a list grown via concat (validates len-not-cap behaviour in the runtime formatter).

Why this closes a goal

The §Top-line objective is "the smallest user-facing bootstrap demo". After Phase 4.2.12 (if-then-else as expression) the v0.10 conditional-expression idiom was green on the C target. The next-canonical demo cluster is the list-tutorial family: examples/v0.2/list.mochi, examples/v0.2/matrix.mochi, and the v0.2/for-in cluster all open with print(values) against a list literal. Before this phase that very first line errored. After it, the list-print idiom compiles for list<int>, the most common element type across the v0.2 cluster. Subsequent sub-phases will extend the same pattern to list<str>, list-of-list, negative indexing, and slicing.

Limitations

• print accepts only list<int> today. list<float> (TypeF64Arr) and list<any> (TypeListAny) and list<str> would each need a parallel OpF64ArrayToStr / OpListAnyToStr / OpListStrToStr op plus runtime helper. Each is one-Phase scope; deferred until the matching fixture lands.
• print(nested_list) (a list<list<int>>) is not supported. The frontend's MVP rejects list<list<...>> element types entirely; supporting it requires both the type-system extension and a recursive formatter.
• The Go-target emit inlines the format via a per-call lambda rather than a runtime helper. The lambda compiles cleanly under go build, but a fixture that uses print(list) in a tight loop will produce many lambda call sites; SSA-level CSE could fold them, but the optimiser cost is not justified until a benchmark surfaces it.
• The C runtime's mochi_list_i64_to_str does not free the result. This matches the existing mochi_str_concat ownership convention (everything leaks, MVP doesn't run finalisers). A long-running fixture printing many large lists will accumulate memory; documented as a known limitation, same as the rest of the string-producing runtime ops.

§10.41 Phase 4.2.14 closeout (LANDED 2026-05-22 10:19 GMT+7)

Phase 4.2.14 extends the print(xs) lift from list<int> to list<float> so the second-most-common list element type compiles on --target=c. The frontend was already rejecting list<float> print args (print() argument type f64array unsupported in MVP); this sub-phase removes that block. The lift mirrors Phase 4.2.13 exactly: a new OpF64ArrayToStr op (TypeStr from TypeF64Arr) feeds the existing single-arg print path, and the runtime helper mochi_f64_array_to_str produces the Mochi reference [1.0, 2.5, 3.14] form. The non-obvious bit is the float-to-string subroutine, which uses Go's FormatFloat 'f' -1 64 rule (shortest fixed-point that round-trips) plus a ".0" suffix on integral values. This is the rule the VM uses in list context (runtime/vm/vm.go); it differs from scalar print(1.0) which uses 'g' format and produces "1", not "1.0". The C side implements the shortest-round-trip search by scanning precision in [0,17] for the smallest %.*f that survives strtod; the Go-side inlines strconv.FormatFloat(x, 'f', -1, 64) + ".0" suffix into a lambda (same alias-collision avoidance rationale as 4.2.13).

Diff shape

• compiler3/ir/types.go: new OpF64ArrayToStr opcode + String entry (f64array.tostr).
• compiler3/ir/validate.go: contract opSig{TypeStr, [3]Type{TypeF64Arr}}.
• compiler3/verify/verify.go: classify the new op under KindConstructor next to OpListI64ToStr.
• runtime/c/src/mochi_f64_array.{h,c}: new mochi_f64_array_to_str(const mochi_f64_array *) helper. Empty array returns the static "[]" literal; non-empty allocates from the rendered length (first pass computes per-element widths via the shortest-round-trip 'f' search, second pass copies into a single malloc). A static format_f64_decimal helper inside the .c implements the format rule.
• compiler3/emit/c/emit.go: dispatch ir.OpF64ArrayToStr to mochi_f64_array_to_str(arg); add the op to the usesF64Array include-detection set.
• compiler3/emit/go/emit.go: dispatch ir.OpF64ArrayToStr to an inline lambda that builds the same [a, b, c] string via stdlib strconv.FormatFloat(x, 'f', -1, 64) + ".0" suffix + strings.Join. Inlined for the same alias-collision rationale as OpListI64ToStr.
• compiler3/frontend/lower.go: in lowerExprAsStmt's single-arg print path, when argType == TypeF64Arr, insert an OpF64ArrayToStr value first; liftToStr gains a parallel TypeF64Arr case so multi-arg print("data:", xs) works through the same op.
• compiler3/build/c/driver_test.go: 5 new tests covering basic list, empty, integral-only (locks the ".0" suffix), multi-arg with string label, and scientific-range values (1e-5 -> "0.00001", 1.5e10 -> "15000000000.0") that distinguish 'f' from 'g'.

Why this closes a goal

Phase 4.2.13 covered list<int>, which is enough for examples/v0.2/list.mochi and the integer-only opening lines of the for-in cluster. But the broader v0.2 tutorial cluster also opens with print of float lists (the math, statistics, and physics tutorials in examples/v0.2/). Without this phase, those fixtures wedged the moment a list<float> reached print(), even though the rest of the lowering pipeline already produced TypeF64Arr SSA values correctly. The end-to-end smoke test (basic [1.0, 2.5, 3.14], integral [1.0, 2.0, 3.0], scientific [1e-5, 1.5e10], empty [], multi-arg with label) now byte-matches mochi run on the canonical fixtures.

Limitations

• list<str> and list<any> and list<list<int>> are still rejected by print. Each needs its own parallel OpListStrToStr / OpListAnyToStr op plus runtime helper; deferred until the matching fixtures land. The same scope rules apply as 4.2.13 (one-Phase per element type).
• NaN, +Inf, -Inf in list context format as "nan" / "+inf" / "-inf". The reference VM uses Go's strconv.FormatFloat, which emits "NaN" / "+Inf" / "-Inf". No bench or tutorial fixture exercises these in list position today; if one surfaces, the case lives in format_f64_decimal and is a one-line patch (swap the snprintf'd "nan" tokens for the Go forms).
• Extreme magnitudes (|v| > 1e25 in fixed form) overflow the 64-byte per-element scratch buffer in mochi_f64_array_to_str. The bench and tutorial corpus stays well below; if a fixture surfaces with 1e100 in list context, the buffer size lives in one place and is a one-line bump.
• The Go-target emit inlines the format via a per-call lambda rather than a runtime helper, same rationale as 4.2.13. Tight-loop fixtures printing lists of floats produce many lambda call sites; SSA-level CSE is the long-run answer.
• The C runtime's mochi_f64_array_to_str does not free the result. Same ownership convention as mochi_list_i64_to_str and mochi_str_concat (everything leaks, MVP doesn't run finalisers).

§10.42 Phase 4.2.15 closeout (LANDED 2026-05-22 10:30 GMT+7)

Phase 4.2.15 makes literal-negative list indexing semantically correct on the C target. Mochi's reference VM wraps negative indices against the list length (xs[-1] returns the last element; xs[-2] the second-to-last); before this phase the C target lowered xs[-1] to mochi_list_i64_get(l, -1) which reads l->data[-1], undefined behaviour that returned 0 on x86_64 with this allocator. The v0.2/list.mochi tutorial fixture's first conditional line (print("last: ", values[-1])) was a primary visible casualty.

The fix is a small frontend fold rather than a runtime change. When the lowered index value is a constant (or the unary negation of a constant, which is how -1 lowers; see constI64 helper), and that constant is negative, the lowering replaces the bare get/set with xs[len + idx] via OpListLenI64 + OpAddI64Imm. The path is symmetric for list<int> (TypeList -> OpListLenI64) and list<float> (TypeF64Arr -> OpF64ArrayLenI64). Dynamic-negative indexing (xs[i] where i is a runtime value that might be negative) is a separate future phase; that needs either a runtime helper with a branch or an SSA-level select op, both meaningfully more invasive.

Diff shape

• compiler3/frontend/lower.go:
  • New helper constI64(id) (int64, bool) that recognises both OpConst(N) and OpNegI64(OpConst(N)) patterns. The latter case is necessary because the surface -1 parses as unary - applied to literal 1, not as a single negative literal.
  • Fold site in lowerPostfix's op.Index != nil branch: when curType is TypeList or TypeF64Arr and constI64 returns a negative value, rewrite xs[idx] to xs[len + idx] before emitting the get op.
  • Fold site in lowerIndexedAssign: same logic for the store side so xs[-1] = v lands in the right slot.
• compiler3/build/c/driver_test.go: 4 new tests covering i64 read, f64 read, indexed assign, and the unary-minus parse shape (-1 -> OpNegI64 of OpConst).

Why this closes a goal

The §Top-line goal "the smallest user-facing bootstrap demo" tracks the v0.2 tutorial cluster. After Phase 4.2.14 the print(list) and print(list) lines compile, but the very next idiom in v0.2/list.mochi (values[-1]) was a silent miscompile rather than a hard error. Silent miscompiles are worse than rejections: a learner gets last: 0 instead of last: 5 and has no signal that the C target is the cause. This phase closes that footgun for the literal case, leaving dynamic-negative as a known-rejection (it still passes through and may UB, but the tutorial fixture doesn't exercise that path). Visible progress: xs[-1] on the C target byte-matches mochi run.

Limitations

• Dynamic negative indices (xs[i] where i is a runtime value) still pass through unchanged. If i is negative at runtime the C target reads past the start of the buffer (undefined behaviour, typically 0). A future phase will either add a runtime wrap helper (one branch + add per get/set, paid on every index) or an SSA-level select op (no overhead on positive indices but a new op + emit case in two targets). The fixture corpus doesn't exercise dynamic negative today, so the decision is deferred.
• Slicing (xs[1:3]) is still rejected by lowerPostfix (the idx.Colon != nil branch). That is a separate phase with its own runtime helper (mochi_list_i64_slice).
• Negative bound in a slice (xs[-2:] or xs[:-1]) inherits the same dynamic-vs-literal split when slicing lands; the fold here is the shape that will extend.
• TypeMap indexing is excluded from the fold because map keys can legitimately be negative. The frontend rejects map negative-key reads as a separate gate (today xs[-1] on a TypeMap binds returns whatever the map contains, no wrap semantics).
• The fold runs purely at lower time. No optimiser pass; no IR-level peephole. A constant-positive index in a long chain still produces a OpConst + OpListGetI64 pair; that's the existing behaviour.

§10.62 Phase 5.2.1 closeout (LANDED 2026-05-22 16:55 GMT+7)

Phase 5.2 left the umbrella Phase 5 row PARTIAL because the Linux ELF run-gates skipped on the Darwin recording host (Homebrew on macOS ships qemu-system-* but not qemu-user). Phase 5.2.1 closes that last gap by adding a .github/workflows/cross-aot.yml job that runs on ubuntu-latest, installs qemu-user-static + wasmtime + zig, and runs the existing Phase 5.0 and Phase 5.2 cross-tests. On linux/amd64 the run-gate fires for x86_64-linux-musl (native), aarch64-linux-musl (qemu-aarch64-static), and wasm32-wasi (wasmtime); the two Mach-O triples skip on Linux for the same reason their inverses skip on Darwin (no cross-OS userland emulator in §9 scope; Darling is out-of-scope for phase-1).

Diff shape

• .github/workflows/cross-aot.yml (new): one job, runs on push to main and on every PR, installs zig 0.15.1 from ziglang.org, qemu-user-static from apt, and wasmtime from the upstream installer; then runs go test -run 'TestBuildCross.*' (Phase 5.0 gates) followed by go test -run 'TestBuildSource.*BgFixtureCross.*' (Phase 5.2 gates).
• The sentinel "Verify runner availability" step asserts qemu-aarch64-static, wasmtime, and zig are all on PATH before tests run. If any install regresses the CI step fails loudly rather than silently skipping the run-gate in the Go tests.
• No changes to cross_test.go or cross_fixture_test.go. The existing findRunner(triple) already returns the right runner on linux/amd64 (native for x86_64-linux-musl, qemu-aarch64-static for aarch64-linux-musl, wasmtime for wasm32-wasi); the workflow just provides the environment those runners need.

Cross-host run-gate evidence

The §9 phase-1 matrix is satisfied by the UNION of two hosts running the same test suite under different runners:

Triple	Darwin (this host, recording)	Linux CI (ubuntu-latest)	Combined run-gate
x86_64-linux-musl	SKIP (no qemu-user via Homebrew)	PASS (native, "69\n" / "42\n")	LANDED
aarch64-linux-musl	SKIP (no qemu-user via Homebrew)	PASS (qemu-aarch64-static, "69\n" / "42\n")	LANDED
aarch64-macos	PASS (native, "69\n" / "293888\n" / "42\n")	SKIP (no Darling)	LANDED
x86_64-macos	PASS (Rosetta 2, "69\n" / "42\n")	SKIP (no Darling)	LANDED
wasm32-wasi	PASS (wasmtime, "69\n" / "42\n")	PASS (wasmtime, "69\n" / "42\n")	LANDED (double-covered)

Reading the §Phased-plan row 5 gate literally ("from any phase-1 host produces a single-file binary that runs on a clean machine of the target platform and matches mochi run stdout"): every row above has at least one (host, runner) tuple where both build and run pass. Reproducibility holds because zig cc -target=<triple> is deterministic on the source bytes, so the same Mochi source produces byte-identical output on either host (Reproducible Builds Project compatibility, MEP-37 lineage).

Why not run all 5 triples on a single host

The §9 gate is "from any phase-1 host" (singular), not "from every phase-1 host". A single host that can run all 5 binaries does not exist in phase-1 scope: macOS dev hosts cannot run Linux ELFs without Docker/Lima/Colima (none ship by default); Linux CI hosts cannot run Mach-O without Darling (out-of-scope). The honest reading is the union framing above. If a future Phase 6.x adds Darling on Linux CI or Docker on macOS dev as a hard requirement, the matrix collapses to a single-host gate; for phase 1 the union is the right model.

Umbrella row flip

The §Phased-plan row 5 ("C-as-target AOT covers all four phase-1 native targets via system cc + LLD") flips from PARTIAL to LANDED with this closeout. All five §9 must-have rows have build evidence (file-format magic) AND run evidence (stdout byte-match) under the union of hosts.

Limitations and deferred sub-phases

Sub-phase	Scope
5.2.2	Run Phase 5.2.1 on macos-latest runners too, so the macOS pair gets a clean-machine run-gate independent of the recording host. Currently the Darwin host is also the developer's laptop; promoting the gate to macos-latest removes that conflation.
5.2.3	Determinism gate: cross-build the same fixture on both runners, store the binary as an artifact, diff between hosts. Cross-host byte-identity proves Reproducible Builds compatibility.
5.2.4	Parametric fixture matrix: drive all 10 §10.7 BG fixtures across all 5 §9 triples in one table-driven test. Currently 2 of 10 fixtures (regex_redux, reverse_complement) sit under the cross matrix.

§10.61 Phase 5.2 closeout (LANDED 2026-05-22 16:54 GMT+7)

Phase 5.0 pinned the one-function "answer/42" program on every §9 triple. The user-facing question that gate doesn't answer is "does a real Mochi program (not a synthesized IR program) cross-build and run on each target?". Phase 5.2 closes that gap by lifting the §10.7 BG fixture suite onto the cross-target framework: the unmodified bench/template/bg/regex_redux/regex_redux.mochi source feeds through the full BuildSource (parse → lower → emit → zig cc) pipeline for every §9 triple, and on the three triples where this host can execute (both Darwin pair natively, wasm32-wasi via wasmtime) the produced binary's stdout byte-matches the host gate's "69\n". Adding a foreign-arch runner becomes a one-line entry in findRunner; everything else (build-gate file-format check, run-gate stdout match) is shared across triples.

Diff shape

• compiler3/build/c/cross_fixture_test.go (new, 6 tests): 5 triple-specific gates plus one second-fixture sanity gate (reverse_complement on aarch64-macos). Each cross-builds via BuildSource(..., Options{Triple: ...}) so the §10.7 BG kernel itself, not a fresh IR, drives every gate. The build-gate (e_machine / Mach-O cputype / Wasm magic) fires unconditionally; the run-gate fires when findRunner(triple) resolves.
• website/docs/mep/mep-0042.md: this closeout plus the matrix update below.

Test surface

Test	Triple	Build-gate	Run-gate (this host)
TestBuildSourceRegexReduxBgFixtureCrossX86_64Linux	x86_64-linux-musl	ELF + e_machine=0x3E	SKIP (no qemu-user on macOS via Homebrew)
TestBuildSourceRegexReduxBgFixtureCrossAArch64Linux	aarch64-linux-musl	ELF + e_machine=0xB7	SKIP (no qemu-user on macOS via Homebrew)
TestBuildSourceRegexReduxBgFixtureCrossAArch64Macos	aarch64-macos	Mach-O 64 + cputype=0x0100000C	PASS (native, stdout "69\n")
TestBuildSourceRegexReduxBgFixtureCrossX86_64Macos	x86_64-macos	Mach-O 64 + cputype=0x01000007	PASS (Rosetta 2, stdout "69\n")
TestBuildSourceRegexReduxBgFixtureCrossWasm32WASI	wasm32-wasi	Wasm 1.0 magic + version 1	PASS (wasmtime, stdout "69\n")
TestBuildSourceReverseComplementBgFixtureCrossAArch64Macos	aarch64-macos	Mach-O 64 + arm64 cputype	PASS (native, stdout "293888\n")

The reverse_complement extension is the second-fixture sanity gate: regex_redux is pure scalar int (let, var, for, if, %, +, *, ==, print int), while reverse_complement allocates a heap buffer and exercises OpNewListI64 / OpListI64Push / OpListI64Get / OpListI64Set / OpListLenI64. Both fixtures share the same C runtime (runtime/c/src/print.{c,h}, list_i64.{c,h}) and the same zig-cc cross-link path, so one fixture proves the scalar surface and a second proves the heap surface cross-clean.

§9 target matrix update

Target ISA	OS	Format	ABI	Phase 5.0 status	Phase 5.2 status
x86_64	Linux	ELF	SysV	LANDED (build)	LANDED (BG fixture build)
aarch64	Linux	ELF	AAPCS64	LANDED (build)	LANDED (BG fixture build)
aarch64	macOS (Apple Silicon)	Mach-O	Apple ABI	LANDED (build + native run)	LANDED (BG fixture build + native run, scalar + heap)
x86_64	macOS	Mach-O	SysV	LANDED (build + Rosetta run)	LANDED (BG fixture build + Rosetta run)
wasm32	browser + WASI	.wasm	Wasm 3.0 + GC	LANDED (build + wasmtime run)	LANDED (BG fixture build + wasmtime run)

The §Phased-plan row 5 ("from any phase-1 host produces a single-file binary that runs on a clean machine of the target platform and matches mochi run stdout") now has the matching BG-fixture evidence on three of five triples (Darwin pair natively, wasm32-wasi via wasmtime), and a deterministic build-gate on the remaining two (Linux ELFs). The Linux clean-machine run-gate moves to Phase 5.2.1 (§10.62), which adds the .github/workflows/cross-aot.yml job that fires the Linux + wasm run-gates on ubuntu-latest. Under the union of Darwin + Linux CI, every §9 row has both build and run evidence.

Picking the fixture

regex_redux was chosen over the other bare-print fixtures (fasta "1072663717\n", reverse_complement "293888\n") for three reasons. (1) Smallest source: ~30 lines, no helper functions, easy to read in a stack trace if zig cc complains. (2) Tightest dependency surface: no heap allocation, no map ops, just scalar arithmetic and print(int). If this fixture fails on a new triple, the problem is the triple's libc or the C target's print runtime, not the fixture's choice of ops. (3) Stable output (matches the existing host gate at TestBuildSourceRegexReduxBgFixture line 1170 of driver_test.go); Phase 5.2 reuses that ground truth verbatim, so a cross-build regression is unambiguously a cross-target bug, not fixture drift.

Why not parameterize all 10 BG fixtures across all 5 triples now

The marginal cost of cross-gating a second fixture (50x runs across the 5 triples for 10 fixtures = 50 builds, ~25 seconds at the Phase 5.0 cost-per-build) is high relative to the marginal information gain: the first fixture proves the cross-link path; subsequent fixtures only catch op-specific cross-arch bugs (signed-vs-unsigned division on aarch64, f64 NaN bit-pattern on wasm32, big-endian disagreement on... well, none of phase-1 is big-endian). Phase 5.2 covers the scalar surface and one heap-buffer fixture; the remaining 8 (mandelbrot, n_body, spectral_norm, nsieve, fannkuch_redux, fasta, k_nucleotide, binary_trees) extend as sub-phases when a cross-arch regression motivates them.

Limitations and deferred sub-phases

Sub-phase	Scope
5.2.1	LANDED 2026-05-22 16:55 (GMT+7), §10.62. Linux ELF run-gate via qemu-user-static + wasm run-gate via wasmtime on ubuntu-latest. With this gate firing the umbrella Phase 5 row flipped to LANDED.
5.2.2	Parametric fixture matrix: drive all 10 §10.7 BG fixtures across all 5 §9 triples in one table-driven test. Useful once 5.2.1 lights up the Linux run-gates.
5.2.3	Determinism gate: cross-build the same fixture twice on the same host and assert byte-identical binaries (Reproducible Builds Project compatibility, MEP-37 lineage).

§10.60 Phase 5.0 closeout (LANDED 2026-05-22 16:37 GMT+7)

Phase 5.0 turns the §Phased-plan row 5 ("C-as-target AOT covers all four phase-1 native targets") from "pending" into a working mochi build --target=c --triple=<triple> for every §9 must-have native target plus wasm32-wasi. The driver routes through zig cc -target=<triple> because Zig ships every musl, wasi-libc, and Mach-O SDK in-process, so cross-building from any §9 host needs no extra toolchain install. Five cross-target gates land in compiler3/build/c/cross_test.go; three of them (the macOS pair and wasm32-wasi) actually execute the foreign-arch binary on the recording Apple Silicon host and assert its stdout matches the host gate's "42\n".

Why now (goal-alignment audit)

Phases 4.2.30 → 4.2.32 closed out the data-driven op registry, which covers ~94 of ~100 IR ops. The remaining 6 ops are call-site-typed or variadic and would each require extending OpInfo's schema, a higher-ceremony refactor for diminishing returns. At the same boundary, §10.7 reports "all 10 in-scope BG fixtures landed. Zero remaining gaps for the user-facing goal" on x86_64 Linux. The user-facing surface that was actually unaddressed sat at Phase 5 (single binary on the other four §9 targets). Per the goal-alignment audit memo, the next sub-phase had to pivot off the registry stream onto Phase 5.

compiler3/build/c/driver.go changes

Area	Change
Options.Triple	New string field. When non-empty, the driver passes -target=<triple> to cc. When CC and $MOCHI_CC are both empty, the default cc switches from cc to zig cc.
resolveCC(explicit, triple)	Returns (executable, argv-prefix) instead of a single string. The argv-prefix is the leading tokens that have to precede the compiler's own flags (e.g. ["cc"] for zig cc). The triple parameter selects zig as the default when no explicit cc is configured.
splitCC(s)	New helper. Accepts either a bare executable ("cc", "/usr/bin/clang") or a wrapper-form string ("zig cc", "ccache clang") and splits on whitespace, so users can pass --cc="zig cc" or MOCHI_CC="ccache cc" without driver-side special casing.
Build(p, opts)	Splices the argv-prefix in front of -std=c99 -O2 -I <outdir>; appends -target <triple> after the std flags when opts.Triple != "". The -lm tail stays unconditional (vacuous on wasm32-wasi where wasi-libc carries the math symbols; harmless on the Darwin Mach-O cases where libSystem already does).

runtime/c/src/mochi_time.c portability fix

gettimeofday(&tv, NULL) referenced NULL without including a header that defines it. Apple's vendored cc indirectly pulled it in via <sys/time.h>, which masked the issue on the Phase 4.0 host gate. Zig cc's musl + wasi-libc sysroots are strict (no transitive NULL from <sys/time.h>), so the cross-build surfaced the missing #include <stddef.h>. Added the include; the host gate is unaffected.

cmd/mochi/main.go CLI change

Flag	Purpose
--triple <triple>	Target triple (e.g. x86_64-linux-musl, aarch64-linux-musl, aarch64-macos, x86_64-macos, wasm32-wasi). --target=c only. When set, the driver defaults to zig cc and passes -target=<triple>.

The flag is wired through both the arg-parser and the cobra command (the file dual-registers for the two CLI shells).

compiler3/build/c/cross_test.go gate

Five tests, one per §9 row:

Test	Triple	Build-gate	Run-gate
TestBuildCrossX86_64Linux	x86_64-linux-musl	ELF e_machine == 0x3E (x86_64)	qemu-x86_64 when on PATH; skip with hint on macOS
TestBuildCrossAArch64Linux	aarch64-linux-musl	ELF e_machine == 0xB7 (aarch64)	qemu-aarch64 when on PATH; skip with hint on macOS
TestBuildCrossAArch64Macos	aarch64-macos	Mach-O cputype == 0x0100000C (arm64)	native execution on arm64 Darwin
TestBuildCrossX86_64Macos	x86_64-macos	Mach-O cputype == 0x01000007 (x86_64)	native on x86_64 Darwin; Rosetta 2 on arm64 Darwin
TestBuildCrossWasm32WASI	wasm32-wasi	Wasm 1.0 magic + version 1	wasmtime / wasmer / wasm3 when on PATH

The run-gate is the load-bearing piece of "the target binary actually runs and prints 42". On the Apple Silicon recording host, three of the five gates execute (both Darwin triples natively, wasm32-wasi via wasmtime) and assert stdout matches "42\n". The two Linux ELF gates skip the run-step (Homebrew on macOS does not ship qemu-user; only qemu-system) but the build-gate (e_machine field) still fires. On a linux/amd64 CI runner with apt install qemu-user-static, all five run-gates fire.

The runner detection lives in one helper (findRunner(triple)) so adding a new target is a single switch arm. Native execution is encoded as runner{cmd:""} (runBinary invokes the binary directly with no emulator prefix) which lets the macOS native pair share the same runner-dispatch shape as the qemu / wasmtime cases.

§9 target matrix update

Target ISA	OS	Format	ABI	Phase 5.0 status
x86_64	Linux	ELF	SysV	LANDED (build)
aarch64	Linux	ELF	AAPCS64	LANDED (build)
aarch64	macOS (Apple Silicon)	Mach-O	Apple ABI	LANDED (build + native run)
x86_64	macOS	Mach-O	SysV	LANDED (build + Rosetta run)
wasm32	browser + WASI	.wasm	Wasm 3.0 + GC	LANDED (build + wasmtime run)

The --target=c --triple=<each> invocation from this aarch64-darwin host produces the correctly-tagged foreign-arch binary in every row; the macOS pair and wasm32-wasi rows also exercise the binary end-to-end.

Smoke test (CLI, recorded on the Phase 5.0 host)

$ echo 'print(42)' > /tmp/answer42.mochi
$ mochi build --target=c --triple=aarch64-macos --binary=/tmp/answer42.arm64 /tmp/answer42.mochi
binary /tmp/answer42.arm64
$ /tmp/answer42.arm64
42
$ mochi build --target=c --triple=x86_64-macos --binary=/tmp/answer42.x64 /tmp/answer42.mochi
binary /tmp/answer42.x64
$ /tmp/answer42.x64
42
$ mochi build --target=c --triple=wasm32-wasi --binary=/tmp/answer42.wasm /tmp/answer42.mochi
binary /tmp/answer42.wasm
$ wasmtime run -- /tmp/answer42.wasm
42

Limitations and deferred sub-phases

Sub-phase	Scope
5.0.1	Linux ELF run-gate via Docker / Lima / Colima fallback on macOS hosts (qemu-user is Linux-only via Homebrew). Currently the macOS dev-loop skips that run-step; CI fires it.
5.1	Auto-detect the host triple and use the system cc directly when --triple matches the host (skip the zig-cc default to avoid the extra zig dependency on hosts that already have a native toolchain).
5.2	Larger-program cross-builds: the §10.7 BG fixture suite under every §9 triple, not just the one-function answer/42 gate. This is the next user-facing slice; gating one BG fixture per triple lights up the "real Mochi programs build everywhere" promise.
5.3	--portable musl-static cross matrix (deferred from Phase 4.5): --triple=x86_64-linux-musl --portable already produces a statically-linked binary on the host because zig cc defaults to static-musl; pin a test that asserts the linker dropped libc.so dependencies.
5.4	DWARF cross-target: zig cc emits DWARF 4 by default; check it survives the strip step and that gdb on the target host resolves Mochi-source names.

The umbrella Phase 5 row in the §Phased-plan table cannot flip to LANDED in this phase because the gate is "from any phase-1 host produces a single-file binary that runs on a clean machine of the target platform and matches mochi run stdout"; this phase pins the build gate and the macOS + wasm run gates but not the Linux clean-machine run gate. The clean-machine BG-fixture build gate landed in Phase 5.2 (§10.61); the Linux clean-machine run gate moves to Phase 5.2.1 (§10.62), and the umbrella row flips to LANDED there.

§10.59 Phase 4.2.32 closeout (LANDED 2026-05-22 16:14 GMT+7)

Phase 4.2.32 migrates the heap-allocating op families (list, map, f64arr, strarr, mapstri64, listlist, listany, plus the *.tostr constructors) to the registry. Combined with Phases 4.2.30 (string surface) and 4.2.31 (scalar surface), the registry now covers every IR op except the handful whose contracts depend on call-site data or variadic argument shapes.

What migrated

37 ops added to opTable. Constructor entries: OpNewList, OpNewMap, OpNewF64Array, OpNewStrArr, OpNewMapStrI64, OpNewListAny, OpNewListList, OpListConcatI64, OpF64ArrayConcat, OpListAnyGetAny, OpStrArrGetStr, OpStrArrSlice, OpListListGet, OpListListToStr, OpMapStrI64SortedKeys, OpListI64ToStr, OpF64ArrayToStr, OpStrArrToStr. Dispatch entries (each carrying the Mutates flag): OpListLenI64, OpListPushI64, OpListGetI64, OpListSetI64, OpListGetF64, OpListSetF64, OpMapSetI64I64, OpMapGetI64I64, OpMapSetStrI64, OpMapGetStrI64, OpMapLenStrI64, OpF64ArrayLenI64, OpF64ArrayPushF64, OpF64ArrayGetF64, OpF64ArraySetF64, OpStrArrLen, OpStrArrPushStr, OpStrArrSetStr, OpListAnyLen, OpListAnyPushAny, OpListListPush, OpListListLen.

Diff shape

• compiler3/ir/optable.go: 37 new OpInfo entries grouped under a Phase 4.2.32 comment block, organized by family.
• compiler3/ir/types.go: removed the 37 cases from OpCode.String()'s switch. The switch is now down to the open-classification ops (OpInvalid, OpParam, OpConst, OpPhi, OpJsonI64Object, OpCall, OpTailCall, OpFnRef, OpQuery*, OpCallGo).
• compiler3/ir/validate.go: same shrinkage in opContract; the switch is now down to OpJsonI64Object (variadic) and the pass-through default.
• compiler3/verify/verify.go: kindOf shrinks dramatically (Constructor and Dispatch arms removed; the remaining entries are the open-classification ops only). contractResult is now a one-case switch handling only OpJsonI64Object. opIsMutating becomes a one-line registry read (info.Mutates). dispatchArena becomes a one-line registry read (info.Args[0] when info.Kind == KindDispatch). The verify-local readDispatchOps and writeDispatchOps slices empty out; mustClassifyAllDispatch continues to union ir.ReadDispatchOps() and ir.WriteDispatchOps(), which now carry the full Dispatch coverage.

Why this closes a goal

After this phase, the registry is the single source of truth for every IR op aside from the variadic / call-site-dependent stragglers. The legacy switches in ir/types.go, ir/validate.go, and verify/verify.go are no longer the place to add a new op; the explicit fall-through is reserved for ops that genuinely cannot be modeled by OpInfo's fixed schema. The original 4.2.28 drift bug class (rule-E classification slipping out of sync with kindOf) cannot recur on any registered op without explicitly contradicting the registry, which the init-time check rejects.

Concretely, the verify-local opIsMutating and dispatchArena functions are no longer per-op switches that need updating each time a Dispatch op is added; they read the Mutates flag and the first-argument arena Type from the registry entry. Three files (ir/types.go, ir/validate.go, verify/verify.go) no longer change when a new op is added in the canonical workflow.

Limitations

• OpJsonI64Object remains the lone variadic stub in the legacy switches. Migrating it requires extending OpInfo with a Variadic flag (or a sentinel NumArgs == -1); deferred to a phase that has an actual second variadic op to motivate the schema change.
• OpCall, OpTailCall, OpCallGo, OpFnRef, and the OpQuery* family are deliberately not registered. Their result Types are call-site dependent (OpCall's result is the callee's declared Result), and a static OpInfo.Result field cannot capture that. A separate registry slot for these would need a ResultFromCallee indicator; deferred.
• OpParam, OpConst, OpPhi, OpInvalid are also unregistered. Their classification (KindMove, KindInline, KindMove, KindInvalid) is structural and lives at the head of kindOf directly; registering them would not simplify anything.
• The verify-local readDispatchOps and writeDispatchOps slices are now empty but retained as the canonical fall-back slot. They will be removed if every future Dispatch op stays in the registry (the expected steady-state).

§10.58 Phase 4.2.31 closeout (LANDED 2026-05-22 16:01 GMT+7)

Phase 4.2.31 migrates the scalar arithmetic, comparison, bitwise, conversion, and math op families to the registry that Phase 4.2.30 introduced. The 47-op batch (every Op*I64, Op*F64, Op*Bool, plus OpI64ToF64, OpF64ToI64, OpSqrtF64, OpNow) drains the largest chunk of the legacy switches and validates the registry mechanism against the largest op family.

Why now

Phase 4.2.30 introduced the registry but only migrated 10 string ops as the proof point. The legacy switches in ir/types.go (String), ir/validate.go (opContract), and verify/verify.go (kindOf, contractResult) still carried ~70 cases. Every new op added through one of those switches was a re-instance of the per-op file-edit friction the registry was designed to eliminate.

The scalar arithmetic family is the natural next migration: it is the largest op family (47 of the remaining ~70 ops), it is fully homogeneous (every entry is KindOperator with a small fixed-arity scalar contract), and it has no rule-E semantics. Migrating it in one batch validates the registry against a family that is structurally different from the string surface (different operand Types, different Kind, more entries) and shrinks the legacy switches to a manageable residue (~25 ops left, all of them heap-allocating or query-shaped).

What migrated

The 47 ops added to opTable, all KindOperator:

• I64 arithmetic: OpAddI64, OpSubI64, OpMulI64, OpDivI64, OpModI64, OpNegI64.
• I64 immediate arithmetic: OpAddI64Imm, OpSubI64Imm, OpMulI64Imm, OpDivI64Imm, OpModI64Imm. One I64 arg (the immediate is encoded in Value.Const, not an operand).
• F64 arithmetic: OpAddF64, OpSubF64, OpMulF64, OpDivF64, OpNegF64.
• I64 comparisons: OpCmpEqI64, OpCmpNeI64, OpCmpLtI64, OpCmpLeI64, OpCmpGtI64, OpCmpGeI64.
• I64 immediate comparisons: OpCmpEqI64Imm, OpCmpNeI64Imm, OpCmpLtI64Imm, OpCmpLeI64Imm, OpCmpGtI64Imm, OpCmpGeI64Imm.
• F64 comparisons: OpCmpEqF64, OpCmpNeF64, OpCmpLtF64, OpCmpLeF64, OpCmpGtF64, OpCmpGeF64.
• Bool comparisons and logic: OpCmpEqBool, OpCmpNeBool, OpAndBool, OpOrBool, OpNotBool.
• I64 bitwise: OpAndI64, OpOrI64, OpXorI64, OpShlI64, OpShrI64, OpNotI64.
• Conversions: OpI64ToF64, OpF64ToI64.
• Math + time: OpSqrtF64, OpNow (zero-args).

Diff shape

• compiler3/ir/optable.go: 47 new OpInfo entries appended to opTable under a // Phase 4.2.31 comment.
• compiler3/ir/types.go: removed 47 cases from OpCode.String()'s switch. Three head-of-switch comment blocks point to opTable for the migrated names.
• compiler3/ir/validate.go: removed the corresponding 47 cases from opContract's switch (the I64 arith group, I64 imm group, F64 arith group, all comparison groups, bitwise group, conversion group, math group, OpNow). The registry prologue at the top of the function handles them.
• compiler3/verify/verify.go: removed 47 cases from kindOf (the giant KindOperator arm shrinks to case ir.OpJsonI64Object:) and 47 cases from contractResult (the I64/F64/Bool result arms collapse; OpNow removed from its standalone case).

Why this closes a goal

After this phase, the registry covers 57 of the ~80 IR ops. The remaining legacy switch entries are heap-allocating ops (list / map / f64arr / strarr / listany / listlist families) and query/call/control-flow ops (OpFnRef, OpCall, OpTailCall, OpCallGo, OpQuery*, OpPhi, OpParam, OpConst, OpInvalid). The next-phase batch (heap-allocating families) is mechanical; the call/control-flow ops need their own classification pass because their contracts depend on call-site data the registry doesn't yet model.

Adding a new scalar op now requires three edits: declare the OpCode, append the OpInfo literal, write the emit case. The string family in Phase 4.2.30 demonstrated this on KindConstructor / KindDispatch; this phase confirms it on KindOperator, the largest classification.

Limitations

• OpJsonI64Object is still classified ad-hoc in kindOf because its variadic argument shape doesn't match the fixed [3]Type slot. A future phase will extend OpInfo (or add a Variadic flag) so it can join the registry.
• The legacy switches in ir/types.go, ir/validate.go, and verify/verify.go still exist as fall-throughs. They will shrink to zero as remaining ops migrate; the final cleanup deletes the switches once opTable is the only source of truth.
• The Args slot is a [3]Type fixed array; ops with more than three operands (none today, but query joins lean close) would need a wider slot. Deferred to the heap-family migration where the question naturally arises.

§10.57 Phase 4.2.30 closeout (LANDED 2026-05-22 15:46 GMT+7)

Phase 4.2.30 collapses the per-op file-edit tax: a registered op now carries its name, result type, operand types, and verifier kind in a single declarative entry. The String surface (10 ops) is the migration proof; downstream phases add new ops by appending one OpInfo literal plus the op-specific emit cases, not by touching ten files.

The audit that motivated this

The string surface phases (4.2.27 through 4.2.29) repeated the same pattern: declare an OpCode, write a String() case, write an opContract case in ir/validate.go, write a kindOf case in verify/verify.go, write a contractResult case in verify/verify.go, (for Dispatch ops) add an entry to readDispatchOps in verify/verify.go, write the emit case in emit/c/emit.go, write the emit case in emit/go/emit.go, write the frontend lowering hook, write the runtime helper. Nine sites for one op.

Worse, two of those sites (opContract and contractResult) carried the same Result/Args data in independent switches; the Phase 4.2.28 verify panic about OpStrIn (Dispatch OpCode str.in (=40) is not classified for rule E) was the symptom of an additional fourth slot (readDispatchOps) drifting from the kindOf classification. The data was redundant; the drift was silent until the verifier ran.

The mechanism

A new file, compiler3/ir/optable.go, declares an OpInfo struct and an opTable slice. Each entry names the op, its result Type, its operand Types, its OpKind classification (Move / Inline / Constructor / Operator / Dispatch / Call / Reserved), and a Mutates flag (consulted only for Dispatch). The registry is built once at init() into a [256]int index for O(1) lookup; double registration and KindUnclassified entries panic at import time.

The four downstream consumers now read the registry first:

• OpCode.String() consults OpInfoOf for the name.
• ir.opContract() consults OpInfoOf for the operand contract.
• verify.kindOf() consults OpInfoOf and projects ir.OpKind onto the verify-public ProducerKind via producerKindFromIR.
• verify.contractResult() consults OpInfoOf for the result Type.
• verify.mustClassifyAllDispatch() unions ir.ReadDispatchOps() and ir.WriteDispatchOps() (both derived from the registry's Mutates flag) into its rule-E coverage set.

Unregistered ops fall through to the legacy switches unchanged. The migration is incremental: ops can move into the registry one at a time without touching the consumers' fall-through arms.

Diff shape

• compiler3/ir/optable.go: new file. Declares OpKind and OpInfo, defines opTable with 10 entries (the string surface), builds opTableIndex at init, validates no OpInvalid or KindUnclassified entries, rejects double registration. Exposes OpInfoOf, ReadDispatchOps, WriteDispatchOps.
• compiler3/ir/types.go: OpCode.String() consults OpInfoOf at the top; removed 10 migrated cases from the switch.
• compiler3/ir/validate.go: opContract consults OpInfoOf at the top; removed 10 migrated cases from the switch.
• compiler3/verify/verify.go: added producerKindFromIR; kindOf consults OpInfoOf at the top; removed 10 migrated cases (OpCmpEqStr, OpCmpNeStr from the Operator clause; OpLenStr, OpStrIn, OpStrRuneLen from the Dispatch clause; OpConcatStr, OpI64ToStr, OpF64ToStr, OpBoolToStr, OpStrCharAt from the Constructor clause, leaving OpListI64ToStr, OpF64ArrayToStr, OpStrArrToStr until their phases migrate). contractResult consults OpInfoOf at the top; removed the same 10 migrated cases. readDispatchOps drops OpLenStr, OpStrIn, OpStrRuneLen (registry-derived now). mustClassifyAllDispatch unions ir.ReadDispatchOps() and ir.WriteDispatchOps() into its coverage set with a same-op double-list panic.
• compiler3/verify/rule_e_test.go: TestMustClassifyAllDispatchCoversAllDispatchOps also unions the registry-derived slices so the test mirrors the init-time check.

Why this closes a goal

Adding a new IR op was the friction point that slowed every preceding phase. With the registry, the steps shrink to three: declare the OpCode in ir/types.go, append an OpInfo literal to opTable, write the genuinely op-specific emit cases in emit/c and emit/go (plus any frontend lowering hook). The validator, the verifier, and the rule-E classification are all derived from the same single entry; drift between independent switches is no longer possible.

Concretely: the Phase 4.2.28 panic about OpStrIn not being classified for rule E was caused by a copy-paste omission in readDispatchOps. Under the registry, OpStrIn's Mutates: false flag is the source of truth and verify.mustClassifyAllDispatch reads it directly. The same class of bug can't recur without explicitly contradicting the registry, which the init-time check rejects.

Limitations

• Only the 10 string-surface ops are migrated in this phase. The remaining 70-ish ops still live in the legacy switches. Migration is mechanical (move the data, delete the case); follow-up phases will sweep the list / map / f64arr / strarr / listany / listlist families.
• OpInfo.NumArgs is declared but not yet consulted; it is reserved for a future phase that will check args-count uniformly. Today validate.go's switch handles variadic ops (OpJsonI64Object) ad hoc.
• The OpKind and verify.ProducerKind enumerations are kept aligned by producerKindFromIR; a future phase could collapse them, but the current split keeps verify independent of ir for new kinds that don't need IR-level structural meaning.
• The legacy switch fall-through in each consumer is a deliberate compatibility shim; once every op is registered, the switches and their associated fall-through arms can be deleted. That cleanup is gated on completing the migration, not on a phase milestone.

§10.56 Phase 4.2.29 closeout (LANDED 2026-05-22 15:30 GMT+7)

Phase 4.2.29 closes the v0.5 string surface on the C target. for ch in s now iterates UTF-8 runes (matching the VM's for _, ch := range []rune(s) lowering), the v0.5/string.mochi and v0.5/string-index-iterator.mochi fixtures pin end to end, and the lowering combines this phase's new OpStrRuneLen with Phase 4.2.27's OpStrCharAt and Phase 4.2.28's OpStrIn.

Before this phase, for ch in s died at lower time with frontend: for-in over str unsupported (need list). The fix is purely a new arm in lowerForCollection's type switch; the underlying SSA shape (phi-tracked index counter, per-iteration bind of the loop variable, snapshot/restore of pre-loop env) reuses every piece Phases 4.2.23 / 4.2.24 already built for the StrArr / ListList arms.

Diff shape

• compiler3/ir/types.go: new OpStrRuneLen op with String() == "str.rune.len". Result Type is TypeI64; classified Dispatch (read-only, no allocation).
• compiler3/ir/validate.go: contract opSig{TypeI64, [3]Type{TypeStr}}.
• compiler3/verify/verify.go: joined OpStrRuneLen to the Dispatch arm of kindOf, added it to readDispatchOps (rule E coverage), and joined it to the TypeI64 result list in contractResult.
• compiler3/emit/c/emit.go: trigger usesStrRuntime on OpStrRuneLen; emit name = mochi_str_rune_len(s);.
• compiler3/emit/go/emit.go: import unicode/utf8; emit name = int64(utf8.RuneCountInString(s)). Cheaper than materialising []rune(s) (the per-element extraction in OpStrCharAt does that separately).
• runtime/c/src/mochi_str.h and runtime/c/src/mochi_str.c: declare and define int64_t mochi_str_rune_len(const char *s). Walks the byte sequence once counting leader bytes via the existing static mochi_str_utf8_width helper. O(bytes), no allocation.
• compiler3/frontend/lower.go: added case ir.TypeStr to lowerForCollection's type switch, with lenOp = OpStrRuneLen, getOp = OpStrCharAt, elemType = elemElemType = TypeStr. No change to the surrounding phi-bookkeeping; the loop variable ch is reset each iteration to the i-th rune (same shape as for x in xs for any other element type).
• compiler3/build/c/driver_test.go: four new pins.
  • TestBuildSourceStrForChIn is the smallest reproducer: iterate the runes of "hello" and print each.
  • TestBuildSourceStrForChInVowelCount covers the cross-phase interaction with Phase 4.2.28 (ch in vowels inside the loop body).
  • TestBuildSourceV05StringFixture reads examples/v0.5/string.mochi verbatim and pins its complete output (index + len + iteration + containment + vowel count).
  • TestBuildSourceV05StringIndexIteratorFixture does the same for the sibling fixture.

Why this closes a goal

The v0.5 fixture corpus on the binary-build axis gains two: v0.5/string.mochi and v0.5/string-index-iterator.mochi. Combined with the already-green v0.5/while.mochi (pinned in Phase 4.2.25), the v0.5 user-facing corpus is now 3 of 4 (the remaining v0.5 fixture is agent-stream which needs its own stream/agent phase). More fundamentally, every later text-processing surface (lexers, simple template engines, character class filtering) needs both s[i] and for ch in s; this phase closes the loop on both.

Limitations

• Per-iteration cost is O(rune-count). OpStrCharAt walks from the start each call, so the loop is O(n^2) in the rune count of s. Fine for v0.5 (string lengths under 20). A future phase could hoist []rune(s) to a TypeStrArr pre-header value; the lowering's pre-header / phi shape already has a slot for that lift, but no fixture motivates it today.
• mochi_str_rune_len and OpLenStr return different numbers for non-ASCII strings (rune count vs byte length). Mochi's surface-level len(s) continues to map to OpLenStr (byte length), matching the VM; only the for-loop bound uses OpStrRuneLen. A user-facing runes(s) builtin would need its own surface op; deferred.
• Loop variable binding type is TypeStr (single-rune string), not a rune scalar. Mochi has no rune type; this matches the VM. if ch == "h" works (OpCmpEqStr is byte equality, and a single-rune string vs a single-byte literal both have the same byte sequence).
• The Go emit's utf8.RuneCountInString matches the C mochi_str_rune_len for well-formed UTF-8. For malformed sequences both walks fall through to a 1-byte advance (the VM and Go stdlib agree here too) so divergence is impossible on inputs the parser accepts.

§10.55 Phase 4.2.28 closeout (LANDED 2026-05-22 15:23 GMT+7)

Phase 4.2.28 lights up the in operator on TypeStr through the C target. Before this phase, the frontend's applyBinOp TypeStr arm only knew +, ==, and !=; a source like if "w" in s { ... } died at lower time with frontend: operator "in" on str unsupported in MVP. The in token was already in the precedence table, so the parse path was fine; only the IR-level binop dispatch was missing.

The new op OpStrIn takes (needle, haystack) and returns TypeBool. C target emits (strstr(haystack, needle) != NULL) (strstr is in <string.h>, already wired through usesStrH). Go target emits strings.Contains(haystack, needle). Both probes are byte-wise so the two targets agree byte for byte with the VM.

Diff shape

• compiler3/ir/types.go: new OpStrIn op with String() == "str.in". Result Type is TypeBool; classified Dispatch (read-only, no allocation).
• compiler3/ir/validate.go: contract opSig{TypeBool, [3]Type{TypeStr, TypeStr}}.
• compiler3/verify/verify.go: joined OpStrIn to the Dispatch arm of kindOf, added it to readDispatchOps (rule E coverage), and joined it to the TypeBool result list in contractResult.
• compiler3/emit/c/emit.go: trigger usesStrH on OpStrIn and emit name = (strstr(haystack, needle) != NULL);.
• compiler3/emit/go/emit.go: import strings and emit name = strings.Contains(haystack, needle).
• compiler3/frontend/lower.go: added case "in" to the TypeStr arm of applyBinOp, setting code = OpStrIn and resType = TypeBool. The l/r argument order from applyBinOp(op, l, r) lines up with the op contract directly (Args[0]=needle=l, Args[1]=haystack=r).
• compiler3/build/c/driver_test.go: two new pins.
  • TestBuildSourceStrInBasic covers both arms: a positive if "w" in s and a negative if "z" in s (else branch).
  • TestBuildSourceStrInSubstring covers multi-byte needles. "ell" appears at offset 1 of "hello"; the reversed "lle" does not. This catches a buggy implementation that only checks for single-character containment.

Why this closes a goal

The v0.5/string.mochi fixture has two in lines (if "w" in s and if "z" in s) that previously rejected at lower time; both now build on the C target. The same gate also unblocks the inner if ch in vowels line of the rune-iteration loop, so once Phase 4.2.29 lands the rune iterator, the full fixture pins end to end. More broadly, substring containment is the load-bearing primitive for every later text-processing fixture (lexers, simple template engines, log filtering).

Limitations

• TypeMapStrI64 still rejects k in m at the same applyBinOp site. Maps are a separate phase: the runtime probe is mochi_map_str_i64_has(m, k) rather than strstr, and the op classification is the same (Dispatch, read-only) but the contract is [3]Type{TypeStr, TypeMapStrI64}. Deferred until a fixture motivates it.
• TypeList / TypeF64Arr / TypeStrArr x in xs containment is also unsupported (linear scan over the array). No v0.5 fixture exercises this today.
• The empty-needle case ("" in haystack) returns true on both targets (strstr returns the haystack pointer; strings.Contains returns true). This matches the VM and is by design but is worth flagging in case a future fixture relies on "" being absent (it never will be).
• Substring search is byte-wise. For multi-byte UTF-8 needles that share a leading byte with a non-needle multi-byte rune, the strstr probe still produces the right answer because UTF-8 is self-synchronising (any byte that could start a continuation cannot be a leading byte of a different rune). No special handling needed.

§10.54 Phase 4.2.27 closeout (LANDED 2026-05-22 15:14 GMT+7)

Phase 4.2.27 lights up s[i] on TypeStr through the C target. Before this phase, the frontend's lowerPostfix index branch rejected anything that wasn't TypeList, TypeF64Arr, TypeStrArr, TypeMap, TypeMapStrI64, TypeListAny, or TypeListList; a Mochi source like print("hello"[0]) died at lower time with "index on non-list str". The VM lowering for the same expression is string([]rune(s)[i]) (rune-based, not byte-based), so the C target's runtime helper walks the UTF-8 byte sequence to the i-th rune leader and copies its leader + continuation bytes into a freshly allocated NUL-terminated buffer. ASCII input (the entire v0.5 fixture corpus) collapses to the 1-byte arm.

Diff shape

• compiler3/ir/types.go: new OpStrCharAt op with String() == "str.charat". Result Type is TypeStr; classified Constructor under verifier rule A because TypeStr is HandleType and the helper returns a fresh allocation.
• compiler3/ir/validate.go: contract opSig{TypeStr, [3]Type{TypeStr, TypeI64}} so Validate enforces argument shape.
• compiler3/verify/verify.go: joined OpStrCharAt to the Constructor list (kindOf) and the contract-result table (contractResult).
• compiler3/emit/c/emit.go: trigger usesStrRuntime on OpStrCharAt (so mochi_str.h gets included) and emit name = mochi_str_char_at(s, i);.
• compiler3/emit/go/emit.go: emit name = string([]rune(s)[i]) so the Go target byte-matches the VM and the C target.
• runtime/c/src/mochi_str.h: add #include <stdint.h>; declare const char *mochi_str_char_at(const char *s, int64_t i);.
• runtime/c/src/mochi_str.c: add static mochi_str_utf8_width(unsigned char) helper (UTF-8 leading-byte width: 1/2/3/4 by prefix, falling through to 1 for continuation bytes or malformed leaders) and mochi_str_char_at that walks the byte sequence to the i-th rune leader and allocates a fresh single-rune string.
• compiler3/frontend/lower.go: relax the index rejection check to admit TypeStr; require the index to be i64 (parallel to the list arm); add a case ir.TypeStr to the get-op switch that emits OpStrCharAt.
• compiler3/build/c/driver_test.go: three new pins.
  • TestBuildSourceStrCharAtBasic covers literal indexing twice, s[0] and s[4] on "hello".
  • TestBuildSourceStrCharAtConcat covers HandleType liveness: the result of s[0] is fed straight into + (OpConcatStr).
  • TestBuildSourceStrCharAtLoopIndex covers indexing under a dynamic i64 induction variable (while-loop walking the full string one rune per iteration).

Why this closes a goal

The v0.5/string.mochi fixture's first three lines (let s = "hello world", print("s[0] =", s[0]), print("s[4] =", s[4])) now build on the C target. The remainder of v0.5/string.mochi (for ch in s and "x" in s) still needs separate phases (rune iteration and substring containment); Phase 4.2.28 / 4.2.29 will tackle those in turn. The v0.5/string-index-iterator.mochi fixture has the same shape and is unblocked at the same point. More broadly, string indexing is the load-bearing primitive that every later string-handling fixture (text search, parser-style loops, ASCII transforms) needs, so this phase unlocks the runway for the rest of the string surface even before the iteration / containment ops land.

Limitations

• OOB is unchecked. Past-end indices walk to the NUL terminator and return an allocation holding "". This matches the existing C-target list-get convention; a future hardening phase can add a runtime wrap helper if a fixture motivates it.
• Negative indices on strings are not supported. The Phase 4.2.24 constant-fold for negative list indices is the same trick that would apply here, but no v0.5/v0.6 fixture exercises a negative string index today.
• Slicing (s[1:3]) remains rejected by the same idx.Colon != nil branch that gates list slicing. Strings would route through a separate mochi_str_slice helper; deferred until a fixture surfaces.
• The Go emit currently rebuilds []rune(s) on every index. That's quadratic on a tight loop. The VM does the same so this matches mochi run byte for byte; a per-loop hoist would be an optimiser pass, not a Phase 4.2.x correctness gate.
• The runtime helper allocates per call and never frees. Identical to the existing concat / i64-to-str / f64-to-str carriers; the process-exit leak is documented in mochi_str.h.

§10.53 Phase 4.2.26 closeout (LANDED 2026-05-22 15:02 GMT+7)

Phase 4.2.26 fixes a long-standing link-time failure on declaration-only and commented-out Mochi sources. Before this phase, mochi build --target=c examples/v0.1/stream.mochi (entirely block-commented) and examples/v0.6/extern.mochi (only extern declarations) failed at cc with Undefined symbols: _main. The frontend lowered the empty program to a Program with zero Funcs, the emitter then skipped int main(void) because p.Main == "", and the resulting object had no entry point.

The fix is a one-line emit-time fallback: when p.Main == "", emit int main(void) { return 0; } instead of nothing. This changes the contract of "empty Main" from "no main, library-style object" to "no-op main, runs and exits 0". The previously-referenced "future --emit=c-library mode" is not wired up today, and when it lands it will need a distinct Options.Library flag (or a sentinel Options.Main value) to gate this branch off explicitly.

The semantics match mochi run on the same sources: a program with no executable top-level statements does nothing and exits 0. Three v0.1/v0.6 fixtures now build to runnable binaries that print empty stdout (verified end to end with runMochiBuild).

Diff shape

• compiler3/emit/c/emit.go: the if p.Main != "" block in Emit gets an else arm that writes int main(void) { return 0; }.
• compiler3/build/c/driver_test.go: four new pins.
  • TestBuildSourceV01StreamFixture reads examples/v0.1/stream.mochi (entirely block-commented), expects empty stdout.
  • TestBuildSourceV01AgentFixture reads examples/v0.1/agent.mochi (same shape), expects empty stdout.
  • TestBuildSourceV06ExternFixture reads examples/v0.6/extern.mochi (declaration-only), expects empty stdout.
  • TestBuildSourceEmptyScriptLinks covers the comment-only edge case directly with an inline // just a comment source.

Why this closes a goal

The v0.1 user-facing corpus on the binary-build axis goes from 7 of 17 to 9 of 17 green (stream + agent newly link). The v0.6 corpus is unblocked at the extern-declarations gate, raising it from 0 of 18 to 1 of 18; the remaining v0.6 fixtures all require dataset/query operations that stay a separate gate. The bigger win is that mochi build no longer requires every script to have at least one executable statement, which removes a footgun for users following the v0.1 tutorials that introduce syntax via commented-out examples.

Limitations

• Does not address v0.4/stream.mochi (a fully-uncommented stream/agent program) or v0.5/agent*.mochi: those still hit frontend: statement kind unsupported in MVP at lower time, well before reaching cc. Stream/agent semantics need their own phase.
• The emit-time fallback is unconditional. A future library-mode build (--emit=c-library) will need an explicit opt-out so it doesn't get a spurious main symbol; this is fine since the library mode is not yet implemented.
• The Go target was not audited in this phase. If a parallel link failure exists there, it would be a separate Go-emit fix.

§10.52 Phase 4.2.25 closeout (LANDED 2026-05-22 14:55 GMT+7)

Phase 4.2.25 is a defensive-pin phase. After Phase 4.2.24 closed the v0.2 user-facing corpus, auditing the next user-facing version corpora (v0.5, v0.7) surfaced three fixtures that already build and run correctly on the C target without any code change: examples/v0.5/while.mochi, examples/v0.7/if_expr.mochi, and examples/v0.7/empty_list.mochi. None had a fixture-level regression test pinning the exact on-disk bytes against the C-target stdout, so a future regression in either the example or the lowering would have gone silent on these programs. This phase pins all three.

No frontend, IR, emit, or runtime change. The features each fixture exercises (while + var mutation; block-form if as a value; explicit list<int> empty binding plus the as-cast empty form) were each landed in earlier phases for unrelated reasons; this phase just extends the corpus-level safety net to cover them.

Diff shape

• compiler3/build/c/driver_test.go: three new fixture pins.
  • TestBuildSourceV05WhileFixture reads examples/v0.5/while.mochi, expects 0\n1\n2\n.
  • TestBuildSourceV07IfExprFixture reads examples/v0.7/if_expr.mochi, expects Status: adult\n.
  • TestBuildSourceV07EmptyListFixture reads examples/v0.7/empty_list.mochi, expects []\n[]\n.

Why this closes a goal

The MEP-42 Phase 4 umbrella's user-facing goal extends beyond v0.2. v0.5 and v0.7 are tutorial corpora that today have a mixed pass/fail profile on the C target (audit notes below). Pinning the already-green fixtures locks in the wins so the visible user-facing coverage stays at least at today's level. The next code-change sub-phase (Phase 4.2.26 onward) is then free to attack a real feature gap without risking silent regression on these programs.

Audit snapshot at the time of this phase (binary-build axis only):

Corpus	Green / Total	Already-pinned	Newly pinned this phase	Notes
v0.5	1 / 5	0	while.mochi	string, string-index-iterator need string indexing; agent, agent-stream need stream/agent statements
v0.7	2 / 8	0	if_expr.mochi, empty_list.mochi	eval, input need builtins; main, docs need package/import; tree needs ADT union types; strings_trim needs go FFI for strings.Split

Limitations

• This phase does not move the user-facing v0.5 or v0.7 corpus gates (1/5 and 2/8 stay at 1/5 and 2/8 respectively). Closing those corpora needs separate phases for string indexing, eval/input builtins, package/import, ADT/union types, and stream/agent statements.
• The fixture pins are read-only on the examples. If a fixture's expected stdout ever drifts intentionally (a tutorial rewrite) the test would catch it as a regression. That is the desired shape: the test is the gate, the fixture is the source of truth.
• No regression-test for v0.6 / v0.8 / v0.9 / v0.11 was added in this phase; v0.6 is entirely dataset/query operations (separate gate), v0.8 / v0.9 / v0.11 have no examples directory today, and v0.10 already has TestBuildSourceV010IfThenElseFixture pinned.

§10.51 Phase 4.2.24 closeout (LANDED 2026-05-22 14:42 GMT+7)

Phase 4.2.24 is the third and last sub-phase of the v0.2/for-in.mochi gate. After Phases 4.2.22 (map literal inference) and 4.2.23 (map iteration), the fixture failed at block 4's for row in matrix; for col in row with frontend: for-in over listlist unsupported (need list). This phase adds TypeListList to lowerForCollection and closes the whole v0.2 user-facing corpus on the C target.

The implementation is a one-arm extension of the existing for-collection lowerer. TypeListList already has OpListListLen (read Dispatch) and OpListListGet (Constructor: returns the inner TypeList row as a borrowed handle into the outer array, classified Constructor under rule A because TypeList is HandleType). The loop variable binds to the inner TypeList, and a nested for col in row then dispatches through the existing TypeList arm. No new IR ops, no runtime change.

One subtle correctness fix lives in this phase: the elemID bind in lowerForCollection was setting ElemType = elemType, which is fine for scalar element types (TypeI64, TypeF64, TypeStr ignore the field on a scalar value) but wrong for the new TypeList element case where ElemType should be the row's element type (TypeI64), matching the convention lowerPostfix uses when emitting OpListListGet directly. The fix introduces elemElemType as the ElemType hint per case; existing arms set it to the same value as elemType for byte-identical behaviour, and the new arm sets it to TypeI64.

Diff shape

• compiler3/frontend/lower.go: lowerForCollection adds a TypeListList arm (OpListListLen + OpListListGet + elemType TypeList + elemElemType TypeI64). The elemID addValue now uses elemElemType instead of elemType for the ElemType field.
• compiler3/build/c/driver_test.go: TestBuildSourceForInListList pins the canonical nested-list iteration shape from block 4. TestBuildSourceV02ForInFixture pins the on-disk v0.2/for-in.mochi fixture verbatim against mochi run's output.

Why this closes a goal

The v0.2/for-in.mochi fixture compiles end to end on the C target. With for-in.mochi green the v0.2 user-facing matrix on the binary-build axis goes from 5 of 6 to 6 of 6 green:

Fixture	C target status
shadow.mochi	green
π.mochi	green (Phase 4.2.19)
map.mochi	green (Phases 4.2.18 + 4.2.19)
list.mochi	green (Phase 4.2.20)
matrix.mochi	green (Phase 4.2.21)
for-in.mochi	green (Phases 4.2.22 + 4.2.23 + 4.2.24, this phase)

The MEP-42 Phase 4 umbrella's user-facing goal ("Mochi v0.2 programs compile via mochi build --target=c and produce byte-identical output to mochi run") is now satisfied for the entire v0.2 user-facing corpus. The umbrella phase still has its broader fixture-corpus targets in §10's matrix; this phase closes the v0.2/* sub-target.

Limitations

• Mochi's for k, v in m (key-value destructuring) is still not handled; the fixture only exercises for k in m, so this stays a future widening.
• Nested-list iteration is locked to int64 element rows (TypeListList only carries list<list<int>>). list<list<float>> and list<list<str>> iteration would each need its own carrier first.
• The ElemType fix shifts a subtle field for the existing TypeList/TypeF64Arr/TypeStrArr arms (all from elemType to elemElemType, which is bound to the same value as elemType for those arms). This is bit-identical with the previous behaviour for scalar element types but means a future "iterate over a nested list whose inner list also has a nontrivial elem hint" would need to re-examine the field plumbing.

§10.50 Phase 4.2.23 closeout (LANDED 2026-05-22 14:37 GMT+7)

Phase 4.2.23 is the second of the three sub-phases for v0.2/for-in.mochi. After Phase 4.2.22 cleared the untyped map binding, the fixture next failed at for name in scores with frontend: for-in over mapstri64 unsupported (need list). This phase adds map iteration on the C target by lowering for k in m (where m is TypeMapStrI64) to iteration over a sorted-keys list, matching the Mochi reference VM which sort.Strings the keys before iterating.

The carrier choice is "convert, don't iterate." The IR could grow a dedicated map-iterator op family (next, valid, key), but that would duplicate the cursor machinery the existing for-collection arm already provides for TypeStrArr. Adding a single OpMapStrI64SortedKeys op that returns a fresh TypeStrArr means map iteration desugars to let keys = sortedkeys(m); for k in keys { body }, which goes through the existing TypeStrArr arm unchanged. The cost is one map walk + qsort per loop entry; the win is zero new iteration ops and a one-line frontend rewrite. The sorted-order requirement comes from the VM (it does sort.Strings before iterating in vm_eval.go:1364), so reuse-of-sorted-keys would not have been right either: each loop entry deserves its own walk in case the map mutated between iterations.

The runtime helper mochi_map_str_i64_sorted_keys collects every occupied bucket into a temporary const char ** buffer, runs qsort with a strcmp-based comparator, then pushes each key into a freshly-allocated mochi_str_array via the existing mochi_str_array_push (which itself doubles from cap=4 on first push). The intermediate buffer is freed before return. Keys are borrowed (the array shares the same const char * storage as the map), so a key whose pointer outlives the map outlives the array too. The Go emitter mirrors the same shape with an inline IIFE that does make + range + append + sort.Strings.

Diff shape

• compiler3/ir/types.go: new op OpMapStrI64SortedKeys; String() case "map.str.i64.sortedkeys".
• compiler3/ir/validate.go: opContract entry TypeStrArr -> TypeMapStrI64.
• compiler3/verify/verify.go: op joins the Constructor list (rule A: TypeStrArr is HandleType, so the get-op must originate from Constructor/Move/Inline/Call); contractResult returns TypeStrArr. Not a Dispatch, so no dispatchArena entry.
• compiler3/emit/c/emit.go: trigger sets both usesMapStrI64 and usesStrArray so the str-array header lands too; emit case mochi_map_str_i64_sorted_keys(m).
• compiler3/emit/go/emit.go: emit case for the IIFE shape (registers the "sort" import on the spot).
• runtime/c/src/mochi_map_str_i64.{h,c}: header now #include "mochi_str_array.h"; new mochi_map_str_i64_sorted_keys function + a static mochi_map_str_keycmp comparator.
• compiler3/frontend/lower.go: lowerForCollection recognises TypeMapStrI64, emits OpMapStrI64SortedKeys, and rewrites the loop subject to the produced TypeStrArr. Everything else (header phis, body, cont) goes through the existing TypeStrArr arm.
• compiler3/build/c/driver_test.go: TestBuildSourceForInMapStrI64 pins the canonical block-2 shape with deliberately-out-of-order inserts (Charlie, Alice, Bob) so the sort is observable. TestBuildSourceForInMapStrI64Empty pins the empty-map path: zero passes through the loop, prefix and suffix prints still fire.

Why this closes a goal

The v0.2/for-in.mochi fixture's block 2 now compiles. The next failure on the fixture moves from for-in over mapstri64 unsupported to for-in over listlist unsupported, which is block 4's for row in matrix. The binary-build matrix is still 5 of 6 green on its own axis, but the for-in.mochi gate is one sub-phase from closing (Phase 4.2.24 for nested-list iteration). Block 1 (list) and block 3 (range) were already supported, so once nested-list iteration lands the whole fixture compiles end to end.

Limitations

• Sorted-order iteration is part of the contract on both targets. A future "iterate in insertion order" mode (if Mochi ever surfaces one) would need its own op family because the map carrier does not track insertion order today.
• The conversion walk is O(n) on every loop entry. A map that grows mid-loop will not surface its new entries because the keys snapshot was taken before the loop began. This matches mochi run behaviour (the VM also snapshots the sorted key list at OpIter time).
• The helper only covers map<str, i64>. A future map<i64, i64> iteration phase would need its own SortedKeys op (or a generic one) and another runtime helper.
• Keys are borrowed; freeing the map invalidates the returned mochi_str_array. The Phase 4 MVP leaks both at process exit, so this is invisible from the source-program side.

§10.49 Phase 4.2.22 closeout (LANDED 2026-05-22 13:40 GMT+7)

Phase 4.2.22 is the first of three sub-phases targeting the v0.2/for-in.mochi fixture, the only remaining v0.2 user-facing gate. The fixture has four blocks; the first one to fail is block 2's untyped binding let scores = {"Alice": 90, ...}, which previously hit frontend: map literal requires map<int, int> or map<str, i64> type annotation on the binding. This phase teaches lowerMapLiteralAsExpr to infer the carrier from the first key when no annotation is set.

The inference rule is intentionally narrow. With two map families on the C target today (TypeMap for the map<int, int> empty-only carrier and TypeMapStrI64 for the full str-keyed family), the only inference path that can produce a working non-empty literal is map<str, i64>; the int-keyed family stays empty-only and would reject the next push anyway. Choosing that target means the inference contract is: an untyped non-empty {...} literal whose first key is a str literal infers map<str, i64>; everything else still reports the annotation error so the user can clarify. Empty {} literals without a hint still report the annotation error (no first key to peek at, and choosing one carrier silently would be confusing).

The implementation extracts the entry-0 key-lowering into the inference probe and feeds the resulting SSA value into a shared lowerMapStrI64Body helper that both the annotated and inferred paths now call. Reusing the lowered key id avoids re-evaluating a side-effecting key expression a second time. The rejection path reports untyped map literal first key must be str (inferred map<str, i64>), got <T> so the user sees both the inferred carrier and the offending key type.

Diff shape

• compiler3/frontend/lower.go: lowerMapLiteralAsExpr now has three arms (annotated map<str, i64>, untyped non-empty inference, annotated map<int, int>); the str-i64 body is factored into lowerMapStrI64Body and called from both the annotated and inferred arms. No new IR ops, no runtime change.
• compiler3/build/c/driver_test.go: TestBuildSourceMapStrI64Inferred pins the canonical untyped let scores = {"Alice": 10, "Bob": 15} shape, including the implicit zero-default on an absent key and len(scores). TestBuildSourceMapStrI64InferredNonStrKey pins the rejection error for let m = {1: 2} so a future widening of the int-keyed family doesn't silently let it through.

Why this closes a goal

The for-in.mochi fixture had three intertwined sub-gates blocking it (untyped map literal, map iteration, range iteration). With this phase, the first block-2 line let scores = {"Alice": 90, ...} now lowers; the next failure on the fixture moves from the literal binding to frontend: for-in over mapstri64 unsupported (need list). The user-facing matrix is unchanged on the binary-build axis (still 5 of 6 green), but the path to closing for-in.mochi is now narrower: the next sub-phase is for-in over map<str, i64>, then for-in over list<list> for block 4. Range iteration (block 3) and list iteration (block 1) already work, so once map iteration and nested-list iteration land the fixture closes.

Limitations

• Untyped empty {} still reports the annotation error. An empty literal could in principle infer to either map family, but the int-keyed carrier can't accept a later non-empty assignment to the same binding (it's empty-only), so silently picking one carrier would surprise the user when a later push fails. The annotation-required error is the safer default until the int-keyed carrier widens.
• Inference targets only map<str, i64>. A binding like let m = {1: 2} rejects because the int-keyed carrier still only supports empty literals; widening it is its own carrier-family change, not an inference change.
• The inference probe lowers the first key in the outer scope (no nested map-literal context applies). A key expression that itself contains a nested untyped map literal would inherit no inference context for the nested literal; the nested literal would have to be annotated. No v0.2 fixture exercises that.

§10.48 Phase 4.2.21 closeout (LANDED 2026-05-22 13:12 GMT+7)

Phase 4.2.21 lands the nested list<list<int>> carrier on the C target. Before this phase the v0.2/matrix.mochi binding let matrix = [[1,2,3],[4,5,6],[7,8,9]] failed at lowerListLiteral with frontend: list literal element type list unsupported in MVP, since the outer literal's first element resolved to TypeList and no carrier accepted it. The phase adds a typed nested-list family of ops + runtime, closing matrix.mochi end to end and moving the v0.2 user-facing matrix to 5 of 6 green.

The carrier choice is deliberate. The IR could have routed the outer literal through TypeListAny (the existing self-referential any-list backed by mochi_tree), but the any-tree pays a tag-dispatch cost on every read and can't return a typed int64_t from a chained index without a runtime cast. Adding TypeListList as a typed nested-list keeps matrix[i][j] in the typed-i64 path: the outer get returns mochi_list_i64*, the inner get returns int64_t. The cost is one new runtime header and one new carrier; the win is zero tag overhead on the matrix-style fixtures the v0.2 corpus advertises as "this is what Mochi does well."

The runtime layout mirrors mochi_list_i64: a heap struct with a mochi_list_i64** data array plus len / cap, doubling-growth from a first-push capacity of 4, no per-row copy on push (the outer struct borrows the caller's row pointer). The display formatter walks the outer array once, calls mochi_list_i64_to_str for each row (caching the per-row pointer), measures the joined width, then assembles the final [[1, 2, 3], ...] form in one malloc. Per-row strings remain owned by the inner formatter (heap, leaked at process exit), so the outer formatter only holds pointer carriers and the temporary scratch array is freed before return.

Verifier classification follows the established handle-typed dispatch pattern. OpNewListList is Constructor (alloc). OpListListGet is Constructor too (its result is TypeList, a HandleType, so rule A requires Constructor origin; the rationale matches OpStrArrGetStr and OpListAnyGetAny: the get-op produces a fresh-looking handle whose payload is a derived pointer into the outer array, not arbitrary bits). OpListListPush is a write Dispatch (rule E mutating). OpListListLen is a read Dispatch returning TypeI64 (value-shaped, no rule A obligation). OpListListToStr is Constructor (result is TypeStr, a HandleType). TypeListList joins HandleType so a future fun parameter of nested-list shape will permit OpParam origin (KindMove).

Diff shape

• compiler3/ir/types.go: added TypeListList and ops OpNewListList, OpListListPush, OpListListGet, OpListListLen, OpListListToStr; String() cases for both.
• compiler3/ir/validate.go: opContract entries (TypeListList / TypeUnit / TypeList / TypeI64 / TypeStr results; arg type triples).
• compiler3/verify/verify.go: TypeListList joins HandleType; ops join their respective kindOf / contractResult / opIsMutating / readDispatchOps / writeDispatchOps / dispatchArena tables.
• runtime/c/src/mochi_list_list.{h,c}: new files. Outer struct + new / len / push / get / to_str. The header includes mochi_list_i64.h so callers see the full row type.
• runtime/c/doc.go: added the two new files to the embed list.
• compiler3/emit/c/emit.go: usesListList trigger (which also forces usesListI64 so mochi_list_i64 is available for inner rows); #include "mochi_list_list.h"; emit cases for all five ops; cType case to mochi_list_list*.
• compiler3/emit/go/emit.go: goType case to [][]int64; emit cases (native Go append/index/len for the structural ops; an inline two-level Join for OpListListToStr that matches the C runtime byte for byte).
• compiler3/frontend/lower.go: lowerType accepts list<list<int>>; lowerListLiteral infers TypeListList when the first element resolves to TypeList and handles its allocate/push lowering; lowerPostfix accepts indexing on TypeListList, extends the constant-negative-index fold, and emits OpListListGet; len() builtin recognises TypeListList; both the single-arg print() path and liftToStr lift TypeListList through OpListListToStr.
• compiler3/build/c/driver_test.go: 4 new tests. TestBuildSourceListListBasic pins the canonical literal + index + nested index shapes. TestBuildSourceListListNegIndex pins the negative-index fold for the outer carrier. TestBuildSourceListListLen pins len(matrix) and len(row) after extraction. TestBuildSourceV02MatrixFixture pins the on-disk v0.2/matrix.mochi fixture.

Why this closes a goal

The v0.2 user-facing matrix moves from 4 of 6 green to 5 of 6 green:

Fixture	C target status
shadow.mochi	green (always was)
π.mochi	green (Phase 4.2.19)
map.mochi	green (Phase 4.2.18 + 4.2.19)
list.mochi	green (Phase 4.2.20)
matrix.mochi	green (Phase 4.2.21)
for-in.mochi	still fails (untyped let scores = {...} map literal needs key-type inference + map iteration + range iteration)

Five of six v0.2 user-facing fixtures green on the C target. for-in.mochi is the last v0.2 gate, and it has three intertwined sub-gates (untyped map inference, for k in map, for i in a..b), so a future phase will likely split it into three sub-phases.

Limitations

• The MVP locks the inner element type to int64. list<list<float>>, list<list<str>>, list<list<list<int>>> (three-deep) all fall back to the existing frontend: list<...> unsupported rejection. Each one needs its own typed carrier (matrix.mochi only exercises i64).
• The Go emitter wraps the inner Push with append(m, row) which mutates the slice header in place; this is consistent with the existing TypeList Push behaviour but means an SSA value that aliases the outer slice header will see the post-push state. The Phase 4 MVP does not produce aliased outer handles today, so the difference is invisible from the source-program side.
• print(matrix) lifts through OpListListToStr to get the display form, which means a future print(matrix, sep) shape (if Mochi ever exposes one) would need separate plumbing. The current print path is space-joined; the single-arg fast path uses one fmt.Println call.
• Outer-list concat is not yet implemented. [m1, m2] works (it lowers as TypeListList), but m1 + m2 (if Mochi ever surfaces it for list<list>) would need OpListListConcat. No v0.2 fixture exercises it.

§10.47 Phase 4.2.20 closeout (LANDED 2026-05-22 12:54 GMT+7)

Phase 4.2.20 lands the bound xs[a:b] slice form on TypeStrArr. Before this phase the v0.2/list.mochi binding let some = fruits[1:3] failed at the frontend lowerPostfix slice branch with frontend: slice indexing unsupported in MVP, blocking the v0.2 list fixture even though all surrounding statements already compiled. The phase adds OpStrArrSlice, a tiny runtime helper, and a one-arm lowering branch that closes list.mochi's last gate.

The runtime helper mochi_str_array_slice does a single-pass copy of the element pointer carriers; the underlying string bytes are not duplicated, mirroring Go's slice-shares-backing-array semantics for the read path. Bounds are clamped to [0, src->len] and end < start returns the empty array, matching Go's behaviour for the equivalent inputs (the C target deliberately does not panic on out-of-range bounds in this MVP; panicking would require a stack-unwind path, which Phase 4 does not yet have). The Go emitter uses native xs[a:b] syntax wrapped in append([]string{}, ...) to break the backing-array share so the source array's later mutations do not corrupt the slice.

The verifier classification reuses the existing handle-typed dispatch pattern. OpStrArrSlice is Constructor: it produces a fresh TypeStrArr, so rule A is satisfied by origin (the alloc itself is the constructor, not a move from an existing carrier). The element pointers stored inside the returned struct are not separate IR values, so rule A does not propagate to them; lifetime of the pointed-at bytes is the carrier contract of TypeStr documented in mochi_str_array.h.

Diff shape

• compiler3/ir/types.go: added OpStrArrSlice op + strarr.slice String case.
• compiler3/ir/validate.go: opContract entry returning (TypeStrArr, [TypeStrArr, TypeI64, TypeI64]).
• compiler3/verify/verify.go: OpStrArrSlice joins Constructor list and contractResult.
• runtime/c/src/mochi_str_array.{h,c}: added mochi_str_array_slice declaration plus implementation. Clamp + memcpy of element pointer carriers.
• compiler3/emit/c/emit.go: trigger usesStrArray on OpStrArrSlice; emit one-line call to mochi_str_array_slice.
• compiler3/emit/go/emit.go: emit append([]string{}, xs[a:b]...) so the returned slice does not share the source's backing array.
• compiler3/frontend/lower.go: new branch in lowerPostfix's index op handler that catches idx.Colon != nil && idx.Start != nil && idx.End != nil (no Colon2, no Step), validates the element type is TypeStrArr and both bounds are TypeI64, then emits OpStrArrSlice. The pre-existing MVP rejection still fires for unsupported slice shapes (half-open, full-copy, step) and for slicing other element types.
• compiler3/build/c/driver_test.go: 3 new tests. TestBuildSourceListStrSlice covers the canonical xs[1:3] case; TestBuildSourceListStrSliceClamp covers the runtime's end-past-len clamp and the empty-result rule; TestBuildSourceV02ListFixture pins the v0.2/list.mochi fixture end to end.

Why this closes a goal

The v0.2 user-facing matrix moves from 3 of 6 green to 4 of 6 green:

Fixture	C target status
shadow.mochi	green (always was)
π.mochi	green (Phase 4.2.19)
map.mochi	green (Phase 4.2.18 + 4.2.19)
list.mochi	green (Phase 4.2.20)
for-in.mochi	still fails (untyped let scores = {...} map literal needs key-type inference; also map iteration for k in m)
matrix.mochi	still fails on nested list<list<i64>>

Four of six fixtures green. The remaining two each map cleanly onto a future phase.

Limitations

• Half-open slice shorthand (xs[:b], xs[a:], xs[:]) is still rejected by the MVP gate. The v0.2 fixture corpus only exercises the bound form; the comment in list.mochi explicitly notes the open-end forms are not supported. Adding them is a frontend-only change (default bounds to 0 and OpStrArrLen respectively) and stays out of scope until a fixture surfaces it.
• Slicing other element types (TypeList for i64, TypeF64Arr, TypeMap, TypeMapStrI64, TypeListAny) is still rejected by the MVP gate. Each needs its own runtime helper; adding them is mechanical but adds runtime surface area.
• Negative bounds are NOT folded yet. xs[-2:] would lower to a literal-negative OpConst for the start, which the slice helper would then clamp to 0 (so xs[-2:] returns the whole list, not the last two). The constant-negative fold that 4.2.15 added for OpListGetI64 could be ported here, but the v0.2 fixture corpus does not exercise it.
• Three-index slicing (xs[a:b:c], governed by the parser's Colon2 field) remains rejected. Mochi does not have a documented semantics for the capacity bound, so the gate stays in place.

§10.46 Phase 4.2.19 closeout (LANDED 2026-05-22 12:41 GMT+7)

Phase 4.2.19 makes test "name" { ... } blocks a no-op at the frontend lower pass. Before this phase the v0.2/π.mochi and v0.2/map.mochi fixtures both ended with a test block and hit frontend: statement kind unsupported in MVP on the very last statement, even though every line of executable code in them already compiled. The phase adds one case st.Test != nil: return nil arm to lowerStmt and pins the rule with three driver tests.

The decision is parity with mochi run: the reference VM's run mode does not execute test bodies (those run under mochi test). A mochi build --target=c user is asking for an executable, not a test runner; dropping the block at lower time makes the C-target binary's stdout match mochi run's stdout byte for byte. The body of the test block is not walked at all, so any expressions inside it (including expressions that would not type-check, such as the Option<int> map indexing shape in v0.2/map.mochi's expect scores["Alice"] == 10) do not surface as errors at build time. This matches the VM contract: under mochi run those type errors are also suppressed; they only fire under mochi test.

Diff shape

• compiler3/frontend/lower.go: one new case st.Test != nil arm in lowerStmt, returning nil. Accompanying comment cites the mochi run parity rationale.
• compiler3/build/c/driver_test.go: 3 new tests. TestBuildSourceTestBlockSkipped uses an expect body that would type-error if visited, confirming the body is never lowered. TestBuildSourceV02PiFixture and TestBuildSourceV02MapFixture pin the on-disk v0.2/π.mochi and v0.2/map.mochi fixtures end to end.

Why this closes a goal

Two of the six v0.2 tutorial fixtures (π.mochi and map.mochi) now compile and run to completion on the C target. Combined with Phase 4.2.18 (which closed map.mochi's main-body map<str, i64> gate) and Phase 4.2.17 (list), the v0.2 user-facing matrix is now:

Fixture	C target status
shadow.mochi	green (always was)
π.mochi	green (Phase 4.2.19)
map.mochi	green (Phase 4.2.18 + 4.2.19)
for-in.mochi	still fails (untyped let scores = {...} map literal needs key-type inference; also map iteration for k in m)
list.mochi	still fails on fruits[1:3] (slice indexing)
matrix.mochi	still fails on nested list<list<i64>>

Three of six fixtures green. The remaining three each have a distinct gate that maps cleanly onto a future phase.

Limitations

• bench "name" { ... } blocks are NOT skipped; they still trip the unsupported-statement gate. The v0.2 fixtures don't use bench, so this stays out of scope until a fixture surfaces it.
• Function definitions inside a test block (a fun declared between { and }) are silently dropped along with the rest of the body. If a future fixture relies on test-block-scoped helpers leaking into the surrounding namespace, this skip would need to revisit.
• The test block is not parsed for unused-import or unused-variable diagnostics. Since the C target has no such diagnostics today (Phase 4 MVP), this is not a regression.

§10.45 Phase 4.2.18 closeout (LANDED 2026-05-22 12:33 GMT+7)

Phase 4.2.18 lands map<str, i64> on the C target. Before this phase the binding let scores: map<string, int> = {"Alice": 10, "Bob": 15} from examples/v0.2/map.mochi failed at lowerType with map<str, i64> unsupported in MVP (only map<int, int>), and for-in.mochi failed its very first map literal with the same message. The phase adds the TypeMapStrI64 carrier, four ops, a C runtime, and the lowering wiring needed to close map.mochi's main body (everything but its test block) and the map literal at the head of for-in.mochi's map section.

The runtime layout mirrors mochi_map_i64_i64: an open-addressing linear-probing hashtable with a power-of-two cap, doubling growth at the 75 percent load threshold, parallel keys/vals/occ arrays, FNV-1a 64-bit hash over the key bytes, byte-equal comparison via strcmp, and Go's map[string]int64{} zero-default for absent reads. The map borrows the caller's key pointer on first insert; the C target already keeps every string literal alive for the duration of the process (Phase 4.2.0 backed TypeStr with const char* carriers that point at the program text or interned slot), so the borrow contract is satisfied without an extra copy.

The verifier classification reuses the existing handle-typed pattern. OpNewMapStrI64 is Constructor (the alloc); OpMapSetStrI64 is a write Dispatch (rule E mutating); OpMapGetStrI64 is a read Dispatch returning TypeI64 (no rule A obligation because the result is value-shaped, not handle-shaped); OpMapLenStrI64 is a read Dispatch returning TypeI64. TypeMapStrI64 itself is added to HandleType so a future fun parameter taking map<str, i64> will be permitted to originate via OpParam (KindMove).

Diff shape

• compiler3/ir/types.go: new TypeMapStrI64 enum tag + String() case; new ops OpNewMapStrI64, OpMapSetStrI64, OpMapGetStrI64, OpMapLenStrI64; String() cases for each.
• compiler3/ir/validate.go: opSig signatures for the four new ops.
• compiler3/verify/verify.go: classification (Constructor for OpNewMapStrI64; Dispatch for the rest), HandleType gains TypeMapStrI64, opIsMutating + readDispatchOps + writeDispatchOps coverage, dispatchArena entry, contractResult lookups.
• runtime/c/src/mochi_map_str_i64.{h,c}: ~75-line header and ~120-line source covering new/get/set/len with the FNV-1a hash, open-addressing probe, and doubling-growth rehash.
• runtime/c/doc.go: //go:embed line gains the two new files so the build driver writes them next to gen.c.
• compiler3/emit/c/emit.go: usesMapStrI64 trigger set; #include "mochi_map_str_i64.h"; per-op dispatch (four cases); TypeMapStrI64 -> mochi_map_str_i64* in cType().
• compiler3/emit/go/emit.go: TypeMapStrI64 -> map[string]int64 in goType(); four op cases mapping to native Go map syntax.
• compiler3/frontend/lower.go:
  • lowerType accepts map<str, i64> (and the surface aliases map<string, int>) -> TypeMapStrI64.
  • A new expectedMapStrI64 builder flag is set by lowerTypedLet when the annotated type is TypeMapStrI64; cleared after the RHS lowers.
  • lowerMapLiteralAsExpr gains a TypeMapStrI64 branch that emits OpNewMapStrI64 followed by one OpMapSetStrI64 per declared entry, validating that each key lowers to TypeStr and each value to TypeI64.
  • lowerPostfix index branch accepts TypeMapStrI64; the index check is widened to require TypeStr for map<str, i64> keys (and stays TypeI64 for list-shaped carriers and map<int, int>); the post-resolve switch emits OpMapGetStrI64.
  • len() builtin accepts TypeMapStrI64 -> OpMapLenStrI64.
• compiler3/build/c/driver_test.go: 3 new tests pinning the literal-plus-get-plus-len shape from v0.2/map.mochi, the Go-shaped zero-default on absent keys, and the empty literal under the new carrier.

Why this closes a goal

The §Top-line goal is "every v0.2 fixture compiles via mochi build --target=c". Two of the six fixtures (map.mochi and for-in.mochi) failed on the very first map line of their main body; this phase clears that line. map.mochi now compiles its full main body (the only remaining gate is the trailing test "map basic operations" {...} block, which is the v0.2 test-block phase). for-in.mochi still has downstream gates (map iteration for name in scores and nested for-in over a 2D list), but the literal-plus-get-plus-len shape that drives the map section is unblocked. A v0.2 learner who writes let s: map<string, int> = {"a": 1, "b": 2}; print(s["a"]) now sees 1 on the C target, matching mochi run byte for byte.

Limitations

• The carrier is fixed to map<str, i64>. Other key/value combinations (map<str, str>, map<i64, str>, etc.) still hit the same "unsupported in MVP" message. Each requires its own carrier and runtime; templating the IR across key/value types is a separate refactor.
• Map iteration (for k in m) is not implemented. The runtime has no public iterator helper and the frontend's lowerForCollection only knows the list-shaped carriers. for-in.mochi's map section still fails on this gate.
• len() is the only read aggregate. There is no contains(m, k) builtin (the v0.2 fixtures don't use it; Mochi spells the membership check with m[k] or default today, which is a separate gate).
• Deletion (del m[k]) is rejected by the parser surface and unimplemented in the runtime; matches map<int, int>.
• The runtime allocates the bucket arrays from malloc and leaks them at process exit. Matches every other Phase 4 C runtime helper; an arena phase is tracked separately.

§10.44 Phase 4.2.17 closeout (LANDED 2026-05-22 11:03 GMT+7)

Phase 4.2.17 lands list<str> on the C target. Before this phase the frontend rejected let xs = ["a", "b"] with frontend: list literal element type str unsupported in MVP; the v0.2 tutorial fixtures v0.2/for-in.mochi and v0.2/list.mochi both fail their first lines on this gate. The phase adds a new IR type (TypeStrArr), six ops, a runtime header, and the corresponding emit + lower wiring.

The runtime layout matches mochi_f64_array byte-for-byte: a heap-resident header struct (const char** data, int64 len, int64 cap) with doubling growth from a first-push capacity of 4. The element carrier is the same const char* Phase 4.2.0 introduced for TypeStr, so a literal push is a single pointer store and OpStrArrGetStr returns a borrow of the slot. Allocations leak at process exit (Phase 4 MVP, parity with the i64 and f64 array runtimes).

The print formatter OpStrArrToStr renders the Mochi reference display form ["a", "b"]: square brackets, comma-space separators, each element double-quoted with the strconv.Quote escape rule (\", \\, \n, \r, \t, \b, \f, \u00NN for the remaining C0 control bytes; 0x20..0xFF passes through verbatim, so multi-byte UTF-8 stays intact). The two-pass length-then-write structure inside quoted_len_and_write keeps the output buffer sized exactly without double-rendering.

The verifier classifies OpStrArrGetStr as Constructor (not Dispatch), matching the rule for OpListAnyGetAny: a TypeStr result is handle-typed (a pointer carrier), and rule A requires handle-typed values to originate from a Constructor/Move/Inline/Call op. The other five ops are Dispatch as usual; the write subset gets the existing rule E classification.

Diff shape

• compiler3/ir/types.go: new TypeStrArr enum tag + String() case; new ops OpNewStrArr, OpStrArrLen, OpStrArrPushStr, OpStrArrGetStr, OpStrArrSetStr, OpStrArrToStr (latter parallels OpListI64ToStr / OpF64ArrayToStr); String() cases for each.
• compiler3/ir/validate.go: opSig signatures for all six ops.
• compiler3/verify/verify.go: classification (Constructor for OpStrArrGetStr and OpNewStrArr; Dispatch for the rest), opIsMutating + readDispatchOps + writeDispatchOps coverage, dispatchArena entry, opType return type lookup.
• runtime/c/src/mochi_str_array.{h,c}: 60-line header and 130-line source covering new/len/push/get/set + the to_str renderer with the quote-escape helper.
• runtime/c/doc.go: //go:embed line gains the two new files so the build driver writes them next to gen.c.
• compiler3/emit/c/emit.go: usesStrArray trigger set; #include "mochi_str_array.h"; per-op dispatch (six cases); TypeStrArr -> mochi_str_array* in cType().
• compiler3/emit/go/emit.go: TypeStrArr -> []string in goType(); six op cases (OpStrArrToStr inlines a strconv.Quote lambda so the file does not need to import the runtime/mochi/fmt package, mirroring how the f64 formatter is inlined).
• compiler3/frontend/lower.go:
  • lowerType accepts both list<str> and [str] annotations -> TypeStrArr.
  • lowerListLiteral accepts TypeStr first elements and binds (TypeStrArr, OpNewStrArr, OpStrArrPushStr).
  • lowerTypedLet and lowerReturn set expectedListElem = TypeStr when the annotated type is TypeStrArr.
  • lowerForCollection adds TypeStrArr branch (OpStrArrLen + OpStrArrGetStr).
  • lowerPostfix index branch and lowerIndexedAssign accept TypeStrArr, emitting OpStrArrGetStr and OpStrArrSetStr respectively; the Phase 4.2.15 literal-negative fold gains a TypeStrArr arm so xs[-1] on list wraps via OpStrArrLen.
  • Single-arg print and liftToStr for multi-arg print lift TypeStrArr through OpStrArrToStr.
  • len() builtin accepts TypeStrArr -> OpStrArrLen.
  • append() builtin accepts TypeStrArr -> OpStrArrPushStr.
• compiler3/build/c/driver_test.go: 6 new tests covering print, empty literal, indexed read, literal-negative index, for-in iteration, and the quote-escape rule (backslash + double-quote + newline + UTF-8).

Why this closes a goal

The §Top-line goal "the smallest user-facing bootstrap demo" is the v0.2 tutorial cluster. Two of its six fixtures (for-in.mochi and list.mochi) fail on the C target at their first list<str> line; this phase clears that line for both. The fixtures still have downstream gates (for-in needs map<str, i64>, list.mochi needs slice indexing xs[1:3]), which are separate phases. The user-facing motion: any v0.2 learner who writes let names = ["alice", "bob"]; print(names) now sees the same output on mochi build --target=c as on mochi run, byte-for-byte including the strconv.Quote escapes.

Limitations

• list<str> concatenation via + (the OpListConcatI64/OpF64ArrayConcat sibling) is not lowered. The frontend's binop site rejects xs + ys on TypeStrArr; a follow-up phase adds OpStrArrConcat once a fixture surfaces the idiom.
• Slice indexing (xs[1:3] on list) is still rejected by lowerPostfix; same gate as list and list. Closes alongside the general slicing phase.
• The runtime allocates one const char** block per array and leaks it at process exit. No arena, no free. Matches the i64 and f64 array runtimes; an arena phase is tracked separately.
• The quoted_len_and_write helper renders pass-through bytes for everything in 0x80..0xFF rather than walking UTF-8 to detect malformed sequences. This matches Go's strconv.Quote for runes that are already printable; the bench corpus does not exercise malformed UTF-8.
• OpStrArrGetStr returns a borrow of the slot, not an owning copy. Mutating the underlying string via xs[i] = s2 invalidates any previously-read pointer (no Mochi-source program can observe this today because TypeStr is immutable and there is no in-place mutation surface). A future phase that adds string mutation would need to revisit this contract.

§10.43 Phase 4.2.16 closeout (LANDED 2026-05-22 10:42 GMT+7)

Phase 4.2.16 puts top-level let bindings in scope inside user-function bodies on the C target. Before this phase the frontend's identifier-lookup path only consulted the per-function b.values map; a name introduced by a module-level let failed with frontend: unbound identifier "n" once it was referenced inside a fun. The v0.2/π.mochi tutorial fixture (let π = 3.14; fun area(r) { return π * r * r }) was the canonical casualty: it ran fine on the VM and got rejected outright on the C target.

The chosen approach is to pre-scan top-level lets into a map[string]*parser.Expr once at the entry of Lower(), then thread that map through lowerFun -> newBuilder so each function builder gets a fallback in its identifier-lookup path. When a name is not in b.values, the builder checks a per-builder cache (globalCache map[string]uint32) and lowers the global's RHS expression once, materialising it as SSA inside the current function and recording the resulting value id. Subsequent references to the same global within the same function body re-use the cached id (no duplicate OpConst for pi if pi appears three times in area).

Diff shape

• compiler3/frontend/lower.go:
  • Lower() pre-scans prog.Statements for top-level Let nodes with non-nil Value into globals map[string]*parser.Expr before any user-function lowering.
  • lowerFun signature gains a globals parameter; both existing call sites pass the pre-scanned map.
  • builder struct gains globals map[string]*parser.Expr and globalCache map[string]uint32 fields; newBuilder initialises the cache empty per function.
  • Identifier-lookup fallback (p.Selector.Root path): cache hit returns the cached SSA id; cache miss lowers globals[name] via b.lowerExpr and stores the result in the cache. A name still missing from both maps falls through to the existing unbound identifier error.
• compiler3/build/c/driver_test.go: 5 new tests covering int global from fn, float global from fn, multiple references to one global (cache observability), mixed scope (main and fn both read it), and parameter-shadows-global.

Why this closes a goal

The §Top-line goal "the smallest user-facing bootstrap demo" tracks the v0.2 tutorial cluster, and v0.2/π.mochi is one of three fixtures in that cluster (area, circ, vol-style geometry primitives). The previous hard-error on the C target meant any v0.2 learner who reads area's body and runs mochi build --target=c gets a frontend: unbound identifier "π" rejection that does not surface on mochi run. After this phase, mochi build --target=c π.mochi succeeds for the geometry portion of the fixture (the test "π" { ... } block remains rejected as statement kind unsupported in MVP, scope of a separate phase). Visible progress: every user function in user-written code can now reference module constants, which is the Mochi convention for naming literals.

Limitations

• The test block in v0.2/π.mochi is still rejected (statement kind unsupported in MVP). That is a separate frontend feature, scoped to its own phase. The geometry portion of the fixture compiles and runs.
• A top-level let with a side-effecting RHS is materialised at each function's first use, not once at module init. For pure constant initialisers (the only shape the parser permits as a top-level let RHS in practice) this is observationally equivalent. If the language ever allows side-effecting top-level lets, the model has to change.
• The fallback only fires for the simple selector case (p.Selector.Root with no tail). Field/index access on a global (config.timeout, xs[0] when xs is global) is not covered by this phase; the v0.2 tutorial fixtures don't use that shape.
• Mutual recursion through globals is not exercised. A let whose RHS calls a function that references another let could trigger order-of-lowering issues; the bench corpus and v0.2 fixtures don't hit that pattern, so it is deferred to a follow-up if it surfaces.
• No emit-side change. The cache lives inside the frontend builder; from the IR consumer's perspective each function still receives a self-contained Function with all the constants it needs.

§11 Risks

11.1 Clang ABI drift breaks stencils

Stencil output depends on Clang's code generation for each version. A Clang upgrade can change calling-convention details, register allocator decisions, or relocation kinds in ways that the runtime patcher does not expect. Mitigation: pin a Clang version in CI (tools/stencilgen/CLANG_VERSION); differential-test every stencil set against the vm3 interpreter on every PR that bumps the Clang version.

11.2 macOS arm64 JIT entitlement

Apple requires every JIT process to ship with a signed binary carrying com.apple.security.cs.allow-jit or com.apple.security.cs.allow-unsigned-executable-memory (the former is preferred). Without it, mmap(PROT_EXEC) fails with EPERM. Mitigation: ship signed Mochi releases with the entitlement plist; document the codesign --entitlements jit.plist flow for users who build Mochi from source on Apple Silicon.

11.3 Code-cache memory pressure

The copy-and-patch code cache is mmap'd at process start and grows as more methods JIT. A long-running REPL or server hits the cap eventually. Mitigation: configurable cap (MOCHI_JIT_CACHE_MB, default 64 MB); LRU eviction when the cap is reached; fallback to vm3 interpretation for evicted methods. The eviction policy is bench-tuned in Phase 3.

11.4 C compiler not installed

mochi build assumes the user has a C compiler. On Ubuntu/Debian this is apt install build-essential; on macOS this is xcode-select --install; on Windows this is the Visual Studio Build Tools download. Mitigation: ship mochi doctor subcommand that detects missing toolchain pieces and prints the install command for each OS; document the zig cc path as the universal fallback ("install Zig, get a C compiler for free").

11.5 Wasm size

A Mochi Wasm module carries the Mochi runtime (handle ops, arena allocator, slow-path callbacks) in addition to the user program. Initial size estimate: 200-400 KB compressed for hello-world, dominated by the runtime. Mitigation: tree-shake the runtime via the same closed-world discipline AOT'd C uses; phase-2 work in ~/notes/Spec/5500/backends/12_wasmtime_aot.md measures real sizes and sets a target.

11.6 Windows ABI complexity

The x86_64 Windows ABI differs from SysV in calling convention (RCX/RDX/R8/R9 vs RDI/RSI/RDX/RCX), shadow space (32 bytes mandatory), and unwind info (.pdata + .xdata are not optional; they are required for any function over a trivial size). The aarch64 Windows ABI adds its own unwind bytecode encoding (xdata blocks are a per-function bytecode program, not just metadata). Mitigation: phase 2 budgets 4 engineer-weeks for Windows alone; gate on real binaries running under Windows Defender's exception handler before declaring done.

11.7 Single-file deployment expectations

Users coming from Go expect mochi build to produce a single binary with no external Mochi dependencies. This is the top-line objective stated near the top of this MEP; it is enforced at every AOT phase gate, not just listed here. The residual risk is the boundary: a default mochi build on Linux produces a glibc-dynamic ELF that needs the target machine's libc to be present. Mitigation: mochi build --portable (musl static-PIE) is documented from Phase 4 forward and tested under the "clean machine" gate; mochi build --bundle (single-file with embedded interpreter for dyn-typed escape) lands in Phase 8 alongside the APE bundler. The default mochi build produces a normal dynamically-linked binary (libc present is assumed; the gate checks for it) and --portable is the opt-in escape valve. The mochi doctor subcommand (Risk §11.4) reports when the host or target environment cannot meet the gate.

11.8 Cross-compilation testing

Cross compiling from a single host (e.g., a macOS CI runner) to all four phase-1 targets requires CI to actually execute the cross-compiled binaries on each target. Mitigation: GitHub Actions matrix (linux/amd64, linux/arm64, macos/arm64, macos/amd64, browser via Playwright headless) runs the same BG kernel suite under each binary; cross-compile output is byte-for-byte deterministic across hosts (Reproducible Builds Project compatibility) so the cross-host build is verifiable.

11.9 Backend bus factor

Copy-and-patch is a niche technique. CPython 3.13 made it production-validated, but the institutional knowledge is in two papers (Xu+Kjolstad PLDI 2021, Bucher CPython PEP 744) and three reference implementations (CPython, the original Tiramisu-stencil work, and JSC's WTF). Mitigation: budget time for two Mochi contributors to read the substrate (~/notes/Spec/5500/naive/00_naive_summary.md reading order), pair-program the first stencil set, and document the stencilgen tool thoroughly. The reading-list discipline matches MEP-40's substrate work.

11.10 C-as-target produces "wrong-feeling" stack traces

Crash dumps from AOT'd C code show C-level stack frames (mochi_op_add_i64_at_0x14), not Mochi-level frames. This is the same UX hit Crystal and Nim took. Mitigation: phase-2 DWARF work emits DW_AT_artificial on synthetic C frames and DW_AT_name carrying the Mochi-source name; gdb and lldb both honor this. Stack traces in mochi build --mode=dev mode show Mochi names; release mode keeps the C names for smaller debug-info size.

§12 References

The full research substrate lives in ~/notes/Spec/5500/ (73 deep-dive files plus six summaries). Each file carries a §1 Provenance section with canonical URLs. The most load-bearing citations for this MEP are:

Code generation backends

• ~/notes/Spec/5500/backends/00_backends_summary.md (recommendation rollup)
• LLVM 20: https://llvm.org/
• Cranelift: https://cranelift.dev/
• QBE: https://c9x.me/compile/
• MIR: https://github.com/vnmakarov/mir
• DynASM: https://luajit.org/dynasm.html
• golang-asm: https://github.com/twitchyliquid64/golang-asm

Copy-and-patch and naive emission

• ~/notes/Spec/5500/naive/00_naive_summary.md (Phase 1 JIT recommendation)
• Xu + Kjolstad, "Copy-and-Patch Compilation" (PLDI 2021): https://fredrikbk.com/publications/copy-and-patch.pdf
• PEP 744 "JIT Compilation" (Python 3.13): https://peps.python.org/pep-0744/
• CPython 3.13 JIT writeup: https://lwn.net/Articles/977855/
• V8 Sparkplug: https://v8.dev/blog/sparkplug
• JSC Baseline: https://webkit.org/blog/10308/speculation-in-javascriptcore/

AOT case studies

• ~/notes/Spec/5500/aot/00_aot_summary.md (Crystal = analog, .NET NativeAOT = template)
• .NET NativeAOT: https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/
• Crystal: https://crystal-lang.org/reference/1.10/syntax_and_semantics/compile_time_flags.html
• Zig self-hosted: https://ziglang.org/devlog/
• GraalVM Native Image: https://www.graalvm.org/latest/reference-manual/native-image/
• Nim: https://nim-lang.org/docs/backends.html
• GHC NCG: https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/compiler/backends/ncg

Target ABIs and formats

• ~/notes/Spec/5500/targets/00_targets_summary.md (target matrix)
• x86_64 SysV ABI: https://gitlab.com/x86-psABIs/x86-64-ABI
• AAPCS64: https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst
• x86_64 Windows ABI: https://learn.microsoft.com/en-us/cpp/build/x64-software-conventions
• WasmGC: https://github.com/WebAssembly/gc
• Wasm 3.0: https://webassembly.github.io/spec/
• WASI Preview 2: https://github.com/WebAssembly/WASI

Linkers, runtime, debug

• ~/notes/Spec/5500/linkers/00_linkers_summary.md (LLD + glibc / musl recommendation)
• LLD: https://lld.llvm.org/
• mold: https://github.com/rui314/mold
• Apple ld_prime: https://developer.apple.com/documentation/xcode-release-notes/xcode-15-release-notes
• musl static-PIE: https://musl.libc.org/
• Cosmopolitan APE: https://justine.lol/cosmopolitan/
• DWARF 5: https://dwarfstd.org/doc/DWARF5.pdf

Recent papers

• ~/notes/Spec/5500/papers/01_pldi_2024_2025_codegen.md
• ~/notes/Spec/5500/papers/02_popl_2024_2025_compiler.md
• ~/notes/Spec/5500/papers/03_mlir_dialects_2026.md
• ~/notes/Spec/5500/papers/04_cranelift_design.md
• ~/notes/Spec/5500/papers/06_compile_time_vs_runtime_tradeoff.md

Mochi cross-references

• MEP-23 (Compile-time budget): provides the compile-time targets each backend must meet.
• MEP-40 (vm3 + compiler3): provides the typed IR, handle Cell, typed arenas, three-bank register file.
• MEP-41 (Memory Safety): provides the verifier rules, generation-as-secret hygiene, W^X + PAC/BTI hardening checklist for the JIT code page.

§13 Workflow note (for implementers)

The MEP-39 standing rule applies: every win must be a generic backend improvement, not a single-purpose super-op. Stencils are generic by construction (one per opcode, not per program pattern); C-as-target is generic (the same lowering for every Mochi program); the Wasm emitter is generic (same module shape regardless of program).

Every phase deliverable is one PR (or a small named set of PRs) gated by the named criterion. No phase ships until its gate is green. The MEP file is updated with measured results at each phase boundary.

The MEP and the code ship in the same PR. A backend change without a corresponding spec update is rejected by review; a spec change without test coverage in the same PR is rejected by review. This is the MEP-spec-in-sync rule.

The two-track structure (JIT phases 1-3, AOT phases 4-7) means contributors can take either track independently after Phase 1. Phase 8-9 are the cross-platform expansion and require both tracks at parity on the existing four targets before adding the fifth (Windows) or sixth (riscv64).

Before starting any sub-phase, audit whether its gate advances the top-line objective (mochi build single-binary) or only clears a spec-internal dependency. If the answer is the latter and the top-line objective is sitting unaddressed at a later phase, surface the gap and consider a pivot rather than walking N → N+1 in spec order. The JIT-track widening sub-phases (1.2 darwin, 1.3 wasm, etc.) clear internal scaffolding but do not move the top-line objective; the AOT-track sub-phases (4.x, 5.x) do. Run both tracks in parallel once Phase 1.0 is in to avoid stalling the user-facing promise behind JIT host coverage.

No phase introduces cgo on the Mochi build host. The shipping Mochi binary stays pure-Go-no-cgo. Clang is a build-time dependency of stencilgen, not a runtime dependency. The user's cc is a build-time dependency of mochi build, not a runtime dependency. This is the same identity rule that MEP-40 vm3 preserves.

The five-research-substrate discipline is intentional: every architecture decision in §1-§10 points to a specific file in ~/notes/Spec/5500/. A reviewer who disagrees with a choice should be able to find the substrate file, read the alternatives, and either propose a different file or argue the substrate is wrong. This is the same provenance discipline MEP-41 uses with ~/notes/Spec/5400/.

The public statement from MEP-41 §10.8 ("Mochi is designed to enable signatories of the CISA Secure-by-Design Pledge to use it as part of their memory-safety roadmap") extends to MEP-42 by virtue of the W^X + PAC/BTI + Spectre-index-masking hardening checklist in §2 above. Phase 2-3 of MEP-42 satisfies the JIT-hardening clauses of MEP-41's public statement; the statement should be updated in the same PR that closes MEP-42 Phase 3.