Robert Allan James
1e76ebea97
Stadium console fabric words (FABRIC.md items 4.3.3/4.3.5/4.3.7e/4.4q/ 4.4v/4.4y). All four files gate their real hardware-touching bodies behind __STARKERNEL__ (and, for keyboard, architecture too): - StarForth_Framebuffer_Words.thy: PLOT/FB-WIDTH/FB-HEIGHT fully modelled for the hosted-build fallback (deterministic, no hardware dependency); kernel bodies (fb_put_pixel/fb_width/fb_height) deferred. Finding: FB-WIDTH/FB-HEIGHT have no overflow guard before pushing -- second instance of this class of bug after DECAY-RATE@. - StarForth_Keyboard_Words.thy: all 6 words' non-kernel-or-wrong-arch fallback modelled (fixed constant pushes / no-op); third and fourth missing-overflow-guard instances. Real hardware polling (i8042/virtio-input) deferred. - StarForth_Scroll_Words.thy / StarForth_TTF_Words.thy: both files gate registration itself behind __STARKERNEL__, so their words don't exist at all in a hosted build -- no fallback to model, sentinel-only. Suite now 48 theories, confirmed green via a full clean rebuild (HOL- Library cold-built in 15m18s after an accidental heap clear, StarForth itself 33s).
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.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
|