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:
@@ -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`
|
||||
|
||||
|
||||
Reference in New Issue
Block a user