How the m2compiler-V2 build process maps to the Blaise compiler
project's phased process (graemeg/blaise: Phase 1 bootstrap
pipeline, 2 type system, 3 generics, 4 multi-file compilation,
5 OPDF debug info, 6 LLVM backend, 7 LSP, 8 migration analyser).
| Blaise phase | Our step | Match |
|---|---|---|
| 1 bootstrap pipeline | 1 Coco/R frontend + gm2 toolchain proof |
Loose — same "prove the pipeline first" idea, but no bootstrapping |
| 2 type system | 2 SymTab semantic analysis | Yes — see summary_m2comp_step2.md ("Follows Blaise Phase 2") |
| (AST/IR) | 3 AST layer (Mössenböck recipe) | Yes in spirit — Blaise builds IR; we build a tree |
| Backend (QBE/native) | 4 MC64 tree-walking backend | Yes — frontend builds tree, backend walks it |
| 4 multi-file compilation | 5 separate compilation | Yes, almost one-to-one |
| 5 OPDF debug info | 7 backend listing (DumpImage) |
Partial — disassembly listing, not debug records |
m2comp-step1 …), test-guarded
progress (3/3 → 65/65).docs/summary_m2comp_stepN.md ~ their
docs/design.adoc).gm2 and target a VM interpreter.goal_step8.md (opaque types,
procedure types, LONGINT quads) targets language completeness;
Blaise's remaining phases (generics, LSP, LLVM, migration
analyser) target ecosystem.mc64-spec.md, loader, STAK/DEP)
has no Blaise counterpart — Turbo Modula-2 archaeology, not
their process.Conclusion: skeleton and phase rhythm are Blaise-like, adapted to a Wirth-style, VM-targeted, non-bootstrapped compiler.