OS_ClaimProcessorVector
Jeffrey Lee (213) 6048 posts |
There are a couple of aspects of OS_ClaimProcessorVector which could be improved upon:
|
Sprow (202) 1155 posts |
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). |
Jeffrey Lee (213) 6048 posts |
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. |
Martin Bazley (331) 379 posts |
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? |
Jeffrey Lee (213) 6048 posts |
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. |
Sprow (202) 1155 posts |
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. |
Martin Bazley (331) 379 posts |
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… :-) |
Jeffrey Lee (213) 6048 posts |
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. |
Steve Revill (20) 1361 posts |
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… :) |
Martin Bazley (331) 379 posts |
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. |
WPB (1391) 352 posts |
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:
If any of the above is wrong – sorry. If any of it’s helpful – good! ;) |
Steve Revill (20) 1361 posts |
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. |
David Thomas (43) 72 posts |
Martin> QuickFiler doesn’t hack the Filer, it uses Wimp and WimpSWIVe filters to intercept and simulate the various operations. |