I wanted to apologise for the bad information I supplied earlier in this thread.
And also to reply to Duane's question regarding why a system would want to prevent the use of FP resources in kernel context.
On Apr 26, 2010, at 8:49 AM, Duane Murphy wrote:
Kernel code must not use FP resources.
Huh? That seems like an onerous restriction. Can someone please
explain this a little better?
There are a number of arguments for not allowing this sort of use:
- Many systems lazily save/restore FP context; allowing kernel code to use FP resources means that user FP context has to be saved/restore at the kernel entry/exit point. Ubiquitous use of FP resources leads to real complications (e.g. imagine taking a lazy FP activation trap while handling another trap). This save/restore can also be expensive.
- There is no exception or termination model for kernel clients of FP resources. This complicates the delivery of various asynchronous FP notifications. With large amounts of work being done by proxy in callbacks, there is often no knowledge of the operational context for the FP operations, so nowhere to deliver these notifications.
- There is no context for optional FP behavioural settings (see above inre: proxy work).
- FP code frequently wants access to (large, complex) support libraries.
- There's rarely a strong argument for doing work involving FP resources in the kernel, vs. doing it in an unprivileged context.
There are some useful algorithms that take use floating point
registers. How might I take advantage of these algorithms?
Structure your code so that the code that needs to do computational heavy lifting in an unprivileged context. The usual rule applies here; unless you absolutely *have* to be running in the kernel, you shouldn't be.