fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

re: [phase+10152]/[phase+10156] are an answer and a request state

Browse Source 
Built-ins 102/103/130 are one trio over two phase fields, read off
four consecutive vtable stubs (slots 70/71/72/97).  102's body:

  state==1 -> return 2                     (pending)
  state==2 -> special[0] = (answer==1); state=0; return 0
  else     -> state=1; answer=0; return 2  (issue)

2 and 0 are the dispatcher's thread codes, so 102 blocks the coroutine
until an answer arrives; 103 is the non-blocking form and 130 clears
the answer.  The answer is published by sub_821A9DC8 under the same
(16,32] gate that request_next's writer uses.

Flags an inherited name I could not verify: prompt_yes_no (102) has no
derivation recorded anywhere in the corpus, so 103 and 130 are left
unnamed rather than named off it.

Docs only; artefacts byte-identical.
This commit is contained in:
Sylpheed RE agent
2026-08-27 09:39:52 +00:00
parent af61c162f3
commit 237dbce155
2 changed files with 78 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

46
docs/re/structures/isl-condition-builtins.md
View File

@@ -88,6 +88,52 @@ each have exactly one dominating condition.
`0x20FFFF00`, the third id (used by the `GRAPH_PATH` / `EX_FONT` / `SYSTEM`
code in `sub_821D6350` and `sub_821D6A40`).
## ✅ (2026-08-27) `[phase+10152]` and `[phase+10156]` are an ANSWER and a STATE
The backlog carried these as "9 and 7 writers, unread". They are read now, and
they are not `request_next`'s siblings-by-adjacency: they belong to a **trio of
built-ins** sitting in four consecutive vtable stubs.
| built-in | vtable slot | handler | body |
|---|---|---|---|
| **102** | 70 | `sub_8226BF48` | the state machine below |
| **103** | 71 | `sub_8226BFA8` | returns `state != 0 && answer == 1` |
| 104 | 72 | `sub_8226BFE0` | `request_next` (above) |
| **130** | 97 | `sub_8226BFD0` | `[phase+10152] = 0` |
Built-in 102, read straight off `0x8226BF48`:
```
state = [phase+10156]
state == 1 -> return 2 ; still pending
state == 2 -> special[0] = (answer == 1) ; state = 0 ; return 0
otherwise -> state = 1 ; answer = 0 ; return 2 ; issue the request
```
**`2` and `0` are the dispatcher's thread codes**, so this is a *blocking*
built-in: it yields the coroutine until an answer arrives, then hands it back.
Built-in 103 is the **non-blocking** form of the same test, and 130 clears the
answer slot.
⇒ **`[phase+10156]` is a request STATE — 0 idle, 1 pending, 2 answered — and
`[phase+10152]` is the ANSWER**, compared against `1`.
The answer is published by `sub_821A9DC8`, which writes
`[phase+10152] = [r6+4]` and `[phase+10156] = 2` **under the same `(16, 32]`
gate on `[r30+104]+12`** that `request_next`'s writer uses — so one
engine→script publish path serves both mechanisms.
⚠️ **A name I did not verify.** `isl.py` calls built-in 102 `prompt_yes_no`,
and the mechanism above is *consistent* with a modal yes/no prompt — but
grepping the corpus, that name appears only in a list of built-ins unused by
Stage 02, with **no derivation recorded anywhere**. What is actually read here is
"a blocking request whose answer is tested against 1". 103 and 130 are therefore
left unnamed rather than named off an unverified premise.
🟡 Also unread: what question is being asked. `sub_821A9DC8` has **no strings**
and exactly one reference in the image — a tail `b` from `0x821AC064` — so the
string recipe finds nothing there.
🟡 Its neighbours belong to the same cluster: `builtin103` reads
`[phase+10156]` and `[phase+10152]` (9 and 7 writers), and a sibling vtable stub
clears `[phase+10152]`. The shape is an engine→script status trio, but that is a