Trace compact opcode-8 descriptor cluster
This commit is contained in:
parent
d18bab9833
commit
4945430149
2 changed files with 37 additions and 0 deletions
|
|
@ -270,6 +270,24 @@ Working rule:
|
|||
`0x00426d60 company_deactivate_and_clear_chairman_share_links`, so the open question is
|
||||
whether grouped descriptor id `548` is the missing compact-event label for that destructive
|
||||
company-clear path or a neighboring unmapped id-space entry in the same branch family
|
||||
- the broader installed-map sweep narrows that question further:
|
||||
across all `41` bundled `.gmp` files in the current `rt3_105/maps` install, grouped descriptor
|
||||
id `548` currently appears only once, in `Texas Tea.gmp` record `7`, with `opcode 8`,
|
||||
`scalar 0`, standalone condition tuple `(7, subtype 0)`, and compact signature family
|
||||
`nondirect-ge1e-h0001-0007-0000-6d00-0200-p0000-0000-0000-ffff`
|
||||
- the same wider sweep also rules out the simplest alias theory:
|
||||
the ordinary checked-in `Deactivate Company` descriptor `13` does appear in real map bundles,
|
||||
but only on `opcode 1` with scalar `1` in `British Isles.gmp`, `Chicago to New York.gmp`,
|
||||
`East Coast, USA.gmp`, `Japan Trembles.gmp`, and `State of Germany.gmp`; it does not appear on
|
||||
the `opcode 8` deactivation branch, so grouped descriptor id `548` is not just the obvious
|
||||
compact stand-in for ordinary descriptor `13`
|
||||
- the frontier is now best treated as a small compact-only opcode-`8` cluster rather than a
|
||||
one-id anomaly:
|
||||
the installed-map sweep now shows unlabeled grouped descriptor ids `[521, 526, 528, 548, 563]`
|
||||
in the `0x00431b20` dispatch strip, all currently on opcode `8`, with current sightings in
|
||||
`Alternate USA.gmp`, `Rhodes Unfinished.gmp`, `Louisiana.gmp`, and `Texas Tea.gmp`; the next
|
||||
static-analysis pass should treat that as one branch family above `0x00426d60`, not five
|
||||
unrelated missing labels
|
||||
- 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