rajamesandClaude Opus 5.5
294e69463a
One boot, v4/system/boot.c, for both products: it starts the nucleus image, finds each capsule in the baked capsule directory, recomputes its hash, checks its signature, gives its blocks to the node a line at a time, and prints PARITY:V4_NUCLEUS, PARITY:V4_CAPSULE and PARITY:OK before the prompt. A line the node does not accept ends the boot with the capsule, block and line named. docs/v4.0.0/NUCLEUS.md. - hosted Linux product for amd64, aarch64 and riscv64 (make -C v4 hosted); make -C v4 hosted-check boots all three and requires identical output - the kernel's v4 entry (STARFORTH_V4=1) calls the same boot - capsules/v4/forth79.4th, block 6000: no definitions yet - mkimage builds the nucleus only; no FORTH source is compiled at build time - capsule_blocks.c: the Block-header parse, free of any VM, for every loader Verified: make -C v4 test passes; hosted-check passes on the three ISAs with the same hashes; the kernel compiles with STARFORTH_V4=1 on the three. Not verified: no bare-metal boot of v4 has been run. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
v4/
StarForth v4: the 32-instruction F18-derived core. The design lives in
docs/v4.0.0/JUSTIFICATION.md (why) and docs/v4.0.0/DECOMPOSITION.md
(every v3 word mapped to a v4 fate).
The first deliverable is the hosted C99 golden model (JUSTIFICATION.md §10,
step 1). It must pass POST and hold K≡1.0 with 32- and 64-bit cells on all
three host ISAs.
Acceptance (JUSTIFICATION.md §16): v4 must be equivalent to v3 at any point
in time, with the same vocabularies and behaviour, on the F18-derived engine;
and every ISA, hosted and bare metal, must still reach its ok prompt.
make -C v4 test passing is a development check, not acceptance.
What exists so far is the single node: registers, circular stacks, memory, all
32 opcodes, per-opcode and per-call-target heat, and three console
registers (CONSOLE-TX, which captures output, and CONSOLE-RX and CONSOLE-STATUS, which hand out
input a test feeds) standing in for the console node until the mesh exists. The tests load definitions
onto a node either opcode by opcode (v4/include/v4/asm.h) or as text in the notation DECOMPOSITION.md
uses (v4/include/v4/text.h). make -C v4 test builds
and runs the tests at both cell widths; make -C v4 sanitize repeats them
under ASan and UBSan. There is no POST and no K measurement yet.
The system: nucleus, capsules, prompt
docs/v4.0.0/NUCLEUS.md is the design. A v4 system is four things:
| Part | Where | What it is |
|---|---|---|
| Engine | v4/src |
The golden model of the 32-opcode node |
| Nucleus | v4/capsule/*.v4, built by v4/tools/mkimage.c |
The assembled words, as a memory image linked into the binary |
| Capsules | capsules/v4/*.4th, baked by tools/mkcapsule.c |
FORTH source, loaded when the system comes up |
| Boot | v4/system/boot.c |
Starts the nucleus, checks and loads each capsule, prints the parity lines, gives the prompt |
Two products link the same four and differ only in the console:
- Hosted Linux,
v4/tools/hosted.c:make -C v4 hostedbuildsv4/build/starforth4-amd64,-aarch64and-riscv64, static, 64-bit cells. - Bare metal,
kernel/src/v4/sk_v4.c:make -f kernel/Makefile ARCH=<arch> STARFORTH_V4=1.
A boot prints:
PARITY:V4_NUCLEUS words=292 image_hash=0x...
PARITY:V4_CAPSULE name=v4:forth79.4th capsule_id=0x... capsule_hash=0x... dict_hash=0x...
PARITY:OK
ok>
Every build of one commit prints the same hashes. make -C v4 hosted-check
boots the three hosted binaries (the two foreign ones under user-mode QEMU)
and fails unless their output is identical and ends in PARITY:OK.
A capsule line the node does not answer ok to ends the boot, naming the
capsule, block and line, with PARITY:FAIL and POST: FAILED.
State, 2026-10-05: capsule loading works hosted on all three ISAs, and the
kernel compiles with STARFORTH_V4=1 on all three. forth79.4th holds no
definitions yet: all 292 words are still in the nucleus. There is no POST
yet, and no bare-metal boot of v4 has been run.