OS_ClaimProcessorVector

There are a couple of aspects of OS_ClaimProcessorVector which could be improved upon:

• If you want your new handler to pass through some/all exceptions to the old handler, there’s no builtin way of doing an atomic claim, because you only find out the address of the old routine once your new routine has been patched in by the kernel. The best option you have available is to disable IRQs around the call, but there’s still a chance of catastrophic failure if an FIQ handler crashes or something hooked onto the SWI vector crashes. Admittedly the chances of this approach failing are pretty slim, but those chances could be changed from “slim” to “none” via a simple revision to the API. So I’m proposing that if you set bit 9 of R0 when claiming a vector, then the kernel will treat R2 as a pointer to a location (within your handler code) at which to store the address of the old handler. This will allow the kernel to patch your handler for you, before hooking your new handler up to the vector.

• There’s no ability to deal with handlers being released out-of-order. To fix this I’m proposing that processor vector releases are performed via a service call. That will allow each claimant to check if its “old handler” pointer matches the handler which is being released, and if so update it to the new value. This won’t fix the problem overnight (it’ll rely on individual programs being updated to support the service call), but as only a handful of programs make use of OS_ClaimProcessorVector (mainly FPEmulator and VFPSupport?) there shouldn’t be many problems remaining once those are updated.

So I’m proposing that if you set bit 9 of R0 when claiming a vector

Looking at the kernel it looks like it doesn’t fault unrecognised set bits for this SWI, so on older kernels (only) bit 9 set would be taken as a release. Bit 8 and bit 9 set would be taken as though only bit 8 set, so the caller would still probably want some way to know that bit 9 had been honoured or not (eg. buffer must be prefilled with zero, check for non zero after the call).

How wonderful. Luckily the kernel does check the vector number, so a simple workaround would be to require that bit 7 is set in order to use any new features controlled by bits 9-31. That way you should at least get a “Bad vector number” error on old kernels.

Can’t we just have a simple mechanism (like the Wimp filters) to register pre- and post-filters for any given SWI numbers, and potentially block their execution?

We could do, yes. How many programs are there which need to trap SWIs in that manner? At the moment I’m only looking at things from the perspective of FPEmulator and VFPSupport, which both hook onto the undefined instruction vector.

I was thinking of mentioning Ben’s suggestion of an improved data/prefetch abort handler, so if we were to implement both that and the SWI trap system then that could allow us to deprecate a few uses of OS_ClaimProcessorVector.

Maybe a similar system could also be used for undefined instructions – after all, FPEmulator and VFPSupport are only interested in coprocessor instructions, so having some central code in the kernel to detect coprocessor instructions and pass the abort to the right handler could help boost performance.

a simple workaround would be to require that bit 7 is set

Cunning, yes that would work. It would be at the expense of potential Cortex M series compatibility (they have > 128 vectors), but I guess the lack of MMU makes that less of a concern.

How many programs are there which need to trap SWIs in that manner?

Well, one specific example I can think of is QuarkNoDisc spoofing ADFS_DiscOp!

I once wrote a utility (the &FFC type) which took as a parameter a memory address which was known to be the start of some Digital Symphony song data, and calculated its length so that it could be saved to file. This was intended to be used in conjunction with ARM_debug trapping the SWI DSym_Load, where (if the data is not being loaded from file) the address to load from was passed in a register. I presume ARM_debug accomplished this by OS_ClaimProcessorVector. Having a straightforward SWI filter would make things much more straightforward, especially since it would allow handlers to be easily deregistered out of order without necessitating the service call workaround you suggest.

I’m sure there are legitimate uses as well… :-)

Well, one specific example I can think of is QuarkNoDisc spoofing ADFS_DiscOp!

I had a feeling you’d mention that! But that’s a somewhat exceptional case, especially since OS_ClaimProcessorVector isn’t even available on RISC OS 2/3.

While we’re talking about trapping SWIs, you should perhaps take a look at DebugTools, specifically the stuff for claiming and releasing OS SWIs. Every time I remember about writing that, I keep thinking it needs moving into the Kernel… :)

