Introduction to the StrongARM Revision 3, 04-Oct-96
Guidelines
* Code written in C or BASIC will generally work, but see issues below.
* Code using the shared C library or Toolbox is generally fine. Using RISCOS_Lib may cause problems, depending on the variant - re-linking to a revised implementation will typically be sufficient. Anything linked with ANSILib will not work. Products should _not_ be linked with ANSILib.
* Proprietary code squeezers may cause problems. Unsqueezed code or standard squeezed code with AIF headers (eg code produced with our Squeeze system) is generally fine. A new module, UnsqueezeAIF, detects squeezed images and unsqueezes them itself with a negligible performance penalty.
* An application patcher will be supplied with RISC OS 3.7 that is capable of detecting some known StrongARM-incompatible code sequences in an AIF image and replacing them before the image is executed. This is only a temporary solution though. If you find your software works only because the patcher is patching it, you should modify it so it does not need patching.
* All Absolute files must have valid AIF headers. Absolute files without AIF headers and untyped files are deprecated.
When writing in Assembler:
* Any self-modifying code or dynamically generated code is a problem. RISC OS 3.7 provides a SWI to support StrongARM synchronisation to dynamic code, but the performance penalty is typically severe; cleaning the data cache will take some time, and the entire instruction cache must be flushed. Hence, most cases of dynamic code can no longer be justified, and should be reimplemented in a static manner. One common reason for dynamic code is the calling of a SWI by SWI code passed in a register. RISC OS 3.7 provides a new SWI which implements this in an entirely static manner.
* The StrongARM pipeline is generally not a problem (even though it is now 5 levels deep rather than 3). The main issue is storing of the PC to memory using STR and STM; this now stores PC+8 instead of PC+12. Code should be made to work whether PC+8 or PC+12 is stored (so that ARM 6,7 are still supported). Use of the PC in data processing instructions (MOV, ADD etc) remains unaltered on StrongARM.
* STRB PC has an undefined result. This has sometimes been used as a shortcut for storing a non-zero semaphore value in speed critical code. This instruction should no longer be used. Use STR PC or STRB of some other register.
Other differences at the assembler level, which affect RISC OS itself but are unlikely to affect applications are:
* StrongARM does not support 26 bit configuration. It does support 26 bit mode within a 32 bit configuration.
* The control of architecture functions via coprocessor #15 is significantly different. The requirements for context switching are significantly more complex.
* The 'abort timing' (definition of values in affected registers) for data aborts has changed.
At the hardware level:
* When storing a byte, previous ARMs replicate the byte across the entire 32 bit data bus. StrongARM only outputs the byte on the relevant byte lane. The StrongARM processor card implements a compatibility fix for pre-Risc PC style podules as follows: bytes stored to word aligned addresses (byte 0) will be replicated on byte 2. This should allow most podules to work without firmware changes.
Backwards compatibility:
* Much StrongARM-ready code (especially in libraries, such as the aforementioned revised RISC_OSLib) may use the new SWI-calling mechanism. Therefore a new module "CallASWI" will be made available for use on RISC OS 3.1, 3.5 and 3.6 to provide the SWIs OS_CallASWI, OS_CallASWIR12, OS_PlatformFeatures and OS_SynchroniseCodeAreas.