CUBELinux-2
4484eba83d
Implements the PDF's Package 4 (cubevm/cubecode): the cube as a substrate for
storing and introspecting code + AI artifacts.
- opcode.rs: decode/encode codec for a deterministic, safe bytecode (28 ops:
stack arithmetic/logic/shift, comparisons, jumps, CALL_LINK, RET, SYSCALL,
DUP/DROP). Body is always decoded through this codec before execution, so
the cube never runs code that didn't survive decode.
- cell.rs: CodeCell + Kind (Fn/Kernel/Layer/Checkpoint/Variant/Other). Kind
rides in the record doc_type; the call graph is the cube's linked_records,
so CALL_LINK n executes linked_records[n].
- vm.rs: stack-based interpreter over CubeStore. CALL_LINK follows cube edges;
call depth is bounded (no infinite cube loops); deterministic + no unsafe +
no float, so runs are reproducible (prereq for 'navigate and reconstruct
experiments'). Host syscalls introspect the cube (degree/link-exists/trace).
Design decision (the PDF's interesting tension): it says body may be
'bytecode, machine code, or serialized model weights' but the load-bearing
clause is a DSL/runtime that 'walks cube links to load and dispatch functions'
= addressable code-as-data. On this hardware a foreign-machine-code JIT is
neither safe nor needed, so we built the safe bytecode VM. cubetrace/
cubedbt/cubeai (execution capture + ML over traces) are the next layer and are
excluded here.
Verified: ./check (fmt+tests+clippy -D warnings) green; cubecode: 13 tests
(arith, div-by-zero fault, CALL_LINK edge-follow, bad-link fault, recursion
depth bound, syscall trace/degree). Gate: cde1e62 -> +Package4.
45 lines
2.2 KiB
Rust
45 lines
2.2 KiB
Rust
//! Package 4 of CUBELinux-2: cubevm / cubecode — code/data mapping over the
|
|
//! CZYX cube (PDF "cubevm or cubecode").
|
|
//!
|
|
//! The PDF's intent: "use the cube as a substrate for storing and
|
|
//! introspecting code and AI artifacts. Treat each function, module, or model
|
|
//! component as a record ... Use association flags and CZYX links for: call
|
|
//! graphs, dependency edges, variant implementations, version history."
|
|
//!
|
|
//! Resolution of the interesting tension: the PDF also says "body: bytecode,
|
|
//! machine code, or serialized model weights" and imagines "a scripting
|
|
//! language or DSL whose runtime walks cube links to load and dispatch
|
|
//! functions." The second clause is the load-bearing one for the design — it
|
|
//! is about *addressable, introspectable code-as-data*. We therefore build a
|
|
//! **safe, deterministic, cube-addressed bytecode VM** rather than a
|
|
//! machine-code JIT:
|
|
//!
|
|
//! * Each function/leaf is a record whose body is bytecode (`opcode.rs`).
|
|
//! * The call graph *is* the cube's association graph: `CALL_LINK n`
|
|
//! executes `linked_records[n]` (`vm.rs`). No foreign machine code is ever
|
|
//! executed; the body is always decoded through the codec first, so the
|
|
//! cube never runs something that didn't survive `decode`.
|
|
//! * AI artifacts (layers, checkpoints) are first-class `Kind`s so they
|
|
//! address into the same cube the code lives in (`cell.rs`).
|
|
//!
|
|
//! This runs on the metal here, needs no elevated privileges, and is fully
|
|
//! deterministic — a prerequisite for the PDF's "navigate and reconstruct
|
|
//! experiments" use case. A real model registry would point `Kind::Layer`
|
|
//! records at weight blobs (stored as record bodies) and link them into a
|
|
//! graph the VM can traverse.
|
|
//!
|
|
//! Scope note: `cubetrace`/`cubedbt`/`cubeai` (execution capture + replay +
|
|
//! ML over traces) are the *next* layer and are excluded on this hardware;
|
|
//! they would consume `cubecode`'s records as their input.
|
|
|
|
#![forbid(unsafe_code)]
|
|
#![warn(missing_docs)]
|
|
|
|
pub mod cell;
|
|
pub mod opcode;
|
|
pub mod vm;
|
|
|
|
pub use cell::{CodeCell, Kind};
|
|
pub use opcode::{decode, encode, CodeError, Op};
|
|
pub use vm::{Fault, RunResult, Vm, SYS_DEGREE, SYS_LINKED_EXISTS, SYS_NOP, SYS_TRACE};
|