SWI OS_AbortTrap
3 posts, 3 voices
Andrew Hodgkinson (6)
465 posts
|
This topic has been imported from the old forum. Due to its use of fixed format text, you may need to make your browser view wider in order to see posts with the correct layout. |
Chris Williams (63)
1 post
|
I've written the basics of a freely available (BSD-licensed) virtual memory system for RISC OS, which uses Sparse DAs and RISC OS 4/6's SWI OS_AbortTrap. See here for docs: http://select.riscos.com/prm/core/aborttrap.html It's a pretty powerful and useful SWI, because it does all the instruction decoding, mode and environment twiddling, and fix ups for you. The handler function just has to copy to and from a kernel buffer. It would be nice to see my vm module running on more than just RiscPCs and A9homes, so hopefully it won't be too much effort to get it going on RISC OS 5 especially with the source code open - although the reinvention of the wheel aspect is sad. Any thoughts, or has someone already written a custom data abort vector handler that could be used for this? I don't mind doing it, but I have a feeling there will be someone who has had code on a shelf somewhere that traps data aborts. Chris. |
Ben Avison (25)
445 posts
|
Chris Williams (63) wrote: > Any thoughts, or has someone already written a custom data abort vector > handler that could be used for this? I don't mind doing it, but I have a > feeling there will be someone who has had code on a shelf somewhere that > traps data aborts. I've written that sort of code myself before now - hidden away inside some of the embedded RISC OS stack - but it doesn't support LDRH/STRH (not that ROL's version does either, I see). I remember that ARM provide support code that does a complete job of it too. Unfortunately I can't remember how to get hold of it now, but hopefully it would be possible to obtain it under similar conditions to the FPA support / FP emulator code. I think the abort system as a whole could do with some careful looking at, to ensure that the existing OS and CLib abort handlers, lazy task swapping and sparse dynamic areas patch-up routines all get called in the correct order with respect to things like a disc swapping system, or (something I'd like to see) an OS watchpoint debugging facility. One more thing: a disc swapping system would be most useful if applied to the application slot rather than dynamic areas. I know it's not your fault - we don't have sparse application slots - but it doesn't make sense to make much use of global virtual address space (ie dynamic areas) on a modern system where the amount of physical RAM is of a similar size to the virtual address space. I guess what I'm saying is that we should chalk sparse application slots up on the wish list too. |
