f4bfe7de02bf1a3e2c462c22bab8a7f766baee69
36
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 rajamesandJunie
|
a8b70e88d3 |
Reorganize source tree: kernel/, v3/, v4/ split and board infrastructure
Source tree reorganization: - Move StarForth v3 engine to v3/ (src/, include/, Makefile) - Move kernel to kernel/ (src/, include/, linker/, Makefile) - Create v4/ skeleton for F18-ISA golden model (DECOMPOSITION.md, JUSTIFICATION.md) - Move FABRIC-0..4.md to docs/fabric/ - Move ONTOLOGY.md and ROADMAP.md to docs/ Board infrastructure: - Add boards/ser5/, boards/raspi/, boards/milkv/, boards/zynq7020/ - Each board has board.mk (ISA, CPU flags, boot recipe) and README.md - Root Makefile becomes thin dispatcher: boot_image, all, clean, docs take TARGET - make boot_image TARGET=SER5|RASPI|MILKV builds one GPT/MBR image per board - ZYNQ7020 target exists but stops with clear error (ARMv7 port not built yet) - scripts/mkdiskimage.sh builds disk images for all boards Docs pipeline: - docs/book/ with LaTeX master (main.tex) and Makefile - pandoc converts Markdown to LaTeX at build time - Two Lua filters: table-widths.lua (wide tables wrap), code-breaks.lua (inline code breaks) - make docs builds single PDF (754 pages, 0 missing characters) - make docs TARGET=<board> adds board appendix - build/docs/<book|board>/meta.tex stamps git commit into PDF Bug fixes: - 42 include paths that only worked by accident now use correct relative paths - clang-18 hardcode replaced with configurable CC variable (fixed aarch64 build) - Pi 5: kernel_2712.img linked at 0x80000, .bss zeroed, memory reserved - Doxyfile, .clang-tidy, README.md, Kconfig paths updated Verified: - Hosted v3 build passes 1012 tests, 0 failures - SER5 image boots in QEMU (OVMF), POST passes, K exact (65536 = Q48_ONE) - Milk-V image boots in QEMU (OpenSBI + U-Boot + bootefi), POST passes - make clean TARGET=<board> removes only that board and its ISA objects - make all builds all boards, hosted v3, and docs in one run Co-authored-by: Junie <junie@jetbrains.com> |
||
|
Robert Allan JamesandClaude Sonnet 5
|
2a084ba037 |
Phase 5 corrections: sharpen 5.1's boundary claim, fix hosted Makefile's own stale VERSION
Advisor review of the Phase 5 close-out commit caught two real issues: - Task 5.1's write-up claimed the Isabelle pass "confirms no regression" -- overstated. Nothing in proof/'s scope changed, so the pass isn't regression evidence, it's a build-completeness formality; the boundary argument alone already supports the real conclusion. Sharpened. - sbom.spdx was regenerated before the 5.4 version bump, so it briefly understated the engine version. Root cause: the hosted Makefile carries its own separate hardcoded VERSION (Makefile:17, still 3.1.0), distinct from Makefile.starkernel's copy that 5.4 bumped -- duplication CLAUDE.md's own "two independently tracked version strings" note doesn't document. Bumped to 3.2.0 to match, regenerated (PackageVersion now correct), and rebuilt the hosted starforth binary so lfs/amd64/starforth reflects it. Also recorded why 5.1-5.4 landed as one commit (deviation from this document's per-task-commit discipline) and sharpened the riscv64 log entry so the FAILED run and the accepted retry aren't ambiguous to a future reader grepping logs/. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
Robert Allan JamesandClaude Sonnet 5
|
6c6293cd52 |
Move PLOT/FB-WIDTH/FB-HEIGHT registration to Hestia only -- FABRIC-3.6.md task 1.8
Real fix for task 0.8's finding. register_framebuffer_words() was
called unconditionally from register_forth79_words() (word_registry.c),
itself called unconditionally from vm_init_with_host() -- the generic
per-VM bootstrap every VM goes through, with no way to know a VM's
name at that point.
Removed the unconditional call. Added a name-gated call instead in
capsule_birth_baby() (capsule_birth.c), beside the existing
is_fleet_foundation check -- the one place in the birth path where
capsule_name and the newly-allocated VM* are both in scope together:
Hestia gets register_framebuffer_words(), nobody else does.
Positively verified live, exactly as the task's own check demands:
FB-WIDTH via VM-EXEC returns UNKNOWN WORD in Hermes and Artemis, 1280
in Hestia. Confirmed at the fundamental level too: Hera's own base
PARITY:M7.1a word count dropped from 531 to 528 -- exactly the three
words removed -- identical across all three architectures.
Three-arch boot clean: amd64/aarch64/riscv64 all reach [zuse@Hera] ok>,
zero UNKNOWN WORD during boot. mkcapsule --lint capsules/ clean, 38
files / 0 violations (pure C change, no capsule content touched). No
compiler warnings.
Side effect on the vendored hosted build, expected and not a
regression: capsule_birth.c is kernel-only, so the hosted starforth
binary has no Hestia concept and now never registers these words at
all -- confirmed live. framebuffer_words.c's own top comment already
calls this surface "kernel-only, no-op on hosted builds," so the prior
stub registration was already vestigial. Ran a plain `make` sanity
build per CLAUDE.md's own stated purpose for that target; regenerated
lfs/amd64/starforth included here rather than left stale.
Authorized by Captain Bob ("yes").
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
Robert Allan JamesandClaude Sonnet 5
|
2a30212bd3 |
Real per-VM log persistence: source attribution + ACL pin (FABRIC-3.md §XXVII)
Wires the previously-unused vm_log_attributed_vm() into LOG-APPEND's kernel primitive so persisted log records carry a trustworthy source (the real attributed VM's registry name, or "HADES" pseudo-source) instead of a caller-supplied, trivially forgeable string. Drops src-addr/src-u from LOG-APPEND's stack signature accordingly. Pins LOG-APPEND via bare ACL-PIN in Artemis's own init.4th, matching BIRTH/CAPSULE-BIRTH's precedent for a privileged word that can't reach the shared, host-portable ACL.4th. Also fixes two console-banner nitpicks: a mis-rendering em dash (U+2014) in the boot banner, and drops "Emergency" from the CLI banner text. Doc corrections to artemis_sig.h/zuse_eligibility_list.h reconciling the three fixed devblock ranges now in play. LOG-FLUSH (the intended normal entry point) and level-aware log eviction remain open, flagged not fixed. Re-verified clean boot to ok> on all 3 architectures after every change. riscv64 showed one new, unrelated virtio_blk write-timeout anomaly during Artemis's early physics self-test (self-recovered, boot unaffected, sector doesn't map to the log region) -- flagged, not investigated. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016UNhH1mhi52i6Qihh7ZV5S |
||
|
Robert Allan JamesandClaude Sonnet 5
|
2c1b3cd695 |
Four bugs found live verifying the 8 identity thumbdrives (FABRIC-3.md §IX)
All found by actually running the identity workflow §VII/§VIII made possible, not by code review: 1. Zuse/WIREBIND cross-contamination on detach: capsule_zuse_boot_logout() and capsule_wirebind_unclean_detach() both had no device parameter, so an unrelated device detaching (while the real owner's own stayed attached) incorrectly tore down the wrong session. Both now compare the departing device against their own tracked one, mirroring capsule_wirebind.c's pre-existing g_wirebind_attached_dev precedent. 2. Dictionary-entry memory leak: vm_create_word()'s sf_malloc()'d DictEntry (plus a second per-entry allocation for transition_metrics) was never freed by vm_cleanup(), in both the hosted and kernel implementations. Caused a real kernel PANIC after 8-9 repeated VM birth/kill cycles in one boot. Fixed by walking vm->latest in both. 3. sf_malloc/sf_free (alloc_kernel.c) was a 4MB bump arena with a deliberate no-op free, sized on "VM born once, never killed" -- fix #2 alone didn't stop the panic because free() itself discarded the pointer regardless. Given a real free list (first-fit reuse). 4. Headless-console gate didn't re-engage after a mid-boot logout: the original fix (sk_console_mark_login(), one-way sticky) only gated the first login of the boot. Replaced with a live check (sk_console_identity_present()) re-evaluated continuously, including inside sk_console_readline()'s own blocking idle loop -- the console is normally sitting blocked there when a hot-unplug logout happens, so checking only at the top of the REPL loop wasn't enough. Also: MINT now verifies its own write (verify_mint(), capsule_mint.c) by reading back through the same check a real attach performs, rather than trusting blkio_write()'s BLK_OK alone -- logged via log_message(), not console_println(), per direct instruction. Verified live, amd64: the full 8-identity repeated attach/detach cycle that previously panicked at the same point every time now completes clean, and a full serial-log sweep found zero bare unauthenticated prompts anywhere in the run. Three-arch clean-qemu acceptance passed. Still open, not fixed here: a 3+-simultaneous-device USB enumeration failure found in a separate live test, not yet root-caused. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018EjXFo7mPXjUMjfJeuUUz4 |
||
|
Robert Allan JamesandClaude Sonnet 5
|
4d4ab59189 |
Build the FIRSTTOUCH overflow trigger flagged in FABRIC-2.md §I.2
The overflow-triggered migration path (a WIREBIND-attached identity's own drive running low on space) was scoped but never built -- only the trigger-detection call site was missing, per this section's own text. - capsule_wirebind.c now tracks the attached blkio_dev* alongside the already-tracked VM id, set in try_attach() and cleared in both EJECT/UNCLEAN paths. - New capsule_wirebind_overflow_idle_check(), called once per idle tick in repl.c right alongside blk_migration_idle_check() (same cadence): reads the attached drive's free/total via blk_get_device_free_blocks(), and if free space is below a fixed 10% threshold, extends the identity's pool with a one-time blk_firsttouch_claim() of 8 additional devblocks on Artemis's system-resident device. - New blk_owner_has_claim(owner_fp) in block_subsystem.c answers the debounce question blk_firsttouch_claim()'s own doc comment had left open: a disk scan, not a RAM flag, so the already-extended answer survives reboot/reattach, matching BMAPFMT's "ownership travels with the block" model. Premise checked before building (does a WIREBIND-attached drive actually give a real free/total signal, or does it stay PROVISIONAL/raw): traced repl.c's attach sequence and confirmed blk_subsys_attach_device() runs on the same dev pointer right after WIREBIND, and a WIREBIND-eligible drive is always already STFR/v2-formatted, so the signal is real. Premise held, unlike the BAM item's overstated one. Verified with the mandatory 3-arch QEMU acceptance (identical dictionary hashes, no regression) plus a live logic test of blk_owner_has_claim(): a temporary TEST-OWNER-CLAIM word, run once via SK_CMD and reverted, confirmed it correctly detects the claiming owner and rejects an unrelated one. The low-disk-space-triggers-a-claim path itself is not verified end-to-end -- that needs a real minted WIREBIND-user thumbdrive with deliberately tiny capacity, out of scope for this pass; noted as such in the FABRIC-2.md §I.2 closure note rather than overclaimed. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018EjXFo7mPXjUMjfJeuUUz4 |
||
|
Robert Allan JamesandClaude Sonnet 5
|
aa33aedca8 |
Fix blk_meta_t/BAM accounting reconciliation flagged in FABRIC-2.md §I.2
FIRSTTOUCH ownership (blk_meta_t's BLK_FLAG_CLAIMED/owner_fp) and the generic block-allocation bitmap (BAM, blk_bam_entry_t) were two parallel, unreconciled accounting systems: blk_firsttouch_claim() never touched the BAM, and blk_allocate()/devblock_is_free() never checked BLK_FLAG_CLAIMED. A FIRSTTOUCH claim could be silently overwritten by a later blk_allocate() call, or could itself steal a devblock already in ordinary use via BLOCK/UPDATE. - devblock_is_free() (shared by blk_firsttouch_claim() and blk_migration_idle_check()) now also checks the BAM entries of all BLK_PACK_RATIO member LBNs, not just blk_meta_t. - New devblock_claimed_by_lbn() helper wired into blk_allocate()'s free-scan, so it skips any LBN whose devblock is BLK_FLAG_CLAIMED. - blk_firsttouch_claim() now marks the BAM allocated for all 3 member LBNs of each devblock it claims, which also fixes vol_meta.free_blocks never decrementing for FIRSTTOUCH claims. - blk_meta_relocate_devblock() traced and confirmed NOT part of the bug — it already keeps BAM in sync via blk_subsys_relocate_block()'s own blk_mark_free()/blk_update() calls. Both boundary cases (the reserved/user LBN split at a slot's start_lbn, and BAM-array bounds) are guarded explicitly. Verified with the mandatory 3-arch QEMU acceptance (identical dictionary hashes, clean BYE) plus a live logic test: a temporary TEST-BAM-RECON word, run once via SK_CMD and fully reverted, confirmed on running code that ordinary allocation and a FIRSTTOUCH claim land on disjoint LBN ranges in both directions. FABRIC-2.md §I.2 updated in place with the closure note, per this project's documentation discipline. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018EjXFo7mPXjUMjfJeuUUz4 |
||
|
Claude
|
7191ce5a56 |
Refresh lfs/amd64/starforth binary artifact
Rebuilt after the EXECUTE/format/TYPE/vocabulary/control-flow fixes in the two preceding commits, per lfs/README.md's convention (this binary is synced whenever the hosted amd64 build runs). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014Qf6YcnHgaEtEygq3knx19 |
||
|
Robert Allan JamesandClaude Sonnet 5
|
fcba528273 |
FABRIC-3.md: Task 1 closed -- master fast-forwarded to v2.0.1, verified
master ( |
||
|
Robert Allan JamesandClaude Sonnet 5
|
b031b802e3 |
Rename FABRIC series: FABRIC.md->0, FABRIC-2.md->1, FABRIC-3.md->2, FABRIC-4.md unchanged
FABRIC.md -> FABRIC-0.md FABRIC-2.md -> FABRIC-1.md FABRIC-3.md -> FABRIC-2.md (the current/living document) FABRIC-4.md unchanged (new #3 to follow separately) Every cross-reference repo-wide updated to match, including doc-comment citations inside kernel source (.c/.h) files -- done via an ordered placeholder substitution (FABRIC-3.md->placeholder2, FABRIC-2.md-> placeholder1, FABRIC.md->placeholder0, then placeholders resolved to final names) in a single pass per file to avoid double-shifting already-renamed references. One line in capsules/font.4th grew past the 64-char block-format limit as a side effect of the longer filename; shortened it and reverified with mkcapsule --lint (34/34 pass) before rebuilding. Verified 3-arch boot to ok> (amd64/aarch64/riscv64, each in the foreground) after the fix; logs and DoE CSVs from this session's verification runs included per this repo's own audit-artifact convention. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var |
||
|
Robert Allan JamesandClaude Sonnet 5
|
4018fe8b04 |
FABRIC-3.md §I.2: FIRSTTOUCH + migration state machine (blk_meta_relocate_devblock)
Closes the block-subsystem punch-list item -- built exactly to §F.11's already-decided algorithm after re-verifying it against current blk_meta_t (a 2026-09-03 re-scoping note had wrongly claimed the chain fields no longer existed; they do, untouched by BMAPFMT). blk_firsttouch_claim(): one linear scan of Artemis's own device (new blk_get_first_disk_range(), correctly bounding the scan instead of the global multi-device LBN space), scattered-chain claim via prev_block/next_block/chain_length, owner_fp stamped on every member devblock, fails outright with no partial claim. blk_meta_relocate_devblock(): the real migration primitive -- bridges the existing FORTH-block-granularity blk_subsys_relocate_block() up to devblock granularity (BLK_PACK_RATIO=3, corrected mid-design), running it 3x and transferring blk_meta_t ownership fields. The "migration state machine" turned out to be just the 2 states BLK_FLAG_MIGRATING already reserved; the real design work was the trigger. Two were scoped in conversation (overflow onto Artemis; heat-based wear leveling); heat/wear-leveling is built and wired into sk_repl_idle() via blk_meta_t.write_count. Overflow is deliberately left open, precisely scoped (needs a slot-lookup-by-device-pointer call site threaded from WIREBIND) rather than guessed at. Also flagged, not fixed: BMAPFMT's owner_fp/CLAIMED and the pre-existing BAM allocator are two parallel, unreconciled accounting systems -- FIRSTTOUCH/relocate only touch the former. Verified 3-arch boot to ok> (amd64/aarch64/riscv64, each in the foreground); logs and DoE CSVs from this session's verification runs included per this repo's own audit-artifact convention. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var |
||
|
Robert Allan JamesandClaude Opus 5
|
405c713c4a |
§H.12 step 15: FORTH wrappers for BMAPFMT block-ACL fields
BLK-ACL-ALLOW@/!, BLK-ACL-TTL@/!, BLK-OWNER@ registered in block_words.c. BLK-OWNER@ packs the 8-byte owner fingerprint into one cell (cell_t is int64_t). No BLK-OWNER! -- ownership stays a controlled C-only operation. Live-tested via QMP keystrokes on a running instance: 1 BLK-ACL-ALLOW@ executed cleanly against a real block. Verified 3-arch boot to ok> (amd64/aarch64/riscv64) plus a hosted sanity build (shared source). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Robert Allan James
|
5689c397fc |
Bug-fix sweep: repl reentrancy, virtio/blocksys bounds, identity CRCs, LOG_LINE_MAX
Code review fixes, all compile clean (hosted gcc + aarch64/riscv64 kernel flags):
- repl.c (H1): reentrancy guards on the MSG-TICK idle pump. sk_repl_idle()
now defers when Hera is mid-interpret (g_mama_interpreting) or when its
own vm_interpret is on the stack (g_idle_pump_active), so a blocking
KEY/EXPECT/QUERY inside a dispatched line can no longer re-enter the
interpreter and clobber the in-flight input buffer.
- virtio_rng.c: clamp device-returned used_len to VRNG_BUF_SIZE before the
caller's data_buf copy, closing a device-controlled OOB read.
- block_subsystem.c: first-write path now keys off created_time==0 instead
of dead magic==0 so fresh blocks get a real created_time stamp; first_free/
last_allocated fixed to absolute Forth LBNs (set in blk_compute_fresh_geometry
from slot->start_lbn, no longer the wrong physical-BAM-index values from
compute_totals_from_B); physical-bounds guard on blk_meta_zone_read/write
prevents unsigned underflow on a corrupt fence >= device size.
- capsule_zuse_boot.c / capsule_wirebind.c: identity seed validated magic ->
version -> CRC-64 (compute_crc64 over offsetof(crc)) before trusting it,
so a corrupt/format-mismatched record is refused, never loaded.
- log.h / starkernel/log.h: unused LOG_LINE_MAX 256 renamed LOG_MSG_LINE_MAX
to lift the include-order collision with vm.h's LOG_LINE_MAX 64; stale
include-order comments dropped (kernel_main.c, shim.c, capsule_birth.c).
- FABRIC-3.md: three stale-doc carry-forward items closed [x] with
|
||
|
Robert Allan JamesandClaude Sonnet 5
|
6e9c1d3bc2 |
Phase 8 C (4/n): metadata fence allocator integration + zone I/O
Corrected meta_fence_blocks units from "Forth 1 KiB blocks" to 4 KiB devblocks (matching bam_devblocks/reloc_devblocks) before anything depended on the original meaning -- a clean fix, not a migration. This let the fence fold directly into compute_totals_from_B()'s existing payload4k formula (total_devblocks - 1 - B - R - F) instead of a separate user_blocks subtraction: total_blocks/user_blocks/free_blocks all shrink correctly for free, in both the fresh-format and reload paths, from one formula change. New blk_meta_zone_read()/blk_meta_zone_write() -- raw, unpacked 4 KiB devblock I/O, same shape as the header/BAM/reloc-table regions, addressed by devblock_from_top counting down from the device's last physical devblock. Refuses rather than clamps if the index exceeds the on-disk meta_fence_blocks. C-only, no FORTH word wraps either -- same discipline as vm_zuse_cert_install(), which will be this zone's first real tenant. Verified independently at every step, never trusting the kernel's own report: capacity math cross-checked against a from-scratch Python recomputation of the same formula (exact match); accessor correctness via a temporary probe (written/run/captured/reverted) that wrote a known pattern and read it back, then independently confirmed via a raw read of the disk image at the exact expected physical byte offset. Full 3-arch acceptance boot against the real, untouched disk/artemis.img, probe code fully reverted -- clean, conservation intact. Still open: wiring vm_zuse_cert_install() to actually persist through these accessors, and the MINT word itself. Documented in FABRIC-3.md. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U14ET9CWAtbQMbYqomKgXd |
||
|
Robert Allan JamesandClaude Sonnet 5
|
2035ebeac0 |
Phase 8 C (3/n): top-of-device metadata fence, step 1 (field round-trip)
Corrected substrate: this OS is anti-POSIX, anti-file by design -- the prior "dedicated system-identity disk" framing was wrong vocabulary, caught before any code was written (saved as feedback_no_files_anti_posix.md). The real primitives are content-addressed capsules and raw LBN blocks, never a filesystem. Design (agreed on request): a growable metadata fence at the TOP of a device's block space, mirroring block_subsystem.c's existing bottom BAM reservation from the opposite end -- the two grow toward each other, never colliding, same shape as a stack/heap. Starts at BLK_META_FENCE_INIT (128 blocks), explicitly never RAM-backed. Reuses Artemis's already-attached, already-proven virtio-blk device -- no new device. Rejected reusing BAM's own reserved zone directly: those blocks are fully claimed by BAM bookkeeping, not free space. Step 1 only: new meta_fence_blocks field in blk_volume_meta_t, appended after reloc_devblocks and carved from _pad[] -- identical graceful- default technique reloc_devblocks already established (a pre-existing volume reads it back as 0, not a format break). Added a compile-time _Static_assert on the struct's total size, same discipline homeblocks_sig.h uses -- caught a real bug immediately: the hand-summed _pad[] formula was off by 4 bytes (a compiler alignment gap the manual count missed), found via offsetof() rather than re-deriving by hand. Worked against disposable clones throughout, never the real disk/artemis.img (ARTDISK is ?=-overridable) -- artemis-metafence-fresh.img (blank, fresh-format path) and artemis-metafence-test.img (copy of the pre-existing artemis.img, graceful-default-on-reload path), kept as regression fixtures matching disk/README.md's existing convention. Verified independently via direct byte reads of the disk image, not the kernel's own log output (log_message(LOG_INFO,...) doesn't reach serial in this build -- unrelated pre-existing gap): fresh format writes 128 at header offset 184, a reboot without reformatting preserves it, the old pre-fence image reads back 0. Full 3-arch acceptance boot against the real, untouched disk/artemis.img also clean. Allocator (user_blocks math) and zone read/write accessors both still open -- next steps, documented in FABRIC-3.md. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U14ET9CWAtbQMbYqomKgXd |
||
|
Robert Allan JamesandClaude Sonnet 5
|
e5cbc71f46 |
Phase 8 C (2/n): expand cert storage; NVRAM persistence crashed, reverted
Cert storage expanded from the old 16-byte placeholder to a real 32-byte seed + 32-byte pubkey. vm_zuse_cert_install() now has a kernel-side duplicate in src/starkernel/vm/vm_core.c -- the kernel build's VM_EXCLUDE list drops src/vm.c entirely (same reason vm_set_base() already has two independent copies), so the hosted-only version added earlier this session was never actually linked into the kernel. FORTH-side ZUSE-CERT-LO@/HI@ replaced with ZUSE-PUBKEY@ (i -- u) over the public half only; ACL-ZUSE-BOOT now checks ZUSE-CERT-INSTALLED? before authenticating instead of unconditionally. Attempted NVRAM-based persistence (GetVariable/SetVariable) for the first-boot mint flow: page-faulted inside OVMF's variable service (CR2 in the flash MMIO window). Moving the call site to match the one proven-safe existing SetVariable call site in this codebase produced the identical crash -- not a timing issue. Localized with debug markers (one boot): GetVariable works; SetVariable with real data never returns. The existing "working" precedent call is actually a delete-of-nonexistent-variable (size=0, data=NULL), a cheaper path that never touches flash, so it proved nothing about real writes. Root cause: this kernel's VMM never maps the region OVMF's variable service needs for real flash writes -- a genuine gap in UEFI runtime- services support, not Zuse-specific, and not obviously fixable in a 3-arch-uniform way (flash window location is firmware/arch-specific). Independently, storing the raw seed in RUNTIME_ACCESS NVRAM would have been a real security defect regardless of the crash -- readable by any later-loaded UEFI app or the booted OS. Reverted to a known-safe state: all NVRAM/mint code removed from kernel_main.c, init.4th's ACL.4th line back to its documented commented-out default. Verified clean compile and clean boot on all three architectures. Cert storage expansion (the part that works) stays. A dedicated system-identity disk (virtio-blk, already proven for writes via Artemis) is the recommended next substrate -- not yet decided or built. Full investigation documented in FABRIC-3.md. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U14ET9CWAtbQMbYqomKgXd |
||
|
Robert Allan JamesandClaude Sonnet 5
|
53e6c5709f |
Phase 8 B: real Ed25519 keygen/signing, verified against OpenSSL
Extends the previously verify-only ed25519.c with ed25519_keygen() and ed25519_sign() per RFC 8032 5.1.5/5.1.6, reusing every point-arithmetic primitive verify already had -- only seed expansion/clamping and per-message nonce derivation are new. Signing is deterministic; only keygen ever touches entropy, via a caller-supplied seed (virtio_rng, Phase A) -- keygen still generates nothing itself. New scalar_muladd() (scalar25519.c) for signing's S = (k*a + r) mod L, the one scalar op verify never needed. Schoolbook multiply into a u128 wide accumulator with one final carry pass -- deliberately the same shape as fe25519.c's existing multiply, which has a documented history of a real bug from carrying mid-accumulation instead of in one pass. Verified against an independent implementation, not self-consistency: a throwaway host harness against Python's cryptography library (OpenSSL- backed) across 6 trials (5 random seed/message pairs + the empty-message case) produced byte-for-byte identical pubkeys and signatures every time. Clean compile on all three architectures and a full 3-arch QEMU acceptance boot, conservation intact, no panics or guest errors. Nothing calls the new functions from the live kernel path yet -- that's Phase C (the MINT word itself), still open, documented in FABRIC-3.md. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U14ET9CWAtbQMbYqomKgXd |
||
|
Robert Allan JamesandClaude Sonnet 5
|
6f5605d479 |
Phase 8: zuse cert storage moved out of the dictionary (fuse-blow install)
Found that a pinned CONSTANT is not actually tamper-proof: ACL-PIN only blocks redefinition, not a >BODY-then-store on the word's existing data field. Moves the Zuse cert value into C-only VM struct fields (zuse_cert_lo/hi + zuse_cert_installed fuse bit) with a one-time vm_zuse_cert_install() and read-only ZUSE-CERT-LO@/HI@/INSTALLED? FORTH accessors, closing the tamper path structurally instead of by convention. Deletes the now-insecure ZUSE-CERT-LO/HI CONSTANT words from zuse.4th. vm_zuse_cert_install() has no caller yet -- the real mint flow (Milestone 6 CA, the MINT word) is still open; this is storage + accessors only, not a stand-in mint. Documented in FABRIC-3.md. Verified: hosted build clean, mkcapsule --lint clean (31/31), clean boot to ok> on amd64/aarch64/riscv64 with Stadium conservation intact and no panics. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U14ET9CWAtbQMbYqomKgXd |
||
|
Robert Allan JamesandClaude Sonnet 5
|
36d832ff47 |
Single-block relocation: RELOCATE-BLOCK, resolve_lbn(), persisted exception table
Implements the full design from the prior commit in one pass. resolve_lbn()
is the single choke point threaded through the ten public LBN-consuming
entry points (blk_get_buffer, blk_update, blk_flush, blk_is_allocated,
blk_mark_allocated, blk_mark_free, blk_is_valid, blk_get_meta, blk_set_meta,
plus blk_get_empty_buffer covered via delegation) -- an LBN->LBN redirect,
not a new storage allocator, since the LBN space is already unified across
every attached blkio_dev backend. VM window cache staleness across a
relocation reuses the existing blk_vm_check_epoch() mechanism from
Milestone 2h's hot-detach fix for free -- g.epoch bumps on relocation too.
Persistence lands in the same pass: two new uint32_t fields
(reloc_start/reloc_devblocks) appended after hdr_crc in blk_volume_meta_t,
carved from existing padding without moving any earlier field's byte
offset -- an old formatted volume's zeroed padding reads back as
reloc_devblocks=0 ("no reloc capacity"), gracefully, not a format-breaking
change. compute_totals_from_B() generalized to account for the new
reserved region. reloc_flush_to_disk()/reloc_load_from_disk() mirror the
BAM I/O functions' own absolute-devblock-addressing shape; the persisted
copy's owner is first_disk_slot() (already existed, already used for this
exact "which device is canonical" question by blk_get_volume_meta()).
blk_subsys_relocate_block() is a mechanical primitive only -- copies
content (staged through a local buffer, since obtaining the target's
blk_get_buffer() result can evict and invalidate the source's cache
pointer if they share a device), frees the source BAM entry, appends the
exception entry, bumps the epoch, flushes to disk. RELOCATE-BLOCK exposes
it to FORTH, no policy of its own (ACL's job, per this session's direction).
A first live-test attempt gave a false negative against disk/artemis.img
(predates reloc capacity, so relocation only ever existed in memory that
boot) -- traced to the test's own setup before being mistaken for a bug,
then re-verified correctly against a fresh volume (new fixture,
disk/artemis-reloc-test.img): relocated a RAMDRIVE block to the fresh
disk, confirmed live resolution through the redirect, then confirmed both
the redirect and the relocated content survived an abrupt QEMU kill and
full reboot. Also fixed three lingering "glibc" doc-comment
misattributions from Milestone 2h (the actual allocator is this kernel's
own kmalloc) that survived an earlier FABRIC-2.md-only correction. All
three architectures re-verified clean.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CXjAPTEKrgY2Mrk25KoLDn
|
||
|
Robert Allan JamesandClaude Sonnet 5
|
8eaefeb9ee |
sk_repl_idle() auto-flush: implement Section V's "anything dirty? no? done" check
Makes blk_vm_flush_all() (block_words.c) non-static and declares it in block_words.h -- it's already the entire implementation behind SAVE-BUFFERS (block_word_save_buffers() is a one-line wrapper), so sk_repl_idle() can call the exact same flush path outside word dispatch without duplicating any logic. Cheap every idle tick regardless of dirty state: every check inside is a small fixed-size scan, so no separate pre-check was needed on top of it. Caught a real bug via a live persistence test before trusting the feature: the first version gated the flush on sk_repl_get_active_vm() returning non-NULL, but NULL is that accessor's documented default (Tripod's own USE-redirect override, "restore default dispatch") -- without an active USE redirect, the flush silently no-op'd for the entire session. Confirmed live: wrote a byte via BUFFER (no UPDATE/SAVE-BUFFERS), waited past the idle cadence, killed QEMU abruptly, rebooted with the same disk image, read back 0 instead of the written 65. Fixed by threading the VM sk_repl_run()'s own loop already resolves each iteration (g_repl_active_vm ? g_repl_active_vm : vm) down as a parameter through sk_readline() into sk_repl_idle(), rather than trying to re-derive it from an accessor with the wrong default. Re-ran the same test after the fix: read back 65, matching the written byte -- the write survived an abrupt kill with no explicit flush call anywhere in the test, proving the idle-tick auto-flush genuinely ran. All three architectures re-verified clean. FABRIC-2.md Section V item 6 and the corresponding Milestone 3 punch-list item marked done. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CXjAPTEKrgY2Mrk25KoLDn |
||
|
Robert Allan JamesandClaude Sonnet 5
|
af267a52a6 |
Artemis Milestone 2h: hot-detach -- 2h complete
blk_subsys_detach_device() (block_subsystem.c) walks the device chain, refuses removal of anything but the current tail (a mid-chain removal would corrupt every later slot's start_lbn -- this architecture's own doc already argues USB stays last specifically to avoid that), unlinks, shrinks total_user_lbn, closes and frees the slot. Discards rather than flushes dirty state -- the device is physically gone by the time this runs (PORTSC disconnect only). Trigger wiring mirrors the attach path: bot_msc_attached (set only once attach actually succeeds) gates a new bot_msc_detach_pending flag set at PORTSC disconnect (not Disable Slot completion, which is conditionally skipped and would miss concurrent connect/disconnect pairs), consumed in sk_repl_idle(). Advisor flagged the real hazard ahead of time: block_words.c's VM block window (blk_vm_lbn[]/blk_vm_cbuf[]) can go stale across a detach then a same-LBN re-attach, and suggested a pointer-identity re-check in blk_vm_load() as a minimal fix. That fix was implemented, then directly falsified by its own designed-for-this test: attach a blank device, read a block (populating the cache), detach, re-attach a device with distinct content at the identical LBN, read again -- served stale content from the first device. Root cause, confirmed live: glibc's allocator hands free(slot) straight back to the very next same-size calloc(), so the "fresh" and stale pointers were bitwise identical despite being two different devices. Fixed properly with a monotonic blk_subsys_epoch() counter (bumped on every attach/detach) checked by a new blk_vm_check_epoch() helper at the one choke point (blk_vm_find(), plus blk_vm_flush_all() which reads the same arrays directly) that covers every path touching the window cache -- unfooled by address reuse. Verified live with a new disk/usb-thumbdrive-test2.img fixture (distinct content from the existing blank test image): attach A, read (cache hit populated), detach, re-attach B at the same LBN, read again -- correctly ran a fresh device read and returned B's real content, not A's stale cached zeros. The failing pointer-comparison attempt's own capture log kept as evidence, not deleted. All three architectures re-verified clean. FABRIC-2.md Section X 2h marked complete -- enumeration through hot-detach all live and verified; only WRITE(10) (2g's own still-open item) remains unimplemented in the driver, not blocking anything here. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CXjAPTEKrgY2Mrk25KoLDn |
||
|
Robert Allan JamesandClaude Sonnet 5
|
70c259dad0 |
Revert HEARTBEAT-TICKS@ to vm->heartbeat.tick_count; FABRIC-2.md Section R:
find and fix the real ACL-TTL measurement bug (zuse session never authenticated, ACL enforcement never active) Two mistakes corrected in sequence, both documented in full in FABRIC-2.md Section R: 1. HEARTBEAT-TICKS@ was swapped to read heartbeat_ticks() -- a newer, kernel-only ISR hardware-timer counter (src/starkernel/heartbeat.c, the M5 TIME-TRUST engine) -- based on a misreading of which counter "the one clock" law refers to. Reverted to vm->heartbeat.tick_count, Loop #7 "Adaptive Heartrate", the actual year-plus-old counter the whole physics runtime is built on. Removed the now-irrelevant HEARTBEAT-PERIOD-NS@ accessor added to diagnose the wrong counter's adaptive re-arm period. Three-arch QEMU re-acceptance: POST 1012/0/0 on amd64/aarch64/riscv64, HEARTBEAT-TICKS@ confirmed returning 77 (matching the original pre-heartbeat_ticks() acceptance) on all three. 2. The real bug, found after the revert: every "ACL enabled" measurement in this investigation (Section P's 18-cell campaign, Section Q's pilot) loaded ACL.4th and ran EXEC-DOE from the bare `ok>` prompt without ever authenticating a zuse session. repl.c:303 keeps emergency_console=1 until zuse_session=1; vm_core.c:755 skips the entire ACL check block (TTL decrement and acl_recheck()) whenever emergency_console is set. ACL was configured but never armed. capsules/zuse.4th's pre-existing self-pin bug means the documented automatic zuse activation doesn't work either (still flagged, not fixed) -- worked around by invoking the directly-registered ZUSE-AUTHENTICATE word explicitly. Validated pilot (amd64, seed 12345, 30 reps, same build, disabled vs. genuinely zuse-authenticated-enabled): +117 ticks, +0.0448% overhead. Disabled-arm determinism double-confirmed (261064 ticks, exact repeat on a fresh boot) -- the 117-tick difference is real signal, not noise. Reconciles with the original ACL-RWT campaign's own heartbeat-tick result (+0.0054%-0.0088%, same order of magnitude). Section P's wall-clock numbers and Section Q's "instrument blind" conclusion are both marked invalidated/corrected in place, not deleted. n=1 per arm, one architecture -- not yet a full campaign. Scoped as next step, not undertaken in this pass. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
Robert Allan JamesandClaude Sonnet 5
|
4076a01c35 |
Fix HEARTBEAT-TICKS@: read heartbeat_ticks() (ISR hardware timer), not
vm->heartbeat.tick_count (FORTH-dispatch counter) Captain Bob's law is unambiguous: the adaptive heartbeat is the one and only clock, full stop. The first cut of this word read the wrong counter under that name -- vm->heartbeat.tick_count is a colon-word- dispatch counter gated at a fixed cadence (frozen during idle, blind to per-dispatch CPU cost, see FABRIC-2.md Section Q). The real adaptive heartbeat is heartbeat_ticks() in src/starkernel/heartbeat.c, driven directly by the ISR-latched 100Hz hardware timer -- genuinely time-based, confirmed advancing during idle wall-clock time on all three architectures (amd64 4039->5510, aarch64 6126->7607, riscv64 2965->4466, each over ~15s idle). Kernel build only (__STARKERNEL__); hosted build has no ISR timer and keeps the old fallback. Three-arch QEMU acceptance: POST 1012/0/0 on each, word live-tested. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
Robert Allan JamesandClaude Sonnet 5
|
0b11f92102 |
Add HEARTBEAT-TICKS@: read-only heartbeat tick counter accessor
The adaptive heartbeat tick counter (vm->heartbeat.tick_count) is the project's sole canonical clock for timing measurements -- host wall-clock is not a valid substitute. Exposes it read-only so DoE/overhead campaigns can measure elapsed ticks instead of wall-clock deltas. Verified: three-arch QEMU acceptance (amd64/aarch64/riscv64), POST 1012/0/0 on each, HEARTBEAT-TICKS@ live-tested returning a real non-zero count on all three. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
Robert Allan JamesandClaude Sonnet 5
|
7e2fd9f044 |
Fix SWAP-MTX: Fisher-Yates shuffle was never actually shuffling correctly
Found while building the analysis report for the ACL-RWT relaunch campaign: cfg=0 was missing from run coverage for 2 of 3 seeds, reproduced identically across all three architectures. Root-caused rather than worked around, per Captain Bob's "this is worrisome." SWAP-MTX (capsules/doe.4th Block 2104) never actually swapped two RUN-MATRIX cells -- it performed a lossy one-way copy (second MATRIX! call mis-targeted mat[i] again instead of mat[j]). Confirmed by direct empirical test on the hosted build: INIT-MATRIX gives mat[0]=0, mat[5]=5; after 0 5 SWAP-MTX, mat[0]=0 (unchanged, should be 5) and mat[5]=0 (correct), with the original value 5 permanently destroyed. Every Fisher-Yates shuffle this mechanism has ever run silently duplicated some values and dropped others -- not a true permutation. Not new, not introduced by item 4.6/Stadium work; predates this session. Fixed with explicit temp variables (SW-I/SW-J/SW-VI/SW-VJ), trivially verifiable by inspection over clever stack juggling. Verified on the hosted build for all three seeds used by the relaunch campaign: each now produces all 16 cfg values exactly 30 times, run_id 0-479 fully distinct. Three-arch QEMU acceptance clean: 1012/0/0 POST on all three, identical dict_hash (expected -- doe.4th isn't C-registered or auto-loaded at boot). BLOCK_MAP.md correctly shows only doe.4th's own hash changed. Also includes the R analysis/chart pipeline (analyse_stadium_relaunch.R) built for the relaunch campaign report, and the three acceptance boot logs. Retroactive caveat: the relaunch campaign's own run-matrix coverage (experiments/bare_metal/runs/acl-rwt-20260820/) is not a valid uniform permutation, having run against the buggy shuffle. Whether to re-run it against the fix is a separate call, not made here. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
Robert Allan JamesandClaude Sonnet 5
|
4e7dcdf889 |
Add FENCE word (SDK v1.9.0 scoping); fix severe pre-existing FORGET use-after-free
FENCE ( -- ) exposes the dict_fence_latest/dict_fence_here state FORGET already honored internally, letting callers (e.g. a future SDK capsule) raise the boundary after loading their own content -- no new VM fields, no policy logic beyond exposing existing state. Writing a direct test for it surfaced a real, severe, pre-existing bug in FORGET's relink logic, unrelated to FENCE itself and reproducible with the original boot-time fence alone: - Forgetting the single newest word incorrectly destroyed every other word back to the fence too, not just the target. - Forgetting an older word (correctly cascading to remove newer words too, per FORTH-79 semantics) crashed with SIGSEGV. Root cause: the relink code's target_prev pointer was, by construction, always inside the range the preceding loop had just freed whenever target wasn't vm->latest -- so writing through it was a use-after-free every time that branch executed. Fixed by removing the target_prev tracking and both branches entirely; vm->latest unconditionally becomes target_next (target's own captured, still-valid link) after the free loop, correct in every case. Added a FENCE test suite to dictionary_manipulation_words_test.c (Module 14) including the exact regression case (forgetting the newest word must not disturb an older one). Verified zero warnings and identical POST/dict_hash results across all three kernel architectures. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
Robert Allan JamesandClaude Sonnet 5
|
abb858a300 |
Add POST coverage for physics-freeze words (Module 27), fix two real bugs found in the process
Cluster 4 of the POST-coverage sweep: physics_freeze_words_test.c covers the 6 words proof/StarForth_Physics_Freeze_Words.thy actually gives real lemmas for (FREEZE-WORD, UNFREEZE-WORD, FROZEN?, HEAT!, HEAT@, DECAY-RATE@), correcting an earlier fork summary's wrong "5 words" scope. Writing the tests surfaced two independent, pre-existing bugs in physics_freeze_words.c, both now fixed: - Every address-taking word cast the VM's caddr directly to a host pointer instead of resolving it through vm_ptr() -- caddr is an offset into vm->memory, not a host pointer. Fixed in all 9 call sites (the 5 in-scope words plus SHOW-HEAT, which shares the identical pattern). - Every underflow check used dsp < N (item count) instead of dsp < N-1, since this VM's dsp is a 0-indexed top-of-stack pointer. Fixed in all 6 checks. Together these meant every word in this file taking a stack-supplied name has been broken for any real caller since the file was written. Verified zero build warnings and a clean three-arch QEMU boot (amd64/aarch64/riscv64), 1009 passed / 0 failed / 0 errors identically on all three, dict_hash matching across arches. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
Robert Allan JamesandClaude Sonnet 5
|
f72422721f |
build: regenerated artifacts from this session's kernel/hosted builds
capsules/BLOCK_MAP.md (mkcapsule --manifest), disk/artemis.img, and lfs/amd64/starforth are routine build byproducts left dirty from build runs earlier this session. Committing per repo convention (these are tracked, not gitignored) to keep the working tree clean for the next session's start. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
Robert Allan JamesandClaude Sonnet 5
|
59458a0a16 |
Cursor indicator + HB-ON/HB-OFF runtime DoE instrumentation toggle
Cursor (Captain Bob: "the only thing we need is a cursor"): vt100_draw_cursor() draws a solid block at the terminal's current position, called from repl.c after the prompt prints and after every keystroke/backspace. vt100_erase_cursor() cleans up the one gap a static cursor has -- Enter/newline moves away from the cursor cell without a character draw ever overwriting it, which left a stray block behind until this fix. HB-ON/HB-OFF (Captain Bob: run a program with or without instrumentation without rebuilding): Converted per-tick DoE logging from a build-time flag (HEARTBEAT_DOE_LOG) to a runtime one. doe_log_tick_row() now self-gates on g_doe_log_enabled (default 1, matching the old default) instead of being compiled out entirely; the call site in vm_runtime.c is unconditional. Two new FORTH words, HB-ON and HB-OFF, flip the flag live. Removed the now-dead HEARTBEAT_DOE_LOG plumbing: the Kconfig symbol, and the -D forwarding in both LOADER_CFLAGS and KERNEL_CFLAGS. Verified: three-arch clean QEMU boot + logs; dictionary word count 466 (463 baseline + ALT+TAB + HB-ON + HB-OFF, exactly the three words added across this session); amd64 screendump confirms the cursor renders correctly after real interactive typing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
Robert Allan JamesandClaude Sonnet 5
|
6a97fa4c98 |
logs: add boot-run audit trail and DoE CSVs from item 4.3.5 work
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
Robert Allan James
|
cb4326c712 |
starkernel: item 4.3.3b -- geometry drawing wordset, fixed Q.TO-INT sign bug
Adds LINE (Bresenham in raster space, endpoints projected once each -- valid because the cavalier projection is linear), CIRCLE/ELLIPSE (36-segment polygon approximation), and ARC (18 segments over a caller radian range) to capsules/fabric.4th (blocks 4903-4912). TO-RASTER factored out of CART-PLOT (same behavior) so LINE can reuse the projection+flip for both endpoints. Found mid-implementation: colon definitions cannot span block boundaries in this capsule loader -- verified with a throwaway test capsule, the continuation lands in a [CAPSULE][DEFER] path that never resolves. LINE's body is split across LINE-SETUP/LINE-DONE?/LINE-STUCK?/LINE-STEP, each self-contained within its block, rather than one long definition. A fourth real bug, serious this time: CIRCLE's first live test rendered only one quadrant, then hung the VM for several minutes on a follow-up call. Root cause: q48_to_u64() (include/q48_16.h and include/starkernel/q48_16.h, backing Q.TO-INT) did an unsigned logical shift, corrupting any negative Q48.16 value into a huge garbage integer instead of sign-extending -- inevitable once Q.SIN/Q.COS leave the first quadrant. That garbage became a bogus LINE target with no bound on LINE-STEP's Bresenham loop. Fixed q48_to_u64 to shift through a signed int64_t intermediate (bit-identical for the non-negative case). Also added LINE-STUCK? (LSTEPS vs FB-WIDTH+FB-HEIGHT, the true worst case for an on-screen line) as a defense-in-depth cap against any future bad target. Verified live on amd64 after both fixes: -65536 Q.TO-INT . now prints -1; LINE/CIRCLE/ARC/ELLIPSE all complete without hanging or erroring, and a combined screendump shows all four rendering correctly and distinctly. All three architectures boot clean to ok> with the DoE completing; dict_hash identical across all three and unchanged from 4.3.3a (expected -- fabric.4th isn't loaded at boot, and the Q.TO-INT fix doesn't change dictionary structure). FABRIC.md item 4.3.3b marked done with full acceptance evidence. |
||
|
Robert Allan James
|
36389e9d4a |
starkernel: item 4.3.3a -- Q48.16 trigonometry (Q.SIN/Q.COS)
Adds q48_reduce_angle() (range-reduce a signed Q48.16 angle into [-PI_Q48, PI_Q48] via one integer division plus a bounded fix-up loop) and q48_sin_approx/q48_cos_approx (Taylor series, terms n=3,5,7,9,11 for sin and n=2,4,6,8,10 for cos, early exit below 10). Q.SIN/Q.COS registered as FORTH words in q48_words.c, same pattern as Q.LOG/Q.EXP/Q.SQRT. Found mid-implementation: this codebase has two independent Q48.16 implementations -- src/word_source/q48_16_words.c (hosted/vendored) and src/starkernel/math/q48_16.c (kernel-only; the kernel build does not compile the former at all). The hosted build linked fine after the first pass; the kernel build failed with undefined references until the same two functions were added to both .c files and both q48_16.h headers (include/q48_16.h and include/starkernel/q48_16.h). Not fixed at the root -- Q.LOG/Q.EXP/Q.SQRT already had this same four-file duplication, unremarked until now -- just navigated correctly for this item. Verified live on amd64 via serial injection: sin/cos at 0, +-pi/2, pi, and 3pi (range-reduction across multiple turns) all match expected values within Taylor-series truncation error (<0.2%). All three architectures boot clean to ok> with the DoE completing; dict_hash identical across all three (0x291a660b05fa7b52). FABRIC.md item 4.3.3a marked done with full acceptance evidence. |
||
|
Robert Allan James
|
ef9806977a |
starkernel: item 4.3.3 -- Cartesian coordinate machinery, found and fixed a VARIABLE alignment bug
Adds Module 28 (framebuffer_words.c/.h): PLOT ( x y color -- ), FB-WIDTH, FB-HEIGHT -- raw hardware-boundary C primitives, kernel-only, no-op on hosted builds, same pattern as every other module. Adds capsules/fabric.4th (blocks 4900-4902, mkcapsule --lint clean): COS45/Z->DELTA/PROJECT/CART-Y/CART-PLOT -- the 45-degree cavalier orthographic projection and Y-flip, in FORTH per the compose-in-FORTH-first rule (this is policy, not hardware access). Found and fixed a second real bug while live-testing CART-PLOT over the serial socket: defining_word_variable() (defining_words.c) captured vm->here as a VARIABLE's address with no alignment call first, while vm_load_cell/vm_store_cell require 8-byte-aligned addresses. This capsule's VARIABLE ZD landed misaligned (945) purely by chance of what preceded it; other capsules' variables happened to land aligned by luck, not guarantee. Real deviation from FORTH-83/ANS, which specifies VARIABLE reserves an aligned cell. Fixed with vm_align(vm) before capturing addr -- ALIGN already existed as a word but VARIABLE wasn't calling it. Verified end-to-end on amd64 via manual serial injection + QEMU screendump: plotted 4 marker points (origin, +100 X, +100 Y, +50 Z) and confirmed all landed at hand-calculated raster coordinates, including the diagonal up-right shift for the Z-axis point -- the projection math is correct, not just non-crashing. fb/fabric-test-cart-plot.png. 4.3.1's corner diagnostic still renders correctly in the same shot, confirming no regression. All three architectures (amd64/aarch64/riscv64) boot clean to ok> with the DoE completing; dict_hash identical across all three (0xc7f9adf885e306d2), confirming parity is unaffected. FABRIC.md item 4.3.3 marked done with full acceptance evidence. |
||
|
Robert Allan JamesandClaude Sonnet 5
|
5a28458b21 |
starkernel: item 4.2 -- Hermes native on the Stadium (complete)
Migrates Hermes's message/channel lifecycle onto the Stadium's unified heat/capacity economy: MSG-ALLOC/FREE-NODE and CH-ALLOC/FREE-NODE now route entirely through stadium_admit()/stadium_evict(), replacing the old local free-list + independent heat-field mechanism. Eight kernel-only STADIUM-* FORTH primitives (ADMIT, EVICT, RES@, RES-PULL, RES-PUSH, HEAT@, HEAT!, WORD-HEAT), VM.stadium_vm_id threaded through all three vm_core.c dispatch sites (replacing item 4.1's hardcoded vm_uuid_hera()), and the stadium_owner[idx] fix so evict-credit lands in the VM that actually admitted a patron, not whoever owned cell 0. This session's own contribution, on top of that pre-existing implementation: found and fixed two bugs blocking the item's own K≡1.0 conservation self-check (HERMES-K was reading 0, not 65536): - Q.SLOT admission-heat fix (capsules/hermes/init.4th): MSG-SEND/ CH-ACCEPT admitted with Q.1 (the entire fleet-wide "1.0" unit) per item, a leftover from before the Stadium migration when each message/channel had its own unconstrained heat field. Instantly drained the shared, finite reservoir. - Reservoir floor for word-execution admission (stadium_words.c): stadium_word_dispatch() (item 4.1) pulls STADIUM_WORD_HEAT_QUANTUM on every word dispatch, not just first admission -- exhausts a VM's entire reservoir in ~32 dispatches, starving any application-level economy sharing that VM's reservoir before it gets a chance to pull anything. word_dispatch_pull() now clamps word-execution's own pulls to leave a Q48_ONE/3 floor (same fair-share figure COMMON-CH's own floor already uses); application-level pulls are unaffected. - STADIUM-WORD-HEAT primitive + stadium_words_resident_heat(): the floor deliberately leaves word-execution residents holding real heat, invisible to HERMES-K's original formula (MSG+CH+reservoir, no term for word patrons). Adding this term closes K to exactly 65536 on all three architectures. Also rules on two open scope questions in FABRIC.md: MBR-ALLOC/ MBR-FREE-NODE stay off the Stadium (membership records have no heat field, never did -- the acceptance bullet's inclusion of them was a completeness gesture predating a check of the actual layout), and records the effort number (12 implementation files, +759/-120 lines). Verified: all three architectures boot clean, full self-test passes, Stadium conservation closes exactly (resident_sum + reservoir = Q48_ONE) at both the C/Stadium level and the FORTH-level HERMES-K check. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
Robert Allan JamesandClaude Sonnet 5
|
3d0b9351bd |
starkernel: item 4.1 -- hot words onto the Stadium, density-ranked eviction
Punch list §25 item 4.1 complete. Replaces the round-robin hotwords cache with Stadium density-ranked admission/eviction on the kernel side, via the §17.7 reservoir mechanism and a kernel-side word_id -> cell_index map (no DictEntry change, dict_hash untouched). Adds stadium_birth_hera() to close the cell-0 panic hazard, STADIUM_WORD_HEAT_QUANTUM/STADIUM_WORD_COOL_RATE_Q48 Kconfig knobs (flagged untuned), and a stadium_word_forget() FORGET coherence hook to close a recycled-word_id aliasing gap. Verified: all five hotwords_cache_* call sites in dictionary_management.c bypassed under __STARKERNEL__; word dispatch feeds the Stadium at all three vm_core.c physics_execution_heat_increment() sites; hosted make unaffected; all three architectures booted to ok> with matching dict_hash (0x3d4e1daf289da94f) and matching conservation stats (promotions=354 evictions=0, resident_sum=65536 reservoir=0 sum=65536). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
Robert Allan James
|
a5ed8c3d87 | Initial commit — LithosAnanke kernel |