Ground infrastructure footer-bit consumers
This commit is contained in:
parent
ec7045363c
commit
ebee1a3a58
2 changed files with 11 additions and 4 deletions
|
|
@ -217,10 +217,15 @@ Working rule:
|
|||
`0x01 / 0x00`, and fixed prior profile span `0x03` in both saves, while
|
||||
`0xff0000ff / 0x0001 / 0xff` stays on prelude `0x0001 / 0xff`, fixed short-flag pair
|
||||
`0x00 / 0x00`, and widely scattered prior profile spans in both saves.
|
||||
- That means the remaining infrastructure question is no longer broad exact-class identity. It is
|
||||
specifically what those two short-flag families mean and why a minority of tunnel rows route
|
||||
into the sparse `0xff0000ff / 0x0001 / 0xff` outlier class instead of the stable
|
||||
`0x000055f3 / 0x0001 / 0xff` tunnel family.
|
||||
- Direct consumers of those footer bits are grounded now too: `0x00528d90` only admits the child
|
||||
when the explicit caller override is set, the surrounding global override byte
|
||||
`[owner+0x3692]` is set, or bit `0x20` in `[child+0x20]` is set; the sibling loop
|
||||
`0x00529730` only takes the later `0x530280` follow-on when bit `0x40` in `[child+0x20]` is
|
||||
set.
|
||||
- That means the remaining infrastructure question is no longer both footer bytes. It is
|
||||
specifically why the stable `0x000055f3 / 0x0001 / 0xff` tunnel family sets the first footer
|
||||
byte / bit-`0x20` admission gate while the sparse `0xff0000ff / 0x0001 / 0xff` outlier class
|
||||
clears it.
|
||||
- Source-side constructor analysis is narrower now too. `0x00490960` takes:
|
||||
- mode at stack arg 1
|
||||
- stem at stack arg 2
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue