Register Load and Store

These are, arguably, the most useful instructions available. It is all very well being able to do stuff with the registers, but if you cannot load and store them to the main memory, then... <grin>

Single Data Transfer

First, we'll look at the instruction:

  LDR    R0, address
  STR    R0, address
  LDRB   R0, address
  STRB   R0, address

The address can be a simple value, or an offset, or a shifted offset. Write-back may be performed (to remove the need for adding/subtracting).

   STR    R0, [Rbase]          Store R0 at Rbase.

   STR    R0, [Rbase, Rindex]  Store R0 at Rbase + Rindex.

   STR    R0, [Rbase, #index]  Store R0 at Rbase + index.
                               Index is an immediate value.
                               STR R0, [R1, #16] would load R0
                               from R1+16.

   STR    R0, [Rbase, Rindex]! Store R0 at Rbase + Rindex, &
                               write back new address to Rbase.

   STR    R0, [Rbase, #index]! Store R0 at Rbase + index, &
                               write back new address to Rbase.

   STR    R0, [Rbase], Rindex  Store R0 at Rbase, & write back
                               Rbase + Rindex to Rbase.

   STR    R0, [Rbase, Rindex, LSL #2] will store R0 at the address
                               Rbase + (Rindex * 4)

   STR    R0, place            Will generate a PC-relative offset
                               to 'place', and store R0 there.

If you specify pre-indexed addressing (where the base and index are both within square brackets), the write-back is controlled by the presence or absence of the '!'. The fourth and fifth examples above reflect this. Using this, you can automatically move forward or backward in memory. A string print routine could then become:

  .loop
    LDRB   R0, [R1, #1]!
    SWI    "OS_WriteC"
    CMP    R0, #0
    BNE    loop

  .loop
    LDRB   R0, [R1]
    SWI    "OS_WriteC"
    ADD    R1, R1, #1
    CMP    R0, #0
    BNE    loop

The use of '!' is invalid for post-indexed addressing (where the index is outside of the square brackets, as in example six above) as write-back is implied.

As you can see, the offset may be shifted. Additionally, the index offset may be subtracted from the base. In this case, you might use code such as:

  LDRB   R0, [R1, #-1]

You cannot modify the PSR with a load or store instruction, though you can store or load the PC. In order to load a stored 'state' and correctly restore it, use:

  LDR    R0, [Rbase]
  MOVS   R15, R0

According to the ARM assembler manual:
A byte load (LDRB) expects the data on bits 0 to 7 if the supplied address is on a word boundary, on bits 8 to 15 if it is a word address plus one byte, and so on. The selected byte is placed in the bottom 8 bits of the destination register, and the remaining bits of the register are filled with zeroes.
A byte store (STRB) repeats the bottom 8 bits of the source register four times across the data bus. The external memory system should activate the appropriate byte subsystem to store the data.
A word load (LDR) or word store (STR) should generate a word aligned address. Using a non-word-aligned addresses has non-obvious and unspecified results.

The only thing of real note here is that you cannot use LDR to load a word from a non-aligned address.

Multiple Data Transfer

The main use of LDM/STM is to dump registers that need to be preserved onto the stack. We've all seen STMFD R13!, {R0-R12, R14}.

The instruction is:

  xxM type cond   base write-back, {register list}

'xx' is LD to load, or ST to store.

'type' is:

  Stack     Other
  LDMED     LDMIB     Pre-incremental load
  LDMFD     LDMIA     Post-incremental load
  LDMEA     LDMDB     Pre-decremental load
  LDMFA     LDMDA     Post-decremental load 

  STMFA     STMIB     Pre-incremental store
  STMEA     STMIA     Post-incremental store
  STMFD     STMDB     Pre-decremental store
  STMED     STMDA     Post-decremental store

FD, ED, FA, and EA refer to a Full or Empty stack which is either Ascending or Descending.
A full stack is where the stack pointer points to the last data item written, and empty stack is where the stack pointer points to the first free slot.
A descending stack grows downwards in memory (ie, from the end of application space down) and an ascending stack is one which grows upwards in memory.

The other forms simply describe the behaviour of the instruction, and mean Increment After, Increment Before, Decrement After, Decrement Before.

RISC OS, by tradition, uses a Fully Descending stack. When writing in APCS assembler, it is common to set your stack pointer to the end of application space and then use a Full Descending stack. If you are working with a high level language (either BASIC or C), then you don't get a choice. The stack pointer (traditionally R13) points to the end of a fully descending stack. You must continue this format, or create and manage your own stack (if you're the sort of die-hard person that would do something like this!).

'base' is the register containing the address to begin with. Traditionally under RISC OS, the stack pointer is R13, though you can use any available register except R15.

If you would like the stack pointer to be updated with the new register contents, simply set the write-back bit by following the stack pointer register with an '!'.

The register list is given in {curly brackets}. It doesn't matter what order you specify the registers in, they are stored from lowest to highest. As a single bit determines whether or not a register is saved, there is no point to trying to specify it twice.
A side effect of this is that code such as:

  STMFD  R13!, {R0, R1}
  LDMFD  R13!, {R1, R0}

When R15 is stored to memory, the PSR bits are also saved. When R15 is reloaded, the PSR bits are NOT restored unless you request it. The method of requesting is to follow the register list with a '^'.

  STMFD  R13!, {R0-R12, R14}
  ...
  LDMFD  R13!, {R0-R12, PC}

  STMFD  R13!, {R0-R12, R14}
  ...
  LDMFD  R13!, {R0-R12, PC}^

Note that in both examples, R14 is loaded directly into PC. This saves the need to MOV(S) R14 into R15.
Warning: Using MOVS PC, ... is not 32 bit compliant. You need to use MRS and MSR to handle the PSR.