Intrepid/prometeu-runtime
Intrepid/prometeu-runtime
3
0
Fork 0
Code Pull Requests Activity

pr4.1

Browse Source
This commit is contained in:
bQUARKz 2026-02-19 12:22:14 +00:00
parent 929dcde0c6
commit 546a4f219b
Signed by: bquarkz
SSH Key Fingerprint: SHA256:Z7dgqoglWwoK6j6u4QC87OveEq74WOhFN+gitsxtkf8
2 changed files with 0 additions and 67 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
crates/console/prometeu-vm/src/virtual_machine.rs
View File

@ -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,

50
files/TODOs.md
View File

@ -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