Native compiler — big map

TypeRB Native is an evidence-driven experiment. Its goal is not merely “emit machine code.” It explores whether a TypeRB-authored compiler and runtime can build useful native programs and reproduce the compiler itself.

Start with the executable trace and short code clinic. Read the change journey when you want responsibility and evidence that survive file moves. Use this page when you need exact source addresses for the newer version below.

Experimental, not a supported target

The Native compiler accepts a deliberately bounded TypeRB subset. Unsupported behavior must fail clearly; it must not fall back to different semantics.

Map version

This map describes TypeRB Native 0.1.0-dev at revision ae9b9d6. Native is versioned independently from TypeRB, and -dev marks this as an unreleased experimental development version. Code links remain pinned to the full revision.

The ordinary compilation path

1. 1TypeRB source
2. 2Native lexer and parser
3. 3Native resolver and checker
4. 4Checked internal model
5. 5QBE IL
6. 6QBE
7. 7Assembler and linker
8. 8Native executable

The compiler-owned stages are written in TypeRB. QBE and the platform C toolchain are explicit external dependencies.

The most direct current frontend tour is compiler/gate4/src/compiler.trb. Despite the historical gate4 directory name, this source has grown into the ordinary self-hosted compiler path used by later bootstrap work.

Find the stages in one source file

The main compiler file is large, but its names provide a route:

Stage	Search for	Job
Command boundary	compiler_main, compiler_file_main, main	Choose check, emit-qbe, or build behavior
Lexing	gate4_lex_source, gate4_lex	Turn source characters into the compiler’s token storage
Parsing	gate4_parse_*	Recognize declarations, types, statements, and expressions
Resolution	gate4_resolve	Connect imports, declarations, and local names
Type checking	gate4_check	Verify the supported static types and calls
QBE emission	gate4_emit_qbe	Produce deterministic QBE IL and runtime support
Platform build	build command path	Invoke explicit QBE and C toolchain paths, then publish an executable

Two smaller modules support the frontend:

• storage.trb provides bounded storage used by compiler tables; and
• path.trb provides the path operations needed by file and project loading.

The verified native boundary

The repository also contains the earlier source-connected pipeline that made native semantics explicit step by step:

reference compiler snapshot
  -> strict decoder
  -> verified Native MIR
  -> QBE emitter
  -> QBE and system toolchain

Useful landmarks include src/native_mir.trb, the gate-specific MIRs, and src/qbe3.trb. These files are both working implementation and a record of how the experiment established verification, layout, managed runtime, and code-generation boundaries.

Do not read gate numbers as ordinary compiler phases

A gate is an experiment checkpoint with acceptance evidence. It is not a runtime stage that every program passes through. Start with the current path, then use older gates to understand why a boundary exists.

The bootstrap map

Self-hosting adds a second map. A compiler is used to build the next compiler:

previous Native seed (B1)
  -> builds B2 from the TypeRB compiler source
B2
  -> builds B3 from the same source
B3
  -> builds B4 from the same source

B2 == B3 == B4 under the fixed-point policy

The ordinary release/bootstrap graph begins with a previously published Native seed. The Go reference compiler is a recovery tool and differential oracle; it is not part of that ordinary Native-to-Native chain.

Start with these files when working on bootstrap or reproducibility:

Concern	Start here
Ordinary chain and fixed-point checks	tools/bootstrap-seed.sh
Published seed policy	docs/gate-6-bootstrap-seed-distribution.md
Native-to-Native closure	docs/gate-6-native-bootstrap.md
Pinned tool and repository identities	compatibility/current.json

Ownership boundary

Reference repository owns	Native repository owns
Portable syntax and language semantics	The experimental Native implementation
Cross-backend conformance behavior	Native MIR and its verification
Portable packages and target contracts	Native layout, ABI, runtime, and backend integration
Go, Ruby, and TypeScript generation	Native bootstrap and measurement evidence

If Native work reveals a language question, settle that question through the reference language design and conformance process. Keep Native-only mechanisms inside the Native repository.

A useful reading order

1. Run the Native executable trace.
2. Complete the String-to-QBE code clinic, which reads the exact older seed source used by that trace.
3. In this newer snapshot, search compiler.trb for compiler_file_main and follow the selected mode.
4. Follow one tiny construct through gate4_lex, gate4_parse_*, gate4_resolve, and gate4_check.
5. Find the same construct in gate4_emit_*.
6. Read one conformance case and the gate document that explains its boundary.
7. Read the bootstrap map only when the ordinary compile path is clear.

This order separates “how one program is compiled” from “how the compiler is reproduced.” Both matter, but they answer different questions.