* 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.
