The last handler that knew a frame offset

handleReadLine used DP1 for the frame and the conversion only looked for
DP2, so it kept the whole dance - and the dance had become a no-op that
looked like work: MVQA copied Q into A, A was written over the saved Q, and
RETI restored it, which is where it started. readLine leaves the length in
Q and SRET keeps Q, so the answer simply stands.

No handler in CosmOS knows what an interrupt frame looks like now. The
0d02 and 0d05 offsets still in the file are structures - an SBEX header, an
entry in the instruction table - and not frames.
This commit is contained in:
Anachronaut
2026-08-27 18:30:28 -04:00
parent 61a80ae13d
commit f1cc2e56b2
+3 -12
View File
@@ -1691,18 +1691,9 @@ handlePrintString:
handleReadLine: handleReadLine:
CALL readLine CALL readLine
; readLine works out how long the line was, and RETI would throw that away: it restores ; readLine works out how long the line was, and it is already in Q where readLine left
; every register from the frame, which is exactly what makes an interrupt safe to arrive ; it. SRET keeps Q and DP3 and puts everything else back, so the answer simply stands.
; unannounced and exactly what stops a service answering. So the answer is written into SRET
; the frame, over the saved Q, and RETI puts it back as though the caller had computed it.
;
; This has to be here rather than in a routine, because the offset is from where the
; Stack Pointer is now and a CALL moves it by ten.
MVQA
MVSD.1
DPUP.1 0d02
STA.1
RETI
; What the program was asked to work on. DP0 says where to put it and B how much room ; What the program was asked to work on. DP0 says where to put it and B how much room
; there is, counting the zero on the end, which is the same bargain readLine offers. ; there is, counting the zero on the end, which is the same bargain readLine offers.