kvlangRuntime extensions
kvlang is an extension-first language. The core stays small; capabilities arrive as runtime extensions and libs. Multiple runtime extensions execute in the same kvspace — one tree of code, frames, and values, visible to every participant.
A runtime registers its opcodes at /lib/<opcode>; a lib is a set of rwir/rwfunc definitions laid out into the same tree.
The deepx repository holds model definitions rather than a runtime extension, and deepx-design is documentation; neither is listed as a runtime below.
Registration styles differ. runtime-c is the C core; runtime-rs and deepx-cpu-compute embed it and declare a capability set. deepx-cpu-compute additionally writes its signatures to /lib/<opcode> for distributed scheduling. deepx-compute-cuda registers tensor functions through its own TfFactory. The Metal compute/heap/io planes and heap-cuda exchange bare opcodes (add, load, print, save) over a Redis task queue rather than through /lib routing.
All deepx extensions are being migrated to embed the runtime-c core and register through the capability/route contract; until that migration completes, the table records their current mechanisms.
| Runtime | Arch/OS | Lib (requires this runtime) | Notes |
|---|---|---|---|
| runtime-c | linux-x86_64, darwin-arm64 |
— | The minimal core: fetch, decode, execute, control flow, native dispatch. Runtime extensions embed this core rather than fork it. |
| runtime-rs | linux-x86_64, darwin-arm64 |
stdlib |
The first runtime extension and its first lib. Embeds the C core and adds the stdlib opcodes (kv, xv, time, duration, string); the binary is still named kvlang.
|
| runtime-rs | linux-x86_64, darwin-arm64 |
byteseek | The second lib. An agent harness written in kvlang, running on runtime-rs against the same kvspace. |
| deepx-cpu-compute | linux-x86_64, linux-arm64, darwin-x86_64, darwin-arm64 |
— |
The CPU op-plat: tensor kernels over OpenBLAS/Highway/OpenMP. Declares myrwircaps = deepx/miaobyte·* (add, sub, mul, div, …), embeds the C core, and writes signatures to /lib for distributed scheduling.
|
| deepx-compute-metal | darwin-arm64 |
— |
The Metal op-plat. Runs elementwise/reduce/changeshape kernels on the GPU; bare task opcodes arrive over Redis, not through /lib. Requires Metal (no CUDA).
|
| deepx-common-metal | darwin-arm64 |
— | The Metal HAL: device detection and shared Metal context used by the other Metal rows. |
| deepx-heap-metal | darwin-arm64 |
— | The Metal heap-plat: tensor lifetime and shared-memory bookkeeping alongside the Metal compute plane. A Redis-driven service, not a kvlang capability set. |
| deepx-io-metal | darwin-arm64 |
— |
The Metal io-plat: load / print / save tasks driven over the Redis queue.
|
| deepx-compute-cuda | linux-x86_64 + CUDA |
— |
The CUDA op-plat. Registers deepx/miaobyte·* tensor functions through its own TfFactory; built in a CUDA 12.8 container, CMake targets sm_75.
|
| deepx-heap-cuda | CUDA (OS not pinned in repo) | — | The CUDA heap-plat: device/host memory lifecycle and synchronisation. A Redis-driven service, not a kvlang capability set. |
| deepx-cuda-kernelcompiler | linux-x86_64 + CUDA |
— |
The GPU kernel compiler: lowers kvlang tensor ops to TileLang kernels (AOT .so); no opcode registration.
|
Extensions grow by registration, not by changing the core: new capabilities land under /lib, and any runtime can provide them. Each lib requires the runtime in the same row to run; a lib's opcodes are registered under that runtime's /lib/<opcode>.