VFPSupport_CreateContext (changes)
Showing changes from revision #4 to #5:
Added | Removed | Changed
VFPSupport
» SWI Calls
» VFPSupport_CreateContext
VFPSupport_CreateContext
(SWI &58EC1)
| Entry | |
|---|---|
| R0 | Flags: |
| Bit 0: User mode flag (0=user mode access not required, 1=user mode access required) | |
| Bit 1: Application space flag (0=not in application space, 1=in application space) | |
| Bit 30: Lazy activation flag (0=leave context inactive, 1=activate lazily. Supercedes bit 31) | |
| Bit 31: Activation flag (0=leave context inactive, 1=activate now) | |
| Other bits reserved, should be zero | |
| R1 | Number of doubleword registers required (1-32) |
| R2 | Pointer to buffer to use for context, or 0 |
| R3 | FPSCR value to initialise the context with |
| Exit | |
|---|---|
| R0 | Context pointer |
| R1 | Previously active context (if R0 bit 30 or 31 was set), else preserved |
| All other registers preserved | |
Use
This call allows programs to create and optionally activate a new VFP context.
Set R1 to the number of doubleword registers you require. When the context is activated registers D0 to Dn will be available to you; do not attempt to access registers outside your allocated range as you your code will either abort or potentially corrupt the state of another context.
Notes
If it is not possible to create a context with the given features, an error will be returned.
The flag in bit 0 of R0 controls a security measure that is supported on some systems; if you only require use of VFP/NEON instructions from privileged modes then it is recommended that you do not set this bit. This will prevent user-mode code from being able to executeVFP/NEON instructions and corrupt your context while it is active.
The flag in bit 1 of R0 must be set if the context is to be stored in application space. If you are not providing your own memory buffer, this flag should be clear.
Bits 30 and 31 of R0 control whether the new context will be activated now or whether it will be left inactive. If bit 30 is set the context will be activated in a lazy manner, i.e. the old context will only be saved and the new context will only be activated once the first VFP/NEON instruction is executed. Using lazy activation can provide improved performance in some situations, by avoiding redundant save/restore operations. If bit 31 is set the context will be activated immediately.
R2 should either be a pointer to a word-aligned buffer of the size indicated by VFPSupport_CheckContext, or 0 to allow the VFPSupport module to manage the context memory itself. Note that if you are managing the context memory yourself, the following rules apply:
- If the context is located in application space, bit 1 of R0 must be set to ensure the context is saved correctly before your task is paged out. Even for applications designed to be single-tasking this flag should be set, as there is the possibility your code may be running in a taskwindow.
- The context save area can be moved, but only when the context is inactive. Use VFPSupport_ExamineContext to check whether the context is active prior to moving the buffer, or use VFPSupport_ChangeContext to forcibly deactivate it.
- You are not required to call VFPSupport_DestroyContext in order to destroy the context, but if you do not use VFPSupport_DestroyContext you must make sure the context is inactive before reusing the memory.
Also note that if R2 is supplied, some error checks are skipped; it is assumed that the values of R0 and R1 were previously OK’d by VFPSupport_CheckContext.
When the context is created, the FPSCR is initialised to the value given in R3, and FPSCR is cleared to zero. The actual floating point registers are undefined.
See also
Social
and
ROOL Store
Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.