log in | register | forums
Show:
Go:
Forums
Username:

Password:

User accounts
Register new account
Forgot password
Forum stats
List of members
Search the forums

Advanced search
Recent discussions
- WROCC Newsletter Volume 41:11 reviewed (News:)
- WROCC March 2024 meeting o... Hughes and Peter Richmond (News:1)
- Rougol March 2024 meeting on monday with Bernard Boase (News:)
- Drag'n'Drop 13i2 edition reviewed (News:)
- South-West Show 2024 talks (News:4)
- February 2024 News Summary (News:1)
- Next developer fireside chat (News:)
- DDE31d released (News:)
- South-West Show 2024 Report (News:)
- South-West Show 2024 in pictures (News:)
Latest postings RSS Feeds
RSS 2.0 | 1.0 | 0.9
Atom 0.3
Misc RDF | CDF
 
View on Mastodon
@www.iconbar.com@rss-parrot.net
Site Search
 
Article archives
The Icon Bar: 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
PhlamethrowerHot 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
PhlamethrowerHot 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 ]
 

The Icon Bar: Programming: Writing agnostic FIQ code for ARM2/3/610+