32 bit operation

A lot of this information is taken from the ARM assembler manual. I didn't have a 32 bit processor at the time, so trusted the documentation...
As it happens, the documentation erroneously stated that UMUL and UMLA could only be performed in 32bit mode. Well, that is incorrect, if your processor can do it (ie: StrongARM), it will work in 32bit OR 26bit...

The ARM2 and ARM3 have a 32 bit data bus and a 26 bit address bus. On later versions of the ARM, both the data bus and the address bus are a full 32 bits wide.
This explains how a "32 bit processor" can be referred to as 26 bit. The data width and instruction/word size is 32 bit, and always has been, but the address bus is only 24 bit.
Oh, whoops, I said 26 bit, didn't I?
:-) Well, as PC is always word aligned, the lower two bits will always be zero in an address, so on the ARM2/ARM3 processor these bits hold the processor mode setting. The width of PC is, effectively, 26 bit even though only 24 bits are actually used.

This is no a problem on the older machines. 4Mb memory was the norm. Some people upgraded to 8Mb, and 16Mb was the theoretical limit.
However a RiscPC with a 26 bit program counter would not have been possible, as 26 bits only allows you to address %11111111111111111111111100 (or 67108860 bytes, or 64Mb). The RiscPC allows for 258Mb of memory to be installed.
This, incidentally, explains the 28Mb size limit for application tasks; the system is expected to be compatible with the older RISC OS API.

The majority of the assembler site has been written regarding 26 bit mode of operation, which is compatible with the versions of RISC OS currently available (ie, RISC OS 2 to RISC OS 4); though some parts cover 32 bit modes (one example briefly runs in SVC32!), and I have noted parts of the examples that are 32 bit unfriendly.

Those with a RiscPC, Mico, RiscStation, A7000 etc have the ability to run a fully 32 bit operating system; indeed ARMLinux is such an operating system. RISC OS is not, because RISC OS needs, for the moment, to remain compatible with existing versions. It is the old dichotomy. It is wonderful to have a nice shiny new fully 32 bit version of RISC OS, but not so good when you realise a lot of your must-have software won't so much as load!
RISC OS isn't totally 26 bit. Some of the handlers need to work in 32 bit mode; however it is limited by money (ie, who's going to pay for RISC OS to be fully converted; and who's going to pay for new development tools to rebuild their code (PD software is strong on RISC OS)) and also by necessity (ie, lots of people use Impression but CC is no longer with us; it is quite likely Impression won't work on an updated RISC OS, so people will not see a necessity to upgrade if their desired software won't work).

Why is this even an issue?
Newer ARM processors will not support 26 bit operation. Several hybrids were made (ARM6, ARM7, StrongARM), but time has come to draw the line. You can either add the complexity of a 26/32 bit system, or you can go 32 bit only and have a simpler, smaller processor.
Either we go with the flow, or get left behind... So really, this is an issue, and we don't have a choice.

32 bit architecture

The ARM architecture changed significantly with the introduction of the ARM6 series. Below, we shall describe the differences in behaviour between 26 bit and 32 bit operation.

In the ARM 6, the program counter was extended to a full 32 bits. As a result:

The PSR had to be separated from the PC into its own register, the CPSR (Current Program Status Register).
The PSR can no longer be saved with the PC when changing processor modes;
instead, each privileged mode now has an extra register - the SPSR (Saved Program Status Register) - to hold the previous mode's PSR.
Instructions have been added to use these new status registers.

A further change was the addition of extra privileged processor modes, allowed by the PSR now having a full 32 bits to use. These modes are used to handle Undefined instruction and Abort exceptions. Consequently:

Undefined instructions, aborts, and supervisor code no longer have to share the same mode. This has removed restrictions on Supervisor mode programs which existed on earlier ARMs.
The availability of these features in the ARM6 series (and other later compatible chips) is set by one of several on-chip control registers. One of three processor configurations can be selected:
- 26 bit program and data space. This configuration forces ARM to operate with a 26 bit address space. In this configuration only the four 26 bit modes are available (refer to the Processor modes description); it is impossible to select a 32 bit mode.
  This configuration is set at reset on all current ARM6 and 7 series processors.
