Tài liệu ARM Architecture Reference Manual- P2 docx

Introduction to the ARM Architecture

1.2.6

Exception-generating instructions
Two types of instruction are designed to cause specific exceptions to occur.
Software interrupt instructions
SWI instructions cause a software interrupt exception to occur. These are normally used to
make calls to an operating system, to request an OS-defined service. The exception entry
caused by a SWI instruction also changes to a privileged processor mode. This allows an
unprivileged task to gain access to privileged functions, but only in ways permitted by the
OS.
Software breakpoint instructions
BKPT instructions cause an abort exception to occur. If suitable debugger software is
installed on the abort vector, an abort exception generated in this fashion is treated as a
breakpoint. If debug hardware is present in the system, it can instead treat a BKPT
instruction directly as a breakpoint, preventing the abort exception from occurring.
In addition to the above, the following types of instruction cause an Undefined Instruction exception to
occur:
•
coprocessor instructions which are not recognized by any hardware coprocessor
•
most instruction words that have not yet been allocated a meaning as an ARM instruction.
In each case, this exception is normally used either to generate a suitable error or to initiate software
emulation of the instruction.

ARM DDI 0100E

Copyright © 1996-2000 ARM Limited. All rights reserved.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

A1-9


Introduction to the ARM Architecture

A1-10

Copyright © 1996-2000 ARM Limited. All rights reserved.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

ARM DDI 0100E


Chapter A2
Programmer’s Model

This chapter introduces the ARM programmer’s model. It contains the following sections:
•
Data types on page A2-2
•
Processor modes on page A2-3
•
Registers on page A2-4
•
General-purpose registers on page A2-5
•
Program status registers on page A2-9
•

Exceptions on page A2-13
•
Memory and memory-mapped I/O on page A2-22.

ARM DDI 0100E

Copyright © 1996-2000 ARM Limited. All rights reserved.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

A2-1


Programmer’s Model

2.1

Data types
ARM processors support the following data types:
Byte

8 bits.

Halfword

16 bits (halfwords must be aligned to two-byte boundaries).

Word

32 bits (words must be aligned to four-byte boundaries).

Note
•
•

All three types are supported in ARM architecture version 4 and above. Only bytes and words were
supported prior to ARM architecture version 4.
When any of these types is described as unsigned, the N-bit data value represents a non-negative
integer in the range 0 to +2N-1, using normal binary format.

•

When any of these types is described as signed, the N-bit data value represents an integer in the range
-2N-1 to +2N-1-1, using two's complement format.

•
•

Load and store operations can transfer bytes, halfwords and words to and from memory,
automatically zero-extending or sign-extending bytes or halfwords as they are loaded.

•

A2-2

All data operations, for example ADD, are performed on word quantities.

ARM instructions are exactly one word (and are aligned on a four-byte boundary). Thumb
instructions are exactly one halfword (and are aligned on a two-byte boundary).

Copyright © 1996-2000 ARM Limited. All rights reserved.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

ARM DDI 0100E


Programmer’s Model

2.2

Processor modes
The ARM architecture supports the seven processor modes shown in Table 2-1.
Table 2-1 ARM version 4 processor modes
Processor mode

Description

User

usr

Normal program execution mode

FIQ

fiq

Supports a high-speed data transfer or channel process

IRQ

irq

Used for general-purpose interrupt handling

Supervisor

svc

A protected mode for the operating system

Abort

abt

Implements virtual memory and/or memory protection

Undefined

und

Supports software emulation of hardware coprocessors

System

sys

Runs privileged operating system tasks (ARM architecture version 4 and above)

Mode changes can be made under software control, or can be caused by external interrupts or exception
processing.
Most application programs execute in User mode. While the processor is in User mode, the program being
executed is unable to access some protected system resources or to change mode, other than by causing an
exception to occur (see Exceptions on page A2-13). This allows a suitably written operating system to
control the use of system resources.
The modes other than User mode are known as privileged modes. They have full access to system resources
and can change mode freely. Five of them are known as exception modes:
•
FIQ
•
IRQ
•
Supervisor
•
Abort
•
Undefined.
These are entered when specific exceptions occur. Each of them has some additional registers to avoid
corrupting User mode state when the exception occurs (see Registers on page A2-4 for details).
The remaining mode is System mode, and is only present in ARM architecture version 4 and above. It is not
entered by any exception and has exactly the same registers available as User mode. However, it is a
privileged mode and is therefore not subject to the User mode restrictions. It is intended for use by operating
system tasks which need access to system resources, but wish to avoid using the additional registers
associated with the exception modes. Avoiding such use ensures that the task state is not corrupted by the
occurrence of any exception.

ARM DDI 0100E

Copyright © 1996-2000 ARM Limited. All rights reserved.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

A2-3


Programmer’s Model

2.3

Registers
The ARM processor has a total of 37 registers:
•
31 general-purpose registers, including a program counter. These registers are 32 bits wide and are
described in General-purpose registers on page A2-5.
•
6 status registers. These registers are also 32 bits wide, but only 12 of the 32 bits are allocated or need
to be implemented. These are described in Program status registers on page A2-9.
Registers are arranged in partially overlapping banks, with a different register bank for each processor
mode, as shown in Figure 2-1. At any time, 15 general-purpose registers (R0 to R14), one or two status
registers and the program counter are visible. Each column of Figure 2-1 shows which general-purpose and
status registers are visible in the indicated processor mode.

Modes
Privileged modes
Exception modes
User

