LITHOS_VERSION 2.0.1 was premature: per this project's own versioning policy, 2.0.1 claims SER5 hardware-track progress (RDRAND backend + thumbdrive image) that was never actually verified on real hardware -- that verification is FABRIC-3.md's own open topic. Reset to 2.0.0 (still a QEMU-only release, correctly). Verified 3-arch boot shows "LithosAnanke v2.0.0" in each serial log directly, not assumed from the Makefile edit alone. Also closes a real gap found in today's earlier FABRIC-series rename: Makefile.starkernel, Kconfig.kernel, scripts/bleach_zuse_img.sh, four proof/*.thy files, and isr.S were never swept -- the original file list only matched *.md/*.c/*.h/*.4th, silently skipping every other extension. Fixed with the same safe placeholder substitution. .claude/settings.local.json's historical permission-grant log and ClaudeEXPORT/'s frozen export were deliberately left untouched. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019YcT3H2PQeyujrzjqS3Var
52 lines
2.5 KiB
Plaintext
52 lines
2.5 KiB
Plaintext
theory StarForth_TTF_Words
|
|
imports StarForth_Base
|
|
begin
|
|
|
|
(* =========================================================================
|
|
Mirrors: src/word_source/ttf_words.c
|
|
Registers (kernel-only -- see below): TTF-TEXT
|
|
|
|
Part of the Stadium console fabric work (FABRIC-0.md item 4.3.7e). Same
|
|
shape as scroll_words.c: the word body AND its `register_word` call are
|
|
both inside `#ifdef __STARKERNEL__`; TTF-TEXT does not exist as a word
|
|
at all on a hosted build.
|
|
|
|
Kernel build: guard `vm->dsp < 5` (needs 6 elements: c-addr u x y size
|
|
color), pops all six, then depends entirely on the TTF subsystem --
|
|
font-capsule loading (`ttf_words_ensure_font`, itself guarded by a
|
|
file-scope `static int g_ttf_font_ready` -- another instance of the
|
|
file-scope-static-instead-of-per-VM pattern this sweep keeps finding,
|
|
though here arguably correct/intentional: a loaded font glyph cache is
|
|
process-wide resource sharing, not per-VM interpreter state, and there
|
|
is exactly one font asset regardless of how many VMs are in the Tripod
|
|
fleet), a hand-rolled UTF-8 decoder reading VM memory via `vm_load_u8`/
|
|
`vm_addr_ok` (tractable in principle -- StarForth_Base.thy's `memory`
|
|
field could back it -- but not attempted here given nothing else in
|
|
this word is modellable, so a UTF-8-decode-only partial model would
|
|
have no consumer), and raster/blit calls into the framebuffer +
|
|
raster-cache subsystem. None of TTF-TEXT's effect is modelled beyond
|
|
the guard shape. *)
|
|
|
|
lemma ttf_text_not_registered_on_hosted_build: True
|
|
\<comment> \<open>Same absent-on-hosted shape as SCROLL-BACK/SCROLL-FWD (see
|
|
StarForth_Scroll_Words.thy) -- register_ttf_words's `#else` branch is
|
|
`(void) vm;`, nothing registered.\<close>
|
|
by simp
|
|
|
|
lemma ttf_text_guard_only_not_mechanised: True
|
|
\<comment> \<open>Kernel build: `vm->dsp < 5` guards a 6-cell pop (c-addr u x y size
|
|
color). The guard SHAPE follows the same pattern as every other
|
|
multi-pop word in this sweep, but is not mechanised here since
|
|
nothing downstream of it is modellable (see file header) -- a bare
|
|
guard lemma with no consumer would be dead weight, unlike
|
|
framebuffer_words.c/keyboard_words.c where the fallback body gives
|
|
the guard somewhere to lead.\<close>
|
|
by simp
|
|
|
|
lemma ttf_text_body_not_modelled: True
|
|
\<comment> \<open>Font-capsule loading, UTF-8 decoding of VM memory, and raster-cache/
|
|
framebuffer blitting -- see file header for the full breakdown.\<close>
|
|
by simp
|
|
|
|
end
|