The compiler compiles the compiler

The compiler compiles.

Not just parses — compiles. Every method in Smalltalk-80.sources now goes through the full pipeline: ANTLR4 parse → AST → Blue Book bytecode emission → CompiledMethod objects in the heap. That includes the Compiler class itself, the Scanner, the Parser, the Encoder — the entire Smalltalk-80 compilation machinery, compiled by our C# compiler into bytecodes that the C# interpreter will execute.

The moment this starts working, the thing it compiled is itself capable of compiling more code at runtime. That’s the bootstrap.

Getting here from the working parser (August 3) took six weeks. The problems were almost all in bytecode generation rather than in the grammar. The Blue Book specifies exact bytecode sequences for every construct, and the specification is precise enough that being one opcode off in a conditional jump causes a context corruption that doesn’t manifest until dozens of message sends later. The blockCopy: bytecode had the wrong argument encoding for three weeks before we found it.

The two-pass compilation architecture was the key structural fix. The first pass walks the AST and determines block sizes — necessary because short jump bytecodes (one byte offset) and long jump bytecodes (two byte offset) have different encodings, and you can’t know which to emit until you know how far the jump goes. The second pass emits the final bytecodes with the correct encodings. Without two passes, every conditional in every method had to use long jumps, which produced bytecode that differed from the reference image and caused method lookup failures.

The compiled bytecodes were validated against the reference coldstart.json method-by-method. Not identical — the C# compiler makes different optimizations than the 1980 Smalltalk compiler — but semantically equivalent and passing the same test cases.

Methods compiled: all of Smalltalk-80.sources. Compilation errors: 0. Passes: 2. Validation: bytecodes compared against coldstart reference for 400+ methods.