Target compatibility

Faber is one language with many compilation contracts. This page is the measured lowerability matrix: for each corpus term, which targets can lower it, and at what support level.

Policy verbs (support / erase / warn / reject / defer) and pipeline routing live on Compiling and targets. This page is the large scannable row list — HIR application-lane targets and MIR systems-lane targets side by side in the tables below.

Live CLI summary: faber targets.

Why the terms below are in Latin. Everywhere else on this site, code renders in your reader locale — the same program, spelled in your language. The term column here does not, because it is not code: it is the identity of each construct, the key the compiler's own corpus is indexed under. Latin is Faber's canonical form precisely because no living language has a claim on it, so no locale's spelling has to be the one the others are measured against. A row is the same row whichever language you read the site in.

Rendered: unknown by faber/scripta/render-matrices.py from radix measurement JSON — do not hand-edit. Measurement: emit_hir_target_matrix + emit_mir_target_matrix (in-process, no external toolchains). Join: corpus/index.toml terms → exempla.

This is the official generated grammar×target support matrix. It reports lowerability — can target X lower grammar production Y — across every term in the exempla corpus. Runtime semantics (erase/warn/defer policy verbs), per-target contracts, and pipeline routing live in Compiling and targets, which links here for the rows.

Legend#

A ✓ means the corpus exempla exercising this term lower to the target. It does not guarantee identical runtime semantics. Some targets erase or warn on certain constructs (e.g. Go erases borrow modes de/in/ex) — those still render ✓ here because they lower. See the policy doc for that nuance.

Corpus-wide summary (all registered terms)#

How to read these percentages#

This matrix answers one narrow question:

For each general-language corpus term, does the named emit target lower the term's exempla?

It is not a product completion score for Metal, CUDA, or GPU training.

• Application HIR percentages (Rust / Go / TS / Faber) are fair "how much of the language emits" scores for host-language projections.
• General MIR percentages (llvm-text, wasm, sexp, …) score ordinary systems IR emission over the same full corpus.
• Device-kernel emitters are not scored here. metal-text and wgsl-text lower a device-safe kernel surface — @ nucleum compute kernels and related GPU views — and deliberately nothing else: no packages, async, CLI, full control flow, or host libraries. Measuring them against all ~280 general-language terms answers a question that does not apply to them, so this matrix does not ask it. Their real support is the device kernel support summary below, and real device execution runs through faber run --backend metal.
• There is no `cuda` column. CUDA is not a text emit target. CUDA device programs are produced on the NVVM → PTX path (staged with llvm-text / MIR device emission) and run with faber run --backend cuda. Product GPU backends are Metal and CUDA; matrix columns track emit surfaces, not every host session.

For product policy (build/run/package, erase/reject, device backends), use Compiling and targets and faber targets — not these corpus rows as a quality score.

Application lane (HIR → emitted source languages)

Systems lane (MIR → device/IR artifacts)

Device kernel support (product summary)#

This section is the GPU product view. It is intentionally separate from the corpus % tables below.

Status of measurement (2026-08-07): dual-backend training proofs and local device fixtures are accepted on named machines. A multi-card CUDA verification matrix (ephemeral cloud pods) is active and expanding — more rows land as RunPod lanes and Faber package fixtures close. Numbers here are evidence snapshots, not a permanent completion score.

Product backends#

Workload / kernel families (measured so far)#

Statuses use three labels only:

CUDA hardware verification matrix (cloud, expanding)#

Opt-in RunPod lanes exercise short CUDA proofs on cards the operator does not own. This is verification infrastructure, not a new product backend.

Honesty bounds on the cloud matrix:

1. The first multi-card receipt was largely a per-pod compile+run viability probe (same small CUDA program, pod-local toolchain), not a claim that every card already ran the full dual-backend MLP oracle.
2. Same-artifact Faber package portability (device-summa / training fixtures on one PTX blob across cards) is the follow-on track — active now.
3. Metal stays on local Apple Silicon acceptance hosts; RunPod lanes are CUDA only.
4. Expect this table to grow as more lanes, fixtures, and receipts land. Prefer linking factory receipts over inventing percentages.

Where to look for live evidence#

Internal factory control plane (not a public product surface): RunPod lane registry and matrix receipts under the radix factory tree (docs/factory/runpod-gpu-verification/).

Keywords — application lane#

keyword#

Operators — application lane#

operator-group#

Keywords — systems lane#

keyword#

Operators — systems lane#

operator-group#

Other terms (existing-home / unspecified)#

existing-home#