From 546a4f219b034e868696877cb96c3fdd520754e1 Mon Sep 17 00:00:00 2001 From: bQUARKz Date: Thu, 19 Feb 2026 12:22:14 +0000 Subject: [PATCH] pr4.1 --- .../prometeu-vm/src/virtual_machine.rs | 17 ------- files/TODOs.md | 50 ------------------- 2 files changed, 67 deletions(-) diff --git a/crates/console/prometeu-vm/src/virtual_machine.rs b/crates/console/prometeu-vm/src/virtual_machine.rs index e2a4be4c..72be3f31 100644 --- a/crates/console/prometeu-vm/src/virtual_machine.rs +++ b/crates/console/prometeu-vm/src/virtual_machine.rs @@ -56,23 +56,6 @@ pub struct BudgetReport { pub reason: LogicalFrameEndingReason, } -/// The PVM (PROMETEU Virtual Machine). -/// -/// A deterministic, stack-based virtual machine designed for game logic and -/// educational simulation. The PVM executes bytecode compiled from TypeScript/JS -/// and interacts with virtual hardware through a specialized instruction set. -/// -/// ### Architecture Highlights: -/// - **Stack-Based**: Most operations pop values from the stack and push results back. -/// - **Deterministic**: Execution is cycle-aware, allowing for precise performance budgeting. -/// - **Sandboxed**: No direct access to the host system; all I/O goes through Syscalls. -/// - **Type-Aware**: Supports integers, floats, booleans, and strings with automatic promotion. -/// -/// ### Memory Regions: -/// - **ROM**: Immutable instruction storage. -/// - **Operand Stack**: Fast-access temporary storage for calculations. -/// - **Global Pool**: Persistent storage for cross-frame variables. -/// - **Heap**: Dynamic memory for complex data (simplified version). pub struct VirtualMachine { /// Program Counter (PC): The absolute byte offset in ROM for the next instruction. pub pc: usize, diff --git a/files/TODOs.md b/files/TODOs.md index fe3eefb4..092c8b4c 100644 --- a/files/TODOs.md +++ b/files/TODOs.md @@ -1,53 +1,3 @@ -# PR-4.1 — Define Canonical Stack Effect Table for Core ISA - -### Briefing - -The verifier must rely on a single canonical definition of stack effects for every opcode. This PR introduces the formal stack effect table for the new core ISA. - -### Target - -* Provide a single authoritative stack effect definition per opcode. -* Ensure verifier and tooling use the same source of truth. - -### Work items - -* Introduce a stack effect table or equivalent structure: - - * Input slot count. - * Output slot count. -* Attach stack effect metadata to each opcode. -* Ensure the table is used by the verifier entry points. -* Document stack effects in code comments (English). - -### Acceptance checklist - -* [ ] Every opcode has a defined stack effect. -* [ ] Verifier uses the canonical table. -* [ ] No duplicated or ad-hoc stack effect logic remains. -* [ ] `cargo test` passes. - -### Tests - -* Add unit test ensuring all opcodes have stack effects defined. - -### Junie instructions - -**You MAY:** - -* Introduce new metadata tables for opcodes. -* Refactor verifier code to use the canonical table. - -**You MUST NOT:** - -* Change opcode semantics. -* Introduce new instructions. - -**If unclear:** - -* Ask before assigning stack effects. - ---- - # PR-4.2 — Basic Stack Safety Verification (Underflow/Overflow) ### Briefing