|
|
Acorn Arcade forums: Programming: Writing agnostic FIQ code for ARM2/3/610+
| |
Writing agnostic FIQ code for ARM2/3/610+ |
| |
sirbod (17:36 16/4/2012)
sirbod (20:36 16/4/2012)
Phlamethrower (21:02 16/4/2012)
sirbod (22:29 16/4/2012)
Phlamethrower (20:54 16/4/2012)
|
| |
|
Jon Abbott |
Message #120100, posted by sirbod at 17:36, 16/4/2012 |
Member
Posts: 563
|
Anyone know or have an example of how to write a Vector handler that works on all the above and also works on RISC OS 3.1 upwards.
Or...any hints of how things need to be handled differently across versions of RISC OS?
I've grasped that FIQ will be in 32bit mode on the ARM610 upwards, not sure on the RISC OS issue though.
For ADFFS, I'm trapping keys (via insV) to change discs and then actioning them. This means the code needs to immediately enable interrupts, switch to SVC mode, action the disc change and finally exit cleanly to the FIQ handler.
At the moment, it's crashing immediately on entering SVC which I'm guessing is due to the stack not being clean on the FIQ side.
EDIT: Just noticed InsV is in IRQ mode, but I believe the same rules apply.
[Edited by sirbod at 19:39, 16/4/2012] |
| |
 [ Log in to reply ] |
| |
|
Jon Abbott |
Message #120101, posted by sirbod at 20:36, 16/4/2012, in reply to message #120100 |
Member
Posts: 563
|
Replying to my own question, I've figured out the beginning bit:
1. Entered in IRQ / IRQ32 mode depending on CPU
2. Pull R14 off the IRQ stack (the IRQ return address as we're handling the request)
3. Switch to SVC / SVC32 mode depending on CPU and OS version and enable IRQ's (see note below)
4. Load the disc (~15 seconds)
5. Exit ?
For 5, I've tried:
5.1 Switch back to IRQ mode and return to the calling IRQ handler, which seems to randomly corrupt the stacks
5.2 Return in SVC mode, more reliable but doesn't sound right
5.3 Returning via "OS_Exit" - the obvious choice but again god knows!
How do you tell if you should be switching to SVC32 though, before calling any SWI's?
[Edited by sirbod at 21:38, 16/4/2012]
Forgot to mention I have to re-enable IRQ's at step 3 as the code take so long to run. My code is re-entrant
[Edited by sirbod at 22:02, 16/4/2012] |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #120102, posted by Phlamethrower at 20:54, 16/4/2012, in reply to message #120100 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
I've grasped that FIQ will be in 32bit mode on the ARM610 upwards, not sure on the RISC OS issue though. Yes, FIQs will be in 32bit mode on ARM6+. Ordinarily IRQs will only be in 32bit mode if you're running on a 32bit OS. However if you (or one of your games!) directly patches the IRQ vector (or any of the other processor vectors), thereby bypassing the OS entirely, then it will be entered in 32bit mode.
For ADFFS, I'm trapping keys (via insV) to change discs and then actioning them. This means the code needs to immediately enable interrupts, switch to SVC mode, action the disc change and finally exit cleanly to the FIQ IRQ handler.
At the moment, it's crashing immediately on entering SVC which I'm guessing is due to the stack not being clean on the FIQ IRQ side. There are a few things I can think of that you could be doing wrong:- Enabling IRQs (perhaps during the mode change). I'm guessing that when the kernel calls InsV in IRQ mode it might be doing so before it's cleared the IRQ state in the keyboard hardware - so if you were to enable IRQs from inside InsV you'd get stuck in a recursive IRQ loop until the stack overflows. Also if you ever enable IRQs while in IRQ mode, you can kiss the contents of R14_irq goodbye.
- Not preserving R14_svc before calling SWIs. Although that would cause it to crash on exit from your code rather than on entry.
- Calling a non re-entrant SWI. Again it sounds like you haven't reached this stage yet, but if you do try calling a filing system SWI from the background (i.e. from an IRQ handler) you'll probably find that it will fail (but usually with an error rather than stiffing the machine). When your InsV code decides it wants to load a new image it's probably a good idea to register a callback and do the actual image loading from there.
At the moment, it's crashing immediately on entering SVC which I'm guessing is due to the stack not being clean There's no requirement for the stacks to be empty when switching modes. As long as the stack pointers are kept valid (or at least kept valid whenever IRQs are enabled) there shouldn't be any stack problems to worry about, except perhaps stack overflows if you're trying to use too much space. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #120103, posted by Phlamethrower at 21:02, 16/4/2012, in reply to message #120101 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
How do you tell if you should be switching to SVC32 though, before calling any SWI's? If you're in IRQ26, you switch to SVC26. If you're in IRQ32, you switch to SVC32. If you're already in SVC mode (whether SVC26 or SVC32) then you don't need to worry about it. But since InsV gets called in both IRQ and SVC mode, you'd usually write your code to do a dummy mode change anyway. The code sequence from the 32bit tech docs should cover everything you need. |
| |
[ Log in to reply ] |
| |
|
Jon Abbott |
Message #120104, posted by sirbod at 22:29, 16/4/2012, in reply to message #120103 |
Member
Posts: 563
|
Perfect answer, seems to work now. |
| |
[ Log in to reply ] |
| |
|
Acorn Arcade forums: Programming: Writing agnostic FIQ code for ARM2/3/610+ | |
|
