Skip to content

C And MoonBit To WASM

sigMAX lowers validated pseudocode to a canonical AST, then generates C or MoonBit deterministically. The selected compiler backend produces WebAssembly, and the validation pipeline checks the artifact against the Binary Contract.

The LLM-backed binary stage generates controlled pseudocode. It does not produce the final C or MoonBit source through a fallback when deterministic compilation fails.

C and MoonBit compilationA binary contract and the primitive catalog constrain pseudo-code. Parsing produces a canonical AST, source generation selects C or MoonBit, the matching compiler produces WASM, and validation checks the recorded artifact.Binarycontractand primitivesValidatepseudo-codeCanonical ASTGenerate Cor MoonBitClang orMoonBitcompilerWASM artifactandagreementValidatebinaryevidence

This diagram describes the Studio toolchain. COS2000’s Radjae compiler is a separate path that emits WASM directly.

The amber hexagons mark checks before lowering and after compilation. The final check reads the WASM artifact and its agreement; it is separate from creating that agreement.

The Rust tools live in studio/tools/pseudocode-compiler. The compiler worker selects the C or MoonBit backend carried by the generation job. Separate queues and images allow the backends to run concurrently.

Tool or formatRole in sigMAX
Rust pseudocode compilerValidates the closed grammar and generates source from the canonical AST.
C subsetBounded generated source using runtime/C/sigma.h.
Clang and LLVMCompile C for the wasm32 target.
MoonBitAlternative generated source and linear-WASM compiler path.
WebAssemblyExecutable artifact with explicit imports, exports and linear memory.
WASINot part of the allowed business-handler import surface.

The shared primitive catalogue is runtime/functions.toon. C headers and the MoonBit runtime library implement its language projections; the Rust host supplies the permitted host imports.

The compiler worker uses --target=wasm32, -nostdlib, hidden symbol visibility and explicit linker exports. It exports linear memory and the handle_<name> entrypoint, while leaving declared primitives as imports.

Compilation choicePurpose
--target=wasm32Emit WebAssembly rather than a native host executable.
-nostdlibAvoid an implicit native C runtime dependency.
--no-entryBuild callable handlers rather than a process entrypoint.
--export=memoryExpose guest memory for controlled host exchange.
--export=handle_<name>Export the handler expected by generated routes.
--allow-undefinedLeave host functions unresolved until runtime linking.

Allowing undefined symbols at link time does not authorize arbitrary imports. The worker reads the compiled WASM import table and rejects functions outside the catalogue allowlist, as well as forbidden non-function imports.

A missing WASM linker fails compilation with a diagnostic. Successfully compiling an object file is not reported as a runnable WASM result.

The module calls explicit imports in the sigmax namespace. Typed values cross the boundary using the contract’s c_repr layout. ObjectIR builds structured JSON output, while DocIR describes documents rendered by the host.

Generated code uses bounded helpers and controlled primitives instead of direct SQL, filesystem access, raw sockets, process APIs or host secret reads. The host checks capabilities and bindings before performing an external effect.

Binary validation rereads artifact bytes, checks recorded digests, parses imports and exports, requires the contracted entrypoint and rejects undeclared imports and WASI. The binary agreement links the contract, generation trace, compact and expanded pseudocode, AST, selected source and WASM artifact.

  1. Compile · wasm.compile Produce the WASM artifact.
  2. Record · binary.agreement Create the agreement with validation pending.
  3. Validate · binary.validate Write the separate report; recorded artifacts are not yet successful acceptance.

A successful compiler exit only proves compilation. It does not prove that business behavior satisfies the contract; declared API scenarios and validation reports provide additional evidence.

Core uses the containerized Rust/Wasmtime execution path with Host and Config on the same machine. Pro uses the COS2000 executor in a KubeVirt VM under Kubernetes.

A portable WASM binary still depends on its imports, ABI and supported WebAssembly features. The current Wasmtime path and the COS2000 executor must not be assumed interchangeable without compatibility validation. The inspected runtime checkout does not contain the complete Pro integration.

See Pseudocode DSL and WASM execution boundaries.