OS_PlatformFeatures 0 Flags (Rev #7, changes)
Showing changes from revision #6 to #7:
Added | Removed | Changed
Programmer's Reference Manuals
» Part 15 – SWI Calls
» OS
» OS_PlatformFeatures
» OS_PlatformFeatures 0
» Flags
Flags
| Bit | Meaning when set |
|---|---|
| 0 | You must tell the OS when a code area changes (OS_SynchroniseCodeAreas) |
| 1 | Enabling then disabling interrupts does not allow them a chance to occur (Use interrupt trigger routine returned in R1) |
| 2 | Hardware vectors are only readable in 32 bit mode |
| 3 | When storing PC, PC+8 is stored (not PC+12) |
| 4 | Data aborts occur with ‘full early’ timing (Base restored abort model) |
| 5 | CPU has split instruction & data caches |
| 6 | OS is 32-bit |
| 7 | CPU doesn’t support 26-bit modes |
| 8 | CPU has ‘M’ extensions (long multiply – UMULL, etc.) |
| 9 | CPU supports Thumb mode |
| 10 | CPU has ‘E’ DSP extensions (QADD, etc.) |
| 11 | 1 → SWP/SWPB are not available |
| 0 → SWP/SWPB might be available (see notes) | |
| 12 | CPU supports LDR/STREX semaphores |
| 13 | CPU supports CLREX and LDR/STREX[B|H|D] semaphores |
| 14 | Reserved |
| 15 | CPU supports extended small page L2 descriptors |
| 16 | CPU doesn’t have a Drain Write Buffer instruction |
| 17 | Aborts don’t correctly follow the documented abort model (e.g. StrongARM pre rev-T; prevents lazy task swapping from being used) |
| 18 | CPU is an XScale |
| 19 | XScale JTAG is connected |
| 20 | High processor vectors are in use (vectors at &FFFF0000 instead of &0). See also OS_PlatformFeatures 32 |
| 21-31 | Reserved |
SWP/SWPB availability
If bit 11 is one, it indicates that SWP/SWPB definitely aren’t available (and LDREX/STREX will generally be available instead). However if bit 11 is zero (or if OS_PlatformFeatures 0 isn’t implemented) there’s no guarantee that SWP/SWPB are available. This is because bit 11 is a recent addition to the flags, which old implementations of OS_PlatformFeatures (such as those provided by the CallASWI module) are not aware of. So an ARM2 machine running CallASWI will generally return from OS_PlatformFeatures 0 with bit 11 clear, even though SWP/SWPB aren’t actually available.
If your code isn’t concerned with ARM2 compatibility, it can simply take bit 11==0 as an indication that SWP/SWPB are available.
If your code is concerned with ARM2 compatibility, it will have to perform a manual check for SWP/SWPB availability whenever bit 11 is zero. For example, you could temporarily install a special error handler and then try to execute a dummy SWP instruction, and check to see if the error handler is invoked. If your code is also 32bit compatible then it could skip this check if bit 6 is set (and assume that SWP/SWPB are available) – any 32bit OS which doesn’t provide SWP/SWPB can be relied upon to correctly indicate this fact by setting bit 11 to 1.
See also
Social
and
ROOL Store
Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.