System

Supervisor

Abort

Undefined

R0

R0

R0

R0

R0

R0

R0

R1

R1

R1

R1

R1

R1

R1

R2

R2

R2

R2

R2

R2

R2

R3

R3

R3

R3

R3

R3

R3

R4

R4

R4

R4

R4

R4

R4

R5

R5

R5

R5

R5

R5

R5

R6

R6

R6

R6

R6

R6

R6

R7

R7

R7

R7

R7

R7

R7

R8

R8

R8

R8

R8

R8

R8_fiq

R9

R9

R9

R9

R9

R9

R9_fiq

R10

R10

R10

R10

R10

R10

R10_fiq

R11

R11

R11

R11

R11

R11

R11_fiq

R12

R12

R12

R12

R12

R12

R12_fiq

R13

R13

R13_svc

R13_abt

R13_und

R13_irq

R13_fiq

R14

R14

R14_svc

R14_abt

R14_und

R14_irq

R14_fiq

PC

PC

CPSR

CPSR

PC

PC

CPSR

CPSR

SPSR_svc

SPSR_abt

PC

CPSR
SPSR_und

Interrupt

PC

Fast interrupt

PC

CPSR

CPSR

SPSR_irq

SPSR_fiq

indicates that the normal register used by User or System mode has
been replaced by an alternative register specific to the exception mode

Figure 2-1 Register organization
A2-4

Copyright © 1996-2000 ARM Limited. All rights reserved.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

ARM DDI 0100E

Programmer’s Model

2.4

General-purpose registers
The general-purpose registers R0-R15 can be split into three groups. These groups differ in the way they
are banked and in their special-purpose uses:
•
The unbanked registers, R0-R7
•
The banked registers, R8-R14
•
Register 15, the PC, is described in The program counter, R15 on page A2-7.

2.4.1

The unbanked registers, R0-R7
Registers R0 to R7 are unbanked registers. This means that each of them refers to the same 32-bit physical
register in all processor modes. They are completely general-purpose registers, with no special uses implied
by the architecture, and can be used wherever an instruction allows a general-purpose register to be
specified.

2.4.2

The banked registers, R8-R14
Registers R8 to R14 are banked registers. The physical register referred to by each of them depends on the
current processor mode. Where a particular physical register is intended, without depending on the current
processor mode, a more specific name (as described below) is used. Almost all instructions allow the banked
registers to be used wherever a general-purpose register is allowed.

Note
A few exceptions to this rule are noted in the individual instruction descriptions. Where a restriction exists
on the use of banked registers, it always applies to all of R8 to R14. For example, R8 to R12 are subject to
such restrictions even in systems in which FIQ mode is never used and so only one physical version of the
register is ever in use.
Registers R8 to R12 have two banked physical registers each. One is used in all processor modes other than
FIQ mode, and the other is used in FIQ mode. Where it is necessary to be specific about which version is
being referred to, the first group of physical registers are referred to as R8_usr to R12_usr and the second
group as R8_fiq to R12_fiq.
Registers R8 to R12 do not have any dedicated special purposes in the architecture. However, for interrupts
that are simple enough to be processed using registers R8 to R14 only, the existence of separate FIQ mode
versions of these registers allows very fast interrupt processing. Examples of this usage can be found in
Single-channel DMA transfer on page A9-13 and Dual-channel DMA transfer on page A9-13.
Registers R13 and R14 have six banked physical registers each. One is used in User and System modes,
while each of the remaining five is used in one of the five exception modes. Where it is necessary to be
specific about which version is being referred to, you use names of the form:
R13_<mode>
R14_<mode>
where <mode> is the appropriate one of usr, svc (for Supervisor mode), abt, und, irq and fiq.

ARM DDI 0100E

Copyright © 1996-2000 ARM Limited. All rights reserved.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

A2-5


Programmer’s Model

Register R13 is normally used as a stack pointer and is also known as the SP. In the ARM instruction set,
this is by convention only, as there are no defined instructions or other functionality which use R13 in a
special-case manner. However, there are such instructions in the Thumb instruction set, as described in
Chapter A6 The Thumb Instruction Set.
Each exception mode has its own banked version of R13, which should normally be initialized to point to a
stack dedicated to that exception mode. On entry, the exception handler typically stores to this stack the
values of other registers to be used. By reloading these values into the registers when it returns, the
exception handler can ensure that it does not corrupt the state of the program that was being executed when
the exception occurred.
Register R14 (also known as the Link Register or LR) has two special functions in the architecture:
•

In each mode, the mode's own version of R14 is used to hold subroutine return addresses. When a
subroutine call is performed by a BL or BLX instruction, R14 is set to the subroutine return address.
The subroutine return is performed by copying R14 back to the program counter. This is typically
done in one of the two following ways:
—
Execute either of these instructions:

—

MOV PC,LR
BX LR
On subroutine entry, store R14 to the stack with an instruction of the form:
STMFD SP!,{<registers>,LR}
and use a matching instruction to return:
LDMFD SP!,{<registers>,PC}

•

When an exception occurs, the appropriate exception mode's version of R14 is set to the exception
return address (offset by a small constant for some exceptions). The exception return is performed in
a similar way to a subroutine return, but using slightly different instructions to ensure full restoration
of the state of the program that was being executed when the exception occurred. See Exceptions on
page A2-13 for more details.

Register R14 can be treated as a general-purpose register at all other times.