I know there are already mechanisms for claiming OS SWIs only – Select has OS_ClaimOSSWI, for example – but they’re not really useful without a way to claim SWI numbers over &40000 as well (which includes the Wimp, among many other technically non-OS components). Indeed, with a lot of OS SWIs there’s no need to bother, because they’re already vectorised through ByteV, SpriteV et al. Effectively, I’m simply proposing to enforce indirection for every single SWI.

I’m not familiar with the Wimp filter system, but does it support multiple claimants or releasing out of order? Ideally you’d be able to do both of those for SWIs.

Take Sound_Control for example. The problem with the system beep going funny when the pitch changes could be solved by installing a pre-filter which automatically bodged around the pitch parameter so as to cancel out the effects of any incorrect tuning assumptions made later on. Obviously in this case it’d be much better if Sound_Control could just be fixed, but it’s an example of the kind of bug/misfeature which could be more easily patched when sources aren’t readily available.

Doesn’t QFiler manually hack into the Filer? I wonder how much of that could be fixed if there was a more complete API for third-party extensions to internal routines in general, not just SWIs? Given that that particular module already has to be updated every single time a new OS release comes out, it’s not as if we’d have any compatibility worries…

EDIT: I seem to remember Acorn promoting RISC OS in the introduction to the PRMs as a ‘modular’ OS, meaning standard components (even major ones like the Wimp) could be switched out and replaced by third-party modules at will – as long as the third-party modules reimplemented every single little detail of the original defined API right down to the last bit. That’s enormously wasteful if you only want to make a small tweak, and probably why nobody’s ever seriously tried to do it. Increasing the resolution of this modularity would not only be beneficial, it’d be much more in keeping with the spirit of RISC OS.

I looked in to different methods/tools for claiming/vectorising SWIs not long ago. It seems there are various methods, the most obvious of which is probably sitting on the hardware SWI vector. But that seems to be generally frowned upon as a performance hit. Another method is to poke around in the SWI dispatcher. That’s generally regarded as hacky (probably rightly so!). Anyway, here’s some of the software I found that’s relevant:

• OS_ClaimOSSWI – only implemented in Select – only vectorises “OS” SWIs. Graham Shaw has written the ClaimASWI module, that implements the functionality on other strands of the OS.

• DebugTools implements the same functionality with different SWIs. I think this sits on the hardware SWI vector.

• DoggySoft’s WimpSWIVe was a cunning way to vectorise WIMP SWIs. It added a module to the module chain with the same SWI chunk number as the Wimp’s. On initialisation, it found the address of the real Wimp SWI handler so it could hook into it. Then it just passed Wimp SWIs on to the Wimp as and when it got them, optionally calling some user code before/afterwards. The most recent version I know of is version 0.21a, created by D. Tanis and available as part of the SmartMenu download here.

• Nemo’s VectorExtend, detailed a little in this thread. Looks very interesting, but I have no idea how it is implemented. Haven’t heard from nemo on these forums for a long time, sadly.

• !RAMplify ’s SimpleSWI, with some hint of documentation in this thread.

• GUS’s Wacky-Talky (I have the source to this now), mentioned in this thread. Quoting, “Wacky-Talky supports claiming any RO SWI with the best way, without slowing down the rest of the SWIs. Using WT_ClaimSWI & WT_ReleaseSWI, any SWI can be used as a vector.” I haven’t studied the source yet to see what this “best way” is. I think it’s a dispatcher hack.

If any of the above is wrong – sorry. If any of it’s helpful – good! ;)

I would point out that the OS SWI claim stuff in DebugTools was developed independently of the similar SWIs in the ROL branch so I’ve no idea how similar the APIs are. All I’m really suggesting here is that there’s no reason why that API couldn’t be adopted as the one for a more general-purpose SWI claim/release facility, living in the Kernel’s SWI dispatch routine. But yes, there are other options available too.

Martin> QuickFiler doesn’t hack the Filer, it uses Wimp and WimpSWIVe filters to intercept and simulate the various operations.