rajamesandClaude Opus 5.5
506b645726
clean qemu with STARFORTH_V4=1 on amd64, aarch64 and riscv64, one at a time. Each prints the same PARITY:V4_NUCLEUS and PARITY:V4_CAPSULE lines as the three hosted binaries (image_hash 0x60b74e4f87adb0ac, dict_hash 0x0baed67626b4fac4), then PARITY:OK and ok>. Each run was ended once the prompt was in the log. Nothing was typed at a bare-metal prompt. The capsules were unsigned: no signing key on this machine. The v3 boot (STARFORTH_V4=0) was not re-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 on all six builds. The three hosted
binaries and the three bare-metal kernels (clean qemu with STARFORTH_V4=1)
print the same four lines and reach ok>:
PARITY:V4_NUCLEUS words=292 image_hash=0x60b74e4f87adb0ac
PARITY:V4_CAPSULE name=v4:forth79.4th capsule_id=0xa4b74bdc7deaf204 capsule_hash=0xa4b74bdc7deaf204 dict_hash=0x0baed67626b4fac4
PARITY:OK
ok>
Bare-metal logs: logs/20261005-152955/amd64/, logs/20261005-154021/aarch64/,
logs/20261005-154150/riscv64/. Each run was ended once the prompt was in the
log; nothing was typed at a bare-metal prompt, so keyboard input there is not
yet verified. The capsules were unsigned (no signing key on this machine).
forth79.4th holds no definitions yet: all 292 words are still in the
nucleus. There is no POST yet.