Bicameral LLC v. NXP USA, Inc. et al

Western District of Texas, txwd-6:2018-cv-00294

Exhibit Ex. 331EX7

Interested in this case?

Current View

Full Text

1 Exhibit 331EX7 1 ARM ARCHITECTURE REFERENCE MANUAL SECOND EDITION EDITED BY DAVID SEAL ADDISON-WESLEY 1 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 = OxFFFF0004 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. A2-15 1 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] = Ob10011 /* 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 = OxFFFF0008 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 = OxFFFF0000 else PC = 0x00000000 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. ARM DDI 0100E 1 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 = OxFFFF0010 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. 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. ARM DDI 0100E Copyright © 1996-2000 ARM Limited. All rights reserved. A2-17 1 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 RO, {RO, R1, R2} and the implementation loads the new RO 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 RO of the instruction is unchanged. This applies even if it was the load of R1 or R2 that aborted, rather than the load of RO. 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. If the instruction only loads one general-purpose register, the value in that register is unchanged. 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. 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. ARM DDI 0100E 1 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] = Ob10010 /* 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 = OxFFFF0018 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. A2-19 1 Programmer's Model * * * R14_fiq = address of next instruction to be executed + 4 SPSR_fiq = CPSR CPSR [4:0] = Ob10001 * 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 = OxFFFF0010 else PC = 0x00000010 * 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 Exception Highest 1 Reset Data Abort FIQ IRQ Prefetch Abort Lowest 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. ARM DDI 0100E 1 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. A2-21 1 ARM Instructions 4.1.11 CDP 31 28 27 26 25 24 23 20 19 16 15 12 11 87 5 4 3 cond 11 1 1 0 opcode_1 CRn CRd cp_num opcode_2 0 CRm The CDP (Coprocessor Data Processing) instruction tells the coprocessor whose number is cp_num to perform an operation that is independent of ARM registers and memory. If no coprocessors indicate that they can execute the instruction, an Undefined Instruction exception is generated. Syntax CDP{<cond>} CDP2 <coproc>, <opcode_1>, <CRd>, <CRn>, <CRm>, <opcode_2> <coproc>, <opcode_1>, <CRd>, <CRn>, <CRm>, <opcode_2> where: <cond> Is the condition under which the instruction is executed. The conditions are defined in The condition field on page A3-5. If <cond> is omitted, the AL (always) condition is used. CDP2 Causes the condition field of the instruction to be set to Ob1111. This provides additional opcode space for coprocessor designers. The resulting instructions can only be executed unconditionally. <coproc> <opcode_1> Specifies the name of the coprocessor, and causes the corresponding coprocessor number to be placed in the cp_num field of the instruction. The standard generic coprocessor names are p0, p1, ..., p15. Specifies (in a coprocessor-specific manner) which coprocessor operation is to be performed. Specifies the destination coprocessor register for the instruction. Specifies the coprocessor register that contains the first operand for the instruction. <CRd> <CRn> <CRm> Specifies the coprocessor register that contains the second operand for the instruction. <opcode_2> Specifies (in a coprocessor-specific manner) which coprocessor operation is to be performed. Architecture version CDP is in Version 2 and above. CDP2 is in Version 5 and above. Exceptions Undefined Instruction A4-20 Copyright © 1996-2000 ARM Limited. All rights reserved. ARM DDI 0100E 1 ARM Instructions Operation if ConditionPassed (cond) then Coprocessor [cp_num] -dependent operation Usage CDP is used to initiate coprocessor instructions that do not operate on values in ARM registers or in main memory. An example is a floating-point multiply instruction for a floating-point coprocessor. Notes Coprocessor fields Only instruction bits[31:24], bits[11:8], and bit[4] are architecturally defined. The remaining fields are recommendations, for compatibility with ARM Development Systems. Unimplemented coprocessor instructions Hardware coprocessor support is optional, regardless of the architecture version. An implementation can choose to implement a subset of the coprocessor instructions, or no coprocessor instructions at all. Any coprocessor instructions that are not implemented instead cause an undefined instruction trap. ARM DDI 0100E Copyright © 1996-2000 ARM Limited. All rights reserved. A4-21 1 ARM Instructions 4.1.50 SWI 31 28 27 26 25 24 23 cond 1 1 1 1 immed_24 The SWI (Software Interrupt) instruction causes a SWI exception (see Exceptions on page A2-13). Syntax SWI{<cond>} <immed_24> where: <cond> Is the condition under which the instruction is executed. The conditions are defined in The condition field on page A3-5. If <cond> is omitted, the AL (always) condition is used. <immed_24> Is a 24-bit immediate value that is put into bits[23:0] of the instruction. This value is ignored by the ARM processor, but can be used by an operating system SWI exception handler to determine what operating system service is being requested (see Usage on page A4-101 below for more details). Architecture version All Exceptions Software interrupt Operation if Condition Passed (cond) then R14_svc = address of next instruction after the SWI instruction SPSR SVC = CPSR CPSR [4:0] = Ob10011 /* 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 = OxFFFF0008 else PC = Ox00000008 A4-100 Copyright © 1996-2000 ARM Limited. All rights reserved. ARM DDI 0100E 1 ARM Instructions Usage The SWI instruction is used as an operating system service call. The method used to select which operating system service is required is specified by the operating system, and the SWI exception handler for the operating system determines and provides the requested service. Two typical methods are: The 24-bit immediate in the instruction specifies which service is required, and any parameters needed by the selected service are passed in general-purpose registers. The 24-bit immediate in the instruction is ignored, general-purpose register RO is used to select which service is wanted, and any parameters needed by the selected service are passed in other general-purpose registers. ARM DDI 0100E Copyright © 1996-2000 ARM Limited. All rights reserved. A4-101 1 PEARSON EDUCATION LIMITED Head Office: Edinburgh Gate Harlow CM20 2JE Tel: +44 (0)1279 623623 Fax: +44 (0)1279 431059 London Office: 128 Long Acre London WC2E 9AN Tel: +44 (0)20 7477 2000 Fax: +44 (0)20 7240 5771 Website: www.aw.com/cseng First published in Great Britain 2001 Copyright © 1996-2000 ARM Limited. All rights reserved. ISBN 0 201 737191 All rights reserved; no part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise without either the prior written permission of the Publishers or a licence permitting restricted copying in the United Kingdom issued by the Copyright Licensing Agency Ltd, 90 Tottenham Court Road, London W1P OLP. This book may not be lent, resold, hired out or otherwise disposed of by way of trade in any form of binding or cover other than that in which it is published, without the prior consent of the Publishers. Release Information: The following changes have been made to this document. Date Issue Change February 1996 First edition. July 1997 B Updated and index added. April 1998 Updated February 2000 Updated for ARM architecture v5. June 2000 Ε Updated for ARM architecture v5TE and corrections to Part B. Proprietary Notice ARM, the ARM Powered logo, Thumb, and Strong ARM are registered trademarks of ARM Limited. The ARM logo, AMBA, Angel, ARMulator, EmbeddedICE, ModelGen, Multi-ICE, PrimeCell, ARM7TDMI, ARM7TDMI-S, ARMSTDMI, ARM9E-S, ETM7, ETM9, TDMI, STRONG, are trademarks of ARM Limited. All other products or services mentioned herein may be trademarks of their respective owners. Neither the whole nor any part of the information contained in, or the product described in, this document may be adapted or reproduced in any material form except with the prior written permission of the copyright holder. The product described in this document is subject to continuous developments and improvements. All particulars of the product and its use contained in this document are given by ARM in good faith. However, all warranties implied or expressed, including but not limited to implied warranties of merchantability, or fitness for purpose, are excluded. This document is intended only to assist the reader in the use of the product. ARM Limited shall not be liable for any loss or damage arising from the use of any information in this document, or any error or omission in such information, or any incorrect use of the product. 10 9 8 7 6 5 4 3 2 1 Typeset by ARM Limited Printed and bound in the UK by Biddles Ltd of Guildford and King's Lynn. The Publishers' policy is to use paper manufactured from sustainable forests. 1 Chapter A1 Introduction to the ARM Architecture This chapter introduces the ARM architecture and contains the following sections: About the ARM architecture on page A1-2 • ARM instruction set on page Al-5. ARM DDI 0100E Copyright © 1996-2000 ARM Limited. All rights reserved. A1-1 1 Introduction to the ARM Architecture 1.1 About the ARM architecture The ARM architecture has been designed to allow very small, yet high-performance implementations. The architectural simplicity of ARM processors leads to very small implementations, and small implementations allow devices with very low power consumption. The ARM is a Reduced Instruction Set Computer (RISC), as it incorporates these typical RISC architecture features: a large uniform register file a load/store architecture, where data-processing operations only operate on register contents, not directly on memory contents simple addressing modes, with all load/store addresses being determined from register contents and instruction fields only uniform and fixed-length instruction fields, to simplify instruction decode. In addition, the ARM architecture gives you: control over both the Arithmetic Logic Unit (ALU) and shifter in every data-processing instruction to maximize the use of an ALU and a shifter auto-increment and auto-decrement addressing modes to optimize program loops Load and Store Multiple instructions to maximize data throughput conditional execution of all instructions to maximize execution throughput. These enhancements to a basic RISC architecture allow ARM processors to achieve a good balance of high performance, low code size, low power consumption and low silicon area. 1.1.1 ARM registers ARM has 31 general-purpose 32-bit registers. At any one time, 16 of these registers are visible. The other registers are used to speed up exception processing. All the register specifiers in ARM instructions can address any of the 16 visible registers. The main bank of 16 registers is used by all unprivileged code. These are the User mode registers. User mode is different from all other modes as it is unprivileged, which means: User mode is the only mode which cannot switch to another processor mode without generating an exception memory systems and coprocessors might allow User mode less access to memory and coprocessor functionality than a privileged mode. A1-2 Copyright © 1996-2000 ARM Limited. All rights reserved. ARM DDI 0100E 1 Introduction to the ARM Architecture Two of the 16 visible registers have special roles: Link register Register 14 is the Link Register (LR). This register holds the address of the next instruction after a Branch and Link (BL) instruction, which is the instruction used to make a subroutine call. At all other times, R14 can be used as a general-purpose register. Program counter Register 15 is the Program Counter (PC). It can be used in most instructions as a pointer to the instruction which is two instructions after the instruction being executed. All ARM instructions are four bytes long (one 32-bit word) and are always aligned on a word boundary. This means that the bottom two bits of the PC are always zero, and therefore the PC contains only 30 non-constant bits. The remaining 14 registers have no special hardware purpose. Their uses are defined purely by software. Software normally uses R13 as a Stack Pointer (SP). For more details on registers, please refer to Registers on page A2-4. 1.1.2 Exceptions ARM supports five types of exception, and a privileged processing mode for each type. The five types of exceptions are: fast interrupt normal interrupt memory aborts, which can be used to implement memory protection or virtual memory attempted execution of an undefined instruction software interrupt (SWI) instructions which can be used to make a call to an operating system. When an exception occurs, some of the standard registers are replaced with registers specific to the exception mode. All exception modes have replacement banked registers for R13 and R14. The fast interrupt mode has more registers for fast interrupt processing. When an exception handler is entered, R14 holds the return address for exception processing. This is used to return after the exception is processed and to address the instruction that caused the exception. Register 13 is banked across exception modes to provide each exception handler with a private stack pointer. The fast interrupt mode also banks registers 8 to 12 so that interrupt processing can begin without the need to save or restore these registers. There is a sixth privileged processing mode, System mode, which uses the User mode registers. This is used to run tasks that require privileged access to memory and/or coprocessors, without limitations on which exceptions can occur during the task. For more details on exceptions, please refer to Exceptions on page A2-13. ARM DDI 0100E Copyright © 1996-2000 ARM Limited. All rights reserved. A1-3 1 Introduction to the ARM Architecture The exception process When an exception occurs, the ARM processor halts execution after the current instruction and begins execution at one of a number of fixed addresses in memory, known as the exception vectors. There is a separate vector location for each exception. An operating system installs a handler on every exception at initialization. Privileged operating system tasks are normally run in System mode to allow exceptions to occur within the operating system without state loss. 1.1.3 Status registers All processor state other than the general-purpose register contents is held in status registers. The current operating processor status is in the Current Program Status Register (CPSR). The CPSR holds: 4 condition code flags (Negative, Zero, Carry and oVerflow) 2 interrupt disable bits, one for each type of interrupt 5 bits which encode the current processor mode • 1 bit which encodes whether ARM or Thumb instructions are being executed. Each exception mode also has a Saved Program Status Register (SPSR) which holds the CPSR of the task immediately before the exception occurred. The CPSR and the SPSRs are accessed with special instructions. For more details on status registers, please refer to Program status registers on page A2-9. A1-4 Copyright © 1996-2000 ARM Limited. All rights reserved. ARM DDI 0100E 1 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. A1-9 1 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 OxFFFF0014 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 0x000000000xFFFF0000 Undefined instructions Undefined Ox00000004 OxFFFF0004 Software interrupt (SWI) Supervisor 0x00000008 OxFFFF0008 Prefetch Abort (instruction fetch memory abort) Abort 0x0000000C 0xFFFF000C Data Abort (data access memory abort) Abort 0x00000010 OxFFFF0010 IRQ (interrupt) IRO 0x00000018 OxFFFF0018 FIQ (fast interrupt) FIQ 0x00000010 OxFFFF0010 When an exception occurs, the banked versions of R14 and the SPSR for the exception mode are used to save state as follows: /* Execute in ARM state */ R14_ <exception_mode> = return link SPSR_<exception_mode> = CPSR PSR [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 /* Disable fast interrupts */ * Disable normal interrupts */ ARM DDI 0100E Copyright © 1996-2000 ARM Limited. All rights reserved. A2-13 1 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 R14, R14, #4 STMFD SP!, {<other_registers>, R14} and return using the instruction: LDMFD SP!, {<other_registers>, PC}^ 2.6.1 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] = Ob10011 CPSR [5] CPSR [6] = 1 CPSR [7] = 1 if high vectors configured then PC = OxFFFF0000 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. ARM DDI 0100E