rtel wrote on Monday, November 14, 2011:
The Cortex-M4F can be configured to use the FPU in several ways.
0) Turn the FPU off. Then you can use the M3 port.
1) Turn the FPU on, but set the hardware not to save its context.
This is fine if only one task uses the FPU, and no interrupts use the FPU. It is also fine if you want to save the FPU context manually for just those tasks that have registered as FPU users. It breaks when interrupts start using the FPU too, and is inefficient whatever as most of the time the FPU context is being saved and restored unnecessarily.
1) Set the processor to save the entire FPU context on every interrupt.
This is a really easy way of using it. You would require some changes to the port layer to setup the initial stack to have an FPU context, but that is not difficult. However, it is *massively* inefficient and *horrendous* in run time and RAM usage, especially when you consider that very few tasks will actually use the FPU, and when interrupts start nesting and each has its own FPU context.
2) Set the processor to use the lazy save mechanism so space is allocated to the stack for the FPU context, but a context save is only triggered if an FPU instruction is actually executed.
This is a clever and brilliant mechanism for efficient FPU usage, with interrupts, in a *single threaded* environment. Think through the consequences in a mult-threaded environment, with nested interrupts that also use FPU instructions, and you will soon see this is *massively* complex, with lots of corner cases, and near impossible to test, and almost unworkable with any sort of reasonable code base, size, run time limits, etc…
Then take into account that you need to inspect the output of your compiler extremely carefully, as some versions will output FPU instructions in the prologue and epilogue of function calls, even when the task makes no use of the FPU at all.
There is a plan to support M4F however, it is just a matter of finding the time.