The VFPSupport module manages the VFP/NEON coprocessor hardware. Most of the SWIs provided by the module focus around the creation and use of VFP contexts. Each program which wishes to use VFP/NEON must create at least one context. The primary use of the context is as a buffer to save the hardware registers and state when another program becomes active, for example when a Wimp task calls Wimp_Poll and another task is paged in. If a program attempts to execute a VFP/NEON instruction without having a context active then the instruction will abort.
Note that depending on the programming language and support libraries your program uses, context creation and management may or may not be handled for you:
For other programming languages, consult the relevant documentation supplied with the compiler/interpreter.
The VFPSupport module allows the use of VFP/NEON contexts from user-mode applications, module code running in supervisor mode, and interrupt handlers.
The Wimp is fully aware of VFP contexts and will switch them automatically when switching tasks; when a task is resumed the context it was previously using will be reactivated. However for other situations (single-tasking programs started from the command line, SWI calls, interrupt handlers, etc.) no automatic context switching occurs. For these situations it is your responsibility (or the responsibility of e.g. the C runtime library) to ensure the previously active context is restored on exit from your code.
Note: Wimp versions prior to 5.60 contained a bug that prevented VFP contexts from being handled correctly if certain types of Wimp_Poll post-filters were used. Therefore it’s recommended that Wimp-based VFP applications ensure Wimp 5.60 or later (RISC OS 5.24). If supporting older Wimps is necessary, the VFP context must be deactivated and reactivated manually around Wimp_Poll calls.