Star forth v4.0.0 #3
@@ -133,6 +133,60 @@ not this step.
|
||||
node prints. That is a work-around for the node owning what the kernel
|
||||
owns, and it goes when the engine takes the VM's place.
|
||||
|
||||
## 1c. The frame: the Stadium
|
||||
|
||||
`FABRIC-2.md` section B: "words are stadium patrons, VMs are patrons,
|
||||
blocks are patrons, messages are stadium patrons, all should be operated on
|
||||
by THE SAME ENGINE."
|
||||
|
||||
- A patron is one 64-byte cell of nine wires: identity, heat, TTL, pin,
|
||||
link, behaviour, mass, payload, contains
|
||||
(`kernel/include/starkernel/vm/stadium.h`).
|
||||
- Heat is a conserved share of 1.0; K is that conservation.
|
||||
- The behaviour is what happens when a patron leaves: words and VMs `COOL`,
|
||||
blocks `MIGRATE`, messages `DELIVER`, ACLs `EXPIRE`.
|
||||
- A cell never holds the thing itself, only its identity and heat. A word's
|
||||
code stays in the dictionary; a block's bytes stay in the block
|
||||
subsystem.
|
||||
|
||||
Compudynamics is therefore the kernel's Stadium, not something inside the
|
||||
VM engine. The engine's part is to report what it executes: in v3,
|
||||
`stadium_word_dispatch(vm, word_id, tick)` from the inner loop.
|
||||
|
||||
**Reading of the opcode ruling (section 2.7) in this frame, stated to
|
||||
Captain Bob 2026-10-05 and not corrected:** on v4 that report carries an
|
||||
opcode, and a VM's word patrons become its 32 opcode patrons.
|
||||
|
||||
## 1d. Blocks (discussed and ruled 2026-10-05)
|
||||
|
||||
**v3, as built:**
|
||||
|
||||
- One block address space in kernel C (`v3/src/block_subsystem.c`): fast
|
||||
RAM at 0 to 2047, the ramdrive, Artemis's virtio disk, USB drives,
|
||||
chained.
|
||||
- Every block has metadata (`blk_meta_t`): the owner's fingerprint,
|
||||
`acl_allow`, `acl_ttl`, a write count, chain links.
|
||||
- Blocks are patrons: `BLOCK`, `BUFFER` and `UPDATE` call
|
||||
`stadium_block_dispatch` with the LBN; heat drives migration and wear
|
||||
levelling (`kernel/src/vm/stadium_blocks.c`).
|
||||
- Artemis is the Tripod leg that owns persistent storage.
|
||||
- Identity lives there: a keypair Zuse mints onto a thumbdrive; its
|
||||
fingerprint is stamped on every block it claims at first touch, behind
|
||||
the home-blocks fence; the disk's genesis signature is how the kernel
|
||||
knows Artemis's disk.
|
||||
|
||||
A v3 VM's block words ask the kernel's block subsystem for a block and get
|
||||
a buffer back. Ownership, ACL, physics and devices are the kernel's.
|
||||
|
||||
**Ruling (Captain Bob, "yes"):** a v4 node only ever asks for a block by
|
||||
number. Everything about who may have it is decided on the kernel's side,
|
||||
under the VM's identity. The device chain, metadata, first-touch claim,
|
||||
ACL, migration and the Stadium touch stay where they are.
|
||||
|
||||
**What this says about the lone-node boot.** It gives the node a bare RAM
|
||||
array behind its four block registers (D-19), which skips the address
|
||||
space, the metadata, the owner, the ACL and the Stadium.
|
||||
|
||||
## 2. Row 3: physics and per-word heat
|
||||
|
||||
### 2.1 What v3 does
|
||||
|
||||
Reference in New Issue
Block a user