C/WASM Generation

C/WASM Generation

sigMAXWebAssemblyLLVMClanggenerationC subsetwasm32compiler toolchaindeterministic generation

Controlled pseudo-code can be transformed into a deterministic C subset, then compiled to WebAssembly.

Compiler chain

LLVM, Clang, WebAssembly and WASI are related, but they do not play the same role. LLVM is the compiler infrastructure, Clang is the C-family frontend, WebAssembly is the binary execution target, and WASI is a standardized host interface for some WASM environments.

sigMAX uses that toolchain as a deterministic compiler step. The safety model does not come from Clang alone: it comes from contracts, the restricted C subset, explicit WASM imports, runtime primitives and Binary Agreements.

Toolchain Building Blocks

LLVM: compiler infrastructure

LLVM provides reusable compiler libraries: intermediate representation, optimizer passes, target backends, object emission and toolchain foundations. In this chain, LLVM is the machinery that makes wasm32 code generation possible.

Official site · logo assets

Clang: C-family frontend

Clang reads C, C++, Objective-C and related languages, validates syntax and semantics, then feeds LLVM. In sigMAX, Clang only sees generated C subset code, not arbitrary application source.

Official site · LLVM logo used by Clang

WebAssembly: portable binary target

WebAssembly is the compact executable format loaded by the runtime. A WASM module has linear memory, explicit imports and exports, and no ambient access to the host unless the embedder provides it.

Official site

WASI: standard host interface

WASI defines standards-track host APIs for WASM applications. sigMAX business handlers do not rely on WASI by default; they use sigMAX runtime primitives instead. WASI remains the reference when a WASI-style host interface is intentionally introduced.

Official site

About the Clang logo

The official Clang site presents Clang as an LLVM subproject and does not expose a distinct standalone logo asset in its page markup. The local Clang card therefore uses the official LLVM wyvern asset while naming Clang separately as the C-family frontend.

From LLVM To Clang

LLVM is a compiler platform made of reusable pieces. A frontend such as Clang is one entry point into that platform.

Layer	General role	In this page
Source language	Human or generated source before compilation.	Deterministic C subset generated from controlled pseudo-code.
Clang frontend	Parses C/C++/Objective-C and produces LLVM-level compiler input.	Parses the generated C subset.
LLVM middle end	Performs target-independent analysis and optimization.	Keeps the compiled path deterministic and inspectable.
LLVM backend	Emits machine code or another target format.	Emits WebAssembly for wasm32.
Link step	Resolves exports, imports and runtime assumptions.	Exports memory and the handler, leaves sigMAX primitives as host imports.

Mental model

When you run clang --target=wasm32, Clang is the visible command, but the compilation path is Clang plus LLVM plus the WebAssembly target backend.

From Clang To WebAssembly

Clang can compile C toward many targets. With --target=wasm32, the target is a 32-bit WebAssembly environment, not a Linux process. That distinction matters: C code that expects files, sockets, libc, POSIX calls or a process environment needs a matching runtime model.

General ClangsigMAX

In a general WebAssembly build, Clang parses C, LLVM lowers it to wasm32, and the final module depends on the selected environment.

• A freestanding build may avoid libc and provide only explicit imports.
• A WASI build uses a WASI sysroot and host APIs.
• A browser or embedder build exposes imports chosen by that embedder.

sigMAX uses the freestanding shape. Generated C includes the runtime header, avoids ambient OS behavior and calls only declared primitives.

• Generated handlers include /runtime/sigma.h.
• Undefined primitive calls become WASM imports.
• Imports are emitted under the sigmax namespace.
• The runtime checks capabilities before host work happens.
• The Binary Agreement records what was actually compiled and accepted.

sigMAX Compile Shape

The component skeleton compiles each generated C file into a WASM module with a compact Clang invocation.

clang \
  --target=wasm32 \
  -nostdlib \
  -fvisibility=hidden \
  -Wl,--no-entry \
  -Wl,--export=memory \
  -Wl,--allow-undefined \
  -Wl,--export=handle_<name> \
  -o <name>.wasm \
  <name>.c

Flag	Why it matters
--target=wasm32	Selects the WebAssembly 32-bit target.
-nostdlib	Prevents accidental dependency on a host C runtime.
-fvisibility=hidden	Keeps generated symbols private unless explicitly exported.
--no-entry	Builds a module with callable exports rather than a process entrypoint.
--export=memory	Exposes WASM linear memory to the runtime.
--allow-undefined	Allows sigMAX primitives to remain host imports.
--export=handle_<name>	Exposes the handler function expected by the route contract.

Compiler step, not policy

Clang and LLVM produce the WASM artifact. They do not decide whether a handler may call storage, HTTP, time, secrets or random data. Those decisions belong to the Binary Contract, runtime capabilities and agreement validation.

sigMAX Compilation Path

The result is a small executable boundary: the WASM module exports a handler and memory, imports only declared sigMAX primitives, and runs behind the Rust runtime.

Runtime Imports

The runtime header marks host primitives so Clang/LLVM emits imports in the sigmax module namespace instead of the default env namespace.

Concern	sigMAX rule
Host access	No direct Linux calls, filesystem, raw sockets or process APIs.
Runtime API	Use declared primitives such as input, response, ObjectIR, storage invocation, HTTP, JSON, regex, crypto and time.
Memory exchange	Use WASM linear memory and C-compatible c_repr layouts where typed buffers cross the boundary.
Errors	Return compact status codes, with handled business errors emitted through response primitives.
Evidence	Store imports, exports, hashes, ABI expectations and validation results in the Binary Agreement.

Why C at all?

The C subset is not a product language for manual business logic. It is a narrow, auditable compilation bridge from controlled pseudo-code to WASM. It gives Clang a stable input while keeping sigMAX generation rules visible.

What sigMAX Avoids

Avoided path	Reason
Arbitrary generated C	Too much surface for undefined behavior and hidden dependencies.
Direct libc or POSIX assumptions	The WASM module is not a normal Linux process.
Direct SQL or sockets	Storage and networking must go through declared runtime primitives.
Raw JSON response strings	Public output should be produced through response and ObjectIR primitives.
Trusting a binary only because it compiled	The compiled artifact still needs contract and agreement validation.

https://sigmax.dev/docs/generation/c-wasm-generation/