Summary
The #682 module statics work (landed in #687, v3.9.0) engages and holds on a real GBA game — but the frame it leaves behind is dominated by top-level statement volume and its temporaries, which the statics do not touch. That half of #682 was the out-of-line chunking (b808163b5), reverted in 1036d1266 for the FnOnce-move reason; after the revert there is no open issue tracking it. Filing so the residual is tracked with a real-game measurement.
Measured (examples/omakase in tish-gba: 13 modules, ~148 module fns, game loop at module top level; thumbv4t release, v3.9.0 d6c7d62e1)
| emission |
run() frame |
default (module statics ON — 615 SingleCore statics emitted) |
20,564 B |
TISH_MODULE_STATICS=0 (whole pre-#682 emission) |
29,908 B |
So the statics recover 9,344 B here and are load-bearing — the pre-#682 emission would sit 2.6 KB from the top of the 32.5 KB IWRAM stack and trip the #655 guard margin. The ROM is behaviourally identical either way (4,000-frame soak clean, frame-period EMA unchanged).
Why the residual is top-level code, not bindings
Two game-side levers measured on the same sources, same compiler, before this issue:
- sinking 74 single-use module
let <X>: i32 = <literal> constants into their one reader: ~4 B each
- moving 7 table functions (22-entry if-ladders) out of tish into a
cargo: crate: ~27 B each
Bindings are no longer where the bytes are. What remains in run() is the program's top-level statements — in this game the main loop itself — whose locals and expression temporaries all live in the one shared frame. That is exactly what the reverted chunking addressed, and the revert note already names the fix shape: "chunking needs real fns with explicit params, which is a separate change."
Ask
Revive the chunking as real fns with explicit parameters (per the revert note), or any equivalent that moves module top-level statement temporaries out of run()'s frame. With the statics landed, this is the remaining term that scales the frame with program size on GBA.
Related: #682 (closed), #687, #684, #655.
Summary
The #682 module statics work (landed in #687, v3.9.0) engages and holds on a real GBA game — but the frame it leaves behind is dominated by top-level statement volume and its temporaries, which the statics do not touch. That half of #682 was the out-of-line chunking (
b808163b5), reverted in1036d1266for the FnOnce-move reason; after the revert there is no open issue tracking it. Filing so the residual is tracked with a real-game measurement.Measured (examples/omakase in tish-gba: 13 modules, ~148 module fns, game loop at module top level; thumbv4t release, v3.9.0
d6c7d62e1)SingleCorestatics emitted)TISH_MODULE_STATICS=0(whole pre-#682 emission)So the statics recover 9,344 B here and are load-bearing — the pre-#682 emission would sit 2.6 KB from the top of the 32.5 KB IWRAM stack and trip the #655 guard margin. The ROM is behaviourally identical either way (4,000-frame soak clean, frame-period EMA unchanged).
Why the residual is top-level code, not bindings
Two game-side levers measured on the same sources, same compiler, before this issue:
let <X>: i32 = <literal>constants into their one reader: ~4 B eachcargo:crate: ~27 B eachBindings are no longer where the bytes are. What remains in
run()is the program's top-level statements — in this game the main loop itself — whose locals and expression temporaries all live in the one shared frame. That is exactly what the reverted chunking addressed, and the revert note already names the fix shape: "chunking needs real fns with explicit params, which is a separate change."Ask
Revive the chunking as real fns with explicit parameters (per the revert note), or any equivalent that moves module top-level statement temporaries out of
run()'s frame. With the statics landed, this is the remaining term that scales the frame with program size on GBA.Related: #682 (closed), #687, #684, #655.