Ticket #538 (Invalid)Thu Nov 25 13:31:22 UTC 2021
PRM: Wimp_Poll and Saving FP state
| Reported by: | Stuart Swales (8827) | Severity: | Normal |
| Part: | RISC OS: Documentation | Release: | |
| Milestone: | Status | Invalid |
Details by Stuart Swales (8827):
PRM Volume 3 states “The floating point registers should only be saved if one or more of the following is true…”
I’d argue that as APCS requires FPA registers <code>F4-F7</code> (but not <code>F0-F3</code>) to be preserved over function calls, any C program that uses FPA floating point and isn’t calling <code>SWI Wimp_Poll</code> (or <code>PollIdle</code>) from only a <code>main()</code>-level dispatch loop ought to be saving the floating point state, rather than those criteria currently listed.
For instance, I might have a numerical application which performs some lengthy calculations, and every milion or so loops, uses <code>SWI Wimp_PollIdle</code> to let other applications do some work. It’d be bad for my intermediate calculations to be corrupted by having other applications’ <code>F4-F7</code>! But according to the current PRM, I am not recommended to use the Wimp to save FP state…
Changelog:
Modified by Sprow (202) Sat, December 18 2021 - 17:57:02 GMT
> I might have a numerical application which performs some lengthy calculations, and
> every milion or so loops, uses SWI Wimp_PollIdle to let other applications do some work
In which case you fall under the first condition listed in the PRM: “The task is controlling arbitrary applications ‘underneath’ it, which may use
floating point instructions”, because in effect you’ve implemented a task scheduler within your own application to split up the big computation, and therefore wish to suspend the computation but retain the state
Modified by Sprow (202) Sun, March 20 2022 - 15:07:48 GMT
- Status changed from Open to Invalid