Note
When nested exceptions are possible, the two special-purpose uses might conflict. For example, if an IRQ
interrupt occurs when a program is being executed in User mode, none of the User mode registers are
necessarily corrupted. But if an interrupt handler running in IRQ mode re-enables IRQ interrupts and a
nested IRQ interrupt occurs, any value the outer interrupt handler is holding in R14_irq at the time is
overwritten by the return address of the nested interrupt.
System programmers need to be careful about such interactions. The usual way to deal with them is to
ensure that the appropriate version of R14 does not hold anything significant at times that nested exceptions
can occur. When this is hard to do in a straightforward way, it is usually best to change to another processor
mode during entry to the exception handler, before re-enabling interrupts or otherwise allowing nested
exceptions to occur. (In ARM architecture version 4 and above, System mode is usually the best mode to
use for this purpose.)

A2-6

Copyright © 1996-2000 ARM Limited. All rights reserved.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

ARM DDI 0100E

Programmer’s Model

2.4.3

The program counter, R15
Register R15 holds the Program Counter (PC). It can often be used in place of one of the general-purpose
registers R0 to R14, and is therefore considered one of the general-purpose registers. However, there are
also many instruction-specific restrictions or special cases about its use. These are noted in the individual
instruction descriptions. Usually, the instruction is UNPREDICTABLE if R15 is used in a manner that breaks
these restrictions.
The Program Counter is always used for a special purpose, as described in:
•
Reading the program counter
•
Writing the program counter on page A2-8.

Reading the program counter
When an instruction reads R15 without breaking any of the restrictions on its use, the value read is the
address of the instruction plus 8 bytes. As ARM instructions are always word-aligned, bits[1:0] of the
resulting value are always zero. (In T variants of the architecture, this behavior changes during Thumb state
execution - see Chapter A6 The Thumb Instruction Set for details.)
This way of reading the PC is primarily used for quick, position-independent addressing of nearby
instructions and data, including position-independent branching within a program.
An exception to the above rule occurs when an STR or STM instruction stores R15. Such instructions can
store either the address of the instruction plus 8 bytes, like other instructions that read R15, or the
instruction's own address plus 12 bytes. Whether the offset of 8 or the offset of 12 is used is
IMPLEMENTATION DEFINED. An implementation must use the same offset for all STR and STM instructions
that store R15. It cannot use 8 for some of them and 12 for others.
Because of this exception, it is usually best to avoid the use of STR and STM instructions that store R15. If

this is difficult, use a suitable instruction sequence in the program to ascertain which offset the
implementation uses. For example, if R0 points to an available word of memory, then the following
instructions put the offset of the implementation in R0:
SUB
STR
LDR
SUB

R1,
PC,
R0,
R0,

PC, #4
[R0]
[R0]
R0, R1

;
;
;
;

R1 = address of following STR instruction
Store address of STR instruction + offset,
then reload it
Calculate the offset as the difference

Note
The rules about how R15 is read apply only to reads by instructions. In particular, they do not necessarily

describe the values placed on a hardware address bus during instruction fetches. Like all other details of
hardware interfaces, such values are IMPLEMENTATION DEFINED.

ARM DDI 0100E

Copyright © 1996-2000 ARM Limited. All rights reserved.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

A2-7


Programmer’s Model

Writing the program counter
When an instruction writes R15 without breaking any of the restrictions on its use, the normal result is that
the value written to R15 is treated as an instruction address and a branch occurs to that address.
Since ARM instructions are required to be word-aligned, values written to R15 are normally expected to
have bits[1:0] == 0b00. The precise rules for this depend on the architecture version:
•

In ARM architecture versions 3 and below, bits[1:0] of a value written to R15 are ignored, so that the
actual destination address of the instruction is (value written to R15) AND 0xFFFFFFFC.

•

In ARM architecture versions 4 and above, bits[1:0] of a value written to R15 in ARM state must be
0b00. If they are not, the results are UNPREDICTABLE.

Similarly, in T variants of ARM architecture versions 4 and above, Thumb instructions are required to be

halfword-aligned. Bit[0] of a value written to R15 in Thumb state is ignored, so that the actual destination
address of the instruction is (value written to R15) AND 0xFFFFFFFE.
Several instructions have their own rules for interpreting values written to R15. For example, BX and other
instructions designed to transfer between ARM and Thumb states use bit[0] of the value to select whether
to execute the code at the destination address in ARM state or Thumb state. Special rules of this type are
described on the individual instruction pages, and override the general rules in this section.

A2-8

Copyright © 1996-2000 ARM Limited. All rights reserved.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

ARM DDI 0100E


Programmer’s Model

2.5

Program status registers
The current program status register (CPSR) is accessible in all processor modes. It contains condition code
flags, interrupt disable bits, the current processor mode, and other status and control information. Each
exception mode also has a saved program status register (SPSR), that is used to preserve the value of the
CPSR when the associated exception occurs.

Note
User mode and System mode do not have an SPSR, because they are not exception modes. All instructions
which read or write the SPSR are UNPREDICTABLE when executed in User mode or System mode.
The format of the CPSR and the SPSRs is shown below.

31 30 29 28 27 26

8

N Z C V Q

2.5.1

DNM(RAZ)

7

6 5

4

3

2

1 0

M M M M M
I F T
4 3 2 1 0

The condition code flags
The N, Z, C, and V (Negative, Zero, Carry and oVerflow) bits are collectively known as the condition code
flags, often referred to as flags. The condition code flags in the CPSR can be tested by most instructions to
determine whether the instruction is to be executed.

