Converting older software to run on 32 bit systems (changes)

Issues affecting all software

Due to the changes between older systems and modern ones, there are a number of issues that may affect your program:

• If your program relies upon external resources (sound player modules, for example) then you will need to track down 32 bit safe versions. RISC OS 5 will not load modules written for older versions of RISC OS.
• There are huge differences in display hardware. Generally speaking, 2, 4, and 16 colour modes are no longer available. For example, selecting MODE 2 on a RaspberryPi actually selects MODE 28 which is quite different. You may need to check that the colours you expected to set are, in fact, being set. The SWI ColourTrans_SetGCOL may help.
• Do not assume the presence of ADFS, or floppy discs.
• Anything that attempts to poke hardware by reading/writing specific addresses is pretty much guaranteed to fail. If your program bashes the IOC for access to the high resolution timer… that does not exist any more. To add insult to injury, the different SoCs implement such a thing in different ways. In some cases workarounds are available – Rik Griffin’s HalTimer provides access to the high resolution timer.
• Do not attempt to directly access page zero (addresses below &8000).
• Likewise, do not expect specific legacy hardware to exist. There are no floppies or harddiscs (any that are connected do so via USB). There is no parallel port. Serial ports generally exist in some manner, though typically only RxD and TxD are connected. DCD, CTS, etc are not.
• Some SWIs have had their entry parameters tightened up for issues arising as a result of having a greater addressing range. Some SWIs (OS_UpdateMEMC) are just obsolete on modern hardware.
  Additionally, while the PRMs stated that SWIs accept ‘0’ as a null pointer, in many cases (the Wimp, especially) a negative value would be treated as a null pointer. This is no longer the case, and a zero should be used as per the documentation. <!-- Link to document detailing changes to SWIs when it exists... -->
• Some SWIs have been obsoleted by newer versions. For instance, OS_IICOp replacing IIC_Control; and any of the filesystem DiscOp calls being replaced by DiscOp64 versions to overcome limitations in disc size and memory locations in the original SWI.
• When dealing with pointers and addresses, you should no longer validate a pointer by checking to see if the value is positive, nor perform signed comparisons on them.
  You should no longer clear the &FC000003 bits from pointers or stuff flags into the high-order bits. Assume that the entire 32 bit value is now a valid address.
  

The first thing you must do is to pick up a copy of The ARM Club’s ARMalyser. This tool is invaluable in helping to detect parts of code that need changing.

Continue reading…

ARM code in a 32 bit world

Instructions to be avoided

The first main problem, and the complete show-stopper, is that the Processor Status Register (PSR) and the Program Counter (PC) are no longer combined. As a result of this, anything that tries to manipulate the PSR by performing operations on PC will fail. An example is returning from an instruction with the V set using ORRS PC, LR, #(1 << 28).

You should note that the following instructions will no longer work as expected:

• MOVS PC
• TEQP
• LDM ^
• TST xx, PC
• Anything that tries to set bits in PC (such as the ORRS above)

The second problem that affects modern processors is the behaviour of unaligned loads – that is to say, executing an LDR instruction on an address that is not word aligned.
This issue has always been contentious, and it can be roughly summarised as follows:

• Old ARMs (Archimedes, RiscPC, Iyonix, emulators):
  • LDM, STM, and STR would ignore bits 0 and 1 and access a word aligned address
  • LDR would load from a word aligned address and rotate in a complex manner
• ARMv6 (RaspberryPi):
  • Has an option to configure the old behaviour described above, or the new behaviour described below, or to just abort.
• ARMv7+ (Beagle, Panda, etc):
  • Can be configured to abort on all unaligned word accesses, otherwise:
  • LDM and STM will always abort.
  • LDR and STR will perform sequential memory accesses to read or write a word at a non-aligned address

The ARMv7 compatibility primer describes the behaviour of non-aligned loads and stores in more detail.

It is worth mentioning that if you are using LDR to read data byte by byte, you should be using LDRB instead.

Detecting 32 bit mode

The legitimate way of detecting a 32 bit system is to called the SWI OS_PlatformFeatures, which will return various flags that indicate the features of the current system. You are particularly interested in bit 6 which means that it is a 32 bit version of RISC OS, and bit 7 which means the processor does not support the older 26 bit mode.

In assembler, the following code can be used to detect a 32 bit mode:

    TEQ R0, R0    ; Set Z flag
    TEQ PC, PC    ; Set Z flag if in 32 bit mode

This works because the second operand to TEQ will include the flags in 26-bit mode, but not in 32-bit mode, whereas the first operand never includes the flags. We are therefore comparing PC with PC+PSR if in 26-bit mode, but comparing PC with PC in 32-bit mode. This will set Z in 32-bit mode but not in 26-bit mode since we know at least one bit (the Z flag) is set in the PSR. Note that the first instruction can be omitted if a flag is known to be set (eg the V flag) or if not in user mode (since one of the mode flag bits will be set).

If in SVC mode (a relocatable module), you could also use the instruction:

    CMP PC, PC

This replies EQual on a 32 bit system, and NotEqual on a 26 bit system, for the same reasons as above (comparing PC with PC+PSR and a mode bit is set; so will differ on a 26 bit system, but will be identical on a 32 bit system as the mode bit is stored elsewhere).

Work in progress – more to come.