Upcall handler

Justin Fletcher justin.fletcher at ntlworld.com
Mon Dec 17 06:05:49 PST 2001

In message <ee424eea4a.kbracey at kbracey.cam.pace.co.uk>
          Kevin Bracey <kevin.bracey at pace.co.uk> wrote:

> In message <f82f48ea4a.Justin at gerph.movspclr.co.uk>
>           Justin Fletcher <justin.fletcher at ntlworld.com> wrote:
> > AIUI, you can't identify that you're in an interrupt though.
> >
> > For example, BufferManager triggered on interrupt, issues OS_UpCall
> > triggering UpCallV, and the first that happens is that you end up in SVC
> > mode (not IRQ mode) and have no idea that you came from IRQ mode. And you
> > can't backtrack the stack to find the old PSR, because there might be
> > post-trap handlers present.
> Regardless of the rest of this discussion, it IS possible to know you're in
> an interrupt. There's a semi-public location in zero-page (I think it was at
> least documented in the Arthur PRMs) called the interrupt semaphore - it's a
> frame pointer pointing at the innermost interrupt on the IRQ stack, or zero
> if not in an interrupt. Location &108.
> I'd personally have no problem with supervisor mode code peeking this
> location.

I dislike any part of zero page being public, so didn't mention it - I don't
consider it part of the public API really. Matter of opinion, I guess.

> Otherwise, you'll just have to only deal with UpCalls you know, or rely on
> no-one else being silly enought to call UpCall from interrupt routines, and
> have special behaviour for the known bad cases.

Well, even that won't help you, because the code that was handling your
upcalls has vanished when the Wimp paged the task out.

Gerph {djf0-.3w6e2w2.226,6q6w2q2,2.3,2m4}
URL: http://www.movspclr.co.uk/
... Eyes to the heavens, screaming at the sky;
    Trying to send you messages, but choking on goodbye.

More information about the gcc mailing list