Extended vectors - huh?

discussion of beeb/electron applications, languages, utils and educational s/w
Post Reply
crj
Posts: 834
Joined: Thu May 02, 2013 4:58 pm
Contact:

Extended vectors - huh?

Post by crj » Mon Mar 19, 2018 7:11 am

Up until now, I'd only ever used extended vectors to implement a filing system. For this purpose - where you wish to be the sole claimant of a normal vector - it's fine.

But what if you want to be able to pass a call on to the vector's previous claimant? Worse, what if the previous claimant was another extended vector?

And what if you want to claim IRQ1V/IRQ2V? The extended vector mechanism exits with an RTS, not an RTI.

Acorn spent a bunch of OS workspace on the extended vector table, and a bunch of ROM on the entry trampolines for all those vectors. They must have had some kind of aspiration that they be useful for stuff other than filing systems... right?

So what's the workaround? Sometimes, if you're wanting to stash details of a vector's previous claimant, you're going to need to claim some workspace for your ROM anyway, at which point you could just drop your own trampoline into RAM and avoid the whole thorny problem. But suppose you want to avoid claiming workspace and have somewhere else you can stash data - sideways RAM, for example. Now what?

I can't see any solution which doesn't involve using the forbidden knowledge that, on entry to your extended vector, the stack contains the return address to the extended vector mechanism (hereinafter "XVRA"), the previous ROM number ("PR#"), two junk bytes then the return address to the caller.

Even armed with that knowledge, what you'd have to do is pretty grim:
  • To pass the call on to a previous non-extended claimant: stack two more bytes. Shuffle XVRA and PR# up by two bytes. Insert previous_claimant - 1 into the gap. RTS.
  • To pass the call on to a previous extended claimant: stack seven more bytes. Copy XVRA. Insert the ROM number of the previous claimant and previous_claimant - 1 into the gap. RTS.
  • To return from an interrupt: Decrement the caller address which is below the stack frame. Yoink the saved P up from below the frame. Shuffle XVRA and PR# down by a byte. Restore P manually. RTS.
Am I overlooking a cleaner, easier or more legal way to do any of this?

SteveF
Posts: 510
Joined: Fri Aug 28, 2015 8:34 pm
Contact:

Re: Extended vectors - huh?

Post by SteveF » Sat Mar 24, 2018 12:47 am

If the vector you're claiming can't be called from within an interrupt (so I guess OSWRCH or OSRDCH are OK, OSWORD probably isn't, for example), could you stash the previous values of the normal vector and the extended vector (5 bytes in total) when you claim the vector? Then to pass a call through to the previous claimant, you could restore those 5 bytes, JSR OSWRCH (or whatever) will then call the original claimant, and you can restore your values to re-claim the vector yourself afterwards.

(I haven't tried this. I am wondering whether your ROM would get paged back in afterwards, but I am guessing it would, otherwise you couldn't make OS calls via extended vectors from within paged ROMs.)

crj
Posts: 834
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: Extended vectors - huh?

Post by crj » Sat Mar 24, 2018 2:28 am

Unfortunately, as well as knowing the call wouldn't be made from an interrupt (and, actually, EVENTV is one of the more desirable things to claim, just to get called regularly on machines before the Master) a second issue is the risk of re-entrancy, i.e. the handling one call generating another to the same entry point.

To some extent, that could work. (Another issue that's just occurred to me is the risk of coming unstuck if the routine exits via BRK rather than RTS. Ick.) It might conform better, but I'm not sure it's necessarily more elegant let alone more efficient. /-8

SteveF
Posts: 510
Joined: Fri Aug 28, 2015 8:34 pm
Contact:

Re: Extended vectors - huh?

Post by SteveF » Sat Mar 24, 2018 3:16 pm

Yeah, I guess BRK really puts the final nail in the coffin of that idea. Oh well. :-)

crj
Posts: 834
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: Extended vectors - huh?

Post by crj » Sat Mar 24, 2018 4:08 pm

Well, you could always work around that by intercepting... BRKV... from... inside... your...

Oh. )-8

Post Reply