| Re: [hatari-devel] DSP long interrupts fix |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Le 25/06/2024 à 08:10, Miro Kropáček a écrit :
On Mon, 24 Jun 2024 at 23:23, Nicolas Pomarède <npomarede@xxxxxxxxxxxx
<mailto:npomarede@xxxxxxxxxxxx>> wrote:
During prefetch the interrupt will then change from "fast" to "long"
and PC/SR will be pushed automatically to the stack not because it's
a JSR (else you would return with an rts, not an rti), but because
it's a long interrupt.
That's good thinking however I'm still puzzled by this explicit line
from the User's Manual:
/While either an unconditional jump or conditional jump can be used
to form a long interrupt, they do not store the PC on the stack;
therefore, there is no return path./
Not only do they explicitly mention that the PC is not stored, they also
mention that you simply can't return from it. So I'm wondering whether
this is actually a bug in the DSP (i.e. the decoder
/should/ differentiate between JSR and JMP) or they didn't realise this
side effect.
Hi
note that the doc also says that as soon as a short int starts then 2
instruction words are prefetched but without updating the PC.
This explains why when the short int is over then prefetch will resume
from the "stalled" PC before the short int which looks as if a "return"
was made even if it is not a true rts/rti.
I think that's what the doc means by there'no return path : there's no
usual PC on stack, the flow of the interrupted code is just resumed with
the value of the PC that was stalled.
At least that's what happening in VOXXX.
Laurent, did you test this on real hardware? I.e. JMP'ed on an
interrupt, and investigated the stack immediately afterwards?
For completeness, maybe other instruction than JMP and JSR should
also change to long interrupt mode (JScc for example).
That's for sure. There's quite a lot of them: Jcc, JScc, JCLR/JSET,
JSCLR/JSSET
--
http://mikro.atari.org <http://mikro.atari.org>