- 26 bit program space and 32 bit data space. This is the same as the 26 bit program and data space configuration, except that address exceptions are disabled to allow data transfer operations to access the full 32 bit address space.
- 32 bit program and data space. This configuration extends the address space to 32 bits, and introduces major changes to the programmer's model. In this configuration you can select any of the 26 bit and the 32 bit processor modes (see Processor modes below).

When configured for a 32 bit program and data space, the ARM6 and ARM7 series support ten overlapping processor modes of operation:

User mode: the normal program execution state
or User26 mode: a 26 bit version
FIQ mode: designed to support a data transfer or channel process
or FIQ26 mode: a 26 bit version
IRQ mode: used for general purpose interrupt handling
or IRQ26 mode: a 26 bit version
SVC mode: a protected mode for the operating system
or SVC26 mode: a 26 bit version
Abort mode (abbreviated to ABT mode): entered after a data or instruction prefetch abort
Undefined mode (abbreviated to UND mode): entered when an undefined instruction is executed.

When in a 26 bit processor mode, the programmer's model reverts to that of earlier 26 bit ARM processors. The behaviour is the same as that of the ARM2aS macrocell with the following alterations:

Address exceptions are only generated by ARM when it is configured for 26 bit program and data space.
In other configurations the OS may still simulate the behaviour of address exception, using external logic such as a memory management unit to generate an abort if the 64Mbyte range is exceeded, and converting that abort into an `address exception trap' for the application.
The new instructions to transfer data between general registers and the program status registers remain operative. The new instructions can be used by the operating system to return to a 32 bit mode after calling a binary containing code written for a 26 bit ARM.
When in a 32 bit program and data space configuration, all exceptions (including Undefined Instruction and Software Interrupt) return the processor to a 32 bit mode, so the operating system must be modified to handle them.
If the processor attempts to write to a location between &0 and &1F inclusive (i.e. the exception vectors), hardware prevents the write operation and generates a data abort. This allows the operating system to intercept all changes to the exception vectors and redirect the vector to some veneer code. The veneer code should place the processor in a 26 bit mode before calling the 26 bit exception handler.

In all other respects, when operating in a 26 bit mode the ARM behaves as like a 26 bit ARM. The relevant bits of the CPSR appear to be incorporated back into R15 to form the PC/PSR with the I and F bits in bits 27 and 26. The instruction set behaves like that of the ARM2aS macrocell, with the addition of the MRS and MSR instructions.

The registers available on the ARM 6 (and later) in 32 bit mode are:


User26   SVC26    IRQ26    FIQ26      User     SVC      IRQ      ABT      UND      FIQ

R0 ----- R0 ----- R0 ----- R0 --   -- R0 ----- R0 ----- R0 ----- R0 ----- R0 ----- R1
R1 ----- R1 ----- R1 ----- R1 --   -- R1 ----- R1 ----- R1 ----- R1 ----- R1 ----- R2
R2 ----- R2 ----- R2 ----- R2 --   -- R2 ----- R2 ----- R2 ----- R2 ----- R2 ----- R2
R3 ----- R3 ----- R3 ----- R3 --   -- R3 ----- R3 ----- R3 ----- R3 ----- R3 ----- R3
R4 ----- R4 ----- R4 ----- R4 --   -- R4 ----- R4 ----- R4 ----- R4 ----- R4 ----- R4
R5 ----- R5 ----- R5 ----- R5 --   -- R5 ----- R5 ----- R5 ----- R5 ----- R5 ----- R5
R6 ----- R6 ----- R6 ----- R6 --   -- R6 ----- R6 ----- R6 ----- R6 ----- R6 ----- R6
R7 ----- R7 ----- R7 ----- R7 --   -- R7 ----- R7 ----- R7 ----- R7 ----- R7 ----- R7
R8 ----- R8 ----- R8       R8_fiq     R8 ----- R8 ----- R8 ----- R8 ----- R8       R8_fiq
R9 ----- R9 ----- R9       R9_fiq     R9 ----- R9 ----- R9 ----- R9 ----- R9       R9_fiq
R10 ---- R10 ---- R10      R10_fiq    R10 ---- R10 ---- R10 ---- R10 ---- R10      R10_fiq
R11 ---- R11 ---- R11      R11_fiq    R11 ---- R11 ---- R11 ---- R11 ---- R11      R11_fiq
R12 ---- R12 ---- R12      R12_fiq    R12 ---- R12 ---- R12 ---- R12 ---- R12      R12_fiq
R13      R13_svc  R13_irq  R13_fiq    R13      R13_svc  R13_irq  R13_abt  R13_und  R13_fiq
R14      R14_svc  R14_irq  R14_fiq    R14      R14_svc  R14_irq  R14_abt  R14_und  R14_fiq
--------- R15 (PC / PSR) ---------    --------------------- R15 (PC) ---------------------
                                      ----------------------- CPSR -----------------------
                                               SPSR_svc SPSR_irq SPSR_abt SPSR_und SPSR_fiq

In short, the 32 bit differences are:

The PC is a full 32 bits wide, and used singularly as a Program Counter.
The PSR is contained within its own register, the CPSR.
Each privileged mode has a private SPSR register in which to save the CPSR.
There are two new privileged modes, each of which has private copies of R13 and R14.

The CPSR and SPSR registers

The allocation of the bits within the CPSR (and the SPSR registers to which it is saved) is:

  31 30 29 28  ---   7   6   -   4   3   2   1   0
  N  Z  C  V         I   F       M4  M3  M2  M1  M0

                                 0   0   0   0   0     User26 mode
                                 0   0   0   0   1     FIQ26 mode
                                 0   0   0   1   0     IRQ26 mode
                                 0   0   0   1   1     SVC26 mode
                                 1   0   0   0   0     User mode
                                 1   0   0   0   1     FIQ mode
                                 1   0   0   1   0     IRQ mode
                                 1   0   0   1   1     SVC mode
                                 1   0   1   1   1     ABT mode
                                 1   1   0   1   1     UND mode

Please refer to the (26 bit) PSR for information on the N, Z, C, V flags and the I and F interrupt flags.

So what does it mean in practice?

Most ARM code will work correctly. The only things that will not work are any operations which fiddle with R15 to set the processor status. Unfortunately, this isn't as easy to fix as it seems.
I examined a 9K program (a MODE 7 teletext frame viewer, written in C) for potential problems, basically looking for:

A MOVS with R15 as the destination.
Any LDMFD suffixed with the '^' character and loading R15.

About 64 instructions fell into one of these categories.

There is likely to be few ways to make the conversion process automatic. Basically...

How will the system know what is data, and what is code.
Actually, a clever rules-based program should be able to make a fairly good guess, but is a "fairly good guess" good enough?
There is NO simple instruction replacement. An automatic system probably could patch in the required instructions and jiggle the code around, but this could cause unexpected side effects, like an ADR directive no longer being in range.
It is incredibly hacky. Surely, much better to recompile, or to repair the source code.

It is NOT easy. Such a small change, but with such far-reaching consequences.

In comp.sys.acorn.programmer, Stewart Brodie answered my query with a hint that may be useful to people intending to work with 32 bit code:

> How is it possible, if 32 bit code uses MSR/MRS to transfer status and
> register, and older ARMs don't have those instructions?
> Are we into "black magic" code for this?

You take advantage of the fact that the encodings for MSR and MRS act as NOPs
on ARM2 and ARM3 ;-)  With some careful arrangement, you can write fairly
tight code.

To refer back to earlier postings, an example of when MOVS pc, lr in a
32-bit mode is useful (entered in SVC or IRQ mode, IRQs disabled):

        ADR     r14, CallBackRegs
        TEQ     PC,PC
        LDREQ   r0, [r14, #16*4]    ; The CPSR
        MSREQ   SPSR_cxsf, r0       ; put into SPSR_svc/SPSR_irq ready for MOVS
        LDMIA   r14, {r0-r14}^      ; Restore user registers
        NOP
        LDR     r14, [r14, #15*4]   ; The pc
        MOVS    pc, r14             ; Back we go (32-bit safe - SPSR set up)

(CallBackRegs contains user mode registers: R0-R15, plus the CPSR if in a
32-bit mode)

Download a 32 bit code scanner (12K)

Where is the example?

In the logical place, in the document describing the processor status register...

Return to assembler index