Showing changes from revision #3 to #4:
Added | Removed | Changed
Entry | |
---|---|
R0 | Context to examine |
R1 | Flags: |
Bit 0: Serialise context | |
Other bits reserved, should be zero |
Exit | |
---|---|
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 29: Context is awaiting lazy activation (0=no, 1=yes) | |
Bit 30: Context status registers are active (0=no, 1=yes) | |
Bit 31: Memory allocation method (0=user allocated, 1=VFPSupport allocated) | |
R1 | Number of doubleword registers (may be greater than number requested upon context creation) |
R2 | Register status bitmask |
R3 | Pointer to dump format descriptor block |
R4 | Context size |
All other registers preserved |
This call is used to examine the state of a VFP context, for example to access the registers without activating the context itself.
If the context being examined is currently active (or scheduled for lazy deactivation) then some of the registers in the save area may be out of date. To avoid this, set bit 1 of R0 to request that the context state is serialised.
On exit, R0 bits 0-1 correspond to the flags passed to VFPSupport_CreateContext, and R1 corresponds to the number of registers stored by the context (which may be larger than the requested number in some situations). The contents of R2 and bit 30 of R0 can be used to detect which registers have been saved to the context and which are currently active (and thus indicate that the saved value may be out of date).
R2 is a bitmask representing the status of each doubleword register. If bit ‘n’ is set then register Dn is active, otherwise it is saved.
R3 is a pointer to a dump format descriptor block, which describes the internal structure of the context area. By parsing the descriptor block you can manually read or modify the register state. The descriptor block is a sequence of words terminated by the value -1. For each word, the lower 16 bits indicate the field within the context, and the upper 16 bits give the offset (in bytes) of the field value within the area. The content of the descriptor block may change from system to system, or even depending on the current state of the context.
Defined field IDs are:
# | Description |
---|---|
0 | Provides the offset to the FPSCR register |
1 | Provides the offset to the FPEXC register |
2 | Provides the offset to the FPINST register |
3 | Provides the offset to the FPINST2 register |
4 | Provides the offset to the FSTMX format word |
5 | Provides the offset to the start of the register dump |
Items 0-4 are all one word in length. Item 5, the reigster register dump, has its length defined by the number of doubleword registers in the context (R1). All items will be at a word aligned offset into the context.
If item 4 is present then it indicates that the register dump is in a VFP implementation-defined format. Otherwise the register dump is in standard format, i.e. a direct representation of the register contents, depending on how the context was being used. For VFP this will most likely be a series of single or double precision floating point values, whereas for NEON it might be integer, floating point, or any arbitrary data.
Note that a context which has FPEXC.EN (bit 30) clear will not have its data registers restored when it is next activated (only the special registers will be restored). VFPSupport creates contexts in this state in order to avoid pointlessly loading the registers with uninitialised data when the context is first activated. Therefore software which wishes to create an inactive context and then write to the data register dump will have to be careful to set FPEXC.EN to 1 otherwise the values will not be used when the context is activated.