re: read the ISL branch handlers -- it is a condition-code machine

Closes the backlog item that was the last thing between the flat decode and a
per-phase clear condition, and closes isl-builtins.md's standing "op10 + op13 look
like a switch -- NOT confirmed".

op10 resolves two operands, issues a SIGNED cmp, and writes three condition bits to
a bitset at phase+24: bit 0 = EQ, bit 1 = GT, bit 2 = LT.  op11 is the same machine
for floats via fcmpu.  op13-op18 branch on those bits to [phase+232] + word@+4 --
the same phase-relative target form as the unconditional op12:

  13 bit0 set    beq      16 bits 2 then 0   ble
  14 bit0 clear  bne      18 bits 1 then 0   bge
  15 bit2 set    blt      17 bit1 set        bgt

13/14/15/17 are byte-identical apart from the bit index and the polarity.  All six
relations are present and each appears exactly once; that completeness is the check
that the reading is right, rather than the usage pattern -- which the item
explicitly warned against.

Operand order recorded because it is easy to reverse: LHS = (kind byte[1], word@+4),
RHS = (kind byte[0], word@+8).

Method note in the doc: the jump table at 0x822635FC holds THUNKS, and the handler
is the bl target inside each.  My first pass guessed handler addresses at a fixed
stride, landed mid-function, and produced a 20-line "difference" that was pure
misalignment.

isl.py names the ops; data/isl-stage02.txt is regenerated and every diff line pairs
exactly, only the op-name column changing (op10->cmp.i x5, op13->beq x4,
op14->bne x1).  data/isl-stage02-phase-ends.txt now shows the phase-3 poll loop
reading as one: unit_state(ADT308) -> op23 -> cmp.i -> beq back to 0xFEB4.

Left unnamed on purpose: op23 (0x82271C30) and op21 (0x82175C20).
This commit is contained in:
Sylpheed RE agent
2026-08-27 05:10:50 +00:00
parent f41847701c
commit bad96eb54a
6 changed files with 226 additions and 56 deletions

View File

@@ -704,9 +704,15 @@ op13 -> 0x5598
Consecutive small immediates each paired with their own code offset is the shape
of a **case/branch dispatch**, and `op12` is already confirmed as the
unconditional jump. **Not confirmed** — the handlers (`0x82271598` for op10,
unconditional jump. ~~**Not confirmed** — the handlers (`0x82271598` for op10,
`0x82271830` for op13) have not been read, and I am not going to name them from
a pattern alone.
a pattern alone.~~
**(2026-08-27) CONFIRMED from the handlers — see
[isl-branches](isl-branches.md).** `op10` is a signed compare writing three
condition bits (0=EQ, 1=GT, 2=LT) to a bitset at `phase+24`; `op11` is the float
twin via `fcmpu`; `op13``op18` are the six relational branches
(`beq bne blt ble bgt bge`) on those bits, targeting `[phase+232] + word@+4`
like `op12`. It is a case dispatch lowered to sequential compare-and-branch.
## 🔴 Correction: `unit_state` does NOT read `+16` — it reads `+4` and `+104`