Zeta is a low-level programming language and a compiler kit.
It gives you a single, versioned contract you can:
- author directly (as readable
.sirsource), - emit from other languages (as
sir-v1.0JSONL), - then verify, run under explicit capabilities, and/or compile to native binaries.
The hook is the language: Zeta is “IR-shaped”, but it’s a genuinely usable systems language—close to C in power, more explicit in semantics, and designed to be verifier-first and capability-first.
Hello world (calling an external symbol):
unit hello target host
extern fn puts(s:ptr) -> i32
fn main() -> i32 public
puts("hello world")
return 0:i32
end
Zeta’s surface (.sir, via sirc) is intentionally close to the underlying IR:
- one line of
.sirbecomes one JSONL record (1:1), - flags are explicit (
+flag/+key=value), - types are explicit (
i32,ptr,vec(i32, 4),fn(...) -> ..., etc), - the toolchain rejects unsupported or ambiguous constructs (by design).
Zeta has grown into a full “platform in a box”:
- Language + IR contract (SIR): a strict, versioned interchange format with a stable codegen boundary (SIR‑Core) and feature‑gated higher forms (SIR‑HL) that are deterministically lowered.
- Verifier:
sircc --verify-onlygives producers a hard pass/fail contract, with structured diagnostics. - Emulator / test harness:
semruns a supported subset deterministically under explicit host capabilities, supports recording/replay (“tapes”), and is meant to be the integration test engine for frontends. - Zero‑trust execution core (library):
sircoreexecutes structured modules with all host interaction via a capability ABI (zi_*+zi_ctl). - Multi-backend direction: compile via LLVM today; also emit
zasm-v1.1JSONL (sircc --emit-zasm) as a backend-neutral lowering target. - A VM tier (in-tree):
svmis the “full VM” direction (JIT/runtime services) and is expected to remain compatible withsircore’s reference semantics.
If LLVM is “IR + optimizer + codegen”, Zeta aims to be:
language + IR + verifier + emulator + capability ABI + multi-backend toolchain
Zeta’s value isn’t just code generation—it’s the whole correctness loop:
- Determinism as a contract: same program + same inputs/caps ⇒ same outputs.
- Verifier-enforced structure: types, references, CFG forms, and feature gates are validated; failures are explicit and stable.
- No ambient authority: programs can be written against
zi_*capabilities instead of implicitly inheriting “the whole OS”. - Emulation-first DX: frontends can do
AST → SIR → semto prove “it runs correctly”, not just “it compiles”. - Shared lowering (compiler kit): intent packs (e.g.
sem:v1) stop every frontend from reinventing CFG plumbing, short-circuiting, switch lowering, and scoped defers.
- It’s a real low-level language. Write kernels/drivers/embedded-style code and normal applications with explicit control over types, memory, and calling conventions.
- It’s a better “lowering target” than “lower to C”. You get a strict verifier, stable diagnostic context (
src/src_ref/loc), and an execution harness (sem) that can prove a lowering is correct by running it deterministically under explicit capabilities. - It scales from hand-written code to compiler pipelines. You can author
.sirdirectly for fast iteration, or emitsir-v1.0JSONL from a frontend/DSL and rely on Zeta’s shared lowering and codegen.
- SIR‑Core: small, stable, executable subset (the codegen boundary).
- SIR‑HL: feature-gated higher-level forms, deterministically lowered to Core.
- Today, the blessed HL subset is
sem:v1intent nodes (examples):sem.if,sem.cond,sem.and_sc,sem.or_scsem.switch,sem.match_sumsem.while,sem.break,sem.continuesem.defer,sem.scope
- Today, the blessed HL subset is
sircc: verifier + compiler + lowerer (LLVM backend; optional zasm emission).sirc: the human-friendly language front-end (.sir→*.sir.jsonl).sem: verifier + deterministic runner under explicit capabilities (built onsircore).
sircore: zero-trust execution core (structured module in; capability calls out).svm: VM tier (JIT/runtime direction; early, but the intent is explicit).
Build the copy/pasteable bundle in ./dist/:
cmake -S . -B build
cmake --build build --target distRun the normative suite (alpha-user friendly):
./dist/bin/<os>/sircc --checkCompile an example:
./dist/bin/<os>/sircc ./dist/test/examples/mem_copy_fill.sir.jsonl -o /tmp/mem_copy_fill
/tmp/mem_copy_fill; echo $?If sirc is bundled, try the full language pipeline:
./dist/bin/<os>/sirc ./dist/test/examples/hello.sir -o /tmp/hello.sir.jsonl
./dist/bin/<os>/sircc /tmp/hello.sir.jsonl -o /tmp/hello
/tmp/helloSupport surface (authoritative; matches the implementation):
./dist/bin/<os>/sircc --print-support --format html --full > /tmp/sircc_support.htmlBundled docs/examples live under:
dist/doc/dist/test/examples/
Zeta is intentionally usable in multiple modes:
- Verify + compile to native (LLVM):
sircc --verify-only your.sir.jsonlsircc your.sir.jsonl -o your_exe
- Verify + run under explicit capabilities (emulation / harness):
sem --verify your.sir.jsonlsem --run your.sir.jsonl --cap ... [--tape-out run.tape]
- Lower to a backend-neutral IR (alternate backends / emulator-driven workflows):
sircc your.sir.jsonl --emit-zasm -o out.zasm.jsonl
These aren’t different products: they’re different lenses over the same contract.
- Project version lives in
./VERSIONand is reported bysircc --version,sirc --version, andsem --version. - Convenience wrappers:
make build,make dist,make bump.
- Zeta is under active development; the verifier and support surface are treated as the truth.
- Use
sircc --print-supportto see exactly what’s implemented today. - The dist bundle is designed to be copy/pasteable for alpha users.
- Tools (
sircc,sirc,sem) and implementation code are GPL-3.0-or-later. - The SIR format/spec + schemas + example IR programs are MIT (
schema/sir/**+LICENSE-LIB).