The condition code flags are usually modified by:
•

Execution of a comparison instruction (CMN, CMP, TEQ or TST).

•

Execution of some other arithmetic, logical or move instruction, where the destination register of the
instruction is not R15. Most of these instructions have both a flag-preserving and a flag-setting
variant, with the latter being selected by adding an S qualifier to the instruction mnemonic. Some of
these instructions only have a flag-preserving version. This is noted in the individual instruction
descriptions.

In either case, the new condition code flags (after the instruction has been executed) usually mean:
N

Is set to bit 31 of the result of the instruction. If this result is regarded as a two's complement
signed integer, then N = 1 if the result is negative and N = 0 if it is positive or zero.

Z

Is set to 1 if the result of the instruction is zero (which often indicates an equal result from
a comparison), and to 0 otherwise.

C

Is set in one of four ways:
•
•

ARM DDI 0100E

For an addition, including the comparison instruction CMN, C is set to 1 if the addition
produced a carry (that is, an unsigned overflow), and to 0 otherwise.
For a subtraction, including the comparison instruction CMP, C is set to 0 if the
subtraction produced a borrow (that is, an unsigned underflow), and to 1 otherwise.

Copyright © 1996-2000 ARM Limited. All rights reserved.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

A2-9


Programmer’s Model

•
•
V

For non-addition/subtractions that incorporate a shift operation, C is set to the last bit
shifted out of the value by the shifter.
For other non-addition/subtractions, C is normally left unchanged (but see the
individual instruction descriptions for any special cases).

Is set in one of two ways:
•

For an addition or subtraction, V is set to 1 if signed overflow occurred, regarding the
operands and result as two's complement signed integers.

•

For non-addition/subtractions, V is normally left unchanged (but see the individual
instruction descriptions for any special cases).

The flags can be modified in these additional ways:
•

Execution of an MSR instruction, as part of its function of writing a new value to the CPSR or SPSR.

•

Execution of MRC instructions with destination register R15. The purpose of such instructions is to
transfer coprocessor-generated condition code flag values to the ARM processor.

•

Execution of some variants of the LDM instruction. These variants copy the SPSR to the CPSR, and
their main intended use is for returning from exceptions.

•

Execution of flag-setting variants of arithmetic and logical instructions whose destination register is
R15. These also copy the SPSR to the CPSR, and are mainly intended for returning from exceptions.

The Q flag
In E variants of ARM architecture 5 and above, bit[27] of the CPSR is known as the Q flag and is used to
indicate whether overflow and/or saturation has occurred in some of the enhanced DSP instructions.
Similarly, bit[27] of each SPSR is a Q flag, and is used to preserve and restore the CPSR Q flag if an

exception occurs. For more details of the Q flag, see Chapter A10 Enhanced DSP Extension.
In architecture versions prior to version 5, and in non-E variants of architecture version 5 and above, bit[27]
of the CPSR and SPSRs should be treated as described in Other bits on page A2-12.

2.5.2

The control bits
The bottom eight bits of a Program Status Register (PSR), incorporating I, F, T and M[4:0], are known
collectively as the control bits. The control bits change when an exception arises and can be altered by
software only when the processor is in a privileged mode.

Interrupt disable bits
I and F are the interrupt disable bits:
I bit
F bit

A2-10

Disables IRQ interrupts when it is set.
Disables FIQ interrupts when it is set.

Copyright © 1996-2000 ARM Limited. All rights reserved.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

ARM DDI 0100E


Programmer’s Model

The T bit
The T bit should be zero (SBZ) on ARM architecture version 3 and below, and on non-T variants of ARM
architecture version 4. No instructions exist in these architectures that can switch between ARM and Thumb
states.
On T variants of ARM architecture 4 and above, the T bit has the following meanings:
T=0

Indicates ARM execution.

T=1

Indicates Thumb execution.

Instructions that switch between ARM and Thumb states can be used freely on implementations of these
architectures.
On non-T variants of ARM architecture version 5 and above, the T bit has the following meanings:
T=0

Indicates ARM execution.

T=1

Forces the next instruction executed to cause an undefined instruction exception (see
Undefined Instruction exception on page A2-15).

Instructions that switch between ARM and Thumb states can be used on implementations of these
architectures, but only function correctly as long as the program remains in ARM state. If the program
attempts to switch to Thumb state, the first instruction executed after the attempted switch causes an
undefined instruction exception. Entry into that exception then switches back to ARM state. The exception
handler can detect that this was the cause of the exception from the fact that the T bit of SPSR_und is set.

Mode bits
M0, M1, M2, M3, and M4 (M[4:0]) are the mode bits, and these determine the mode in which the processor
operates. Their interpretation is shown in Table 2-2.
Table 2-2 The mode bits
M[4:0]

Mode

Accessible registers

0b10000

User

PC, R14 to R0, CPSR

0b10001

FIQ

PC, R14_fiq to R8_fiq, R7 to R0, CPSR, SPSR_fiq

0b10010

IRQ

PC, R14_irq, R13_irq, R12 to R0, CPSR, SPSR_irq

0b10011

Supervisor

PC, R14_svc, R13_svc, R12 to R0, CPSR, SPSR_svc

0b10111

Abort

PC, R14_abt, R13_abt, R12 to R0, CPSR, SPSR_abt

0b11011

Undefined

PC, R14_und, R13_und, R12 to R0, CPSR, SPSR_und

0b11111

System

PC, R14 to R0, CPSR (ARM architecture v4 and above)

