Technology Stack

A technical overview of the ERD-TSVM compiler, virtual machine, syscall architecture, and platform targets.

Compiler Pipeline

The ERD compiler transforms TypeScript source into compact bytecode through a multi-stage pipeline. Each stage refines the representation, applying type checks, optimisations, and platform-specific code generation.

Decorator Support

TC39 Stage 3 decorators are fully supported and lowered at compile time. Class, method, getter, setter, and field decorators all work as specified. Auto-accessor declarations (accessor x = 0) are desugared into a backing property with generated getter/setter. Decorator context objects include kind, name, static, private, addInitializer, access, and metadata. Symbol.metadata inheritance follows the specification via prototype chaining.

Optimisation Pipeline

The compiler includes a multi-phase optimisation pipeline that progressively improves code quality and reduces output size. Optimisations include constant folding, dead code elimination, constant propagation, strength reduction, loop-invariant code motion, tail call optimisation, common subexpression elimination, loop unrolling, and type-guided transforms.

Optimisation Levels

Four optimisation levels control how aggressively the compiler optimises. Individual optimisations can also be toggled explicitly.

Project Configuration — erdtsconfig.json

The erdtsconfig.json file configures the compiler per-project. It follows the same pattern as TypeScript's tsconfig.json — place it in your project root and the compiler discovers it automatically. CLI flags always override config values.

Example with path aliases for a multi-package project:

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@sensors/*": ["packages/sensors/src/*"],
      "@utils/*": ["packages/utils/src/*"]
    },
    "optimizationLevel": 2,
    "snapshot": true,
    "target": "esp32"
  },
  "manifest": {
    "moduleName": "sensor-hub",
    "version": "1.0.0",
    "capabilities": ["gpio", "bus", "mqtt"]
  }
}

Heap Snapshot System

The heap snapshot system captures the VM's post-initialisation memory state and embeds it as a binary section in the .erd bytecode file. On cold start, the runtime deserialises the snapshot directly into the heap — skipping all module imports, class definitions, prototype chains, and constant materialisation.

Capture Pipeline

TypeScript source
    ↓  compile + bundle
.erd bytecode (without snapshot)
    ↓  erd-snapshot-bootstrap
    ↓    1. Load in fresh Isolate
    ↓    2. Run $bundled_init to completion
    ↓    3. Capture heap via HeapSnapshotWriter
    ↓    4. Splice SNAPSHOT section into .erd
.erd bytecode (with snapshot)
    ↓  runtime cold start
    ↓    1. Detect SNAPSHOT section
    ↓    2. Validate CRC-32 hashes
    ↓    3. Restore heap (skip $bundled_init)
    ↓    4. Schedule main closure
Program running (up to 82× faster)

Bytecode Format — ERD1

The compiler outputs ERD1 bytecode files — a compact, section-based binary format designed for minimal memory footprint and fast loading on constrained devices. The format supports optional debug information, compressed sections, cryptographic signing, integrity verification via checksums, and heap snapshots for fast cold start.

Virtual Machine

The ERD-TSVM executes compiled bytecode on a register-based architecture with up to 256 general-purpose registers per stack frame, automatic register spilling, a generational garbage collector, super instruction fusion, and an async fiber scheduler.

Memory Management

The runtime uses a generational garbage collector designed for low-latency execution on constrained devices. Short-lived objects are collected quickly via a young generation collector, while long-lived objects are promoted to an old generation with mark-and-sweep collection.

Hidden Classes

Objects with the same properties added in the same order share a hidden class, allowing the runtime to optimise property access by offset rather than dictionary lookup. This technique — common in production JavaScript engines — delivers fast property access even on constrained hardware.

Fiber Scheduling

The runtime uses cooperative fibers for concurrency — no OS threads are needed, making it ideal for single-core microcontrollers. Each async function, Promise.then() chain, or timer callback runs in its own fiber. When a fiber awaits an async operation (I/O, timer, Promise), it suspends and the scheduler picks the next ready fiber. This model delivers non-blocking I/O with deterministic execution order and minimal memory overhead.

Event Loop

The runtime implements an event loop with semantics matching browser and Node.js behaviour — Promise reactions and microtasks are processed before timers and I/O completions, ensuring predictable execution order for async code.

Syscall Architecture

Syscalls bridge TypeScript code and native platform capabilities. When TypeScript calls a standard library function, the compiler emits a syscall instruction. At runtime, the VM dispatches to a platform-specific native handler.

Syscalls are organized into domains — logical groupings of related functionality. Each domain has its own handler that processes syscalls for its category. All I/O domains support both synchronous and asynchronous modes. In async mode, the calling fiber suspends and is resumed when the operation completes, enabling non-blocking I/O without callbacks or OS threads.

Platform adapters implement only the syscalls relevant to their target — unsupported syscalls return a clear error at runtime. This allows the same TypeScript source to compile once and run on any platform, with platform-specific capabilities gracefully degrading where not available.

Platform Targets

Platform Abstraction

The runtime uses a platform abstraction layer that isolates hardware and OS differences behind portable interfaces. Each platform (ESP32, Desktop, WASM) provides its own implementation. This architecture enables write-once TypeScript code: the same bytecode runs unchanged on a microcontroller, a development laptop, or a web browser.

Security

Security is built into every layer of the stack — from the bytecode format to the runtime execution model.

TypeScript Support

ERD-TSVM targets TypeScript 6.0 and the ES2026 specification. The compiler tracks 254+ language features across all ECMAScript editions from ES2015 through ES2026.

Type Erasure

Type annotations are checked during semantic analysis and erased during bytecode generation. There is no runtime type metadata — consistent with standard TypeScript behavior. This means interfaces, type aliases, and generic constraints have zero runtime cost.