FABRIC.md item 4.5d: root-caused the -O2 boot stall via QEMU '-d int'
tracing -- not a hang. It's a genuine divide-error (#DE) cascading through
a double fault into a triple fault, which -no-reboot converts into a
silent, clean QEMU exit (indistinguishable from a hang without tracing).
muldiv64()'s inline asm declared RDX as a plain output ("=d"(hi)), which
only tells GCC "I want RDX's value after this block" -- nothing told it
that mulq writes RDX *before* divq needs to read a *different* value (the
divisor c) out of it. Nothing stopped the register allocator from placing
c itself in RDX, which mulq then overwrites with the product's high 64
bits before divq ever reads it. Confirmed via the fault's register state:
RAX=0xe8d4a51000 (=1000*1e9 exactly, product fits in the low 64 bits, so
mulq's high-word output is 0) -- if c got allocated to RDX, divq then
divides by that corrupted 0, exactly matching #DE. Worked by accident at
-O0 (different, more conservative allocation); -O2 actually hit it.
A unsigned __int128 rewrite was tried first but needs libgcc's __udivti3
for the general 128-bit case, undefined in this freestanding build -- not
viable, same class of problem as the earlier putc/getc finding. Fixed
instead by declaring rdx a pure clobber rather than an output, the same
pattern the Linux kernel's own mul_u64_u64_div_u64 uses -- a clobber tells
GCC the register is used internally for the whole block and must never be
allocated to any operand, which is the guarantee the previous constraint
list was missing.
Also added a defensive end_tsc<start_tsc guard in the caller
(calibrate_tsc_with_pmtimer): this file's own comments already flag TSC
non-monotonicity as a real risk under TCG hypervisor mode, and an
underflowed delta_tsc would hit the same class of quotient-overflow #DE.
Not the bug that was found, but a real latent risk given what this
function's own documentation already says about the environment.
Verified: with -O2 (uncommitted, not yet reintroduced) this specific stall
is gone -- boot now proceeds far past this point, through capsule birth
and into Hermes's word registration, before hitting a second, different,
not-yet-root-caused fault (write-up follows). Three-arch acceptance boot
clean at unchanged -O0 (this fix doesn't change -O0 behavior, only
prevents UB that only manifested under optimization).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
LithosAnanke v1.5.4
UEFI-bootable FORTH microkernel. Boots from firmware, initialises memory and interrupts, then runs the StarForth VM as its sole userspace runtime. No libc. No OS. Just stone and necessity.
Lithos (foundation) + Ananke (necessity) — the kernel under StarshipOS.
Status — M7.1 (Capsule System · Multi-VM Fleet)
| Milestone | Status | |
|---|---|---|
| M0–M6 | UEFI boot · PMM · VMM · IDT · APIC · heap · framebuffer VT100 console (v1.5.1-FINAL) | ✅ Complete |
| M7 | StarForth VM integration + parity validation | ✅ Complete |
| M7.1 | Capsule birth protocol · Mama FORTH vocabulary · Tripod multi-VM fleet (Hermes/Artemis) · Word-level ACL (Phases 1–7) | 🔄 In Progress |
| M8 | REPL — keyboard input, interactive Forth | Planned |
| M9 | Block storage — AHCI driver | Planned |
POST at boot: parity hash verified across amd64/aarch64/riscv64 · Mama capsule dictionary: 453 words
What's live in M7.1
- Tripod — a named multi-VM fleet (Hera the Mama VM, Artemis, two Hermes instances) births, runs, and re-births independently, verified booting live pre-REPL on all three architectures.
- Hermes — a 17-block inter-VM messaging/channel layer between fleet members, with async delivery and channel negotiation.
- Artemis — a Block Allocation Map (BAM) storage subsystem with Q48.16
block-heat tracking and cooldown/reclamation (
ART-COOL/ART-REAP). - Word-level ACL — every dictionary entry carries a TTL/allow/mode/pin
access-control record. Strict, TTL, and pinned modes; two console layers
(emergency
ok>and superuserzuse)ok>). Phases 1–7 complete (C infrastructure, FORTH policy layer,zusebootstrap superuser, Isabelle proof stubs, kernel parity); Phase 8 (Ed25519 PKI / thumbdrive challenge-response) is the only item remaining. Measured overhead once active on every check: +0.0054%–+0.0088%, CV = 0.000%, across a 3×3 Latin-square DoE campaign (architecture × seed × 30 replicates) — three orders of magnitude below the measurement floor. - VM Fleet Attractor physics — the L8 Jacquard mode selector now has a real per-VM heat channel into fleet-wide tuning, replacing hardcoded compudynamics constants with a dynamically-inferred rate.
- Kconfig build configuration — every physics/heartbeat/pipelining/ kernel-only tuning knob (~40 total) is now a discoverable, optional Kconfig symbol shared with the hosted VM build. See Quick Start below.
Quick Start
# Build kernel (requires cross-compilation toolchain, or native gcc)
make -f Makefile.starkernel ARCH=amd64
# Run in QEMU with OVMF
make -f Makefile.starkernel qemu
# Other architectures
make -f Makefile.starkernel ARCH=aarch64 qemu
make -f Makefile.starkernel ARCH=riscv64 qemu
Artifacts: build/amd64/kernel/starkernel_loader.efi · build/amd64/kernel/starkernel_kernel.elf
For the hosted VM by itself (Linux, no cross-compiler needed, no bare-metal tooling): see
the separate StarForth repository — LithosAnanke used to be a branch inside that repo,
now it's its own project with its own master.
Build configuration (optional)
Every kernel-only knob (STARFORTH_ENABLE_VM, PARITY_MODE, the shared
physics/heartbeat family, etc.) is an optional Kconfig symbol — a plain
make -f Makefile.starkernel uses the same defaults it always has unless
you opt in:
make -f Makefile.starkernel ARCH=amd64 menuconfig
make -f Makefile.starkernel ARCH=amd64 kernel_amd64_defconfig
Documentation
| System Architecture | Full kernel + VM design |
| HAL Reference | Hardware abstraction layer interfaces |
| Capsule System — M7.1 | Capsule birth protocol design |
| VM Fleet Attractor design log | Tripod/Hermes/Artemis physics + build-system history |
| Getting Started / Kconfig reference | Full symbol reference for both build targets |
| Changelog | Milestone-level history |
| Roadmap | Milestone plan through self-hosting |
License
Starship License 1.0 (SL-1.0) — free for personal, research, and educational use. Commercial use requires a separate agreement. Attribution to R.A. James (Captain Bob) must be preserved in all distributions.
Patent pending. USPTO provisional filed December 2025 — physics-grounded self-adaptive runtime system. This license does not grant patent rights. Licensing inquiries: rajames440@gmail.com
Robert A. James (Captain Bob) · Systems Engineer · Hacking since 1973