ARM DDI 0100E

Copyright © 1996-2000 ARM Limited. All rights reserved.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

A2-11

Programmer’s Model

Not all combinations of the mode bits define a valid processor mode. Only those combinations explicitly
described can be used. If any other value is programmed into the mode bits M[4:0], the result is
UNPREDICTABLE. See also Table 8-1 on page A8-9 for details of the mode bits in the 26-bit architectures.

2.5.3

Other bits
Other bits in the program status registers are reserved for future expansion. In general, programmers must
take care to write code in such a way that these bits are never modified. Failure to do this might result in
code which has unexpected side-effects on future versions of the architecture. See the usage notes for the
MSR instruction on page A4-62 for more details.

A2-12

Copyright © 1996-2000 ARM Limited. All rights reserved.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

ARM DDI 0100E


Programmer’s Model

2.6

Exceptions

Exceptions are generated by internal and external sources to cause the processor to handle an event, such as
an externally generated interrupt or an attempt to execute an undefined instruction. The processor state just
before handling the exception must be preserved so that the original program can be resumed when the
exception routine has completed. More than one exception can arise at the same time.
ARM supports seven types of exception. Table 2-3 lists the types of exception and the processor mode that
is used to process that exception. When an exception occurs, execution is forced from a fixed memory
address corresponding to the type of exception. These fixed addresses are called the exception vectors.

Note
The normal vector at address 0x00000014 and the high vector at address 0xFFFF0014 are not normally
used and are reserved for future expansion. The reserved vector at address 0x00000014 was used for an
Address Exception vector in earlier versions of the ARM architecture which had a 26-bit address space. See
Chapter A8 The 26-bit Architectures for more information.

Table 2-3 Exception processing modes
Exception type

Mode

Normal
address

High vector
address

Reset

Supervisor

0x00000000

0xFFFF0000

Undefined instructions

Undefined

0x00000004

0xFFFF0004

Software interrupt (SWI)

Supervisor

0x00000008

0xFFFF0008

Prefetch Abort (instruction fetch memory abort)

Abort

0x0000000C

0xFFFF000C

Data Abort (data access memory abort)

Abort

0x00000010

0xFFFF0010

IRQ (interrupt)

IRQ

0x00000018

0xFFFF0018

FIQ (fast interrupt)

FIQ

0x0000001C

0xFFFF001C

When an exception occurs, the banked versions of R14 and the SPSR for the exception mode are used to
save state as follows:
R14_<exception_mode> = return link
SPSR_<exception_mode> = CPSR
CPSR[4:0] = exception mode number
CPSR[5] = 0
if <exception_mode> == Reset or FIQ then
CPSR[6] = 1
/* else CPSR[6] is unchanged */

CPSR[7] = 1
PC = exception vector address

ARM DDI 0100E

/* Execute in ARM state */
/* Disable fast interrupts */
/* Disable normal interrupts */

Copyright © 1996-2000 ARM Limited. All rights reserved.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

A2-13


Programmer’s Model

To return after handling the exception, the SPSR is moved into the CPSR, and R14 is moved to the PC. This
can be done atomically in two ways:
•
using a data-processing instruction with the S bit set, and the PC as the destination
•
using the Load Multiple with Restore CPSR instruction, as described in LDM (3) on page A4-34.
The following sections show what happens automatically when the exception occurs, and also show the
recommended data-processing instruction to use to return from each exception. This instruction is always a
MOVS or SUBS instruction with the PC as its destination.

Note
When the recommended data-processing instruction is a SUBS and a Load Multiple with Restore CPSR

instruction is used to return from the exception handler, the subtraction must still be performed. This is
usually done at the start of the exception handler, before the return link is stored to memory.
For example, an interrupt handler that wishes to store its return link on the stack might use instructions of
the following form at its entry point:
SUB
STMFD

R14, R14, #4
SP!, {<other_registers>, R14}

and return using the instruction:
LDMFD

2.6.1

SP!, {<other_registers>, PC}^

Reset
When the Reset input is asserted on the processor, the ARM processor immediately stops execution of the
current instruction. When Reset is de-asserted, the following actions are performed:
R14_svc
= UNPREDICTABLE value
SPSR_svc = UNPREDICTABLE value
CPSR[4:0] = 0b10011
CPSR[5]
= 0
CPSR[6]
= 1
CPSR[7]
= 1

if high vectors configured then
PC
= 0xFFFF0000
else
PC
= 0x00000000

/*
/*
/*
/*

Enter Supervisor mode */
Execute in ARM state */
Disable fast interrupts */
Disable normal interrupts */

After Reset, the ARM processor begins execution at address 0x00000000 or 0xFFFF0000 in Supervisor
mode with interrupts disabled. See About the MMU architecture on page B3-2 for more information on the
effects of Reset.

Note
There is no architecturally defined way of returning from a Reset.

A2-14

Copyright © 1996-2000 ARM Limited. All rights reserved.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

ARM DDI 0100E


Programmer’s Model

2.6.2

