CUBELinux-2
1539ecd1bb
- cubecode/src/cb.rs: Behavior descriptor bitflag (PURE/IO_HEAVY/HOT_PATH) encoded into HeaderFlags bits 13..15; C_OS_KERNEL=210 / C_OS_EFFECT=211 coordinate bands; round-trip unit test. - fix: HEADER_FLAG_BEHAVIOR mask was 0x7000 (bits 12-14) which grabbed the ENCRYPTED bit (12) and dropped HOT_PATH (bit 15). Corrected to 0xE000. - store_code_cell/put_code_cell/header_for_code gain optional descriptor arg; all 12 prior call sites pass None (total change). - CLI: prog K=<flag> tokens, kernel verb (links+descriptors), tick verb lays down the OS kernel call-graph (cfg->decide->summarize->tick), native-apply verb = thin effector (runs kernel in VM, reads computed result, emits effect). - integration test os_kernels_live_in_cube_with_call_graph_and_descriptors. Proven green via ./check quick (fmt+clippy -D warnings+tests).
48 lines
2.3 KiB
Rust
48 lines
2.3 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 cb;
|
|
pub mod cell;
|
|
pub mod opcode;
|
|
pub mod vm;
|
|
|
|
pub use cb::{Behavior, C_OS_EFFECT, C_OS_KERNEL, HEADER_FLAG_BEHAVIOR};
|
|
|
|
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};
|