Internals

Architecture

NanoVM is a multi-tier platform: one shared kernel, a set of peer runners that each execute a kind of program on a different engine, and apps delivered through the catalog.

One kernel, peer runners, apps

A shared kernel provides the OS contract — a bus, a virtual filesystem, a process router, networking, capabilities and services, plus the worker-spawn host infrastructure. Each runner registers a spawn delegate with the router and executes one kind of program; apps are prebuilt binaries that target a runner’s ABI and are installed on demand through the catalog.

The runners

Runner
Runs
Engine
Trust
Speed
riscv
RV64 ELF (busybox, node)
emulated CPU (Rust → wasm)
fidelity oracle
slow
node
Node.js
host JS engine
trusted
fast
wasm
wasm32-wasip1 commands
host wasm engine
capability-scoped
fast
boa
untrusted JS
Boa interpreter (Rust → wasm)
sandboxed
medium

The dependency rule

  • A runner imports only from the kernel — the shared bus, VFS, router, net, caps and services, plus the worker-spawn host infrastructure.
  • No runner imports another runner. Cross-tier work goes through router.route(), the bus and the shared VFS.
  • Apps target a runner ABI (wasm32-wasip1, riscv64-elf) and are consumed via the catalog / CAS — they import nothing.

The RISC-V runner

The historic “NanoVM” is the RISC-V runner — a full RV64GC Linux userland VM, and the correctness oracle the faster tiers are validated against. Its Bellard-style monolithic interpreter, memory layout, the 12,680-byte VM struct and its threading model are covered on the RISC-V runner page.

Terminal: model / render split

The terminal model lives inside the guest — the RISC-V runner’s term.rs (an ANSI / vte parser plus a fixed cell grid) and tty.rs (the line discipline and stdin ring) — while the separate <nano-terminal> web component reads the grid out of linear memory and renders it.