Undefined Instruction exception
If the ARM processor executes a coprocessor instruction, it waits for any external coprocessor
to acknowledge that it can execute the instruction. If no coprocessor responds, an Undefined Instruction
exception occurs.
If an attempt is made to execute an instruction that is UNDEFINED, an Undefined Instruction exception occurs
(see Extending the instruction set on page A3-27).
The Undefined Instruction exception can be used for software emulation of a coprocessor in a system that
does not have the physical coprocessor (hardware), or for general-purpose instruction set extension by
software emulation.
When an Undefined Instruction exception occurs, the following actions are performed:
R14_und
= address of next instruction after the undefined instruction
SPSR_und = CPSR
CPSR[4:0] = 0b11011
/* Enter Undefined mode */
CPSR[5]
= 0
/* Execute in ARM state */
/* CPSR[6] is unchanged */
CPSR[7]
= 1
/* Disable normal interrupts */
if high vectors configured then

PC
= 0xFFFF0004
else
PC
= 0x00000004

To return after emulating the undefined instruction use:
MOVS PC,R14

This restores the PC (from R14_und) and CPSR (from SPSR_und) and returns to the instruction following
the undefined instruction.
In some coprocessor designs, an internal exceptional condition caused by one coprocessor instruction is
signaled imprecisely by refusing to respond to a later coprocessor instruction. In these circumstances, the
Undefined Instruction handler takes whatever action is necessary to clear the exceptional condition, then
returns to the second coprocessor instruction. To do this use:
SUBS PC,R14,#4

ARM DDI 0100E

Copyright © 1996-2000 ARM Limited. All rights reserved.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

A2-15


Programmer’s Model

2.6.3

Software Interrupt exception
The Software Interrupt instruction (SWI) enters Supervisor mode to request a particular supervisor
(operating system) function. When a SWI is executed, the following actions are performed:
R14_svc
= address of next instruction after the SWI instruction
SPSR_svc = CPSR
CPSR[4:0] = 0b10011
/* Enter Supervisor mode */
CPSR[5]
= 0
/* Execute in ARM state */
/* CPSR[6] is unchanged */
CPSR[7]
= 1
/* Disable normal interrupts */
if high vectors configured then
PC
= 0xFFFF0008
else
PC
= 0x00000008

To return after performing the SWI operation, use the following instruction to restore the PC
(from R14_svc) and CPSR (from SPSR_svc) and return to the instruction following the SWI:
MOVS PC,R14

2.6.4

Prefetch Abort (instruction fetch memory abort)
A memory abort is signaled by the memory system. Activating an abort in response to an instruction fetch

marks the fetched instruction as invalid. A Prefetch Abort exception is generated if the processor tries to
execute the invalid instruction. If the instruction is not executed (for example, as a result of a branch being
taken while it is in the pipeline), no Prefetch Abort occurs.
In ARM architecture version 5 and above, a Prefetch Abort exception can also be generated as the result of
executing a BKPT instruction. For details, see BKPT on page A4-14 (ARM instruction) and BKPT on
page A7-24 (Thumb instruction).
When an attempt is made to execute an aborted instruction, the following actions are performed:
R14_abt
= address of the aborted instruction + 4
SPSR_abt = CPSR
CPSR[4:0] = 0b10111
/* Enter Abort mode */
CPSR[5]
= 0
/* Execute in ARM state */
/* CPSR[6] is unchanged */
CPSR[7]
= 1
/* Disable normal interrupts */
if high vectors configured then
PC
= 0xFFFF000C
else
PC
= 0x0000000C

To return after fixing the reason for the abort, use:
SUBS PC,R14,#4

This restores both the PC (from R14_abt) and CPSR (from SPSR_abt), and returns to the aborted

instruction.

A2-16

Copyright © 1996-2000 ARM Limited. All rights reserved.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

ARM DDI 0100E


Programmer’s Model

2.6.5

Data Abort (data access memory abort)
A memory abort is signaled by the memory system. Activating an abort in response to a data access (load
or store) marks the data as invalid. A Data Abort exception occurs before any following instructions or
exceptions have altered the state of the CPU. The following actions are performed:
R14_abt
= address of the aborted instruction + 8
SPSR_abt = CPSR
CPSR[4:0] = 0b10111
/* Enter Abort mode */
CPSR[5]
= 0
/* Execute in ARM state */
/* CPSR[6] is unchanged */
CPSR[7]
= 1

/* Disable normal interrupts */
if high vectors configured then
PC
= 0xFFFF0010
else
PC
= 0x00000010

To return after fixing the reason for the abort use:
SUBS PC,R14,#8

This restores both the PC (from R14_abt) and CPSR (from SPSR_abt), and returns to re-execute the aborted
instruction.
If the aborted instruction does not need to be re-executed use:
SUBS PC,R14,#4

Effects of data-aborted instructions
Instructions that access data memory can modify memory by storing one or more values. If a Data Abort
occurs in such an instruction, the value of each memory location that the instruction stores to is:
•
unchanged if the memory system does not permit write access to the memory location
UNPREDICTABLE otherwise.
•
Instructions that access data memory can modify registers in three ways:
•

By loading values into one or more of the general-purpose registers, which can include the PC.

•

By specifying base register writeback, in which the base register used in the address calculation has
a modified value written to it. All instructions that allow this to be specified have UNPREDICTABLE
results if base register writeback is specified and the base register is the PC, so only general-purpose
registers other than the PC can legitimately be modified in this way.

•

By loading values into coprocessor registers.

If a Data Abort occurs, the values left in these registers are determined by the following rules:
1.

ARM DDI 0100E

The PC value on entry to the data abort handler is 0x00000010 or 0xFFFF0010, and the R14_abt
value is determined from the address of the aborted instruction. Neither is affected in any way by the
results of any PC load specified by the instruction.

Copyright © 1996-2000 ARM Limited. All rights reserved.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

A2-17


Programmer’s Model

