Clarify add-building batch row semantics
This commit is contained in:
parent
a916e2d371
commit
32e7d797fe
2 changed files with 14 additions and 4 deletions
|
|
@ -301,10 +301,12 @@ Working rule:
|
|||
EventEffects table proves the actual grouped descriptors are add-building slots, not
|
||||
special-condition verbs
|
||||
- the compact opcode-`8` frontier therefore shifts:
|
||||
the next static-analysis pass should determine whether opcode `8` on that shell-owned
|
||||
add-building strip means a distinct add-building shell flow, and then continue the candidate
|
||||
bridge past the currently grounded `503..569` front half of the widened strip, not more
|
||||
missing-label recovery
|
||||
direct disassembly of `0x00430270` now shows that the add-building consumer does not branch on
|
||||
grouped opcode at all for descriptor strip `503..613`; it consumes the descriptor-derived
|
||||
candidate id, placement count byte `0x11`, and the packed span words at `0x14/0x16`.
|
||||
The next static-analysis pass should therefore target the remaining span-field meaning and
|
||||
shell-owned placement-flow ownership on that strip, then continue the candidate bridge past the
|
||||
currently grounded `503..569` front half of the widened strip, not more missing-label recovery
|
||||
- the concrete owner strip above that bundle is grounded now too:
|
||||
`0x00433060` is the direct non-direct serializer loop that writes `0x4e99/0x4e9a/0x4e9b`,
|
||||
calls `0x00430d70` per live collection row, and sits beside the sibling `0x00433130` size/load
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue