Speak in meaning. Think beyond syntax. Built beyond language.

Selfhosting

Definition

For this project, true selfhosting means the compiler is capable of compiling its own Semantic source into the next compiler executable.

The intended proof is:

Stage 1 compiler
    ↓ compiles
msplc-selfhost.se
    ↓
Stage 2 compiler
    ↓ compiles the same source
msplc-selfhost.se
    ↓
Stage 3 compiler

A strong bootstrap check compares Stage 2 and Stage 3 behavior/artifacts under a deterministic build contract.

What does not count

The following may be useful during bootstrap engineering, but they are not the final selfhosting proof:

  • embedding a previously compiled EXE into .se comments or data;
  • extracting/replaying a seed executable;
  • invoking Go/C/C++ as the hidden implementation of the Semantic compiler;
  • replacing unsupported semantics with silent stubs.

Bootstrap stages

flowchart TD S0[Bootstrap implementation] --> S1[Stage 1 MSPLC] SRC[Semantic compiler source] --> S1 S1 -->|compile SRC| S2[Stage 2 MSPLC] SRC --> S2 S2 -->|compile SRC| S3[Stage 3 MSPLC] S2 --> V{Behavior / deterministic artifact check} S3 --> V

Why object-first debugging helps

The compiler is too large to treat every failure as a monolithic “EXE build failed”. COFF staging gives a finer-grained milestone:

  1. parse/index Semantic compiler modules;
  2. lower individual compiler units;
  3. emit valid object artifacts;
  4. resolve cross-unit symbols;
  5. link the compiler executable;
  6. use that executable for the next bootstrap stage.

Current status

MSPLC provides a minimal Linux-only self-hosting compiler for x86-64. Its 48 Semantic source units compile directly to Linux ELF, and the Stage 1 → Stage 2 → Stage 3 proof is reproducible with byte-identical artifacts and no external compiler, assembler, or linker in the self-hosting transitions.

MSPLC is available as an official Semantic module and is maintained in the GitHub repository.

This Linux milestone is intentionally separate from the Windows compiler effort. It does not claim that the full universal Semantic compiler or Windows PE backend is self-hosted.

SWC Windows compiler

The Semantic Windows Compiler (SWC) is the current native Windows x64 compiler project for Semantic source and Universal AST documents. Its executable-facing command is swc, and its current source and release package are maintained in the Semantic Programming Language repository.

The SWC package contains the native swc.exe, the canonical Semantic compiler source, Semantic reader units, matrix-driven transpiler data, UAST routing/lowering units, tests, and development tools. It intentionally does not claim that the complete universal compiler is finished.

Current CLI

swc version
swc help
swc compile <input.se|input.sp|input.spz|input.json|input.smod> -o <output.exe> [--embed-all|--embed-needed|--no-modules]

The current native executable accepts the documented compile formats and module-mode flags. The Semantic reader, format dispatch, matrix data, and lowering contracts are present in the source tree.

Current implementation boundary

SWC is not yet a full native replacement for the former Go transpiler. The matrix and transpiler routes are connected as compiler seams, but the complete UAST-to-machine-code emitter and PE linker closure are still being implemented. Compiling a large rich Semantic source can therefore currently produce a small fallback PE stub; that is not a successful executable build.

  • Native Windows x64 CLI and version/help dispatch: available.
  • Semantic source reader and current canonical UAST subset: available.
  • Transpiler matrix and module/lowering contracts: integrated as active implementation paths.
  • Complete rich-UAST lowering, PE code emission, and executable linking: in progress.
  • Full Windows SWC selfhosting: not claimed yet.

Modules and registry in the selfhost path

Selfhosting depends on stable module identity. The Semantic package registry and local module stores provide discoverable package manifests, Semantic-ready units, hashes, and dependency metadata. A selfhost build can therefore resolve a declared module graph, select the required Semantic units, and carry that graph into the compiler project closure.

The native SWC compiler is building on this foundation. Its next integration step is to make registry lookup, local caching, dependency resolution, and --embed-all, --embed-needed, or --no-modules policies part of the complete native compile path.