2.

If base register writeback is not specified, the base register value is unchanged. This applies even if

the instruction loaded its own base register and the memory access to load the base register occurred
earlier than the aborting access.
For example, suppose the instruction is:
LDMIA R0,{R0,R1,R2}

and the implementation loads the new R0 value, then the new R1 value and finally the new R2 value.
If a Data Abort occurs on any of the accesses, the value in the base register R0 of the instruction is
unchanged. This applies even if it was the load of R1 or R2 that aborted, rather than the load of R0.
3.

If base register writeback is specified, the value left in the base register is determined by the abort
model of the implementation, as described in Abort models.

4.

If the instruction only loads one general-purpose register, the value in that register is unchanged.

5.

If the instruction loads more than one general-purpose register, UNPREDICTABLE values are left in
destination registers which are neither the PC nor the base register of the instruction.

6.

If the instruction loads coprocessor registers, UNPREDICTABLE values are left in the destination
coprocessor registers, unless otherwise specified in the instruction set description of the specific
coprocessor.

Abort models
The abort model used by an ARM implementation is IMPLEMENTATION DEFINED, and is one of the

following:
Base Restored Abort Model
If a Data Abort occurs in an instruction which specifies base register writeback, the value in
the base register is unchanged.
Base Updated Abort Model
If a Data Abort occurs in an instruction which specifies base register writeback, the base
register writeback still occurs.
In either case, the abort model applies uniformly across all instructions. An implementation does not use the
Base Restored Abort Model for some instructions and the Base Updated Abort Model for others.

Note
In some ARMv3 and earlier implementations, a third abort model (the Early Abort Model) was used. In this
model, base register writeback occurred for LDC, LDM, STC and STM instructions, and the base register was
unchanged for all other instructions.
The Early Abort Model is not valid in ARM architecture versions 3M, 4 and above.
Some of these implementations optionally allowed a Late Abort Model to be selected. This is identical to
the Base Updated Abort Model.

A2-18

Copyright © 1996-2000 ARM Limited. All rights reserved.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

ARM DDI 0100E


Programmer’s Model

2.6.6

Interrupt request (IRQ) exception
The IRQ exception is generated externally by asserting the IRQ input on the processor. It has a lower
priority than FIQ (see Table 2-4 on page A2-20), and is masked out when an FIQ sequence is entered.
Interrupts are disabled when the I bit in the CPSR is set. If the I bit is clear, ARM checks for an IRQ at
instruction boundaries.

Note
The I bit can only be changed from a privileged mode.
When an IRQ is detected, the following actions are performed:
R14_irq
= address of next instruction to be executed + 4
SPSR_irq = CPSR
CPSR[4:0] = 0b10010
/* Enter IRQ mode */
CPSR[5]
= 0
/* Execute in ARM state */
/* CPSR[6] is unchanged */
CPSR[7]
= 1
/* Disable normal interrupts */
if high vectors configured then
PC
= 0xFFFF0018
else
PC
= 0x00000018

To return after servicing the interrupt, use:

SUBS PC,R14,#4

This restores both the PC (from R14_irq) and CPSR (from SPSR_irq), and resumes execution of the
interrupted code.

2.6.7

Fast interrupt request (FIQ) exception
The FIQ exception is generated externally by asserting the FIQ input on the processor. FIQ is designed to
support a data transfer or channel process, and has sufficient private registers to remove the need for register
saving in such applications, therefore minimizing the overhead of context switching.
Fast interrupts are disabled when the F bit in the CPSR is set. If the F bit is clear, ARM checks for an FIQ
at instruction boundaries.

Note
The F bit can only be changed from a privileged mode.
When an FIQ is detected, the following actions are performed:

ARM DDI 0100E

Copyright © 1996-2000 ARM Limited. All rights reserved.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

A2-19


Programmer’s Model

R14_fiq

= address of next instruction to be executed + 4
SPSR_fiq = CPSR
CPSR[4:0] = 0b10001
/* Enter FIQ mode */
CPSR[5]
= 0
/* Execute in ARM state */
CPSR[6]
= 1
/* Disable fast interrupts */
CPSR[7]
= 1
/* Disable normal interrupts */
if high vectors configured then
PC
= 0xFFFF001C
else
PC
= 0x0000001C

To return after servicing the interrupt, use:
SUBS PC, R14,#4

This restores both the PC (from R14_fiq) and CPSR (from SPSR_fiq), and resumes execution of the
interrupted code.
The FIQ vector is deliberately the last vector to allow the FIQ exception-handler software to be placed
directly at address 0x0000001C or 0xFFFF001C, without requiring a branch instruction from the vector.

2.6.8

Exception priorities
Table 2-4 shows the exception priorities:
Table 2-4 Exception priorities
Priority
Highest

Exception
Reset

2

Data Abort

3

FIQ

4

IRQ

5
Lowest

1

Prefetch Abort

6

Undefined instruction
SWI

Undefined instruction and software interrupt cannot occur at the same time, as they each correspond to
particular (non-overlapping) decodings of the current instruction, and both must be lower priority than
prefetch abort, as a prefetch abort indicates that no valid instruction was fetched.
The priority of a Data Abort exception is higher than FIQ, which ensures that the data abort handler is
entered before the FIQ handler is entered (so that the Data Abort is resolved after the FIQ handler has
completed).

A2-20

Copyright © 1996-2000 ARM Limited. All rights reserved.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

ARM DDI 0100E


Programmer’s Model

2.6.9

High vectors
Some ARM implementations allow the exception vector locations to be moved from their normal address
range 0x00000000-0x0000001C at the bottom of the 32-bit address space, to an alternative address
range 0xFFFF0000-0xFFFF001C near the top of the address space. These alternative locations are
known as the high vectors.
It is IMPLEMENTATION DEFINED whether the high vectors are supported. When they are, a hardware
configuration input selects whether the normal vectors or the high vectors are to be used.

The ARM instruction set does not contain any instructions which can directly change whether normal or
high vectors are configured. However, if the standard System Control coprocessor is attached to an ARM
processor which supports the high vectors, bit[13] of coprocessor 15 register 1 can be used to switch
between using the normal vectors and the high vectors (see Register 1: Control register on page B2-13).

ARM DDI 0100E

Copyright © 1996-2000 ARM Limited. All rights reserved.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

A2-21


Programmer’s Model

2.7

Memory and memory-mapped I/O
This section discusses memory and memory-mapped I/O, mainly with regard to the assumptions ARM
processor implementations make about how their memory systems behave and how programs should access
memory. As a result, it describes the memory system from the outside, specifying how it should behave
without going into much detail of how this behavior can or should be implemented. More details of how
some standard memory systems behave can be found in Part B: Memory and System Architectures.
The ARM architecture allows a wide variety of memory system designs, using the range of memory and I/O
devices which are available. This makes it difficult to specify absolute rules about how a memory system
should behave.
Many of the rules below can be broken if the hardware and software are designed appropriately. However,
breaking these rules is discouraged, for the following reasons:
•

•

It might cause difficulties in porting the system (hardware and/or software) to future ARM
processors.

•

2.7.1

It might make implementing the memory system more difficult.

Standard software (such as compilers and other software toolkit components) might not work with
the rule-breaking system.

Address space
The ARM architecture uses a single, flat address space of 232 8-bit bytes. Byte addresses are treated as
unsigned numbers, running from 0 to 232 - 1.
This address space is regarded as consisting of 230 32-bit words, each of whose addresses is word-aligned,
which means that the address is divisible by 4. The word whose word-aligned address is A consists of the
four bytes with addresses A, A+1, A+2 and A+3.
In ARM architecture version 4 and above, the address space is also regarded as consisting of 231 16-bit
halfwords, each of whose addresses is halfword-aligned (divisible by 2). The halfword whose
halfword-aligned address is A consists of the two bytes with addresses A and A+1.

Note
Prior to ARM architecture version 3, the address space was only 226 bytes, with addresses running from 0
to 226 - 1. This address space was split into 224 words.
Some implementations of subsequent non-T variants of the ARM architecture include
backwards-compatibility features to allow execution of code written for this address space. These features
are described in Chapter A8 The 26-bit Architectures. Their use for any purpose other than executing old

code is strongly discouraged.
These backwards-compatibility features are not compatible with T variants of the architecture, due to
conflicting uses of bits[1:0] of R15.

A2-22

Copyright © 1996-2000 ARM Limited. All rights reserved.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

ARM DDI 0100E


Programmer’s Model

Address calculations are normally performed using ordinary integer instructions. This means that they
normally wrap around if they overflow or underflow the address space. This means that the result of the
calculation is reduced modulo 232. However, to minimize the chances of incompatibility if the address space
is extended in the future, programs should not be written so that they rely on this behavior. Address
calculations should be written so that their results would still lie in the range 0 to 232 - 1 if they were
calculated without wrap-around.
Most branch instructions calculate their targets by adding an instruction-specified offset to the value of the
PC and writing the result back to the PC. If the overall effect of this calculation of:
(address_of_current_instruction) + 8 + offset
is to overflow or underflow the address space, the instruction is technically UNPREDICTABLE because it relies
on address wrap-around. The result of this is that forward branches past address 0xFFFFFFFF and
backward branches past address 0x00000000 should not be used.
Also, normal sequential execution of instructions effectively calculates:
(address_of_current_instruction) + 4
after each instruction to determine which instruction to execute next. If this calculation overflows the top of

the address space, the result is again technically UNPREDICTABLE. In other words, programs should not rely
on sequential execution of the instruction at address 0x00000000 after the instruction at address
0xFFFFFFFC.

Note
The above only applies to instructions that are executed, including those which fail their condition code
check. Most ARM implementations prefetch instructions ahead of the currently-executing instruction. If
this prefetching overflows the top of the address space, it does not cause the implementation’s behavior to
become UNPREDICTABLE until and unless the prefetched instructions are actually executed.
LDC, LDM, STC, and STM instructions access a sequence of words at increasing memory addresses,
effectively incrementing a memory address by 4 for each load or store. If this calculation overflows the top
of the address space, the result is again technically UNPREDICTABLE. In other words, programs should not
use these instructions in such a way that they access the word at address 0x00000000 sequentially after
the word at address 0xFFFFFFFC.

2.7.2

Endianness
The rules in Address space on page A2-22 require that for a word-aligned address A:
•
The word at address A consists of the bytes at addresses A, A+1, A+2 and A+3.
•
The halfword at address A consists of the bytes at addresses A and A+1.
•
The halfword at address A+2 consists of the bytes at addresses A+2 and A+3.
•
The word at address A therefore consists of the halfwords at addresses A and A+2.
However, this does not totally specify the mappings between words, halfwords and bytes.

ARM DDI 0100E

Copyright © 1996-2000 ARM Limited. All rights reserved.

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

A2-23