DDI0406C D Armv7ar Arm PDF

ARM Architecture Reference Manual
ARMv7-A and ARMv7-R edition
Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved.
ARM DDI 0406C.d (ID040418)
ARM Architecture Reference Manual
ARMv7-A and ARMv7-R edition
Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved.
Release Information
The following changes have been made to this document.
Change History
Date Issue Confidentiality Change
05 April 2007 A Non-Confidential New edition for ARMv7-A and ARMv7-R architecture profiles.
Document number changed from ARM DDI 0100 to ARM DDI 0406 and contents restructured.
29 April 2008 B Non-Confidential Addition of the VFP Half-precision and Multiprocessing Extensions, and many clarifications and enhancements.
23 November 2011 C (C.a) Non-Confidential Addition of the Virtualization Extensions, Large Physical Address Extension, Generic Timer Extension, and other
additions. Many other clarifications and enhancements.
24 July 2012 C.b Non-Confidential Errata release for issue C.a.
20 May 2014 C.c Non-Confidential Second errata release for issue C.a.
29 March 2018 C.d Non-Confidential Addition of CSDB instruction and some defect fixes.
Note that issue C.a, the first publication of issue C of this manual, was originally identified as issue C.
From ARMv7, the ARM® architecture defines different architectural profiles and this edition of this manual describes only the A
and R profiles. For details of the documentation of the ARMv7-M profile see Additional reading on page xxiii. Before ARMv7
there was only a single ARM Architecture Reference Manual, with document number DDI 0100. The first issue of this was in
February 1996, and the final issue, issue I, was in July 2005. For more information see Additional reading on page xxiii.
Proprietary Notice
This document is protected by copyright and other related rights and the practice or implementation of the information contained
in this document may be protected by one or more patents or pending patent applications. No part of this document may be
reproduced in any form by any means without the express prior written permission of Arm. No license, express or implied, by
estoppel or otherwise to any intellectual property rights is granted by this document unless specifically stated.
Your access to the information in this document is conditional upon your acceptance that you will not use or permit others to use
the information for the purposes of determining whether implementations infringe any third party patents.
THIS DOCUMENT IS PROVIDED “AS IS”. ARM PROVIDES NO REPRESENTATIONS AND NO WARRANTIES,
EXPRESS, IMPLIED OR STATUTORY, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
MERCHANTABILITY, SATISFACTORY QUALITY, NON-INFRINGEMENT OR FITNESS FOR A PARTICULAR
PURPOSE WITH RESPECT TO THE DOCUMENT. For the avoidance of doubt, Arm makes no representation with respect to,
and has undertaken no analysis to identify or understand the scope and content of, patents, copyrights, trade secrets, or other rights.
This document may include technical inaccuracies or typographical errors.
TO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT WILL ARM BE LIABLE FOR ANY DAMAGES,
INCLUDING WITHOUT LIMITATION ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE, OR
CONSEQUENTIAL DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING
OUT OF ANY USE OF THIS DOCUMENT, EVEN IF ARM HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES.
This document consists solely of commercial items. You shall be responsible for ensuring that any use, duplication or disclosure
of this document complies fully with any relevant export laws and regulations to assure that this document or any portion thereof
is not exported, directly or indirectly, in violation of such export laws. Use of the word “partner” in reference to Arm’s customers
is not intended to create or refer to any partnership relationship with any other company. Arm may make changes to this document
at any time and without notice.
If any of the provisions contained in these terms conflict with any of the provisions of any click through or signed written
agreement covering this document with Arm, then the click through or signed written agreement prevails over and supersedes the
conflicting provisions of these terms. This document may be translated into other languages for convenience, and you agree that
if there is any conflict between the English version of this document and any translation, the terms of the English version of the
Agreement shall prevail.
ii Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved. ARM DDI 0406C.d
Non-Confidential ID040418
The Arm corporate logo and words marked with ® or ™ are registered trademarks or trademarks of Arm Limited (or its subsidiaries)
in the US and/or elsewhere. All rights reserved. Other brands and names mentioned in this document may be the trademarks of
their respective owners. You must follow the Arm’s trademark usage guidelines
http://www.arm.com/company/policies/trademarks.
Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 Arm Limited (or its affiliates). All rights reserved.
Arm Limited. Company 02557590 registered in England.

110 Fulbourn Road, Cambridge, England CB1 9NJ.
LES-PRE-20349
In this document, where the term ARM is used to refer to the company it means “Arm or any of its subsidiaries as appropriate”.
Confidentiality Status
This document is Non-Confidential. The right to use, copy and disclose this document may be subject to license restrictions in
accordance with the terms of the agreement entered into by Arm and the party that Arm delivered this document to.
Product Status
The information in this document is final, that is for a developed product.
Web Address
http://www.arm.com
ARM DDI 0406C.d Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved. iii
ID040418 Non-Confidential
iv Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved. ARM DDI 0406C.d
Contents
ARM Architecture Reference Manual ARMv7-A and
ARMv7-R edition
Preface
About this manual ..................................................................................................... xiv
Using this manual ...................................................................................................... xvi
Conventions .............................................................................................................. xxi
Additional reading ................................................................................................... xxiii
Feedback ................................................................................................................ xxiv
Part A Application Level Architecture

Chapter A1 Introduction to the ARM Architecture
A1.1 About the ARM architecture ................................................................................ A1-28
A1.2 The instruction sets ............................................................................................. A1-29
A1.3 Architecture versions, profiles, and variants ........................................................ A1-30
A1.4 Architecture extensions ....................................................................................... A1-32
A1.5 The ARM memory model .................................................................................... A1-35
Chapter A2 Application Level Programmers’ Model

A2.1 About the Application level programmers’ model ................................................ A2-38
A2.2 ARM core data types and arithmetic ................................................................... A2-40
A2.3 ARM core registers ............................................................................................. A2-45
A2.4 The Application Program Status Register (APSR) .............................................. A2-49
A2.5 Execution state registers ..................................................................................... A2-50
A2.6 Advanced SIMD and Floating-point Extensions .................................................. A2-54
A2.7 Floating-point data types and arithmetic ............................................................. A2-62
A2.8 Polynomial arithmetic over {0, 1} ......................................................................... A2-92
A2.9 Coprocessor support ........................................................................................... A2-93
ARM DDI 0406C.d Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved. v
A2.10 Thumb Execution Environment ........................................................................... A2-94
A2.11 Jazelle direct bytecode execution support .......................................................... A2-96
A2.12 Exceptions, debug events and checks .............................................................. A2-101
Chapter A3 Application Level Memory Model

A3.1 Address space .................................................................................................. A3-104
A3.2 Alignment support ............................................................................................. A3-106
A3.3 Endian support .................................................................................................. A3-108
A3.4 Synchronization and semaphores ..................................................................... A3-112
A3.5 Memory types and attributes and the memory order model .............................. A3-123
A3.6 Access rights ..................................................................................................... A3-139
A3.7 Virtual and physical addressing ........................................................................ A3-142
A3.8 Memory access order ........................................................................................ A3-143
A3.9 Caches and memory hierarchy ......................................................................... A3-153
Chapter A4 The Instruction Sets

A4.1 About the instruction sets .................................................................................. A4-158
A4.2 Unified Assembler Language ............................................................................ A4-160
A4.3 Branch instructions ............................................................................................ A4-162
A4.4 Data-processing instructions ............................................................................. A4-163
A4.5 Status register access instructions .................................................................... A4-172
A4.6 Load/store instructions ...................................................................................... A4-173
A4.7 Load/store multiple instructions ......................................................................... A4-175
A4.8 Miscellaneous instructions ................................................................................ A4-176
A4.9 Exception-generating and exception-handling instructions ............................... A4-177
A4.10 Coprocessor instructions ................................................................................... A4-178
A4.11 Advanced SIMD and Floating-point load/store instructions ............................... A4-179
A4.12 Advanced SIMD and Floating-point register transfer instructions ..................... A4-181
A4.13 Advanced SIMD data-processing instructions ................................................... A4-182
A4.14 Floating-point data-processing instructions ....................................................... A4-189
Chapter A5 ARM Instruction Set Encoding

A5.1 ARM instruction set encoding ........................................................................... A5-192
A5.2 Data-processing and miscellaneous instructions .............................................. A5-194
A5.3 Load/store word and unsigned byte .................................................................. A5-206
A5.4 Media instructions ............................................................................................. A5-207
A5.5 Branch, branch with link, and block data transfer .............................................. A5-212
A5.6 Coprocessor instructions, and Supervisor Call ................................................. A5-213
A5.7 Unconditional instructions ................................................................................. A5-214
Chapter A6 Thumb Instruction Set Encoding

A6.1 Thumb instruction set encoding ........................................................................ A6-218
A6.2 16-bit Thumb instruction encoding .................................................................... A6-221
A6.3 32-bit Thumb instruction encoding .................................................................... A6-228
Chapter A7 Advanced SIMD and Floating-point Instruction Encoding

A7.1 Overview ........................................................................................................... A7-252
A7.2 Advanced SIMD and Floating-point instruction syntax ...................................... A7-253
A7.3 Register encoding ............................................................................................. A7-257
A7.4 Advanced SIMD data-processing instructions ................................................... A7-259
A7.5 Floating-point data-processing instructions ....................................................... A7-270
A7.6 Extension register load/store instructions .......................................................... A7-272
A7.7 Advanced SIMD element or structure load/store instructions ........................... A7-273
A7.8 8, 16, and 32-bit transfer between ARM core and extension registers ............. A7-276
A7.9 64-bit transfers between ARM core and extension registers ............................. A7-277
Chapter A8 Instruction Descriptions

A8.1 Format of instruction descriptions ..................................................................... A8-280
vi Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved. ARM DDI 0406C.d
A8.2 Standard assembler syntax fields ..................................................................... A8-285
A8.3 Conditional execution ........................................................................................ A8-286
A8.4 Shifts applied to a register ................................................................................. A8-289
A8.5 Memory accesses ............................................................................................. A8-292
A8.6 Encoding of lists of ARM core registers ............................................................ A8-293
A8.7 Additional pseudocode support for instruction descriptions .............................. A8-294
A8.8 Alphabetical list of instructions .......................................................................... A8-298
Chapter A9 The ThumbEE Instruction Set

A9.1 About the ThumbEE instruction set ................................................................. A9-1112
A9.2 ThumbEE instruction set encoding ................................................................. A9-1115
A9.3 Additional instructions in Thumb and ThumbEE instruction sets .................... A9-1116
A9.4 ThumbEE instructions with modified behavior ................................................ A9-1117
A9.5 Additional ThumbEE instructions .................................................................... A9-1123
Part B System Level Architecture

Chapter B1 System Level Programmers’ Model
B1.1 About the System level programmers’ model .................................................. B1-1134
B1.2 System level concepts and terminology .......................................................... B1-1135
B1.3 ARM processor modes and ARM core registers ............................................. B1-1139
B1.4 Instruction set states ....................................................................................... B1-1155
B1.5 The Security Extensions ................................................................................. B1-1156
B1.6 The Large Physical Address Extension ........................................................... B1-1159
B1.7 The Virtualization Extensions .......................................................................... B1-1161
B1.8 Exception handling .......................................................................................... B1-1164
B1.9 Exception descriptions .................................................................................... B1-1204
B1.10 Coprocessors and system control ................................................................... B1-1225
B1.11 Advanced SIMD and floating-point support ..................................................... B1-1228
B1.12 Thumb Execution Environment ....................................................................... B1-1239
B1.13 Jazelle direct bytecode execution ................................................................... B1-1240
B1.14 Traps to the hypervisor ................................................................................... B1-1246
Chapter B2 Common Memory System Architecture Features

B2.1 About the memory system architecture ........................................................... B2-1262
B2.2 Caches and branch predictors ........................................................................ B2-1264
B2.3 IMPLEMENTATION DEFINED memory system features ............................... B2-1290
B2.4 Pseudocode details of general memory system operations ............................ B2-1291
Chapter B3 Virtual Memory System Architecture (VMSA)

B3.1 About the VMSA .............................................................................................. B3-1306
B3.2 The effects of disabling MMUs on VMSA behavior ......................................... B3-1312
B3.3 Translation tables ............................................................................................ B3-1316
B3.4 Secure and Non-secure address spaces ........................................................ B3-1320
B3.5 Short-descriptor translation table format ......................................................... B3-1321
B3.6 Long-descriptor translation table format .......................................................... B3-1334
B3.7 Memory access control ................................................................................... B3-1352
B3.8 Memory region attributes ................................................................................ B3-1362
B3.9 Translation Lookaside Buffers (TLBs) ............................................................. B3-1374
B3.10 TLB maintenance requirements ...................................................................... B3-1377
B3.11 Caches in a VMSA implementation ................................................................. B3-1389
B3.12 VMSA memory aborts ..................................................................................... B3-1392
B3.13 Exception reporting in a VMSA implementation .............................................. B3-1406
B3.14 Virtual Address to Physical Address translation operations ............................ B3-1434
B3.15 About the system control registers for VMSA .................................................. B3-1440
B3.16 Organization of the CP14 registers in a VMSA implementation ...................... B3-1464
B3.17 Organization of the CP15 registers in a VMSA implementation ...................... B3-1465
ARM DDI 0406C.d Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved. vii
B3.18 Functional grouping of VMSAv7 system control registers ............................... B3-1486
B3.19 Pseudocode details of VMSA memory system operations .............................. B3-1498
Chapter B4 System Control Registers in a VMSA implementation

B4.1 VMSA System control registers descriptions, in register order ....................... B4-1518
B4.2 VMSA system control operations described by function ................................. B4-1735
Chapter B5 Protected Memory System Architecture (PMSA)

B5.1 About the PMSA .............................................................................................. B5-1748
B5.2 Memory access control ................................................................................... B5-1753
B5.3 Memory region attributes ................................................................................ B5-1754
B5.4 PMSA memory aborts ..................................................................................... B5-1757
B5.5 Exception reporting in a PMSA implementation .............................................. B5-1761
B5.6 About the system control registers for PMSA .................................................. B5-1766
B5.7 Organization of the CP14 registers in a PMSA implementation ...................... B5-1778
B5.8 Organization of the CP15 registers in a PMSA implementation ...................... B5-1779
B5.9 Functional grouping of PMSAv7 system control registers ............................... B5-1791
B5.10 Pseudocode details of PMSA memory system operations .............................. B5-1798
Chapter B6 System Control Registers in a PMSA implementation

B6.1 PMSA System control registers descriptions, in register order ....................... B6-1802
B6.2 PMSA system control operations described by function ................................. B6-1932
Chapter B7 The CPUID Identification Scheme

B7.1 Introduction to the CPUID scheme .................................................................. B7-1938
B7.2 The CPUID registers ....................................................................................... B7-1939
B7.3 Advanced SIMD and Floating-point Extension feature identification registers B7-1944
Chapter B8 The Generic Timer

B8.1 About the Generic Timer ................................................................................. B8-1946
B8.2 Generic Timer registers summary ................................................................... B8-1955
Chapter B9 System Instructions

B9.1 General restrictions on system instructions ..................................................... B9-1958
B9.2 Encoding and use of Banked register transfer instructions ............................. B9-1959
B9.3 Alphabetical list of instructions ........................................................................ B9-1964
Part C Debug Architecture

Chapter C1 Introduction to the ARM Debug Architecture
C1.1 Scope of part C of this manual ........................................................................ C1-2008
C1.2 About the ARM Debug architecture ................................................................ C1-2009
C1.3 Security Extensions and debug ....................................................................... C1-2013
C1.4 Register interfaces .......................................................................................... C1-2014
Chapter C2 Invasive Debug Authentication

C2.1 About invasive debug authentication .............................................................. C2-2016
C2.2 Invasive debug with no Security Extensions ................................................... C2-2017
C2.3 Invasive debug with the Security Extensions .................................................. C2-2019
C2.4 Invasive debug authentication security considerations ................................... C2-2021
Chapter C3 Debug Events

C3.1 About debug events ........................................................................................ C3-2024
C3.2 BKPT instruction debug events ....................................................................... C3-2026
C3.3 Breakpoint debug events ................................................................................ C3-2027
C3.4 Watchpoint debug events ................................................................................ C3-2045
viii Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved. ARM DDI 0406C.d
C3.5 Vector catch debug events .............................................................................. C3-2053
C3.6 Halting debug events ...................................................................................... C3-2061
C3.7 Generation of debug events ............................................................................ C3-2062
C3.8 Debug event prioritization ............................................................................... C3-2064
C3.9 Pseudocode details of Software debug events ............................................... C3-2066
Chapter C4 Debug Exceptions

C4.1 About debug exceptions .................................................................................. C4-2076
C4.2 Avoiding debug exceptions that might cause UNPREDICTABLE behavior .... C4-2078
Chapter C5 Debug State

C5.1 About Debug state .......................................................................................... C5-2080
C5.2 Entering Debug state ...................................................................................... C5-2081
C5.3 Executing instructions in Debug state ............................................................. C5-2084
C5.4 Behavior of non-invasive debug in Debug state .............................................. C5-2092
C5.5 Exceptions in Debug state .............................................................................. C5-2093
C5.6 Memory system behavior in Debug state ........................................................ C5-2097
C5.7 Exiting Debug state ......................................................................................... C5-2098
Chapter C6 Debug Register Interfaces

C6.1 About the debug register interfaces ................................................................ C6-2102
C6.2 Synchronization of debug register updates ..................................................... C6-2103
C6.3 Access permissions ........................................................................................ C6-2105
C6.4 The CP14 debug register interface ................................................................. C6-2109
C6.5 The memory-mapped and recommended external debug interfaces .............. C6-2114
C6.6 Summary of the v7 Debug register interfaces ................................................. C6-2116
C6.7 Summary of the v7.1 Debug register interfaces .............................................. C6-2125
Chapter C7 Debug Reset and Powerdown Support

C7.1 Debug guidelines for systems with energy management capability ................ C7-2136
C7.2 Power domains and debug ............................................................................. C7-2137
C7.3 The OS Save and Restore mechanism ........................................................... C7-2140
C7.4 Reset and debug ............................................................................................. C7-2148
Chapter C8 The Debug Communications Channel and Instruction Transfer Register

C8.1 About the DCC and DBGITR .......................................................................... C8-2152
C8.2 Operation of the DCC and Instruction Transfer Register ................................ C8-2155
C8.3 Behavior of accesses to the DCC registers and DBGITR ............................... C8-2159
C8.4 Synchronization of accesses to the DCC and the DBGITR ............................ C8-2164
Chapter C9 Non-invasive Debug Authentication

C9.1 About non-invasive debug authentication ....................................................... C9-2170
C9.2 Non-invasive debug authentication ................................................................. C9-2171
C9.3 Effects of non-invasive debug authentication .................................................. C9-2173
Chapter C10 Sample-based Profiling

C10.1 Sample-based profiling ................................................................................. C10-2176
Chapter C11 The Debug Registers

C11.1 About the debug registers ............................................................................. C11-2180
C11.2 Debug register summary ............................................................................... C11-2181
C11.3 Debug identification registers ........................................................................ C11-2184
C11.4 Control and status registers .......................................................................... C11-2185
C11.5 Instruction and data transfer registers ........................................................... C11-2186
C11.6 Software debug event registers .................................................................... C11-2187
C11.7 Sample-based profiling registers ................................................................... C11-2188
C11.8 OS Save and Restore registers .................................................................... C11-2189
ARM DDI 0406C.d Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved. ix
C11.9 Memory system control registers .................................................................. C11-2190
C11.10 Management registers .................................................................................. C11-2191
C11.11 Register descriptions, in register order .......................................................... C11-2197
Chapter C12 The Performance Monitors Extension

C12.1 About the Performance Monitors .................................................................. C12-2288
C12.2 Accuracy of the Performance Monitors ......................................................... C12-2292
C12.3 Behavior on overflow ..................................................................................... C12-2293
C12.4 Effect of the Security Extensions and Virtualization Extensions ................... C12-2295
C12.5 Event filtering, PMUv2 ................................................................................... C12-2297
C12.6 Counter enables ............................................................................................ C12-2299
C12.7 Counter access ............................................................................................. C12-2300
C12.8 Event numbers and mnemonics .................................................................... C12-2301
C12.9 Performance Monitors registers .................................................................... C12-2314
Part D Appendixes
Appendix A Recommended External Debug Interface
D1.1 About the recommended external debug interface ......................................... D1-2324
D1.2 Authentication signals ..................................................................................... D1-2326
D1.3 Run-control and cross-triggering signals ......................................................... D1-2328
D1.4 Recommended debug slave port .................................................................... D1-2332
D1.5 Other debug signals ........................................................................................ D1-2334
Appendix B Recommended Memory-mapped and External Debug Interfaces for the

Performance Monitors
D2.1 About the memory-mapped views of the Performance Monitors registers ...... D2-2340
D2.2 PMU register descriptions for memory-mapped register views ....................... D2-2349
Appendix C Recommendations for Performance Monitors Event Numbers for

IMPLEMENTATION DEFINED Events
D3.1 ARM recommendations for IMPLEMENTATION DEFINED event numbers ... D3-2364
Appendix D Example OS Save and Restore Sequences for External Debug Over
Powerdown
D4.1 Example OS Save and Restore sequences for v7 Debug .............................. D4-2376
D4.2 Example OS Save and Restore sequences for v7.1 Debug ........................... D4-2380
Appendix E System Level Implementation of the Generic Timer

D5.1 About the Generic Timer specification ............................................................ D5-2384
D5.2 Memory-mapped counter module ................................................................... D5-2385
D5.3 Counter module control and status register summary ..................................... D5-2388
D5.4 Memory-mapped timer components ................................................................ D5-2390
D5.5 The CNTBaseN and CNTPL0BaseN frames .................................................. D5-2391
D5.6 The CNTCTLBase frame ................................................................................. D5-2393
D5.7 System level Generic Timer register descriptions, in register order ................ D5-2394
D5.8 Providing a complete set of counter and timer features .................................. D5-2411
D5.9 Gray-count scheme for timer distribution scheme ........................................... D5-2413
Appendix F Common VFP Subarchitecture Specification

D6.1 Scope of this appendix .................................................................................... D6-2417
D6.2 Introduction to the Common VFP subarchitecture .......................................... D6-2418
D6.3 Exception processing ...................................................................................... D6-2420
D6.4 Support code requirements ............................................................................. D6-2424
D6.5 Context switching ............................................................................................ D6-2426
D6.6 Subarchitecture additions to the Floating-point Extension system registers ... D6-2427
x Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved. ARM DDI 0406C.d
D6.7 Earlier versions of the Common VFP subarchitecture .................................... D6-2433
Appendix G Barrier Litmus Tests

D7.1 Introduction ..................................................................................................... D7-2436
D7.2 Simple ordering and barrier cases .................................................................. D7-2439
D7.3 Exclusive accesses and barriers ..................................................................... D7-2446
D7.4 Using a mailbox to send an interrupt ............................................................... D7-2448
D7.5 Cache and TLB maintenance operations and barriers .................................... D7-2449
Appendix H Legacy Instruction Mnemonics

D8.1 Thumb instruction mnemonics ........................................................................ D8-2456
D8.2 Other UAL mnemonic changes ....................................................................... D8-2457
D8.3 Pre-UAL pseudo-instruction NOP ................................................................... D8-2460
Appendix I Deprecated and Obsolete Features

D9.1 Deprecated features ........................................................................................ D9-2462
D9.2 Obsolete features ............................................................................................ D9-2471
D9.3 Use of the SP as a general-purpose register .................................................. D9-2472
D9.4 Explicit use of the PC in ARM instructions ...................................................... D9-2473
D9.5 Deprecated Thumb instructions ...................................................................... D9-2474
Appendix J Fast Context Switch Extension (FCSE)

D10.1 About the FCSE ............................................................................................ D10-2476
D10.2 Modified virtual addresses ............................................................................ D10-2477
D10.3 Debug and trace ............................................................................................ D10-2479
Appendix K VFP Vector Operation Support

D11.1 About VFP vector mode ................................................................................ D11-2482
D11.2 Vector length and stride control .................................................................... D11-2483
D11.3 VFP register banks ........................................................................................ D11-2484
D11.4 VFP instruction type selection ....................................................................... D11-2485
Appendix L ARMv6 Differences

D12.1 Introduction to ARMv6 ................................................................................... D12-2488
D12.2 Application level register support .................................................................. D12-2489
D12.3 Application level memory support ................................................................. D12-2492
D12.4 Instruction set support ................................................................................... D12-2495
D12.5 System level register support ........................................................................ D12-2500
D12.6 System level memory model ......................................................................... D12-2503
D12.7 System Control coprocessor, CP15, support ................................................ D12-2510
Appendix M v6 Debug and v6.1 Debug Differences

D13.1 About v6 Debug and v6.1 Debug .................................................................. D13-2534
D13.2 Invasive debug authentication, v6 Debug and v6.1 Debug ........................... D13-2535
D13.3 Debug events, v6 Debug and v6.1 Debug .................................................... D13-2536
D13.4 Debug exceptions, v6 Debug and v6.1 Debug .............................................. D13-2540
D13.5 Debug state, v6 Debug and v6.1 Debug ....................................................... D13-2541
D13.6 Debug register interfaces, v6 Debug and v6.1 Debug .................................. D13-2545
D13.7 Reset and powerdown support ..................................................................... D13-2548
D13.8 The Debug Communications Channel and Instruction Transfer Register ..... D13-2549
D13.9 Non-invasive debug authentication, v6 Debug and v6.1 Debug ................... D13-2550
D13.10 Sample-based profiling, v6 Debug and v6.1 Debug ...................................... D13-2552
D13.11 The debug registers, v6 Debug and v6.1 Debug .......................................... D13-2553
D13.12 Performance monitors, v6 Debug and v6.1 Debug ....................................... D13-2564
Appendix N Secure User Halting Debug

D14.1 About Secure User halting debug ................................................................. D14-2566
ARM DDI 0406C.d Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved. xi
D14.2 Invasive debug authentication in an implementation that supports SUHD .... D14-2567
D14.3 Effects of SUHD on Debug state ................................................................... D14-2568
Appendix O ARMv4 and ARMv5 Differences

D15.1 Introduction to ARMv4 and ARMv5 ............................................................... D15-2574
D15.2 Application level register support .................................................................. D15-2575
D15.3 Application level memory support ................................................................. D15-2576
D15.4 Instruction set support ................................................................................... D15-2581
D15.5 System level register support ........................................................................ D15-2587
D15.6 System level memory model ......................................................................... D15-2590
D15.7 System Control coprocessor, CP15 support ................................................. D15-2598
Appendix P Pseudocode Definition

D16.1 About the ARMv7 pseudocode ..................................................................... D16-2628
D16.2 Pseudocode for instruction descriptions ........................................................ D16-2629
D16.3 Data types ..................................................................................................... D16-2631
D16.4 Expressions ................................................................................................... D16-2635
D16.5 Operators and built-in functions .................................................................... D16-2637
D16.6 Statements and program structure ................................................................ D16-2642
D16.7 Miscellaneous helper procedures and functions ........................................... D16-2646
Appendix Q Pseudocode Index

D17.1 Pseudocode operators and keywords ........................................................... D17-2652
D17.2 Pseudocode functions and procedures ......................................................... D17-2655
Appendix R Registers Index

D18.1 Alphabetic index of ARMv7 registers, by register name ................................ D18-2672
D18.2 Full registers index ........................................................................................ D18-2683
Glossary
xii Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved. ARM DDI 0406C.d
Preface
This preface introduces the ARM® Architecture Reference Manual, ARM®v7-A and ARM®v7-R edition. It contains
the following sections:
• About this manual on page xiv
• Using this manual on page xvi
• Conventions on page xxi
• Additional reading on page xxiii
• Feedback on page xxiv.
ARM DDI 0406C.d Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved. xiii
Preface
About this manual
About this manual

This manual describes the A and R profiles of the ARM® architecture v7, ARMv7. It includes descriptions of:
• The processor instruction sets:

— the original ARM® instruction set
— the high code density Thumb® instruction set
— the ThumbEE instruction set, that includes specific support for Just-In-Time (JIT) or Ahead-Of-Time
(AOT) compilation.
• The modes and states that determine how a processor operates, including the current execution privilege and
security.
• The exception model.
• The memory model, that defines memory ordering and memory management:
— the ARMv7-A architecture profile defines a Virtual Memory System Architecture (VMSA)
— the ARMv7-R architecture profile defines a Protected Memory System Architecture (PMSA).
• The programmers’ model, and its use of a coprocessor interface to access system control registers that control
most processor and memory system features.
• The OPTIONAL Floating-point (VFP) Extension, that provides high-performance floating-point instructions
that support:
— single-precision and double-precision operations
— conversions between double-precision, single-precision, and half-precision floating-point values.
• The OPTIONAL Advanced SIMD Extension, that provides high-performance integer and single-precision
floating-point vector operations.
• The OPTIONAL Security Extensions, that facilitate the development of secure applications.
• The OPTIONAL Virtualization Extensions, that support the virtualization of Non-secure operation.
• The Debug architecture, that provides software access to debug features in the processor.
Note
ARMv7 introduces the architecture profiles. A separate Architecture Reference Manual describes the third profile,
the Microcontroller profile, ARMv7-M. For more information see Architecture versions, profiles, and variants on
page A1-30.
This manual gives the assembler syntax for the instructions it describes, meaning it can specify instructions in
textual form. However, this manual is not a tutorial for ARM assembler language, nor does it describe ARM
assembler language, except at a very basic level. To make effective use of ARM assembler language, read the
documentation supplied with the assembler being used.
This manual is organized into parts:
Part A Describes the application level view of the architecture. It describes the application level view of
the programmers’ model and the memory model. It also describes the precise effects of each
instruction in User mode, the normal operating mode, including any restrictions on its use. This
information is of primary importance to authors and users of compilers, assemblers, and other
programs that generate ARM machine code. Software execution in User mode is at the PL0
privilege level, also described as unprivileged.
Note
User mode is the only mode where software execution is unprivileged.
xiv Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved. ARM DDI 0406C.d
Preface
About this manual
Part B Describes the system level view of the architecture. It gives details of system registers, most of
which are not accessible from PL0, and the system level view of the memory model. It also gives
full details of the effects of instructions executed with some level of privilege, where these are
different from their effects in unprivileged execution.
Part C Describes the Debug architecture. This is an extension to the ARM architecture that provides
configuration, breakpoint and watchpoint support, and a Debug Communications Channel (DCC)
to a debug host.
Appendixes Provide additional information that is not part of the ARMv7 architectural requirements, including
descriptions of:
• features that are recommended but not required
• differences in previous versions of the architecture.
ARM DDI 0406C.d Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved. xv
Preface
Using this manual
Using this manual

The information in this manual is organized into parts, as described in this section.
Part A, Application Level Architecture

Part A describes the application level view of the architecture. It contains the following chapters:
Chapter A1 Introduction to the ARM Architecture

Gives an overview of the ARM architecture, and the ARM and Thumb instruction sets.
Chapter A2 Application Level Programmers’ Model

Describes the application level view of the ARM programmers’ model, including the application
level view of the Advanced SIMD and Floating-point Extensions. It describes the types of values
that ARM instructions operate on, the ARM core registers that contain those values, and the
Application Program Status Register.
Chapter A3 Application Level Memory Model

Describes the application level view of the memory model, including the ARM memory types and
attributes, and memory access control.
Chapter A4 The Instruction Sets

Describes the range of instructions available in the ARM, Thumb, Advanced SIMD, and VFP
instruction sets. It also contains some details of instruction operation that are common to several
instructions.
Chapter A5 ARM Instruction Set Encoding

Describes the encoding of the ARM instruction set.
Chapter A6 Thumb Instruction Set Encoding

Describes the encoding of the Thumb instruction set.
Chapter A7 Advanced SIMD and Floating-point Instruction Encoding

Describes the encoding of the Advanced SIMD and Floating-point Extension (VFP) instruction sets.
Chapter A8 Instruction Descriptions

Gives a full description of every instruction available in the Thumb, ARM, Advanced SIMD, and
Floating-point Extension instruction sets, with the exception of information only relevant to
execution with some level of privilege.
Chapter A9 The ThumbEE Instruction Set

Gives a full description of the Thumb Execution Environment variant of the Thumb instruction set.
This means it describes the ThumbEE instruction set.
xvi Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved. ARM DDI 0406C.d
Preface
Using this manual
Part B, System Level Architecture

Part B describes the system level view of the architecture. It contains the following chapters:
Chapter B1 System Level Programmers’ Model

Describes the system level view of the programmers’ model.
Chapter B2 Common Memory System Architecture Features

Describes the system level view of the memory model features that are common to all memory
systems.
Chapter B3 Virtual Memory System Architecture (VMSA)

Describes the system level view of the Virtual Memory System Architecture (VMSA) that is part of
all ARMv7-A implementations. This chapter includes a description of the organization and general
properties of the system control registers in a VMSA implementation.
Chapter B4 System Control Registers in a VMSA implementation

Describes all of the system control registers in VMSA implementation, including the registers that
are part of the OPTIONAL extensions to a VMSA implementation. The registers are described in
alphabetical order.
Chapter B5 Protected Memory System Architecture (PMSA)

Describes the system level view of the Protected Memory System Architecture (PMSA) that is part
of all ARMv7-R implementations. This chapter includes a description of the organization and
general properties of the system control registers in a PMSA implementation.
Chapter B6 System Control Registers in a PMSA implementation

Describes all of the system control registers in PMSA implementation, including the registers that
are part of the OPTIONAL extensions to a PMSA implementation. The registers are described in
alphabetical order.
Chapter B7 The CPUID Identification Scheme

Describes the CPUID scheme. This provides registers that identify the architecture version and
many features of the processor implementation. This chapter also describes the registers that
identify the implemented Advanced SIMD and VFP features, if any.
Chapter B8 The Generic Timer

Describes the OPTIONAL Generic Timer architecture extension.
Chapter B9 System Instructions

Provides detailed reference information about system instructions, and more information about
instructions that behave differently when executed with some level of privilege.
Part C, Debug Architecture

Part C describes the Debug architecture. It contains the following chapters:
Chapter C1 Introduction to the ARM Debug Architecture

Introduces the Debug architecture, defining the scope of this part of the manual.
Chapter C2 Invasive Debug Authentication

Describes the authentication of invasive debug.
Chapter C3 Debug Events

Describes the debug events.
ARM DDI 0406C.d Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved. xvii
Preface
Using this manual
Chapter C4 Debug Exceptions

Describes the debug exceptions that handle debug events when the processor is configured for
Monitor debug-mode.
Chapter C5 Debug State

Describes Debug state that is entered if a debug event occurs when the processor is configured for
Halting debug-mode.
Chapter C6 Debug Register Interfaces

Describes the permitted debug register interfaces and the options for their implementation.
Chapter C7 Debug Reset and Powerdown Support

Describes the reset and powerdown support in the Debug architecture, including support for debug
over powerdown.
Chapter C8 The Debug Communications Channel and Instruction Transfer Register

Describes the Debug Communication Channel (DCC) and Instruction Transfer Register (ITR), and
how an external debugger uses these features to communicate with the debug logic.
Chapter C9 Non-invasive Debug Authentication

Describes the authentication of non-invasive debug.
Chapter C10 Sample-based Profiling

Describes sample-based profiling, that provides sampling of the program counter.
Chapter C11 The Debug Registers

Describes the debug registers.
Chapter C12 The Performance Monitors Extension

Describes the OPTIONAL Performance Monitors Extension.
Part D, Appendixes
This manual contains the following appendixes:
Appendix D1 Recommended External Debug Interface

Describes the recommended external interface to the ARM debug architecture.
Note
This description is not part of the ARM architecture specification. It is included here as
supplementary information, for the convenience of developers and users who might require this
information.
Appendix D2 Recommended Memory-mapped and External Debug Interfaces for the Performance Monitors
Describes the recommended external interfaces to the Performance Monitors Extension.
Note
information.
Appendix D3 Recommendations for Performance Monitors Event Numbers for IMPLEMENTATION

DEFINED Events
Gives the ARM recommendations for the use of the event numbers in the IMPLEMENTATION
DEFINED event number space.
xviii Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved. ARM DDI 0406C.d
Preface
Using this manual
Note
information.
Appendix D4 Example OS Save and Restore Sequences for External Debug Over Powerdown
Gives software examples that perform the OS Save and Restore sequences, for v7 Debug and v7.1
Debug implementations.
Note
Chapter C7 Debug Reset and Powerdown Support describes the OS Save and Restore mechanism,
for both v7 Debug and v7.1 Debug.
Appendix D5 System Level Implementation of the Generic Timer

Contains the ARM Generic Timer architecture specification for the memory-mapped interface to
the Generic Timer.
Note
information.
Appendix D6 Common VFP Subarchitecture Specification

Defines version 2 of the Common VFP Subarchitecture.
Note
This specification is not part of the ARM architecture specification. This sub-architectural
information is included here as supplementary information, for the convenience of developers and
users who might require this information.
Appendix D7 Barrier Litmus Tests

Gives examples of the use of the barrier instructions provided by the ARMv7 architecture.
Note
These examples are not part of the ARM architecture specification. They are included here as
information.
Appendix D8 Legacy Instruction Mnemonics

Describes the legacy mnemonics and their Unified Assembler Language equivalents.
Appendix D9 Deprecated and Obsolete Features

Lists the deprecated architectural features, with references to their descriptions in parts A to C of
the manual.
Appendix D10 Fast Context Switch Extension (FCSE)

Describes the Fast Context Switch Extension (FCSE). See the appendix for information about the
status of this in different versions of the ARM architecture.
Appendix D11 VFP Vector Operation Support

Describes the VFP vector operations. ARM deprecates the use of these operations.
ARM DDI 0406C.d Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved. xix
Preface
Using this manual
Appendix D12 ARMv6 Differences

Describes how the ARMv6 architecture differs from the description given in parts A and B of this
manual.
Appendix D13 v6 Debug and v6.1 Debug Differences

Describes how the two debug architectures for ARMv6 differ from the description given in part C
of this manual.
Appendix D14 Secure User Halting Debug

Describes the Secure User halting debug (SUHD) feature.
Appendix D15 ARMv4 and ARMv5 Differences

Describes how the ARMv4 and ARMv5 architectures differ from the description given in parts A
and B of this manual.
Appendix D16 Pseudocode Definition

The formal definition of the pseudocode used in this manual.
Appendix D17 Pseudocode Index

Gives indexes to definitions of pseudocode operators, keywords, functions, and procedures.
Appendix D18 Registers Index

Gives indexes to register descriptions in the manual.
xx Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved. ARM DDI 0406C.d
Preface
Conventions
Conventions
The following sections describe conventions that this book can use:
• Typographic conventions
• Signals
• Numbers on page xxii
• Pseudocode descriptions on page xxii
• Assembler syntax descriptions on page xxii.
Typographic conventions
The typographic conventions are:
italic Introduces special terminology, and denotes citations.
bold Denotes signal names, and is used for terms in descriptive lists, where appropriate.
monospace Used for assembler syntax descriptions, pseudocode, and source code examples.
Also used in the main text for instruction mnemonics and for references to other items appearing in
assembler syntax descriptions, pseudocode, and source code examples.
SMALL CAPITALS
Used in body text for a few terms that have specific technical meanings, and are defined in the
Glossary.
Colored text Indicates a link. This can be:

• a URL, for example http://infocenter.arm.com
• a cross-reference, that includes the page number of the referenced information if it is not on
the current page, for example, Pseudocode descriptions on page xxii
• a link, to a chapter or appendix, or to a glossary entry, or to the section of the document that
defines the colored term, for example Simple sequential execution or SCTLR.
Note
Many links are to a register or instruction definition. Remember that:
• many system control registers are defined both in Chapter B4 System Control Registers in a
VMSA implementation and in Chapter B6 System Control Registers in a PMSA
implementation
• many instructions are defined in multiple forms, and in some cases the ARM encodings of an
instruction are defined separately to the Thumb encodings.
Ensure that any linked definition you refer to is appropriate to your context.
Signals
In general this specification does not define processor signals, but it does include some signal examples and
recommendations. The signal conventions are:
Signal level The level of an asserted signal depends on whether the signal is active-HIGH or
active-LOW. Asserted means:
• HIGH for active-HIGH signals
• LOW for active-LOW signals.
Lower-case n At the start or end of a signal name denotes an active-LOW signal.
ARM DDI 0406C.d Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved. xxi
Preface
Conventions
Numbers
Numbers are normally written in decimal. Binary numbers are preceded by 0b, and hexadecimal numbers by 0x. In
both cases, the prefix and the associated value are written in a monospace font, for example 0xFFFF0000.
Pseudocode descriptions
This manual uses a form of pseudocode to provide precise descriptions of the specified functionality. This
pseudocode is written in a monospace font, and is described in Appendix D16 Pseudocode Definition.
Assembler syntax descriptions

This manual contains numerous syntax descriptions for assembler instructions and for components of assembler
instructions. These are shown in a monospace font, and use the conventions described in Assembler syntax on
page A8-281.
xxii Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved. ARM DDI 0406C.d
Preface
Additional reading
Additional reading
This section lists relevant publications from ARM and third parties.
See the Infocenter http://infocenter.arm.com, for access to ARM documentation.
ARM publications
• ARM® Debug Interface v5 Architecture Specification (ARM IHI 0031).
• ARM®v7-M Architecture Reference Manual (ARM DDI 0403).
• ARM CoreSight™ Architecture Specification (ARM IHI 0029).
• ARM® Architecture Reference Manual (ARM DDI 0100I).
Note
— Issue I of the ARM Architecture Reference Manual (DDI 0100I) was issued in July 2005 and describes
the first version of the ARMv6 architecture, and all previous architecture versions.
— Addison-Wesley Professional publish ARM Architecture Reference Manual, Second Edition
(December 27, 2000). The contents of this are identical to issue E of the ARM Architecture Reference
Manual (DDI 0100E). It describes ARMv5TE and earlier versions of the ARM architecture, and is
superseded by DDI 0100I.
• ARM Embedded Trace Macrocell Architecture Specification (ARM IHI 0014).

• ARM CoreSight™ Program Flow Trace Architecture Specification (ARM IHI 0035).
• ARM® Generic Interrupt Controller Architecture Specification (ARM IHI 0048).
Other publications
The following books are referred to in this manual, or provide more information:
• IEEE Std 1596.5-1993, IEEE Standard for Shared-Data Formats Optimized for Scalable Coherent Interface
(SCI) Processors, ISBN 1-55937-354-7.
• IEEE Std 1149.1-2001, IEEE Standard Test Access Port and Boundary Scan Architecture (JTAG).
• ANSI/IEEE Std 754-2008, and ANSI/IEEE Std 754-1985, IEEE Standard for Binary Floating-Point
Arithmetic. See also Floating-point standards, and terminology on page A2-55.
• JEDEC Solid State Technology Association, Standard Manufacturer’s Identification Code, JEP106.
• Tim Lindholm and Frank Yellin, The Java Virtual Machine Specification, Second Edition, Addison Wesley,
ISBN: 0-201-43294-3.
• Kourosh Gharachorloo, Memory Consistency Models for Shared Memory-Multiprocessors, 1995, Stanford
University Technical Report CSL-TR-95-685.
ARM DDI 0406C.d Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved. xxiii
Preface
Feedback
Feedback
ARM welcomes feedback on its documentation.
Feedback on this manual

If you have comments on the content of this manual, send e-mail to errata@arm.com. Give:
• the title
• the number, ARM DDI 0406C.d
• the page numbers to which your comments apply
• a concise explanation of your comments.
ARM also welcomes general suggestions for additions and improvements.
xxiv Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved. ARM DDI 0406C.d
Part A
Application Level Architecture
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-28.
• The instruction sets on page A1-29.
• Architecture versions, profiles, and variants on page A1-30.
• Architecture extensions on page A1-32.
• The ARM memory model on page A1-35.
ARM DDI 0406C.d Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved. A1-27
A1 Introduction to the ARM Architecture
A1.1 About the ARM architecture
A1.1 About the ARM architecture

The ARM architecture supports implementations across a wide range of performance points. The architectural
simplicity of ARM processors leads to very small implementations, and small implementations mean devices can
have very low power consumption. Implementation size, performance, and very low power consumption are key
attributes of the ARM architecture.
The ARM architecture is a Reduced Instruction Set Computer (RISC) architecture, as it incorporates these 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.
In addition, the ARM architecture provides:
• Instructions that combine a shift with an arithmetic or logical operation.
• Auto-increment and auto-decrement addressing modes to optimize program loops.
• Load and Store Multiple instructions to maximize data throughput.
• Conditional execution of many instructions to maximize execution throughput.
These enhancements to a basic RISC architecture mean ARM processors achieve a good balance of high
performance, small program size, low power consumption, and small silicon area.
This Architecture Reference Manual defines a set of behaviors to which an implementation must conform, and a set
of rules for software to use the implementation. It does not describe how to build an implementation.
Except where the architecture specifies differently, the programmer-visible behavior of an implementation must be
the same as a simple sequential execution of the program. This programmer-visible behavior does not include the
execution time of the program.
The ARM architecture includes definitions of:
• An associated debug architecture, see Debug architecture versions on page A1-31 and Part C of this manual.
• Associated trace architectures, which define trace macrocells that implementers can implement with the
associated processor. For more information, see the ARM Embedded Trace Macrocell Architecture
Specification and the ARM CoreSight™ Program Flow Trace Architecture Specification.
A1-28 Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved. ARM DDI 0406C.d
A1.2 The instruction sets
A1.2 The instruction sets

The ARM instruction set is a set of 32-bit instructions providing comprehensive data-processing and control
functions.
The Thumb instruction set was developed as a 16-bit instruction set with a subset of the functionality of the ARM
instruction set. It provides significantly improved code density, at a cost of some reduction in performance. A
processor executing Thumb instructions can change to executing ARM instructions for performance critical
segments, in particular for handling interrupts.
ARMv6T2 introduced Thumb-2 technology. This technology extends the original Thumb instruction set with many
32-bit instructions. The range of 32-bit Thumb instructions included in ARMv6T2 permits Thumb code to achieve
performance similar to ARM code, with code density better than that of earlier Thumb code.
From ARMv6T2, the ARM and Thumb instruction sets provide almost identical functionality. For more
information, see Chapter A4 The Instruction Sets.
A1.2.1 Execution environment support

Two additional instruction sets support execution environments:
• The architecture can provide hardware acceleration of Java bytecodes. For more information, see:
— Jazelle direct bytecode execution support on page A2-96, for application level information.
— Jazelle direct bytecode execution on page B1-1240, for system level information.
The Virtualization Extensions do not support hardware acceleration of Java bytecodes. That is, they support
only a trivial implementation of the Jazelle® extension.
• The ThumbEE instruction set is a variant of the Thumb instruction set that minimizes the code size overhead
of a Just-In-Time (JIT) or Ahead-Of-Time (AOT) compiler. JIT and AOT compilers convert execution
environment source code to a native executable. For more information, see:
— Thumb Execution Environment on page A2-94, for application level information.
— Thumb Execution Environment on page B1-1239, for system level information.
From the publication of issue C.a of this manual, ARM deprecates any use of the ThumbEE instruction set.
A1.3 Architecture versions, profiles, and variants

The ARM architecture has evolved significantly since its introduction, and ARM continues to develop it. Seven
major versions of the architecture have been defined to date, denoted by the version numbers 1 to 7. Of these, the
first three versions are now obsolete.
ARMv7 provides three profiles:
ARMv7-A Application profile, described in this manual:

• Implements a traditional ARM architecture with multiple modes.
• Supports a Virtual Memory System Architecture (VMSA) based on a Memory Management
Unit (MMU). An ARMv7-A implementation can be called a VMSAv7 implementation.
• Supports the ARM and Thumb instruction sets.
ARMv7-R Real-time profile, described in this manual:

• Implements a traditional ARM architecture with multiple modes.
• Supports a Protected Memory System Architecture (PMSA) based on a Memory Protection
Unit (MPU). An ARMv7-R implementation can be called a PMSAv7 implementation.
• Supports the ARM and Thumb instruction sets.
ARMv7-M Microcontroller profile, described in the ARMv7-M Architecture Reference Manual:

• Implements a programmers' model designed for low-latency interrupt processing, with
hardware stacking of registers and support for writing interrupt handlers in high-level
languages.
• Implements a variant of the ARMv7 PMSA.
• Supports a variant of the Thumb instruction set.
Note
Parts A, B, and C of this Architecture Reference Manual describe the ARMv7-A and ARMv7-R profiles:
• Appendixes describe how the ARMv4-ARMv6 architecture versions differ from ARMv7.
• Separate Architecture Reference Manuals define the M-profile architectures, see Additional reading on
page xxiii.
Architecture versions can be qualified with variant letters to specify additional instructions and other functionality
that are included as an architecture extension.
Some extensions are described separately instead of using a variant letter. For details of these extensions, see
Architecture extensions on page A1-32.
The valid variants of ARMv4, ARMv5, and ARMv6 are as follows:
ARMv4 The earliest architecture variant covered by this manual. It includes only the ARM instruction set.
ARMv4T Adds the Thumb instruction set.
ARMv5T Improves interworking of ARM and Thumb instructions. Adds Count Leading Zeros (CLZ) and
Software Breakpoint (BKPT) instructions.
ARMv5TE Enhances arithmetic support for digital signal processing (DSP) algorithms. Adds Preload Data
(PLD), Load Register Dual (LDRD), Store Register Dual (STRD), and 64-bit coprocessor register transfer
(MCRR, MRRC) instructions.
ARMv5TEJ Adds the BXJ instruction and other support for the Jazelle® architecture extension.
ARMv6 Adds many new instructions to the ARM instruction set. Formalizes and revises the memory model
and the Debug architecture.
ARMv6K Adds instructions to support multiprocessing to the ARM instruction set, and some extra memory
model features.
ARMv6T2 Introduces Thumb-2 technology, that supports a major development of the Thumb instruction set to
provide a similar level of functionality to the ARM instruction set.
Note
Where appropriate, the terms ARMv6KZ or ARMv6Z describe the ARMv6K architecture with the ARMv6
Security Extensions, that were an OPTIONAL addition to the VMSAv6 architecture.
For detailed information about how earlier versions of the ARM architecture differ from ARMv7, see
Appendix D12 ARMv6 Differences and Appendix D15 ARMv4 and ARMv5 Differences.
The following architecture variants are now obsolete:
ARMv1, ARMv2, ARMv2a, ARMv3, ARMv3G, ARMv3M, ARMv4xM, ARMv4TxM, ARMv5, ARMv5xM,
ARMv5TxM, and ARMv5TExP.
Contact ARM if you require details of obsolete variants.
Each instruction description in this manual specifies the architecture versions that include the instruction.
A1.3.1 Debug architecture versions

Before ARMv6, the debug implementation for an ARM processor was IMPLEMENTATION DEFINED. ARMv6 defined
the first debug architecture.
The debug architecture versions are:
v6 Debug Introduced with the original ARMv6 architecture definition.
v6.1 Debug Introduced to ARMv6K with the OPTIONAL Security Extensions, described in Architecture
extensions on page A1-33. A VMSAv6 implementation that includes the Security Extensions must
implement v6.1 Debug.
v7 Debug First defined in issue A of this manual, and required by any ARMv7-R implementation
An ARMv7-A implementation that does not include the Virtualization Extensions must implement
either v7 Debug or v7.1 Debug.
For more information about the Virtualization Extensions, see Architecture extensions on
page A1-33.
v7.1 Debug First defined in issue C.a of this manual, and required by any ARMv7-A implementation that
includes the Virtualization Extensions.
For more information, see:

• Chapter C1 Introduction to the ARM Debug Architecture, for v7 Debug and v7.1 Debug.
• About v6 Debug and v6.1 Debug on page D13-2534, for v6 Debug and v6.1 Debug.
Note
In this manual:
• Debug usually refers to invasive debug, that permits modification of the state of the processor.
• Trace usually refers to non-invasive debug, that does not permit modification of the state of the processor.
For more information, see About the ARM Debug architecture on page C1-2009.
A1.4 Architecture extensions

Instruction set architecture extensions summarizes the extensions that mainly affect the Instruction Set Architecture
(ISA), either extending the instructions implemented in the ARM and Thumb instruction sets, or implementing an
additional instruction set.
Architecture extensions on page A1-33 describes other extensions to the architecture.
A1.4.1 Instruction set architecture extensions

This manual describes the following extensions to the ISA:
Jazelle Is the Java bytecode execution extension that extended ARMv5TE to ARMv5TEJ. From
ARMv6, the architecture requires at least the trivial Jazelle implementation, but a Jazelle
implementation is still often described as a Jazelle extension.
The Virtualization Extensions require that the Jazelle implementation is the trivial Jazelle
implementation.
ThumbEE Is an extension that provides the ThumbEE instruction set, a variant of the Thumb
instruction set that is designed as a target for dynamically generated code. In the original
release of the ARMv7 architecture, the ThumbEE extension was:
• A required extension to the ARMv7-A profile.
• An optional extension to the ARMv7-R profile.
From publication of issue C.a of this manual, ARM deprecates any use of ThumbEE
instructions. However, ARMv7-A implementations must continue to include ThumbEE
support, for backwards compatibility.
Floating-point Is a floating-point coprocessor extension to the instruction set architectures. For historic
reasons, the Floating-point Extension is also called the VFP Extension. There have been the
following versions of the Floating-point (VFP) Extension:
VFPv1 Obsolete. Details are available on request from ARM.
VFPv2 An optional extension to:
• The ARM instruction set in the ARMv5TE, ARMv5TEJ, ARMv6, and
ARMv6K architectures.
• The ARM and Thumb instruction sets in the ARMv6T2 architecture.
VFPv3 An OPTIONAL extension to the ARM, Thumb, and ThumbEE instruction sets in
the ARMv7-A and ARMv7-R profiles.
VFPv3 can be implemented with either 32 or 16 doubleword registers, as
described in Advanced SIMD and Floating-point Extension registers on
page A2-56. Where necessary, the terms VFPv3-D32 and
VFPv3-D16distinguish between these two implementation options. Where the
term VFPv3 is used it covers both options.
VFPv3U is a variant of VFPv3 that supports the trapping of floating-point
exceptions to support code, see VFPv3U and VFPv4U on page A2-61.
VFPv3 with Half-precision Extension
VFPv3 and VFPv3U can be extended by the OPTIONAL Half-precision
Extension, that provides conversion functions in both directions between
half-precision floating-point and single-precision floating-point.
VFPv4 An OPTIONAL extension to the ARM, Thumb, and ThumbEE instruction sets in
the ARMv7-A and ARMv7-R profiles.
VFPv4U is a variant of VFPv4 that supports the trapping of floating-point
exceptions to support code, see VFPv3U and VFPv4U on page A2-61.
VFPv4 and VFPv4U add both the Half-precision Extension and the fused
multiply-add instructions to the features of VFPv3. VFPv4 can be implemented
with either 32 or 16 doubleword registers, see Advanced SIMD and
Floating-point Extension registers on page A2-56. Where necessary, these
implementation options are distinguished using the terms:
• VFPv4-D32, or VFPv4U-D32, for a 32 register implementation.
• VFPv4-D16, or VFPv4U-D16, for a 16 register implementation.
Where the term VFPv4 is used it covers both options.
If an implementation includes both the Floating-point and Advanced SIMD Extensions:
• It must implement the corresponding versions of the extensions:
— If the implementation includes VFPv3 it must include Advanced SIMDv1.
— If the implementation includes VFPv3 with the Half-precision Extension it
must include Advanced SIMDv1 with the half-precision extensions.
— If the implementation includes VFPv4 it must include Advanced SIMDv2.
• The two extensions use the same register bank. This means VFP must be
implemented as VFPv3-D32, or as VFPv4-D32.
• Some instructions apply to both extensions.
Advanced SIMD Is an instruction set extension that provides Single Instruction Multiple Data (SIMD)
integer and single-precision floating-point vector operations on doubleword and quadword
registers. There have been the following versions of Advanced SIMD:
Advanced SIMDv1
It is an OPTIONAL extension to the ARMv7-A and ARMv7-R profiles.
Advanced SIMDv1 with Half-precision Extension
Advanced SIMDv1 can be extended by the OPTIONAL Half-precision Extension,
that provides conversion functions in both directions between half-precision
floating-point and single-precision floating-point.
Advanced SIMDv2
It is an OPTIONAL extension to the ARMv7-A and ARMv7-R profiles.
Advanced SIMDv2 adds both the Half-precision Extension and the fused
multiply-add instructions to the features of Advanced SIMDv1.
See the description of the Floating-point Extension for more information about
implementations that include both the Floating-point Extension and the Advanced SIMD
Extension.
A1.4.2 Architecture extensions

This manual also describes the following extensions to the ARMv7 architecture:
Security Extensions
Are an OPTIONAL SET OF extensions to VMSAv6 implementations of the ARMv6K architecture, and
to the ARMv7-A architecture profile, that provide a set of security features that facilitate the
development of secure applications.
Multiprocessing Extensions
Are an OPTIONAL SET OF extensions to the ARMv7-A and ARMv7-R profiles, that provides a set of
features that enhance multiprocessing functionality.
Large Physical Address Extension

Is an OPTIONAL extension to VMSAv7 that provides an address translation system supporting
physical addresses of up to 40 bits at a fine grain of translation.
The Large Physical Address Extension requires implementation of the Multiprocessing Extensions.
Virtualization Extensions
Are an OPTIONAL set of extensions to VMSAv7 that provides hardware support for virtualizing the
Non-secure state of a VMSAv7 implementation. This supports system use of a virtual machine
monitor, also called a hypervisor, to switch Guest operating systems.
The Virtualization Extensions require implementation of:
• The Security Extensions.
• The Large Physical Address Extension.
• The v7.1 Debug architecture, see Scope of part C of this manual on page C1-2008.
If an implementation that includes the Virtualization Extensions also implements:
• The Performance Monitors Extension, then it must implement version 2 of that extension,
PMUv2, see About the Performance Monitors on page C12-2288.
• A trace macrocell, that trace macrocell must support the Virtualization Extensions. In
particular, if the trace macrocell is:
— An Embedded Trace Macrocell (ETM), the macrocell must implement ETMv3.5 or
later, see the Embedded Trace Macrocell Architecture Specification.
— A Program Trace Macrocell (PTM), the macrocell must implement PFTv1.1 or later,
see the CoreSight Program Flow Trace Architecture Specification.
In some tables in this manual, an ARMv7-A implementation that includes the Virtualization
Extensions is described as ARMv7VE, or as v7VE.
Generic Timer Extension

Is an OPTIONAL extension to any ARMv7-A or ARMv7-R, that provides a system timer, and a
low-latency register interface to it.
This extension is introduced with the Large Physical Address Extension and Virtualization
Extensions, but can be implemented with any earlier version of the ARMv7 architecture. The
Generic Timer Extension does not require the implementation of any of the extensions described in
this subsection.
For more information, see Chapter B8 The Generic Timer.
Performance Monitors Extension

The ARMv7 architecture:
• Reserves CP15 register space for IMPLEMENTATION DEFINED performance monitors.
• Defines a recommended performance monitors implementation.
From issue C.a of this manual, this recommended implementation is called the Performance
Monitors Extension.
The Performance Monitors Extension does not require the implementation of any of the extensions
described in this subsection.
If an ARMv7 implementation that includes v7.1 Debug also includes the Performance Monitors
Extension, it must implement PMUv2.
For more information, see Chapter C12 The Performance Monitors Extension.
Note
The Fast Context Switch Extension (FCSE) is an older ARM extension, described in Appendix D10:
• ARM deprecates any use of this extension. This means in ARMv7 implementations before the introduction
of the Multiprocessing Extensions, the FCSE is OPTIONAL and deprecated.
• The Multiprocessing Extensions obsolete the FCSE. This means that any processor that includes the
Multiprocessing Extensions cannot include the FCSE. This includes all processors that implement the Large
Physical Address Extension.
A1.5 The ARM memory model

The ARM instruction sets address a single, flat address space of 232 8-bit bytes. This address space is also regarded
as 230 32-bit words or 231 16-bit halfwords.
The architecture provides facilities for:
• Generating an exception on an unaligned memory access.
• Restricting access by applications to specified areas of memory.
• Translating virtual addresses provided by executing instructions into physical addresses.
• Altering the interpretation of word and halfword data between big-endian and little-endian.
• Controlling the order of accesses to memory.
• Controlling caches.
• Synchronizing access to shared memory by multiple processors.

• Chapter A3 Application Level Memory Model.
• Chapter B2 Common Memory System Architecture Features.
• Chapter B3 Virtual Memory System Architecture (VMSA).
• Chapter B5 Protected Memory System Architecture (PMSA).
Chapter A2
Application Level Programmers’ Model
This chapter gives an application level view of the ARM programmers’ model. It contains the following sections:
• About the Application level programmers’ model on page A2-38.
• ARM core data types and arithmetic on page A2-40.
• ARM core registers on page A2-45.
• The Application Program Status Register (APSR) on page A2-49.
• Execution state registers on page A2-50.
• Advanced SIMD and Floating-point Extensions on page A2-54.
• Floating-point data types and arithmetic on page A2-62.
• Polynomial arithmetic over {0, 1} on page A2-92.
• Coprocessor support on page A2-93.
• Thumb Execution Environment on page A2-94.
• Jazelle direct bytecode execution support on page A2-96.
• Exceptions, debug events and checks on page A2-101.
Note
In this chapter, system register names usually link to the description of the register in Chapter B4 System Control
Registers in a VMSA implementation, for example FPSCR. If the register is included in a PMSA implementation,
then it is also described in Chapter B6 System Control Registers in a PMSA implementation.
A2 Application Level Programmers’ Model
A2.1 About the Application level programmers’ model

This chapter contains the programmers’ model information required for application development.
The information in this chapter is distinct from the system information required to service and support application
execution under an operating system, or higher level of system software. However, some knowledge of that system
information is needed to put the Application level programmers' model into context.
Depending on the implemented architecture extensions, the architecture supports multiple levels of execution
privilege, that number upwards from PL0, where PL0 is the lowest privilege level and is often described as
unprivileged. The Application level programmers’ model is the programmers’ model for software executing at PL0.
For more information see Processor privilege levels, execution privilege, and access privilege on page A3-139.
System software determines the privilege level at which application software runs. When an operating system
supports execution at both PL1 and PL0, an application usually runs unprivileged. This:
• Permits the operating system to allocate system resources to an application in a unique or shared manner.
• Provides a degree of protection from other processes and tasks, and so helps protect the operating system
from malfunctioning applications.
This chapter indicates where some system level understanding is helpful, and if appropriate it gives a reference to
the system level description in Chapter B1 System Level Programmers’ Model, or elsewhere.
The Security Extensions extend the architecture to provide hardware security features that support the development
of secure applications, by providing two Security states. The Virtualization Extensions further extend the
architecture to provide virtualization of operation in Non-secure state. However, application level software is
generally unaware of these extensions. For more information, see The Security Extensions on page B1-1156 and The
Virtualization Extensions on page B1-1161.
Note
• When an implementation includes the Security Extensions, application and operating system software
normally executes in Non-secure state.
• The virtualization features accessible only at PL2 are implemented only in Non-secure state. Secure state has
only two privilege levels, PL0 and PL1.
• Older documentation, describing implementations or architecture versions that support only two privilege
levels, often refers to execution at PL1 as privileged execution.
• In this manual, the following terms have special meanings, defined in the Glossary:
— IMPLEMENTATION DEFINED, see IMPLEMENTATION DEFINED.
— OPTIONAL, see OPTIONAL.
— SUBARCHITECTURE DEFINED, see SUBARCHITECTURE DEFINED.
— UNDEFINED, see UNDEFINED.
— UNKNOWN, see UNKNOWN.
— UNPREDICTABLE, see UNPREDICTABLE.
A2.1.1 Instruction sets, arithmetic operations, and register files

The ARM and Thumb instruction sets both provide a wide range of integer arithmetic and logical operations, that
operate on register file of sixteen 32-bit registers, the ARM core registers. As described in ARM core registers on
page A2-45, these registers include the special registers SP, LR, and PC. ARM core data types and arithmetic on
page A2-40 gives more information about these operations.
In addition, if an implementation includes:
• The Floating-point (VFP) Extension, the ARM and Thumb instruction sets include floating-point
instructions.
• The Advanced SIMD Extension, the ARM and Thumb instruction sets include vector instructions.
Floating-point and vector instructions operate on an independent register file, described in Advanced SIMD and
Floating-point Extension registers on page A2-56. In an implementation that includes both of these extensions, they
share a common register file. The following sections give more information about these extensions and the
instructions they provide:
• Advanced SIMD and Floating-point Extensions on page A2-54.
• Floating-point data types and arithmetic on page A2-62.
• Polynomial arithmetic over {0, 1} on page A2-92.
A2.2 ARM core data types and arithmetic

All ARMv7-A and ARMv7-R processors support the following data types in memory:
Byte 8 bits
Halfword 16 bits
Word 32 bits
Doubleword 64 bits.
Processor registers are 32 bits in size. The instruction set contains instructions supporting the following data types
held in registers:
• 32-bit pointers.
• Unsigned or signed 32-bit integers.
• Unsigned 16-bit or 8-bit integers, held in zero-extended form.
• Signed 16-bit or 8-bit integers, held in sign-extended form.
• Two 16-bit integers packed into a register.
• Four 8-bit integers packed into a register.
• Unsigned or signed 64-bit integers held in two registers.
Load and store operations can transfer bytes, halfwords, or words to and from memory. Loads of bytes or halfwords
zero-extend or sign-extend the data as it is loaded, as specified in the appropriate load instruction.
The instruction sets include load and store operations that transfer two or more words to and from memory. Software
can load and store doublewords using these instructions.
Note
For information about the atomicity of memory accesses see Atomicity in the ARM architecture on page A3-125.
When any of the data 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.
The instructions that operate on packed halfwords or bytes include some multiply instructions that use just one of
two halfwords, and SIMD instructions that perform parallel addition or subtraction on all of the halfwords or bytes.
Direct instruction support for 64-bit integers is limited, and most 64-bit operations require sequences of two or more
instructions to synthesize them.
A2.2.1 Integer arithmetic

The instruction set provides a wide variety of operations on the values in registers, including bitwise logical
operations, shifts, additions, subtractions, multiplications, and many others. The pseudocode described in
Appendix D16 Pseudocode Definition defines these operations, usually in one of three ways:
• By direct use of the pseudocode operators and built-in functions defined in Operators and built-in functions
on page D16-2637.
• By use of pseudocode helper functions defined in the main text. These can be located using the table in
Appendix D17 Pseudocode Index.
• By a sequence of the form:

1. Use of the SInt(), UInt(), and Int() built-in functions defined in Converting bitstrings to integers on
page D16-2639 to convert the bitstring contents of the instruction operands to the unbounded integers
that they represent as two's complement or unsigned integers.
2. Use of mathematical operators, built-in functions and helper functions on those unbounded integers to
calculate other such integers.
3. Use of either the bitstring extraction operator defined in Bitstring extraction on page D16-2638 or of
the saturation helper functions described in Pseudocode details of saturation on page A2-44 to convert
an unbounded integer result into a bitstring result that can be written to a register.
Shift and rotate operations

The following types of shift and rotate operations are used in instructions:
Logical Shift Left

(LSL) moves each bit of a bitstring left by a specified number of bits. Zeros are shifted in at the right
end of the bitstring. Bits that are shifted off the left end of the bitstring are discarded, except that the
last such bit can be produced as a carry output.
Logical Shift Right

(LSR) moves each bit of a bitstring right by a specified number of bits. Zeros are shifted in at the left
end of the bitstring. Bits that are shifted off the right end of the bitstring are discarded, except that
the last such bit can be produced as a carry output.
Arithmetic Shift Right

(ASR) moves each bit of a bitstring right by a specified number of bits. Copies of the leftmost bit are
shifted in at the left end of the bitstring. Bits that are shifted off the right end of the bitstring are
discarded, except that the last such bit can be produced as a carry output.
Rotate Right (ROR) moves each bit of a bitstring right by a specified number of bits. Each bit that is shifted off the
right end of the bitstring is re-introduced at the left end. The last bit shifted off the right end of the
bitstring can be produced as a carry output.
Rotate Right with Extend

(RRX) moves each bit of a bitstring right by one bit. A carry input is shifted in at the left end of the
bitstring. The bit shifted off the right end of the bitstring can be produced as a carry output.
Pseudocode details of shift and rotate operations
These shift and rotate operations are supported in pseudocode by the following functions:
// LSL_C()
// =======
(bits(N), bit) LSL_C(bits(N) x, integer shift)

assert shift > 0;
extended_x = x : Zeros(shift);
result = extended_x<N-1:0>;
carry_out = extended_x<N>;
return (result, carry_out);
// LSL()
// =====
bits(N) LSL(bits(N) x, integer shift)

assert shift >= 0;
if shift == 0 then
result = x;
else
(result, -) = LSL_C(x, shift);
return result;
// LSR_C()
// =======
(bits(N), bit) LSR_C(bits(N) x, integer shift)

assert shift > 0;
extended_x = ZeroExtend(x, shift+N);
result = extended_x<shift+N-1:shift>;
carry_out = extended_x<shift-1>;
// LSR()
// =====
bits(N) LSR(bits(N) x, integer shift)

assert shift >= 0;
if shift == 0 then
result = x;
else
(result, -) = LSR_C(x, shift);
return result;
// ASR_C()
// =======
(bits(N), bit) ASR_C(bits(N) x, integer shift)

assert shift > 0;
extended_x = SignExtend(x, shift+N);
result = extended_x<shift+N-1:shift>;
carry_out = extended_x<shift-1>;
// ASR()
// =====
bits(N) ASR(bits(N) x, integer shift)

assert shift >= 0;
if shift == 0 then
result = x;
else
(result, -) = ASR_C(x, shift);
return result;
// ROR_C()
// =======
(bits(N), bit) ROR_C(bits(N) x, integer shift)

assert shift != 0;
m = shift MOD N;
result = LSR(x,m) OR LSL(x,N-m);
carry_out = result<N-1>;
// ROR()
// =====
bits(N) ROR(bits(N) x, integer shift)

if shift == 0 then
result = x;
else
(result, -) = ROR_C(x, shift);
return result;
// RRX_C()
// =======
(bits(N), bit) RRX_C(bits(N) x, bit carry_in)

result = carry_in : x<N-1:1>;
carry_out = x<0>;
// RRX()
// =====
bits(N) RRX(bits(N) x, bit carry_in)

(result, -) = RRX_C(x, carry_in);
return result;
Pseudocode details of addition and subtraction

In pseudocode, addition and subtraction can be performed on any combination of unbounded integers and bitstrings,
provided that if they are performed on two bitstrings, the bitstrings must be identical in length. The result is another
unbounded integer if both operands are unbounded integers, and a bitstring of the same length as the bitstring
operand(s) otherwise. For the precise definition of these operations, see Addition and subtraction on
page D16-2640.
The main addition and subtraction instructions can produce status information about both unsigned carry and signed
overflow conditions. When necessary, multi-word additions and subtractions are synthesized from this status
information. In pseudocode the AddWithCarry() function provides an addition with a carry input and carry and
overflow outputs:
// AddWithCarry()
// ==============
(bits(N), bit, bit) AddWithCarry(bits(N) x, bits(N) y, bit carry_in)

unsigned_sum = UInt(x) + UInt(y) + UInt(carry_in);
signed_sum = SInt(x) + SInt(y) + UInt(carry_in);
result = unsigned_sum<N-1:0>; // same value as signed_sum<N-1:0>
carry_out = if UInt(result) == unsigned_sum then '0' else '1';
overflow = if SInt(result) == signed_sum then '0' else '1';
return (result, carry_out, overflow);
An important property of the AddWithCarry() function is that if:
(result, carry_out, overflow) = AddWithCarry(x, NOT(y), carry_in)
then:
• If carry_in == '1', then result == x-y with:
— overflow == '1' if signed overflow occurred during the subtraction.
— carry_out == '1' if unsigned borrow did not occur during the subtraction, that is, if x >= y.
• If carry_in == '0', then result == x-y-1 with:
— overflow == '1' if signed overflow occurred during the subtraction.
— carry_out == '1' if unsigned borrow did not occur during the subtraction, that is, if x > y.
Together, these mean that the carry_in and carry_out bits in AddWithCarry() calls can act as NOT borrow flags for
subtractions as well as carry flags for additions.
Pseudocode details of saturation

Some instructions perform saturating arithmetic, that is, if the result of the arithmetic overflows the destination
signed or unsigned N-bit integer range, the result produced is the largest or smallest value in that range, rather than
wrapping around modulo 2N. This is supported in pseudocode by:
• The SignedSatQ() and UnsignedSatQ() functions when an operation requires, in addition to the saturated
result, a Boolean argument that indicates whether saturation occurred.
• The SignedSat() and UnsignedSat() functions when only the saturated result is required.
// SignedSatQ()
// ============
(bits(N), boolean) SignedSatQ(integer i, integer N)

if i > 2^(N-1) - 1 then
result = 2^(N-1) - 1; saturated = TRUE;
elsif i < -(2^(N-1)) then
result = -(2^(N-1)); saturated = TRUE;
else
result = i; saturated = FALSE;
return (result<N-1:0>, saturated);
// UnsignedSatQ()
// ==============
(bits(N), boolean) UnsignedSatQ(integer i, integer N)

if i > 2^N - 1 then
result = 2^N - 1; saturated = TRUE;
elsif i < 0 then
result = 0; saturated = TRUE;
else
result = i; saturated = FALSE;
return (result<N-1:0>, saturated);
// SignedSat()
// ===========
bits(N) SignedSat(integer i, integer N)

(result, -) = SignedSatQ(i, N);
return result;
// UnsignedSat()
// =============
bits(N) UnsignedSat(integer i, integer N)

(result, -) = UnsignedSatQ(i, N);
return result;
SatQ(i, N, unsigned) returns either UnsignedSatQ(i, N) or SignedSatQ(i, N) depending on the value of its third
argument, and Sat(i, N, unsigned) returns either UnsignedSat(i, N) or SignedSat(i, N) depending on the value of
its third argument:
// SatQ()
// ======
(bits(N), boolean) SatQ(integer i, integer N, boolean unsigned)

(result, sat) = if unsigned then UnsignedSatQ(i, N) else SignedSatQ(i, N);
return (result, sat);
// Sat()
// =====
bits(N) Sat(integer i, integer N, boolean unsigned)

result = if unsigned then UnsignedSat(i, N) else SignedSat(i, N);
return result;
A2.3 ARM core registers

In the application level view, an ARM processor has:
• 13 general-purpose 32-bit registers, R0 to R12.
• Three 32-bit registers with special uses, SP, LR, and PC, that can be described as R13 to R15.
The special registers are:
SP, the stack pointer

The processor uses SP as a pointer to the active stack.
In the Thumb instruction set, most instructions cannot access SP. The only instructions that can
access SP are those designed to use SP as a stack pointer.
The ARM instruction set provides more general access to the SP, and it can be used as a
general-purpose register. However, ARM deprecates the use of SP for any purpose other than as a
stack pointer.
Note
Using SP for any purpose other than as a stack pointer is likely to break the requirements of
operating systems, debuggers, and other software systems, causing them to malfunction.
Software can refer to SP as R13.
LR, the link register

The link register is a special register that can hold return link information. Some cases described in
this manual require this use of the LR. When software does not require the LR for linking, it can use
it for other purposes. It can refer to LR as R14.
PC, the program counter

• When executing an ARM instruction, PC reads as the address of the current instruction
plus 8.
• When executing a Thumb instruction, PC reads as the address of the current instruction
plus 4.
• Writing an address to PC causes a branch to that address.
Most Thumb instructions cannot access PC.
The ARM instruction set provides more general access to the PC, and many ARM instructions can
use the PC as a general-purpose register. However, ARM deprecates the use of PC for any purpose
other than as the program counter. See Writing to the PC for more information.
Software can refer to PC as R15.
See ARM core registers on page B1-1143 for the system level view of these registers.
Note
In general, ARM strongly recommends using the names SP, LR and PC instead of R13, R14 and R15. However,
sometimes it is simpler to use the R13-R15 names when referring to a group of registers. For example, it is simpler
to refer to Registers R8 to R15, rather than to Registers R8 to R12, the SP, LR and PC. These two descriptions of the
group of registers have exactly the same meaning.
A2.3.1 Writing to the PC

In ARMv7, many data-processing instructions can write to the PC. Writes to the PC are handled as follows:
• In Thumb state, the following 16-bit Thumb instruction encodings branch to the value written to the PC:
— Encoding T2 of ADD (register, Thumb) on page A8-308.
— Encoding T1 of MOV (register, Thumb) on page A8-487.
The value written to the PC is forced to be halfword-aligned by ignoring its least significant bit, treating that
bit as being 0.
• The B, BL, CBNZ, CBZ, CHKA, HB, HBL, HBLP, HBP, TBB, and TBH instructions remain in the same instruction set state
and branch to the value written to the PC.
The definition of each of these instructions ensures that the value written to the PC is correctly aligned for
the current instruction set state.
• The BLX (immediate) instruction switches between ARM and Thumb states and branches to the value written
to the PC. Its definition ensures that the value written to the PC is correctly aligned for the new instruction
set state.
• The following instructions write a value to the PC, treating that value as an interworking address to branch
to, with low-order bits that determine the new instruction set state:
— BLX (register), BX, and BXJ.
— LDR instructions with <Rt> equal to the PC.
— POP and all forms of LDM except LDM (exception return), when the register list includes the PC.
— In ARM state only, ADC, ADD, ADR, AND, ASR (immediate), BIC, EOR, LSL (immediate), LSR (immediate), MOV,
MVN, ORR, ROR (immediate), RRX, RSB, RSC, SBC, and SUB instructions with <Rd> equal to the PC and without
flag-setting specified.
For details of how an interworking address specifies the new instruction set state and instruction address, see
Pseudocode details of operations on ARM core registers.
Note
— The register-shifted register instructions, that are available only in the ARM instruction set and are
summarized inData-processing (register-shifted register) on page A5-195, cannot write to the PC.
— The LDR, POP, and LDM instructions first have interworking branch behavior in ARMv5T.
— The instructions listed as having interworking branch behavior in ARM state only first have this
behavior in ARMv7.
In the cases where later versions of the architecture introduce interworking branch behavior, the behavior in
earlier architecture versions is a branch that remains in the same instruction set state. For more information,
see:
— Interworking on page D12-2489, for ARMv6.
— Interworking on page D15-2575, for ARMv5 and ARMv4.
• Some instructions are treated as exception return instructions, and write both the PC and the CPSR. For more
information, including which instructions are exception return instructions, see Exception return on
page B1-1193.
• Some instructions cause an exception, and the exception handler address is written to the PC as part of the
exception entry. Similarly, in ThumbEE state, an instruction that fails its null check causes the address of the
null check handler to be written to the PC, see Null checking on page A9-1113.
A2.3.2 Pseudocode details of operations on ARM core registers

In pseudocode, the uses of the R[] function are:
• Reading or writing R0-R12, SP, and LR, using n == 0-12, 13, and 14 respectively.
• Reading the PC, using n == 15.
This function has prototypes:
bits(32) R[integer n]
assert n >= 0 && n <= 15;
R[integer n] = bits(32) value

assert n >= 0 && n <= 14;
Pseudocode details of ARM core register operations on page B1-1144 explains the full operation of this function.
Descriptions of ARM store instructions that store the PC value use the PCStoreValue() pseudocode function to
specify the PC value stored by the instruction:
// PCStoreValue()
// ==============
bits(32) PCStoreValue()
// This function returns the PC value. On architecture versions before ARMv7, it
// is permitted to instead return PC+4, provided it does so consistently. It is
// used only to describe ARM instructions, so it returns the address of the current
// instruction plus 8 (normally) or 12 (when the alternative is permitted).
return PC;
Writing an address to the PC causes either a simple branch to that address or an interworking branch that also selects
the instruction set to execute after the branch. A simple branch is performed by the BranchWritePC() function:
// BranchWritePC()
// ===============
BranchWritePC(bits(32) address)
if CurrentInstrSet() == InstrSet_ARM then
if ArchVersion() < 6 && address<1:0> != '00' then UNPREDICTABLE;
BranchTo(address<31:2>:'00');
elsif CurrentInstrSet() == InstrSet_Jazelle then
if JazelleAcceptsExecution() then
BranchTo(address<31:0>);
else
newaddress = address;
newaddress<1:0> = bits(2) UNKNOWN;
BranchTo(newaddress);
else
An interworking branch is performed by the BXWritePC() function:
// BXWritePC()
// ===========
BXWritePC(bits(32) address)
if CurrentInstrSet() == InstrSet_ThumbEE then
if address<0> == '1' then
BranchTo(address<31:1>:'0'); // Remaining in ThumbEE state
else
UNPREDICTABLE;
else
if address<0> == '1' then
SelectInstrSet(InstrSet_Thumb);
elsif address<1> == '0' then
SelectInstrSet(InstrSet_ARM);
BranchTo(address);
else // address<1:0> == '10'
UNPREDICTABLE;
The LoadWritePC() and ALUWritePC() functions are used for two cases where the behavior was systematically
modified between architecture versions:
// LoadWritePC()
// =============
LoadWritePC(bits(32) address)
if ArchVersion() >= 5 then
BXWritePC(address);
else
BranchWritePC(address);
// ALUWritePC()
// ============
ALUWritePC(bits(32) address)
if ArchVersion() >= 7 && CurrentInstrSet() == InstrSet_ARM then
BXWritePC(address);
else
BranchWritePC(address);
Note
The behavior of the PC writes performed by the ALUWritePC() function is different in Debug state, where there are
more UNPREDICTABLE cases. The pseudocode in this section only handles the non-debug cases. For more
information, see Behavior of Data-processing instructions that access the PC in Debug state on page C5-2088.
A2.4 The Application Program Status Register (APSR)
A2.4 The Application Program Status Register (APSR)

Program status is reported in the 32-bit Application Program Status Register (APSR). The APSR bit assignments
are:
31 30 29 28 27 26 24 23 20 19 16 15 0
RAZ/ Reserved,
N Z C V Q GE[3:0] Reserved, UNKNOWN/SBZP
SBZP UNK/SBZP
The APSR bit categories are:
• Reserved bits, that are allocated to system features, or are available for future expansion. Unprivileged
execution ignores writes to fields that are accessible only at PL1 or higher. However, application level
software that writes to the APSR must treat reserved bits as Do-Not-Modify (DNM) bits. For more
information about the reserved bits, see Format of the CPSR and SPSRs on page B1-1148.
Although bits[15:0] are UNKNOWN on reads, it is permitted that, on a read of APSR:
— Bit[9] returns the value of CPSR.E.
— Bits[8:6] return the value of CPSR.{A,I, F}, the mask bits.
This is an exception to the general rule that an UNKNOWN field must not return information that cannot be
obtained, at the current Privilege level, by an architected mechanism.
ARM recommends that these bits do not return the CPSR bit values on a read of the APSR.
• Bits that can be set by many instructions:

— The Condition flags:
N, bit[31] Negative condition flag. Set to bit[31] of the result of the instruction. If the result is
regarded as a two's complement signed integer, then the processor sets N to 1 if the result
is negative, and sets N to 0 if it is positive or zero.
Z, bit[30] Zero condition flag. Set to 1 if the result of the instruction is zero, and to 0 otherwise. A
result of zero often indicates an equal result from a comparison.
C, bit[29] Carry condition flag. Set to 1 if the instruction results in a carry condition, for example an
unsigned overflow on an addition.
V, bit[28] Overflow condition flag. Set to 1 if the instruction results in an overflow condition, for
example a signed overflow on an addition.
— The Overflow or saturation flag:
Q, bit[27] Set to 1 to indicate overflow or saturation occurred in some instructions, normally related
to digital signal processing (DSP). For more information, see Pseudocode details of
saturation on page A2-44.
— The Greater than or Equal flags:
GE[3:0], bits[19:16]
The instructions described in Parallel addition and subtraction instructions on
page A4-169 update these flags to indicate the results from individual bytes or halfwords
of the operation. These flags can control a later SEL instruction. For more information, see
SEL on page A8-603.
• Bits[26:24] are RAZ/SBZP. Therefore, software can use MSR instructions that write the top byte of the APSR
without using a read, modify, write sequence. If it does this, it must write zeros to bits[26:24].
Instructions can test the N, Z, C, and V condition flags, combining these with the condition code for the instruction
to determine whether the instruction must be executed. In this way, execution of the instruction is conditional on the
result of a previous operation. For more information about conditional execution, see Conditional execution on
page A4-159 and Conditional execution on page A8-286.
In ARMv7-A and ARMv7-R, the APSR is the same register as the CPSR, but the APSR must be used only to access
the N, Z, C, V, Q, and GE[3:0] bits. For more information, see Program Status Registers (PSRs) on page B1-1147.
A2.5 Execution state registers

The execution state registers modify the execution of instructions. They control:
• Whether instructions are interpreted as Thumb instructions, ARM instructions, ThumbEE instructions, or
Java bytecodes. For more information, see Instruction set state register, ISETSTATE.
• In Thumb state and ThumbEE state only, the condition codes that apply to the next one to four instructions.
For more information, see IT block state register, ITSTATE on page A2-51.
• Whether data is interpreted as big-endian or little-endian. For more information, see Endianness mapping
register, ENDIANSTATE on page A2-53.
In ARMv7-A and ARMv7-R, the execution state registers are part of the Current Program Status Register. For more
information, see Program Status Registers (PSRs) on page B1-1147.
There is no direct access to the execution state registers from application level instructions, but they can be changed
by side-effects of application level instructions.
A2.5.1 Instruction set state register, ISETSTATE

The instruction set state register, ISETSTATE, format is:
1 0
J T
The J bit and the T bit determine the current instruction set state for the processor. Table A2-1 shows the encoding
of these bits.
Table A2-1 J and T bit encoding in ISETSTATE
J T Instruction set state
0 0 ARM
0 1 Thumb
1 0 Jazelle
1 1 ThumbEE
ARM state The processor executes the ARM instruction set described in Chapter A5 ARM Instruction
Set Encoding.
Thumb state The processor executes the Thumb instruction set as described in Chapter A6 Thumb
Instruction Set Encoding.
Jazelle state The processor executes Java bytecodes as part of a Java Virtual Machine (JVM). For more
information, see:
• Jazelle direct bytecode execution support on page A2-96, for application level
information.
• Jazelle direct bytecode execution on page B1-1240, for system level information.
ThumbEE state The processor executes a variation of the Thumb instruction set specifically targeted for use
with dynamic compilation techniques associated with an execution environment. This can
be Java or other execution environments. This feature is required in ARMv7-A, and optional
in ARMv7-R. For more information, see:
• Thumb Execution Environment on page A2-94, for application level information.
• Thumb Execution Environment on page B1-1239, for system level information.
Pseudocode details of ISETSTATE operations

The following pseudocode functions return the current instruction set and select a new instruction set:
enumeration InstrSet {InstrSet_ARM, InstrSet_Thumb, InstrSet_Jazelle, InstrSet_ThumbEE};
// CurrentInstrSet()
// =================
InstrSet CurrentInstrSet()
case ISETSTATE of
when '00' result = InstrSet_ARM;
when '01' result = InstrSet_Thumb;
when '10' result = InstrSet_Jazelle;
when '11' result = InstrSet_ThumbEE;
return result;
// SelectInstrSet()
// ================
SelectInstrSet(InstrSet iset)
case iset of
when InstrSet_ARM
UNPREDICTABLE;
else
ISETSTATE = '00';
when InstrSet_Thumb
ISETSTATE = '01';
when InstrSet_Jazelle
ISETSTATE = '10';
when InstrSet_ThumbEE
ISETSTATE = '11';
return;
A2.5.2 IT block state register, ITSTATE

The IT block state register, ITSTATE, format is:
7 0
IT[7:0]
This field holds the If-Then execution state bits for the Thumb IT instruction, that applies to the IT block of one to
four instructions that immediately follow the IT instruction. See IT on page A8-391 for a description of the IT
instruction and the associated IT block.
ITSTATE divides into two subfields:
IT[7:5] Holds the base condition for the current IT block. The base condition is the top 3 bits of the
condition code specified by the <firstcond> field of the IT instruction.
This subfield is 0b000 when no IT block is active.
IT[4:0] Encodes:
• The size of the IT block. This is the number of instructions that are to be conditionally
executed. The size of the block is implied by the position of the least significant 1 in this field,
as shown in Table A2-2 on page A2-52.
• The value of the least significant bit of the condition code for each instruction in the block.
Note
Changing the value of the least significant bit of a condition code from 0 to 1 has the effect
of inverting the condition code.
This subfield is 0b00000 when no IT block is active.
When an IT instruction is executed, these bits are set according to the <firstcond> condition code in the instruction,
and the Then and Else (T and E) parameters in the instruction. For more information, see IT on page A8-391.
When permitted, an instruction in an IT block is conditional, see Conditional instructions on page A4-160 and
Conditional execution on page A8-286. The condition code used is the current value of IT[7:4]. When an instruction
in an IT block completes its execution normally, ITSTATE advances to the next line of Table A2-2. A few instructions,
for example BKPT, cannot be conditional and therefore are always executed, ignoring the current ITSTATE.
For details of what happens if an instruction in an IT block:

• Takes an exception, see Overview of exception entry on page B1-1169.
• In ThumbEE state, causes a branch to a check handler, see IT block and check handlers on page A9-1114.
An instruction that might complete its normal execution by branching is only permitted in an IT block as the last
instruction in the block. This means that normal execution of the instruction always results in ITSTATE advancing to
normal execution.
Table A2-2 Effect of IT execution state bits
IT bits a
Note
[7:5] [4] [3] [2] [1] [0]
cond_base P1 P2 P3 P4 1 Entry point for 4-instruction IT block
cond_base P1 P2 P3 1 0 Entry point for 3-instruction IT block
cond_base P1 P2 1 0 0 Entry point for 2-instruction IT block
cond_base P1 1 0 0 0 Entry point for 1-instruction IT block
000 0 0 0 0 0 Normal execution, not in an IT block
a. Combinations of the IT bits not shown in this table are reserved.
On a branch or an exception return, if ITSTATE is set to a value that is not consistent with the instruction stream
being branched to or returned to, then instruction execution is UNPREDICTABLE.
ITSTATE affects instruction execution only in Thumb and ThumbEE states. In ARM and Jazelle states, ITSTATE must
be '00000000', otherwise the behavior is UNPREDICTABLE.
Pseudocode details of ITSTATE operations

ITSTATE advances after normal execution of an IT block instruction. This is described by the ITAdvance() pseudocode
function:
// ITAdvance()
// ===========
ITAdvance()
if ITSTATE<2:0> == '000' then
ITSTATE.IT = '00000000';
else
ITSTATE.IT<4:0> = LSL(ITSTATE.IT<4:0>, 1);
The following functions test whether the current instruction is in an IT block, and whether it is the last instruction
of an IT block:
// InITBlock()
// ===========
boolean InITBlock()
return (ITSTATE.IT<3:0> != '0000');
// LastInITBlock()
// ===============
boolean LastInITBlock()
return (ITSTATE.IT<3:0> == '1000');
A2.5.3 Endianness mapping register, ENDIANSTATE

ARMv7-A and ARMv7-R support configuration between little-endian and big-endian interpretations of data
memory, as shown in Table A2-3. The endianness is controlled by ENDIANSTATE.
Table A2-3 ENDIANSTATE encoding of endianness
ENDIANSTATE Endian mapping
0 Little-endian
1 Big-endian
The ARM and Thumb instruction sets both include an instruction to manipulate ENDIANSTATE:
SETEND BE Sets ENDIANSTATE to 1, for big-endian operation.
SETEND LE Sets ENDIANSTATE to 0, for little-endian operation.
The SETEND instruction is unconditional. For more information, see SETEND on page A8-605.
Pseudocode details of ENDIANSTATE operations

The BigEndian() pseudocode function tests whether big-endian memory accesses are currently selected.
// BigEndian()
// ===========
boolean BigEndian()
return (ENDIANSTATE == '1');
A2.6 Advanced SIMD and Floating-point Extensions

Advanced SIMD and Floating-point (VFP) are two OPTIONAL extensions to ARMv7.
The Advanced SIMD Extension performs packed Single Instruction Multiple Data (SIMD) operations, either
integer or single-precision floating-point. The Floating-point Extension performs single-precision or
double-precision floating-point operations.
Both extensions permit floating-point exceptions, such as overflow or division by zero, to be handled without
trapping. When handled in this way, a floating-point exception causes a cumulative status register bit to be set to 1
and a default result to be produced by the operation.
The ARMv7 Floating-point Extension implementation can be VFPv3 or VFPv4, see Architecture extensions on
page A1-32. ARMv7 also defines variants of VFPv3 and VFPv4, VFPv3U and VFPv4U, that support the trapping
of floating-point exceptions, see VFPv3U and VFPv4U on page A2-61. VFPv2 also supports the trapping of
floating-point exceptions.
The Advanced SIMD implementation can be Advanced SIMDv1 or Advanced SIMDv2.
If an implementation includes both the Advanced SIMD and the Floating-point Extensions then the versions of the
two extensions must align, as described in Instruction set architecture extensions on page A1-32.
For more information about floating-point exceptions see Floating-point exceptions on page A2-69.
Each version of these extensions can be implemented at a number of levels. Table A2-4 shows the permitted
combinations of implementations of the two extensions.
Table A2-4 Permitted combinations of Advanced SIMD and Floating-point Extensions
Advanced SIMD Floating-point (VFP)
Not implemented Not implemented
Integer only Not implemented
Integer and single-precision floating-point Single-precision floating-point only a
Integer and single-precision floating-point Single-precision and double-precision floating-point
Not implemented Single-precision floating-point only a
Not implemented Single-precision and double-precision floating-point
a. Must be able to load and store double-precision data using the bottom 16 double-precision registers, D0-D15.
The Half-precision Extension provides conversion functions in both directions between half-precision
floating-point and single-precision floating-point. This extension:
• Can be implemented with any Advanced SIMDv1 or VFPv3 implementation that supports single-precision
floating-point, and the Half-precision extension applies to both VFP and Advanced SIMD if they are both
implemented.
• Is included in any Advanced SIMDv2 or VFPv4 implementation that supports single-precision

floating-point.
For system level information about the Advanced SIMD and Floating-point Extensions see Advanced SIMD and
floating-point support on page B1-1228.
Note
Before ARMv7, the Floating-point Extension was called the Vector Floating-point Architecture, and was used for
vector operations. For details of these deprecated operations see Appendix D11 VFP Vector Operation Support. In
ARMv7:
• ARM recommends that the Advanced SIMD Extension is used for single-precision vector floating-point
operations.
• An implementation that requires support for vector operations must implement the Advanced SIMD
Extension.
A2.6.1 Floating-point standards, and terminology

The ARM floating-point implementation includes support for all the required features of ANSI/IEEE Std 754-2008,
IEEE Standard for Binary Floating-Point Arithmetic, referred to as IEEE 754-2008. However, the original
implementation was based on the 1985 version of this standard, referred to as IEEE 754-1985, In this manual:
• Floating-point terminology generally uses the IEEE 754-1985 terms. This section summarizes how
IEEE 754-2008 changes these terms.
• References to IEEE 754 that do not include the issue year apply to either issue of the standard.
Table A2-5 shows how the terminology in this manual differs from that used in IEEE 754-2008.
Table A2-5 Floating-point terminology
This manual, based on IEEE 754-1985 a IEEE 754-2008
Normalized Normal
Denormal, or denormalized Subnormal
Round towards Minus Infinity roundTowardsNegative
Round towards Plus Infinity roundTowardsPositive
Round towards Zero roundTowardZero
Round to Nearest roundTiesToEven
Rounding mode Rounding-direction attribute
a. Except that normalized number is used in preference to normal number, because of

the other specific uses of normal in this manual.
The fused multiply add operations are first defined in IEEE 754-2008, and are introduced in VFPv4 and
Advanced SIMDv2. The following sections describe the instructions that perform these operations:
• VFMA, VFMS on page A8-893.
• VFNMA, VFNMS on page A8-895.
All other ARMv7 floating-point operations are defined in both issues of IEEE 754.
Note
ARMv7 does not support the IEEE 754-2008 roundTiesToAway rounding mode. However, IEEE 754-compliance
does not require support for this mode.
A2.6.2 Advanced SIMD and Floating-point Extension registers

From VFPv3, the Advanced SIMD and Floating-point (VFP) Extensions use the same register set. This is distinct
from the ARM core register set. These registers are generally referred to as the extension registers.
The extension register set consists of either 32 or 16 doubleword registers, as follows:
• If VFPv2 is implemented, it consists of 16 doubleword registers.
• If VFPv3 is implemented, it consists of either 32 or 16 doubleword registers. Where necessary, these two
— VFPv3-D32, for an implementation with 32 doubleword registers.
• If VFPv4 is implemented, it consists of either 32 or 16 doubleword registers. Where necessary, these two
• If Advanced SIMD is implemented, it consists of 32 doubleword registers.
• If Advanced SIMD and Floating-point are both implemented, Floating-point must be implemented as
VFPv3-D32 or VFPv4-D32.
The Advanced SIMD and Floating-point views of the extension register set are not identical. The following sections
describe these different views.
Figure A2-1 on page A2-57 shows the views of the extension register set, and the way the word, doubleword, and
quadword registers overlap.
Advanced SIMD views of the extension register set

Advanced SIMD can view this register set as:
• Sixteen 128-bit quadword registers, Q0-Q15.
• Thirty-two 64-bit doubleword registers, D0-D31. This view is also available in VFPv3-D32 and VFPv4-D32.
These views can be used simultaneously. For example, a program might hold 64-bit vectors in D0 and D1 and a
128-bit vector in Q1.
Floating-point views of the extension register set

In VFPv4-D32 or VFPv3-D32, the extension register set consists of 32 doubleword registers, that VFP can view as:
• Thirty-two 64-bit doubleword registers, D0-D31. This view is also available in Advanced SIMD.
• Thirty-two 32-bit single word registers, S0-S31. Only half of the set is accessible in this view.
In VFPv4-D16, VFPv3-D16, and VFPv2, the extension register set consists of 16 doubleword registers, that VFP
can view as:
• Sixteen 64-bit doubleword registers, D0-D15.
• Thirty-two 32-bit single word registers, S0-S31.
In each case, the two views can be used simultaneously.
Advanced SIMD and Floating-point register mapping

Figure A2-1 on page A2-57 shows the different views of Advanced SIMD and Floating-point register banks, and
the relationship between them.
S0-S31 D0-D15 D0-D31 Q0-Q15

VFPv2, VFPv3-D32,
Advanced SIMD
VFP only VFPv3-D16, or VFPv4-D32, or
only
VFPv4-D16 Advanced SIMD
S0
D0 D0
S1
Q0
S2
D1 D1
S3
S4
D2 D2
S5
Q1
S6
D3 D3
S7
S28
D14 D14
S29
Q7
S30
D15 D15
S31
D16
Q8
D17
D30
Q15
D31
Figure A2-1 Advanced SIMD and Floating-point Extensions register set
The mapping between the registers is as follows:

• S<2n> maps to the least significant half of D<n>.
• S<2n+1> maps to the most significant half of D<n>.
• D<2n> maps to the least significant half of Q<n>.
• D<2n+1> maps to the most significant half of Q<n>.
For example, software can access the least significant half of the elements of a vector in Q6 by referring to D12, and
the most significant half of the elements by referring to D13.
Pseudocode details of Advanced SIMD and Floating-point Extension registers

The pseudocode function VFPSmallRegisterBank() returns FALSE if all of the 32 registers D0-D31 can be accessed,
and TRUE if only the 16 registers D0-D15 can be accessed:
boolean VFPSmallRegisterBank()
In more detail, VFPSmallRegisterBank():

• Returns TRUE for a VFPv2, VFPv3-D16, or VFPv4-D16 implementation
• For a VFPv3-D32 or VFPv4-D32 implementation:
— Returns FALSE if CPACR.D32DIS is set to 0.
— Returns TRUE if CPACR.D32DIS and CPACR.ASEDIS are both set to 1.
— Results in UNPREDICTABLE behavior if CPACR.D32DIS is set to 1 and CPACR.ASEDIS is set to 0.
For details of the CPACR, see either:
• CPACR, Coprocessor Access Control Register, VMSA on page B4-1547.
• CPACR, Coprocessor Access Control Register, PMSA on page B6-1823.
The following functions provide the S0-S31, D0-D31, and Q0-Q15 views of the registers:
// The 64-bit extension register bank for Advanced SIMD and VFP.
array bits(64) _D[0..31];
// Clone the 64-bit Advanced SIMD and VFP extension register bank for use as input to
// instruction pseudocode, to avoid read-after-write for Advanced SIMD and VFP operations.
array bits(64) _Dclone[0..31];
// S[] - non-assignment form

// =========================
bits(32) S[integer n]
assert n >= 0 && n <= 31;
if (n MOD 2) == 0 then
result = D[n DIV 2]<31:0>;
else
result = D[n DIV 2]<63:32>;
return result;
// S[] - assignment form

// =====================
S[integer n] = bits(32) value

assert n >= 0 && n <= 31;
if (n MOD 2) == 0 then
D[n DIV 2]<31:0> = value;
else
D[n DIV 2]<63:32> = value;
return;
// D[] - non-assignment form

// =========================
bits(64) D[integer n]
assert n >= 0 && n <= 31;
if n >= 16 && VFPSmallRegisterBank() then UNDEFINED;
return _D[n];
// D[] - assignment form

// =====================
D[integer n] = bits(64) value

assert n >= 0 && n <= 31;
_D[n] = value;
return;
// Q[] - non-assignment form

// =========================
bits(128) Q[integer n]
assert n >= 0 && n <= 15;
return D[2*n+1]:D[2*n];
// Q[] - assignment form

// =====================
Q[integer n] = bits(128) value

assert n >= 0 && n <= 15;
D[2*n] = value<63:0>;
D[2*n+1] = value<127:64>;
return;
The Din[] function returns a Doubleword register from the _Dclone[] copy of the Advanced SIMD and
Floating-point register bank, and the Qin[] function returns a Quadword register from that register bank.
Note
The CheckAdvancedSIMDEnabled() function copies the _D[] register bank to _Dclone[], see Pseudocode details of
enabling the Advanced SIMD and Floating-point Extensions on page B1-1234.
// Din[] - non-assignment form

// ===========================
bits(64) Din[integer n]
assert n >= 0 && n <= 31;
return _Dclone[n];
// Qin[] - non-assignment form

// ===========================
bits(128) Qin[integer n]
assert n >= 0 && n <= 15;
return Din[2*n+1]:Din[2*n];
A2.6.3 Data types supported by the Advanced SIMD Extension

In an implementation that includes the Advanced SIMD Extension, the Advanced SIMD instructions can operate
on integer and floating-point data, and the extension defines a set of data types to represent the different data
formats. Table A2-6 shows the available formats. Each instruction description specifies the data types that the
instruction supports.
Table A2-6 Advanced SIMD data types
Data type specifier Meaning
.<size> Any element of <size> bits
.F<size> Floating-point number of <size> bits
.I<size> Signed or unsigned integer of <size> bits
.P<size> Polynomial over {0, 1} of degree less than <size>
.S<size> Signed integer of <size> bits
.U<size> Unsigned integer of <size> bits
Polynomial arithmetic over {0, 1} on page A2-92 describes the polynomial data type.
The .F16 data type is the half-precision data type selected by the FPSCR.AHP bit. It is supported only if an
implementation includes the Half-precision extension.
The .F32 data type is the ARM standard single-precision floating-point data type, see Advanced SIMD and
Floating-point single-precision format on page A2-63.
The instruction definitions use a data type specifier to define the data types appropriate to the operation. Figure A2-2
on page A2-60 shows the hierarchy of Advanced SIMD data types.
.S8
.I8
.U8
.8
.P8
-
.S16
.I16
.U16
.16
.P16 †
.F16 ‡
.S32
.I32
.U32
.32
-
.F32
.S64
.I64
.U64
.64
-
-
† Output format only. See VMULL instruction description.
‡ Supported only if the implementation includes the Half-precision Extension.
Figure A2-2 Advanced SIMD data type hierarchy
For example, a multiply instruction must distinguish between integer and floating-point data types.
An integer multiply instruction that generates a double-width (long) result must specify the input data types as
signed or unsigned. However, some integer multiply instructions use modulo arithmetic, and therefore do not have
to distinguish between signed and unsigned inputs.
A2.6.4 Advanced SIMD vectors

In an implementation that includes the Advanced SIMD Extension, a register can hold one or more packed elements,
all of the same size and type. The combination of a register and a data type describes a vector of elements. The vector
is considered to be an array of elements of the data type specified in the instruction. The number of elements in the
vector is implied by the size of the data elements and the size of the register.
Vector indices are in the range 0 to (number of elements – 1). An index of 0 refers to the least significant end of the
vector. Figure A2-3 shows examples of Advanced SIMD vectors:
127 112 111 96 95 80 79 64 63 48 47 32 31 16 15 0
Qn
128-bit vector of single-precision

.F32 .F32 .F32 .F32
(32-bit) floating-point numbers
[3] [2] [1] [0]
128-bit vector of 16-bit signed integers .S16 .S16 .S16 .S16 .S16 .S16 .S16 .S16
[7] [6] [5] [4] [3] [2] [1] [0]
63 48 47 32 31 16 15 0
Dn
64-bit vector of 32-bit signed integers .S32 .S32

[1] [0]
64-bit vector of 16-bit unsigned integers .U16 .U16 .U16 .U16

[3] [2] [1] [0]
Figure A2-3 Examples of Advanced SIMD vectors
Pseudocode details of Advanced SIMD vectors

The pseudocode function Elem[] accesses the element of a specified index and size in a vector:
// Elem[] - non-assignment form

// ============================
bits(size) Elem[bits(N) vector, integer e, integer size]

assert e >= 0 && (e+1)*size <= N;
return vector<(e+1)*size-1:e*size>;
// Elem[] - assignment form

// ========================
Elem[bits(N) vector, integer e, integer size] = bits(size) value

assert e >= 0 && (e+1)*size <= N;
vector<(e+1)*size-1:e*size> = value;
return;
A2.6.5 Advanced SIMD and Floating-point system registers

The Advanced SIMD and Floating-point (VFP) Extensions have a shared register space for system registers. Only
one register in this space is accessible at the Application level, see either:
• FPSCR, Floating-point Status and Control Register, VMSA on page B4-1566.
• FPSCR, Floating-point Status and Control Register, PMSA on page B6-1839.
Note
In this chapter, short links to the FPSCR are to the description in Chapter B4 System Control Registers in a VMSA
implementation. The FPSCR description in Chapter B6 System Control Registers in a PMSA implementation is
identical to this description.
Writes to the FPSCR can have side-effects on various aspects of processor operation. All of these side-effects are
synchronous to the FPSCR write. This means they are guaranteed not to be visible to earlier instructions in the
execution stream, and they are guaranteed to be visible to later instructions in the execution stream.
See Advanced SIMD and Floating-point Extension system registers on page B1-1235 for the system level view of
the registers.
A2.6.6 VFPv3U and VFPv4U

The VFPv3 and VFPv4 versions of the Floating-point Extension do not support the exception trap enable bits in the
FPSCR. With these versions of the Floating-point Extension, all floating-point exceptions are untrapped.
The VFPv3U variant of the VFPv3 extension, and the VFPv4U variant of the VFPv4 extension, implement
exception trap enable bits in the FPSCR, and provide exception handling as described in Floating-point support
code on page B1-1236. There is a separate trap enable bit for each of the six floating-point exceptions described in
Floating-point exceptions on page A2-69. Except for support for this trapping mechanism:
• The VFPv3U architecture is identical to VFPv3.
• The VFPv4U architecture is identical to VFPv4.
Trapped exception handling never causes the corresponding cumulative exception bit of the FPSCR to be set to 1.
If this behavior is desired, the trap handler routine must use a read, modify, write sequence on the FPSCR to set the
cumulative exception bit.
Both VFPv3U and VFPv4U can be implemented with either 32 or 16 doubleword registers. That is:
• VFPv3U can be implemented as VFPv3U-D32, or as VFPv3U-D16.
• VFPv4U can be implemented as VFPv4U-D32, or as VFPv4U-D16.
VFPv3U-D16 and VFPv4U-D16 are backwards compatible with VFPv2.
A2.7 Floating-point data types and arithmetic

The Floating-point (VFP) Extension supports single-precision (32-bit) and double-precision (64-bit) floating-point
data types and arithmetic as defined by the IEEE 754 floating-point standard. It also supports the half-precision
(16-bit) floating-point data type for data storage only, by supporting conversions between single-precision and
half-precision data types.
ARM standard floating-point arithmetic means IEEE 754 floating-point arithmetic with the following restrictions:
• denormalized numbers are flushed to zero, see Flush-to-zero on page A2-67
• only default NaNs are supported, see NaN handling and the Default NaN on page A2-68
• the Round to Nearest rounding mode selected, by setting FPSCR.RMode to 0b00
• untrapped exception handling selected for all floating-point exceptions, by setting FPSCR[15, 12:8] to
0b000000.
In ARMv7 implementations, trapped floating-point exception handling is supported in the VFPv3U and VFPv4U
variants of the Floating-point Extension, see VFPv3U and VFPv4U on page A2-61. In implementations of previous
architecture versions, it is supported in VFPv2.
The Advanced SIMD Extension supports only single-precision ARM standard floating-point arithmetic.
Note
Implementations of the Floating-point Extension require support code to be installed in the system if trapped
floating-point exception handling is required. See Floating-point support code on page B1-1236.
Some implementations might also require support code to support other aspects of their floating-point arithmetic.
However, with the ARMv7 architecture, ARM deprecates using support code in this way.
It is IMPLEMENTATION DEFINED which aspects of Floating-point Extension floating-point arithmetic are supported
in a system without support code installed.
Aspects of floating-point arithmetic that are implemented in support code are likely to run much more slowly than
those that are executed in hardware.
ARM recommends that:
• To maximize the chance of getting high floating-point performance, software developers use ARM standard
floating-point arithmetic.
• Software developers check whether their systems have support code installed, and if not, observe the
IMPLEMENTATION DEFINED restrictions on what operations their Floating-point Extension implementation
can handle without support code.
• Floating-point Extension implementation developers implement at least ARM standard floating-point

arithmetic in hardware, so that it can be executed without any need for support code.
The following sections give more information about ARM floating-point data types and arithmetic:
• ARM standard floating-point input and output values.
• Advanced SIMD and Floating-point single-precision format on page A2-63.
• Floating-point double-precision format on page A2-64.
• Advanced SIMD and Floating-point half-precision formats on page A2-65.
• Flush-to-zero on page A2-67.
• NaN handling and the Default NaN on page A2-68.
• Floating-point exceptions on page A2-69.
• Pseudocode details of floating-point operations on page A2-72.
A2.7.1 ARM standard floating-point input and output values

ARM standard floating-point arithmetic supports the following input formats defined by the IEEE 754
floating-point standard:
• Zeros.
• Normalized numbers.
• Denormalized numbers are flushed to 0 before floating-point operations, see Flush-to-zero on page A2-67.
• NaNs.
• Infinities.
ARM standard floating-point arithmetic supports the Round to Nearest rounding mode defined by the IEEE 754
standard.
ARM standard floating-point arithmetic supports the following output result formats defined by the IEEE 754
standard:
• Zeros.
• Normalized numbers.
• Results that are less than the minimum normalized number are flushed to zero, see Flush-to-zero on
page A2-67.
• NaNs produced in floating-point operations are always the default NaN, see NaN handling and the Default
NaN on page A2-68.
• Infinities.
A2.7.2 Advanced SIMD and Floating-point single-precision format

The single-precision floating-point format used by the Advanced SIMD and Floating-point Extensions is as defined
by the IEEE 754 standard.
This description includes ARM-specific details that are left open by the standard. It is only intended as an
introduction to the formats and to the values they can contain. For full details, especially of the handling of infinities,
NaNs and signed zeros, see the IEEE 754 standard.
A single-precision value is a 32-bit word with the format:

31 30 23 22 0
S exponent fraction
The interpretation of the format depends on the value of the exponent field, bits[30:23]:
0 < exponent < 0xFF

The value is a normalized number and is equal to:
(–1)S × 2(exponent – 127) × (1.fraction).
The minimum positive normalized number is 2–126, or approximately 1.175 × 10–38.
The maximum positive normalized number is (2 – 2–23) × 2127, or approximately 3.403 × 1038.
exponent == 0
The value is either a zero or a denormalized number, depending on the fraction bits:
fraction == 0
The value is a zero. There are two distinct zeros:
+0 When S==0.
–0 When S==1.
These usually behave identically. In particular, the result is equal if +0 and –0 are
compared as floating-point numbers. However, they yield different results in some
circumstances. For example, the sign of the infinity produced as the result of dividing
by zero depends on the sign of the zero. The two zeros can be distinguished from each
other by performing an integer comparison of the two words.
fraction != 0
The value is a denormalized number and is equal to:
(–1)S × 2–126 × (0.fraction)
The minimum positive denormalized number is 2–149, or approximately 1.401 × 10–45.
Denormalized numbers are always flushed to zero in the Advanced SIMD Extension. They are
optionally flushed to zero in the Floating-point Extension. For details see Flush-to-zero on
page A2-67.
exponent == 0xFF
The value is either an infinity or a Not a Number (NaN), depending on the fraction bits:
fraction == 0
The value is an infinity. There are two distinct infinities:
+infinity When S==0. This represents all positive numbers that are too big to be
represented accurately as a normalized number.
-infinity When S==1. This represents all negative numbers with an absolute value
that is too big to be represented accurately as a normalized number.
fraction != 0
The value is a NaN, and is either a quiet NaN or a signaling NaN.
In the Floating-point Extension, the two types of NaN are distinguished on the basis of
their most significant fraction bit, bit[22]:
bit[22] == 0
The NaN is a signaling NaN. The sign bit can take any value, and the
remaining fraction bits can take any value except all zeros.
bit[22] == 1
The NaN is a quiet NaN. The sign bit and remaining fraction bits can take
any value.
For details of the default NaN see NaN handling and the Default NaN on page A2-68.
Note
NaNs with different sign or fraction bits are distinct NaNs, but this does not mean software can use floating-point
comparison instructions to distinguish them. This is because the IEEE 754 standard specifies that a NaN compares
as unordered with everything, including itself.
A2.7.3 Floating-point double-precision format

The double-precision floating-point format used by the Floating-point Extension is as defined by the IEEE 754
standard.
This description includes Floating-point Extension-specific details that are left open by the standard. It is only
intended as an introduction to the formats and to the values they can contain. For full details, especially of the
handling of infinities, NaNs and signed zeros, see the IEEE 754 standard.
A double-precision value is a 64-bit doubleword, with the format:
63 62 52 51 32 31 0
S exponent fraction
Double-precision values represent numbers, infinities and NaNs in a similar way to single-precision values, with
the interpretation of the format depending on the value of the exponent:
0 < exponent < 0x7FF

(–1)S × 2(exponent–1023) × (1.fraction).

The minimum positive normalized number is 2–1022, or approximately 2.225 × 10–308.
The maximum positive normalized number is (2 – 2–52) × 21023, or approximately 1.798 × 10308.
exponent == 0
fraction == 0
The value is a zero. There are two distinct zeros that behave analogously to the two
single-precision zeros:
+0 when S==0.
–0 when S==1.
fraction != 0
(-1)S × 2–1022 × (0.fraction).
Optionally, denormalized numbers are flushed to zero in the Floating-point Extension. For details
see Flush-to-zero on page A2-67.
exponent == 0x7FF
The value is either an infinity or a NaN, depending on the fraction bits:
fraction == 0
the value is an infinity. As for single-precision, there are two infinities:
+infinity When S==0.
-infinity When S==1.
fraction != 0
The value is a NaN, and is either a quiet NaN or a signaling NaN.
In the Floating-point Extension, the two types of NaN are distinguished on the basis of
their most significant fraction bit, bit[51] of the doubleword:
bit[51] == 0
The NaN is a signaling NaN. The sign bit can take any value, and the
remaining fraction bits can take any value except all zeros.
bit[51] == 1
The NaN is a quiet NaN. The sign bit and the remaining fraction bits can
take any value.
For details of the default NaN, see NaN handling and the Default NaN on page A2-68.
Note
NaNs with different sign or fraction bits are distinct NaNs, but this does not mean software can use floating-point
comparison instructions to distinguish them. This is because the IEEE 754 standard specifies that a NaN compares
as unordered with everything, including itself.
A2.7.4 Advanced SIMD and Floating-point half-precision formats

The Half-precision Extension to the Advanced SIMD and Floating-point Extensions uses two half-precision
floating-point formats:
• IEEE half-precision, as described in the IEEE 754-2008 standard.
• Alternative half-precision.
The description of IEEE half-precision includes ARM-specific details that are left open by the standard, and is only
an introduction to the formats and to the values they can contain. For more information, especially on the handling
of infinities, NaNs, and signed zeros, see the IEEE 754 standard.
For both half-precision floating-point formats, the layout of the 16-bit number is the same. The format is:
15 14 10 9 0
S exponent fraction
The interpretation of the format depends on the value of the exponent field, bits[14:10] and on which half-precision
format is being used.
0 < exponent < 0x1F

(–1)S × 2(exponent-15) × (1.fraction).
The minimum positive normalized number is 2–14, or approximately 6.104 ⋅ 10–5.
The maximum positive normalized number is (2 – 2–10) × 215, or 65504.
Larger normalized numbers can be expressed using the alternative format when the
exponent == 0x1F.
exponent == 0
fraction == 0
The value is a zero. There are two distinct zeros:
+0 when S==0.
–0 when S==1.
fraction != 0
(–1)S × 2–14 × (0.fraction).
exponent == 0x1F
The value depends on which half-precision format is being used:
IEEE half-precision
The value is either an infinity or a Not a Number (NaN), depending on the fraction bits:
fraction == 0
The value is an infinity. There are two distinct infinities:
+infinity When S==0. This represents all positive numbers that are too
big to be represented accurately as a normalized number.
-infinity When S==1. This represents all negative numbers with an
absolute value that is too big to be represented accurately as a
normalized number.
fraction != 0
The value is a NaN, and is either a quiet NaN or a signaling NaN. The two
types of NaN are distinguished by their most significant fraction bit, bit[9]:
bit[9] == 0 The NaN is a signaling NaN. The sign bit can take any value,
and the remaining fraction bits can take any value except all
zeros.
bit[9] == 1 The NaN is a quiet NaN. The sign bit and remaining fraction
bits can take any value.
Alternative half-precision
-1S × 216 × (1.fraction).
The maximum positive normalized number is (2-2-10) × 216 or 131008.
A2.7.5 Flush-to-zero
The performance of floating-point implementations can be significantly reduced when performing calculations
involving denormalized numbers and Underflow exceptions. In particular this occurs for implementations that only
handle normalized numbers and zeros in hardware, and invoke support code to handle any other types of value. For
an algorithm where a significant number of the operands and intermediate results are denormalized numbers, this
can result in a considerable loss of performance.
In many of these algorithms, this performance can be recovered, without significantly affecting the accuracy of the
final result, by replacing the denormalized operands and intermediate results with zeros. To permit this optimization,
Floating-point Extension implementations have a special processing mode called Flush-to-zero mode. Advanced
SIMD implementations always use Flush-to-zero mode.
Behavior in Flush-to-zero mode differs from normal IEEE 754 arithmetic in the following ways:
• All inputs to floating-point operations that are double-precision denormalized numbers or single-precision
denormalized numbers are treated as though they were zero. This causes an Input Denormal exception, but
does not cause an Inexact exception. The Input Denormal exception occurs only in Flush-to-zero mode.
Note
Combinations of exceptions on page A2-70 defines the floating-point operations.
The FPSCR contains a cumulative exception bit FPSCR.IDC and trap enable bit FPSCR.IDE corresponding
to the Input Denormal exception.
The occurrence of all exceptions except Input Denormal is determined using the input values after
flush-to-zero processing has occurred.
• The result of a floating-point operation is flushed to zero if the result of the operation before rounding
satisfies the condition:
0 < Abs(result) < MinNorm, where:
— MinNorm is 2-126 for single-precision.
— MinNorm is 2-1022 for double-precision.
This causes the FPSCR.UFC bit to be set to 1, and prevents any Inexact exception from occurring for the
operation.
Underflow exceptions occur only when a result is flushed to zero.
In a VFPv2, VFPv3U, or VFPv4U implementation Underflow exceptions that occur in Flush-to-zero mode
are always treated as untrapped, even when the Underflow trap enable bit, FPSCR.UFE, is set to 1.
• An Inexact exception does not occur if the result is flushed to zero, even though the final result of zero is not
equivalent to the value that would be produced if the operation were performed with unbounded precision
and exponent range.
When an input or a result is flushed to zero the value of the sign bit of the zero is determined as follows:
• In VFPv4, VFPv4U, VFPv3, or VFPv3U, it is preserved. That is, the sign bit of the zero matches the sign bit
of the input or result that is being flushed to zero.
• In VFPv2, it is IMPLEMENTATION DEFINED whether it is preserved or always positive. The same choice must
be made for all cases of flushing an input or result to zero.
Flush-to-zero mode has no effect on half-precision numbers that are inputs to floating-point operations, or results
from floating-point operations.
Note
Flush-to-zero mode is incompatible with the IEEE 754 standard, and must not be used when IEEE 754 compatibility
is a requirement. Flush-to-zero mode must be used with care. Although it can improve performance on some
algorithms, there are significant limitations on its use. These are application dependent:
• On many algorithms, it has no noticeable effect, because the algorithm does not normally use denormalized
numbers.
• On other algorithms, it can cause exceptions to occur or seriously reduce the accuracy of the results of the
algorithm.
A2.7.6 NaN handling and the Default NaN

The IEEE 754 standard specifies that:
• An operation that produces an Invalid Operation floating-point exception generates a quiet NaN as its result
if that exception is untrapped.
• An operation involving a quiet NaN operand, but not a signaling NaN operand, returns an input NaN as its
result.
The Floating-point Extension behavior when Default NaN mode is disabled adheres to this, with the following
additions:
• If an untrapped Invalid Operation floating-point exception is produced, the quiet NaN result is derived from:
— The first signaling NaN operand, if the exception was produced because at least one of the operands
is a signaling NaN.
— Otherwise, the default NaN
• If an untrapped Invalid Operation floating-point exception is not produced, but at least one of the operands
is a quiet NaN, the result is derived from the first quiet NaN operand.
Depending on the operation, the exact value of a derived quiet NaN result may differ in both sign and number of
fraction bits from its source. For a quiet NaN result derived from signaling NaN operand, the most-significant
fraction bit is set to 1.
Note
• In these descriptions, first operand relates to the left-to-right ordering of the arguments to the pseudocode
function that describes the operation.
• The IEEE 754 standard specifies that the sign bit of a NaN has no significance.
The Floating-point Extension behavior when Default NaN mode is enabled, and the Advanced SIMD behavior in
all circumstances, is that the Default NaN is the result of all floating-point operations that either:
• Generate untrapped Invalid Operation floating-point exceptions.
• Have one or more quiet NaN inputs, but no signaling NaN inputs.
Table A2-7 shows the format of the default NaN for ARM floating-point processors.
Default NaN mode is selected for the Floating-point Extension by setting the FPSCR.DN bit to 1.
Other aspects of the functionality of the Invalid Operation exception are not affected by Default NaN mode. These
are that:
• If untrapped, it causes the FPSCR.IOC bit be set to 1.
• If trapped, it causes a user trap handler to be invoked. This is only possible in VFPv2, VFPv3U, and VFPv4U.
Table A2-7 Default NaN encoding
Half-precision, IEEE Format Single-precision Double-precision
Sign bit 0 0a 0a
Exponent 0x1F 0xFF 0x7FF
Fraction Bit[9] == 1, bits[8:0] == 0 bit[22] == 1, bits[21:0] == 0 bit[51] == 1, bits[50:0] == 0
a. In VFPv2, the sign bit of the Default NaN is UNKNOWN.
A2.7.7 Floating-point exceptions

The Advanced SIMD and Floating-point Extensions record the following floating-point exceptions in the FPSCR
cumulative bits:
FPSCR.IOC Invalid Operation. The bit is set to 1 if the result of an operation has no mathematical value or cannot
be represented. Cases include, for example:
• (infinity) × 0.
• (+infinity) + (–infinity).
These tests are made after flush-to-zero processing. For example, if flush-to-zero mode is selected,
multiplying a denormalized number and an infinity is treated as (0 × infinity), and causes an Invalid
Operation floating-point exception.
IOC is also set on any floating-point operation with one or more signaling NaNs as operands, except
for negation and absolute value, as described in Floating-point negation and absolute value on
page A2-74.
FPSCR.DZC Division by Zero. The bit is set to 1 if a divide operation has a zero divisor and a dividend that is
not zero, an infinity or a NaN. These tests are made after flush-to-zero processing, so if flush-to-zero
processing is selected, a denormalized dividend is treated as zero and prevents Division by Zero
from occurring, and a denormalized divisor is treated as zero and causes Division by Zero to occur
if the dividend is a normalized number.
For the reciprocal and reciprocal square root estimate functions the dividend is assumed to be +1.0.
This means that a zero or denormalized operand to these functions sets the DZC bit.
FPSCR.OFC Overflow. The bit is set to 1 if the absolute value of the result of an operation, produced after
rounding, is greater than the maximum positive normalized number for the destination precision.
FPSCR.UFC Underflow. The bit is set to 1 if the absolute value of the result of an operation, produced before
rounding, is less than the minimum positive normalized number for the destination precision, and
the rounded result is inexact.
The criteria for the Underflow exception to occur are different in Flush-to-zero mode. For details,
see Flush-to-zero on page A2-67.
FPSCR.IXC Inexact. The bit is set to 1 if the result of an operation is not equivalent to the value that would be
produced if the operation were performed with unbounded precision and exponent range.
The criteria for the Inexact exception to occur are different in Flush-to-zero mode. For details, see
Flush-to-zero on page A2-67.
FPSCR.IDC Input Denormal. The bit is set to 1 if a denormalized input operand is replaced in the computation
by a zero, as described in Flush-to-zero on page A2-67.
With the Advanced SIMD Extension and the VFPv3 or VFPv4 versions of the Floating-point Extension these are
non-trapping exceptions and the data-processing instructions do not generate any trapped exceptions.
With the VFPv2, VFPv3U, and VFPv4U versions of the Floating-point Extension:
• These exceptions can be trapped, by setting trap enable bits in the FPSCR, see VFPv3U and VFPv4U on
page A2-61. The way in which trapped floating-point exceptions are delivered to user software is
IMPLEMENTATION DEFINED. However, ARM recommends use of the VFP subarchitecture defined in
Appendix D6 Common VFP Subarchitecture Specification.
• The definition of the Underflow exception is different in the trapped and cumulative exception cases. In the
trapped case, meaning for VFPv2, VFPv3U, or VFPv4U, the definition is:
— The trapped Underflow exception occurs if the absolute value of the result of an operation, produced
before rounding, is less than the minimum positive normalized number for the destination precision,
regardless of whether the rounded result is inexact.
• As with cumulative exceptions, higher priority trapped exceptions can prevent lower priority exceptions from
occurring, as described in Combinations of exceptions.
Table A2-8 shows the results of untrapped floating-point exceptions:
Table A2-8 Results of untrapped floating-point exceptions
Exception type Default result for positive sign Default result for negative sign
IOC, Invalid Operation Quiet NaN Quiet NaN
DZC, Division by Zero +infinity -infinity
OFC, Overflow RN, RP: +infinity RN, RM: -infinity

RM, RZ: +MaxNorm RP, RZ: -MaxNorm
UFC, Underflow Normal rounded result Normal rounded result
IXC, Inexact Normal rounded result Normal rounded result
IDC, Input Denormal Normal rounded result Normal rounded result
In Table A2-8:
MaxNorm The maximum normalized number of the destination precision.
RM Round towards Minus Infinity mode, as defined in the IEEE 754 standard.
RN Round to Nearest mode, as defined in the IEEE 754 standard.
RP Round towards Plus Infinity mode, as defined in the IEEE 754 standard.
RZ Round towards Zero mode, as defined in the IEEE 754 standard.
• For Invalid Operation exceptions, for details of which quiet NaN is produced as the default result see NaN
handling and the Default NaN on page A2-68.
• For Division by Zero exceptions, the sign bit of the default result is determined normally for a division. This
means it is the exclusive OR of the sign bits of the two operands.
• For Overflow exceptions, the sign bit of the default result is determined normally for the overflowing
operation.
Combinations of exceptions
The following pseudocode functions perform floating-point operations:
FixedToFP()
FPAdd()
FPCompare()
FPCompareEQ()
FPCompareGE()
FPCompareGT()
FPDiv()
FPDoubleToSingle()
FPHalfToSingle()
FPMax()
FPMin()
FPMul()
FPMulAdd()
FPRecipEstimate()
FPRecipStep()
FPRSqrtEstimate()
FPRSqrtStep()
FPSingleToDouble()
FPSingleToHalf()
FPSqrt()
FPSub()
FPToFixed()
All of these operations can generate floating-point exceptions.
Note
FPAbs() and FPNeg() are not classified as floating-point operations because:
• They cannot generate floating-point exceptions.
• The floating-point operation behavior described in the following sections does not apply to them:
— Flush-to-zero on page A2-67.
— NaN handling and the Default NaN on page A2-68.
More than one exception can occur on the same operation. The only combinations of exceptions that can occur are:
• Overflow with Inexact.
• Underflow with Inexact.
• Input Denormal with other exceptions.
When none of the exceptions caused by an operation are trapped, any exception that occurs causes the associated
cumulative bit in the FPSCR to be set.
When one or more exceptions caused by an operation are trapped, the behavior of the instruction depends on the
priority of the exceptions. The Inexact exception is treated as lowest priority, and Input Denormal as highest priority:
• If the higher priority exception is trapped, its trap handler is called. It is IMPLEMENTATION DEFINED whether
the parameters to the trap handler include information about the lower priority exception. Apart from this,
the lower priority exception is ignored in this case.
• If the higher priority exception is untrapped, its cumulative bit is set to 1 and its default result is evaluated.
Then the lower priority exception is handled normally, using this default result.
Some floating-point instructions specify more than one floating-point operation, as indicated by the pseudocode
descriptions of the instruction. In such cases, an exception on one operation is treated as higher priority than an
exception on another operation if the occurrence of the second exception depends on the result of the first operation.
Otherwise, it is UNPREDICTABLE which exception is treated as higher priority.
For example, a VMLA.F32 instruction specifies a floating-point multiplication followed by a floating-point addition.
The addition can generate Overflow, Underflow and Inexact exceptions, all of which depend on both operands to
the addition and so are treated as lower priority than any exception on the multiplication. The same applies to Invalid
Operation exceptions on the addition caused by adding opposite-signed infinities. The addition can also generate an
Input Denormal exception, caused by the addend being a denormalized number while in Flush-to-zero mode. It is
UNPREDICTABLE which of an Input Denormal exception on the addition and an exception on the multiplication is
treated as higher priority, because the occurrence of the Input Denormal exception does not depend on the result of
the multiplication. The same applies to an Invalid Operation exception on the addition caused by the addend being
a signaling NaN.
Note
• The VFMA instruction performs a vector addition and a vector multiplication as a single operation. The VFMS
instruction performs a vector subtraction and a vector multiplication as a single operation.
• Like other details of Floating-point instruction execution, these rules about exception handling apply to the
overall results produced by an instruction when the system uses a combination of hardware and support code
to implement it. See Floating-point support code on page B1-1236 for more information.
These principles also apply to the multiple floating-point operations generated by Floating-point instructions
in the deprecated VFP vector mode of operation. For details of this mode of operation, see Appendix D11
VFP Vector Operation Support.
A2.7.8 Pseudocode details of floating-point operations

The following subsections contain pseudocode definitions of the floating-point functionality supported by the
ARMv7 architecture:
• Generation of specific floating-point values.
• Floating-point negation and absolute value on page A2-74.
• Floating-point value unpacking on page A2-74.
• Floating-point exception and NaN handling on page A2-75.
• Floating-point rounding on page A2-77.
• Selection of ARM standard floating-point arithmetic on page A2-78.
• Floating-point comparisons on page A2-79.
• Floating-point maximum and minimum on page A2-80.
• Floating-point addition and subtraction on page A2-81.
• Floating-point multiplication and division on page A2-82.
• Floating-point fused multiply-add on page A2-82.
• Floating-point reciprocal estimate and step on page A2-84.
• Floating-point square root on page A2-86.
• Floating-point reciprocal square root estimate and step on page A2-86.
• Floating-point conversions on page A2-89.
Generation of specific floating-point values

The following pseudocode functions generate specific floating-point values. The sign argument of FPInfinity(),
FPMaxNormal(), and FPZero() is '0' for the positive version and '1' for the negative version.
// FPZero()
// ========
bits(N) FPZero(bit sign, integer N)

assert N IN {16,32,64};
if N == 16 then
E = 5;
elsif N == 32 then
E = 8;
else E = 11;
F = N - E - 1;
exp = Zeros(E);
frac = Zeros(F);
return sign:exp:frac;
// FPTwo()
// =======
bits(N) FPTwo(integer N)
assert N IN {32,64};
if N == 16 then
E = 5;
elsif N == 32 then
E = 8;
else E = 11;
F = N - E - 1;
sign = '0';
exp = '1':Zeros(E-1);
frac = Zeros(F);
// FPThree()
// =========
bits(N) FPThree(integer N)
if N == 16 then
E = 5;
elsif N == 32 then
E = 8;
else E = 11;
F = N - E - 1;
sign = '0';
exp = '1':Zeros(E-1);
frac = '1':Zeros(F-1);
// FPMaxNormal()
// =============
bits(N) FPMaxNormal(bit sign, integer N)

assert N IN {16,32,64};
if N == 16 then
E = 5;
elsif N == 32 then
E = 8;
else E = 11;
F = N - E - 1;
exp = Ones(E-1):'0';
frac = Ones(F);
// FPInfinity()
// ============
bits(N) FPInfinity(bit sign, integer N)

assert N IN {16,32,64};
if N == 16 then
E = 5;
elsif N == 32 then
E = 8;
else E = 11;
F = N - E - 1;
exp = Ones(E);
frac = Zeros(F);
// FPDefaultNaN()
// ==============
bits(N) FPDefaultNaN(integer N)
assert N IN {16,32,64};
if N == 16 then
E = 5;
elsif N == 32 then
E = 8;
else E = 11;
F = N - E - 1;
sign = '0';
exp = Ones(E);
frac = '1':Zeros(F-1);
Note
This definition of FPDefaultNaN() applies to VFPv4, VFPv4U, VFPv3, and VFPv3U implementations. For VFPv2,
the sign bit of the result is a single-bit UNKNOWN value, instead of 0.
Floating-point negation and absolute value

The floating-point negation and absolute value operations only affect the sign bit. They do not treat NaN operands
specially, nor denormalized number operands when flush-to-zero is selected.
// FPNeg()
// =======
bits(N) FPNeg(bits(N) operand)

return NOT(operand<N-1>) : operand<N-2:0>;
// FPAbs()
// =======
bits(N) FPAbs(bits(N) operand)

return '0' : operand<N-2:0>;
Floating-point value unpacking

The FPUnpack() function determines the type and numerical value of a floating-point number. It also does
flush-to-zero processing on input operands.
enumeration FPType {FPType_Nonzero, FPType_Zero, FPType_Infinity, FPType_QNaN, FPType_SNaN};
// FPUnpack()
// ==========
//
// Unpack a floating-point number into its type, sign bit and the real number
// that it represents. The real number result has the correct sign for numbers
// and infinities, is very large in magnitude for infinities, and is 0.0 for
// NaNs. (These values are chosen to simplify the description of comparisons
// and conversions.)
//
// The 'fpscr_val' argument supplies FPSCR control bits. Status information is
// updated directly in the FPSCR where appropriate.
(FPType, bit, real) FPUnpack(bits(N) fpval, bits(32) fpscr_val)

assert N IN {16,32,64};
if N == 16 then
sign = fpval<15>;
exp16 = fpval<14:10>;
frac16 = fpval<9:0>;
if IsZero(exp16) then
// Produce zero if value is zero
if IsZero(frac16) then
type = FPType_Zero; value = 0.0;
else
type = FPType_Nonzero; value = 2.0^-14 * (UInt(frac16) * 2.0^-10);
elsif IsOnes(exp16) && fpscr_val<26> == '0' then // Infinity or NaN in IEEE format
type = FPType_Infinity; value = 2.0^1000000;
else
type = if frac16<9> == '1' then FPType_QNaN else FPType_SNaN;
value = 0.0;
else
type = FPType_Nonzero; value = 2.0^(UInt(exp16)-15) * (1.0 + UInt(frac16) * 2.0^-10);
elsif N == 32 then
sign = fpval<31>;
exp32 = fpval<30:23>;
// Produce zero if value is zero or flush-to-zero is selected.
if IsZero(frac32) || fpscr_val<24> == '1' then

if !IsZero(frac32) then // Denormalized input flushed to zero
FPProcessException(FPExc_InputDenorm, fpscr_val);
else
elsif IsOnes(exp32) then
else
value = 0.0;
else
else // N == 64
sign = fpval<63>;
exp64 = fpval<62:52>;
// Produce zero if value is zero or flush-to-zero is selected.
if IsZero(frac64) || fpscr_val<24> == '1' then
if !IsZero(frac64) then // Denormalized input flushed to zero
FPProcessException(FPExc_InputDenorm, fpscr_val);
else
elsif IsOnes(exp64) then
else
value = 0.0;
else
if sign == '1' then value = -value;

return (type, sign, value);
Floating-point exception and NaN handling

The FPProcessException() procedure checks whether a floating-point exception is trapped, and handles it
accordingly:
enumeration FPExc {FPExc_InvalidOp, FPExc_DivideByZero, FPExc_Overflow,

FPExc_Underflow, FPExc_Inexact, FPExc_InputDenorm};
// FPProcessException()
// ====================
//
FPProcessException(FPExc exception, bits(32) fpscr_val)

// Get appropriate FPSCR bit numbers
case exception of
when FPExc_InvalidOp enable = 8; cumul = 0;
when FPExc_DivideByZero enable = 9; cumul = 1;
when FPExc_Overflow enable = 10; cumul = 2;
when FPExc_Underflow enable = 11; cumul = 3;
when FPExc_Inexact enable = 12; cumul = 4;
when FPExc_InputDenorm enable = 15; cumul = 7;
if fpscr_val<enable> == '1' then
IMPLEMENTATION_DEFINED floating-point trap handling;
else
FPSCR<cumul> = '1';
return;
The FPProcessNaN() function processes a NaN operand, producing the correct result value and generating an Invalid
Operation exception if necessary:
// FPProcessNaN()
// ==============
//
bits(N) FPProcessNaN(FPType type, bits(N) operand, bits(32) fpscr_val)

topfrac = if N == 32 then 22 else 51;
result = operand;
if type == FPType_SNaN then
result<topfrac> = '1';
FPProcessException(FPExc_InvalidOp, fpscr_val);
if fpscr_val<25> == '1' then // DefaultNaN requested
result = FPDefaultNaN(N);
return result;
The FPProcessNaNs() function performs the standard NaN processing for a two-operand operation:
// FPProcessNaNs()
// ===============
//
// The boolean part of the return value says whether a NaN has been found and
// processed. The bits(N) part is only relevant if it has and supplies the
// result of the operation.
//
(boolean, bits(N)) FPProcessNaNs(FPType type1, FPType type2,

bits(N) op1, bits(N) op2,
bits(32) fpscr_val)
if type1 == FPType_SNaN then
done = TRUE; result = FPProcessNaN(type1, op1, fpscr_val);
elsif type2 == FPType_SNaN then
elsif type1 == FPType_QNaN then
else
done = FALSE; result = Zeros(N); // 'Don't care' result
return (done, result);
The FPProcessNaNs3() function performs the standard NaN processing for a three-operand operation:
// FPProcessNaNs3()
// ===============
//
// The boolean part of the return value says whether a NaN has been found and
// processed. The bits(N) part is only relevant if it has and supplies the
// result of the operation.
//
(boolean, bits(N)) FPProcessNaNs3(FPType type1, FPType type2, FPType type3,

bits(N) op1, bits(N) op2, bits(N) op3,
bits(32) fpscr_val)
if type1 == FPType_SNaN then

else
done = FALSE; result = Zeros(N); // 'Don't care' result
return (done, result);
Floating-point rounding
The FPRound() function rounds and encodes a supplied floating-point value to a specified destination format. This
includes processing Overflow, Underflow, and Inexact floating-point exceptions and performing flush-to-zero
processing on the resulting value.
// FPRound()
// =========
//
bits(N) FPRound(real value, integer N, bits(32) fpscr_val)

assert N IN {16,32,64};
assert value != 0.0;
// Obtain format parameters - minimum exponent, numbers of exponent and fraction bits.
if N == 16 then
E = 5;
elsif N == 32 then
E = 8;
else E = 11;
minimum_exp = 2 - 2^(E-1);
F = N - E - 1;
// Split value into sign, unrounded mantissa and exponent.

if value < 0.0 then
sign = '1'; mantissa = -value;
else
sign = '0'; mantissa = value;
exponent = 0;
while mantissa < 1.0 do
mantissa = mantissa * 2.0; exponent = exponent - 1;
while mantissa >= 2.0 do
mantissa = mantissa / 2.0; exponent = exponent + 1;
// Deal with flush-to-zero.

if fpscr_val<24> == '1' && N != 16 && exponent < minimum_exp then
result = FPZero(sign, N);
FPSCR.UFC = '1'; // Flush-to-zero never generates a trapped exception
else
// Start creating the exponent value for the result. Start by biasing the actual exponent
// so that the minimum exponent becomes 1, lower values 0 (indicating possible underflow).
biased_exp = Max(exponent - minimum_exp + 1, 0);
if biased_exp == 0 then mantissa = mantissa / 2^(minimum_exp - exponent);
// Get the unrounded mantissa as an integer, and the "units in last place" rounding error.
int_mant = RoundDown(mantissa * 2^F); // < 2^F if biased_exp == 0, >= 2^F if not
error = mantissa * 2^F - int_mant;
// Underflow occurs if exponent is too small before rounding, and result is inexact or
// the Underflow exception is trapped.
if biased_exp == 0 && (error != 0.0 || fpscr_val<11> == '1') then

FPProcessException(FPExc_Underflow, fpscr_val);
// Round result according to rounding mode.

case fpscr_val<23:22> of
when '00' // Round to Nearest (rounding to even if exactly halfway)
round_up = (error > 0.5 || (error == 0.5 && int_mant<0> == '1'));
overflow_to_inf = TRUE;
when '01' // Round towards Plus Infinity
round_up = (error != 0.0 && sign == '0');
overflow_to_inf = (sign == '0');
when '10' // Round towards Minus Infinity
round_up = (error != 0.0 && sign == '1');
overflow_to_inf = (sign == '1');
when '11' // Round towards Zero
round_up = FALSE;
overflow_to_inf = FALSE;
if round_up then
int_mant = int_mant + 1;
if int_mant == 2^F then // Rounded up from denormalized to normalized
biased_exp = 1;
if int_mant == 2^(F+1) then // Rounded up to next exponent
biased_exp = biased_exp + 1;
int_mant = int_mant DIV 2;
// Deal with overflow and generate result.

if N != 16 || fpscr_val<26> == '0' then // Single, double or IEEE half precision
if biased_exp >= 2^E - 1 then
result = if overflow_to_inf then FPInfinity(sign, N) else FPMaxNormal(sign, N);
FPProcessException(FPExc_Overflow, fpscr_val);
error = 1.0; // Ensure that an Inexact exception occurs
else
result = sign:biased_exp<E-1:0>:int_mant<F-1:0>;
else // Alternative half precision (with N==16)
if biased_exp >= 2^E then
result = sign : Ones(15);
error = 0.0; // Ensure that an Inexact exception does not occur
else
result = sign:biased_exp<E-1:0>:int_mant<F-1:0>;
// Deal with Inexact exception.

if error != 0.0 then
FPProcessException(FPExc_Inexact, fpscr_val);
return result;
Selection of ARM standard floating-point arithmetic

The StandardFPSCRValue() function returns the FPSCR value that selects ARM standard floating-point arithmetic.
Most of the arithmetic functions have a Boolean fpscr_controlled argument that is TRUE for Floating-point
operations and FALSE for Advanced SIMD operations, and that selects between using the real FPSCR value and this
value.
// StandardFPSCRValue()
// ====================
bits(32) StandardFPSCRValue()
return '00000' : FPSCR<26> : '11000000000000000000000000';
Floating-point comparisons
The FPCompare() function compares two floating-point numbers, producing a {N, Z, C, V} condition flags result as
shown in Table A2-9:
Table A2-9 Effect of a Floating-point comparison on the condition flags
Comparison result N Z C V
Equal 0 1 1 0
Less than 1 0 0 0
Greater than 0 0 1 0
Unordered 0 0 1 1
This result defines the operation of the VCMP instruction in the Floating-point Extension. The VCMP instruction writes
these flag values in the FPSCR. After using a VMRS instruction to transfer them to the APSR, they can control
conditional execution as shown in Table A8-1 on page A8-286.
// FPCompare()
// ===========
(bit, bit, bit, bit) FPCompare(bits(N) op1, bits(N) op2, boolean quiet_nan_exc,
boolean fpscr_controlled)
fpscr_val = if fpscr_controlled then FPSCR else StandardFPSCRValue();
(type1,sign1,value1) = FPUnpack(op1, fpscr_val);
if type1==FPType_SNaN || type1==FPType_QNaN || type2==FPType_SNaN || type2==FPType_QNaN then
result = ('0','0','1','1');
if type1==FPType_SNaN || type2==FPType_SNaN || quiet_nan_exc then
else
// All non-NaN cases can be evaluated on the values produced by FPUnpack()
if value1 == value2 then
result = ('0','1','1','0');
elsif value1 < value2 then
result = ('1','0','0','0');
else // value1 > value2
result = ('0','0','1','0');
return result;
The FPCompareEQ(), FPCompareGE() and FPCompareGT() functions describe the operation of Advanced SIMD
instructions that perform floating-point comparisons.
// FPCompareEQ()
// =============
boolean FPCompareEQ(bits(32) op1, bits(32) op2, boolean fpscr_controlled)

result = FALSE;
if type1==FPType_SNaN || type2==FPType_SNaN then
else
result = (value1 == value2);
return result;
// FPCompareGE()
// =============
boolean FPCompareGE(bits(32) op1, bits(32) op2, boolean fpscr_controlled)

result = FALSE;
else
result = (value1 >= value2);
return result;
// FPCompareGT()
// =============
boolean FPCompareGT(bits(32) op1, bits(32) op2, boolean fpscr_controlled)

result = FALSE;
else
result = (value1 > value2);
return result;
Floating-point maximum and minimum

// FPMax()
// =======
bits(N) FPMax(bits(N) op1, bits(N) op2, boolean fpscr_controlled)

(done,result) = FPProcessNaNs(type1, type2, op1, op2, fpscr_val);
if !done then
if value1 > value2 then
(type,sign,value) = (type1,sign1,value1);
else
if type == FPType_Infinity then
result = FPInfinity(sign, N);
elsif type == FPType_Zero then
sign = sign1 AND sign2; // Use most positive sign
else
result = FPRound(value, N, fpscr_val);
return result;
// FPMin()
// =======
bits(N) FPMin(bits(N) op1, bits(N) op2, boolean fpscr_controlled)

if !done then
if value1 < value2 then
else
if type == FPType_Infinity then

sign = sign1 OR sign2; // Use most negative sign
else
result = FPRound(value, N, fpscr_val);
return result;
Floating-point addition and subtraction

// FPAdd()
// =======
bits(N) FPAdd(bits(N) op1, bits(N) op2, boolean fpscr_controlled)

if !done then
inf1 = (type1 == FPType_Infinity); inf2 = (type2 == FPType_Infinity);
zero1 = (type1 == FPType_Zero); zero2 = (type2 == FPType_Zero);
if inf1 && inf2 && sign1 == NOT(sign2) then
elsif (inf1 && sign1 == '0') || (inf2 && sign2 == '0') then
result = FPInfinity('0', N);
elsif zero1 && zero2 && sign1 == sign2 then
result = FPZero(sign1, N);
else
result_value = value1 + value2;
if result_value == 0.0 then // Sign of exact zero result depends on rounding mode
result_sign = if fpscr_val<23:22> == '10' then '1' else '0';
result = FPZero(result_sign, N);
else
result = FPRound(result_value, N, fpscr_val);
return result;
// FPSub()
// =======
bits(N) FPSub(bits(N) op1, bits(N) op2, boolean fpscr_controlled)

if !done then
if inf1 && inf2 && sign1 == sign2 then
elsif zero1 && zero2 && sign1 == NOT(sign2) then
else
result_value = value1 - value2;
else

return result;
Floating-point multiplication and division

// FPMul()
// =======
bits(N) FPMul(bits(N) op1, bits(N) op2, boolean fpscr_controlled)

if !done then
if (inf1 && zero2) || (zero1 && inf2) then
elsif inf1 || inf2 then
result_sign = if sign1 == sign2 then '0' else '1';
result = FPInfinity(result_sign, N);
elsif zero1 || zero2 then
else
result = FPRound(value1*value2, N, fpscr_val);
return result;
// FPDiv()
// =======
bits(N) FPDiv(bits(N) op1, bits(N) op2, boolean fpscr_controlled)

if !done then
if (inf1 && inf2) || (zero1 && zero2) then
elsif inf1 || zero2 then
result = FPInfinity(result_sign, N);
if !inf1 then FPProcessException(FPExc_DivideByZero, fpscr_val);
elsif zero1 || inf2 then
else
result = FPRound(value1/value2, N, fpscr_val);
return result;
Floating-point fused multiply-add

// FPMulAdd()
// ==========
//
// Calculates addend + op1*op2 with a single rounding.
bits(N) FPMulAdd(bits(N) addend, bits(N) op1, bits(N) op2,

boolean fpscr_controlled)

(typeA,signA,valueA) = FPUnpack(addend, fpscr_val);
inf1 = (type1 == FPType_Infinity); zero1 = (type1 == FPType_Zero);
inf2 = (type2 == FPType_Infinity); zero2 = (type2 == FPType_Zero);
(done,result) = FPProcessNaNs3(typeA, type1, type2, addend, op1, op2, fpscr_val);
if typeA == FPType_QNaN && ((inf1 && zero2) || (zero1 && inf2)) then
if !done then
infA = (typeA == FPType_Infinity); zeroA = (typeA == FPType_Zero);
// Determine sign and type product will have if it does not cause an Invalid
// Operation.
signP = if sign1 == sign2 then '0' else '1';
infP = inf1 || inf2;
zeroP = zero1 || zero2;
// Non SNaN-generated Invalid Operation cases are multiplies of zero by infinity and
// additions of opposite-signed infinities.
if (inf1 && zero2) || (zero1 && inf2) || (infA && infP && signA == NOT(signP)) then
// Other cases involving infinities produce an infinity of the same sign.

elsif (infA && signA == '0') || (infP && signP == '0') then
elsif (infA && signA == '1') || (infP && signP == '1') then
// Cases where the result is exactly zero and its sign is not determined by the
// rounding mode are additions of same-signed zeros.
elsif zeroA && zeroP && signA == signP then
result = FPZero(signA, N);
// Otherwise calculate numerical result and round it.

else
result_value = valueA + (value1 * value2);
else
return result;
Floating-point reciprocal estimate and step

The Advanced SIMD Extension includes instructions that support Newton-Raphson calculation of the reciprocal of
a number.
The VRECPE instruction produces the initial estimate of the reciprocal. It uses the following pseudocode functions:
// FPRecipEstimate()
// =================
bits(32) FPRecipEstimate(bits(32) operand)
(type,sign,value) = FPUnpack(operand, StandardFPSCRValue());

if type == FPType_SNaN || type == FPType_QNaN then
result = FPProcessNaN(type, operand, StandardFPSCRValue());
elsif type == FPType_Infinity then
result = FPZero(sign, 32);
result = FPInfinity(sign, 32);
FPProcessException(FPExc_DivideByZero, StandardFPSCRValue());
elsif Abs(value) >= 2^126 then // Result underflows to zero of correct sign
FPProcessException(FPExc_Underflow, StandardFPSCRValue());
else
// Operand must be normalized, since denormalized numbers are flushed to zero. Scale to a
// double-precision value in the range 0.5 <= x < 1.0, and calculate result exponent.
// Scaled value is positive, with:
// exponent = 1022 = double-precision representation of 2^(-1)
// fraction = original fraction extended with zeros.
scaled = '0 01111111110' : operand<22:0> : Zeros(29);
result_exp = 253 - UInt(operand<30:23>); // In range 253-252 = 1 to 253-1 = 252
// Call C function to get reciprocal estimate of scaled value.

estimate = recip_estimate(scaled);
// Result is double-precision and a multiple of 1/256 in the range 1 to 511/256. Convert

// to scaled single-precision result with the original sign bit, the copied high-order
// fraction bits, and the exponent calculated above.
result = sign : result_exp<7:0> : estimate<51:29>;
return result;
// UnsignedRecipEstimate()
// =======================
bits(32) UnsignedRecipEstimate(bits(32) operand)
if operand<31> == '0' then // Operands <= 0x7FFFFFFF produce 0xFFFFFFFF

result = Ones(32);
else
// Generate double-precision value = operand * 2^(-32). This has zero sign bit, with:
// exponent = 1022 = double-precision representation of 2^(-1)
// fraction taken from operand, excluding its most significant bit.
dp_operand = '0 01111111110' : operand<30:0> : Zeros(21);

estimate = recip_estimate(dp_operand);
// Result is double-precision and a multiple of 1/256 in the range 1 to 511/256.

// Multiply by 2^31 and convert to an unsigned integer - this just involves
// concatenating the implicit units bit with the top 31 fraction bits.
result = '1' : estimate<51:21>;
return result;
where recip_estimate() is defined by the following C function:
double recip_estimate(double a)
{
int q, s;
double r;
q = (int)(a * 512.0); /* a in units of 1/512 rounded down */
r = 1.0 / (((double)q + 0.5) / 512.0); /* reciprocal r */
s = (int)(256.0 * r + 0.5); /* r in units of 1/256 rounded to nearest */
return (double)s / 256.0;
}
Table A2-10 shows the results where input values are out of range.
Table A2-10 VRECPE results for out of range inputs
Number type Input Vm[i] Result Vd[i]
Integer <= 0x7FFFFFFF 0xFFFFFFFF
Floating-point NaN Default NaN
Floating-point ±0 or denormalized number ±infinity a
Floating-point ±infinity ±0
Floating-point Absolute value >= 2126 ±0
a. FPSCR.DZC is set to 1
The Newton-Raphson iteration:
xn+1 = xn(2-dxn)
converges to (1/d) if x0 is the result of VRECPE applied to d.
The VRECPS instruction performs a (2 - op1×op2) calculation and can be used with a multiplication to perform a
step of this iteration. The functionality of this instruction is defined by the following pseudocode function:
// FPRecipStep()
// =============
bits(32) FPRecipStep(bits(32) op1, bits(32) op2)

(type1,sign1,value1) = FPUnpack(op1, StandardFPSCRValue());
(done,result) = FPProcessNaNs(type1, type2, op1, op2, StandardFPSCRValue());
if !done then
product = FPZero('0', 32);
else
product = FPMul(op1, op2, FALSE);
result = FPSub(FPTwo(32), product, FALSE);
return result;
Table A2-11 VRECPS results for out of range inputs
Input Vn[i] Input Vm[i] Result Vd[i]
Any NaN - Default NaN
Table A2-11 VRECPS results for out of range inputs (continued)
- Any NaN Default NaN
±0.0 or denormalized number ±infinity 2.0
±infinity ±0.0 or denormalized number 2.0
Floating-point square root

// FPSqrt()
// ========
bits(N) FPSqrt(bits(N) operand)

(type,sign,value) = FPUnpack(operand, FPSCR);
result = FPProcessNaN(type, operand, FPSCR);
elsif type == FPType_Infinity && sign == '0' then
elsif sign == '1' then
FPProcessException(FPExc_InvalidOp, FPSCR);
else
result = FPRound(Sqrt(value), N, FPSCR);
return result;
Floating-point reciprocal square root estimate and step

The Advanced SIMD Extension includes instructions that support Newton-Raphson calculation of the reciprocal of
the square root of a number.
The VRSQRTE instruction produces the initial estimate of the reciprocal of the square root. It uses the following
pseudocode functions:
// FPRSqrtEstimate()
// =================
bits(32) FPRSqrtEstimate(bits(32) operand)
(type,sign,value) = FPUnpack(operand, StandardFPSCRValue());

result = FPProcessNaN(type, operand, StandardFPSCRValue());
FPProcessException(FPExc_DivideByZero, StandardFPSCRValue());
elsif sign == '1' then
result = FPDefaultNaN(32);
FPProcessException(FPExc_InvalidOp, StandardFPSCRValue());
result = FPZero('0', 32);
else
// Operand must be normalized, since denormalized numbers are flushed to zero. Scale to a
// double-precision value in the range 0.25 <= x < 1.0, with the evenness or oddness of
// the exponent unchanged, and calculate result exponent.
// Scaled value has positive sign bit, with:
// exponent = 1022 or 1021 = double-precision representation of 2^(-1) or 2^(-2)
// fraction = original fraction extended with zeros.
if operand<23> == '0' then
else
result_exp = (380 - UInt(operand<30:23>)) DIV 2;

estimate = recip_sqrt_estimate(scaled);
// Result is double-precision and a multiple of 1/256 in the range 1 to 511/256. Convert

// to scaled single-precision result with positive sign bit and high-order fraction bits,
// and exponent calculated above.
result = '0' : result_exp<7:0> : estimate<51:29>;
return result;
// UnsignedRSqrtEstimate()
// =======================
bits(32) UnsignedRSqrtEstimate(bits(32) operand)
if operand<31:30> == '00' then // Operands <= 0x3FFFFFFF produce 0xFFFFFFFF

result = Ones(32);
else
// Generate double-precision value = operand * 2^(-32). This has zero sign bit, with:
// exponent = 1022 or 1021 = double-precision representation of 2^(-1) or 2^(-2)
// fraction taken from operand, excluding its most significant one or two bits.
if operand<31> == '1' then
else // operand<31:30> == '01'

estimate = recip_sqrt_estimate(dp_operand);
// Result is double-precision and a multiple of 1/256 in the range 1 to 511/256.

// Multiply by 2^31 and convert to an unsigned integer - this just involves
// concatenating the implicit units bit with the top 31 fraction bits.
result = '1' : estimate<51:21>;
return result;
where recip_sqrt_estimate() is defined by the following C function:
double recip_sqrt_estimate(double a)
{
int q0, q1, s;
double r;
if (a < 0.5) /* range 0.25 <= a < 0.5 */
{
q0 = (int)(a * 512.0); /* a in units of 1/512 rounded down */
r = 1.0 / sqrt(((double)q0 + 0.5) / 512.0); /* reciprocal root r */
}
else /* range 0.5 <= a < 1.0 */
{
q1 = (int)(a * 256.0); /* a in units of 1/256 rounded down */
r = 1.0 / sqrt(((double)q1 + 0.5) / 256.0); /* reciprocal root r */
}
s = (int)(256.0 * r + 0.5); /* r in units of 1/256 rounded to nearest */
return (double)s / 256.0;
}
Table A2-12 VRSQRTE results for out of range inputs
Number type Input Vm[i] Result Vd[i]
Integer <= 0x3FFFFFFF 0xFFFFFFFF
Floating-point NaN, –(normalized number), –infinity Default NaN
Floating-point –0 or –(denormalized number) – infinity a
Floating-point +0 or +(denormalized number) +infinity a
Floating-point +infinity +0
a. FPSCR.DZC is set to 1.
The Newton-Raphson iteration:
xn+1 = xn(3-dxn2)/2
converges to (1/√d) if x0 is the result of VRSQRTE applied to d.
The VRSQRTS instruction performs a (3 – op1×op2)/2 calculation and can be used with two multiplications to perform
a step of this iteration. The FPRSqrtStep() pseudocode function defines the functionality of this instruction:
// FPRSqrtStep()
// =============
bits(32) FPRSqrtStep(bits(32) op1, bits(32) op2)

(done,result) = FPProcessNaNs(type1, type2, op1, op2, StandardFPSCRValue());
if !done then
product = FPZero('0', 32);
else
product = FPMul(op1, op2, FALSE);
result = FPHalvedSub(FPThree(32), product, FALSE);
return result;
Table A2-13 VRSQRTS results for out of range inputs
Any NaN - Default NaN
- Any NaN Default NaN
±0.0 or denormalized number ±infinity 1.5
±infinity ±0.0 or denormalized number 1.5
FPRSqrtStep() calls the FPHalvedSub() pseudocode function:
// FPHalvedSub()
// =============
bits(N) FPHalvedSub(bits(N) op1, bits(N) op2, boolean fpscr_controlled)


if !done then
if inf1 && inf2 && sign1 == sign2 then
elsif zero1 && zero2 && sign1 == NOT(sign2) then
else
result_value = (value1 - value2) / 2.0;
else
return result;
Floating-point conversions
The following functions perform conversions between half-precision and single-precision floating-point numbers.
// FPHalfToSingle()
// ================
bits(32) FPHalfToSingle(bits(16) operand, boolean fpscr_controlled)

(type,sign,value) = FPUnpack(operand, fpscr_val);
if fpscr_val<25> == '1' then // DN bit set
else
result = sign : '11111111 1' : operand<8:0> : Zeros(13);
else
result = FPRound(value, 32, fpscr_val); // Rounding will be exact
return result;
// FPSingleToHalf()
// ================
bits(16) FPSingleToHalf(bits(32) operand, boolean fpscr_controlled)

if fpscr_val<26> == '1' then // AH bit set
elsif fpscr_val<25> == '1' then // DN bit set
else
result = sign : '11111 1' : operand<21:13>;
if type == FPType_SNaN || fpscr_val<26> == '1' then
if fpscr_val<26> == '1' then // AH bit set
result = sign : Ones(15);

else
else
result = FPRound(value, 16, fpscr_val);
return result;
The following functions perform conversions between single-precision and double-precision floating-point
numbers.
// FPSingleToDouble()
// ==================
bits(64) FPSingleToDouble(bits(32) operand, boolean fpscr_controlled)

else
result = sign : '11111111111 1' : operand<21:0> : Zeros(29);
else
result = FPRound(value, 64, fpscr_val); // Rounding will be exact
return result;
// FPDoubleToSingle()
// ==================
bits(32) FPDoubleToSingle(bits(64) operand, boolean fpscr_controlled)

else
result = sign : '11111111 1' : operand<50:29>;
else
result = FPRound(value, 32, fpscr_val);
return result;
The following functions perform conversions between floating-point numbers and integers or fixed-point numbers:
// FPToFixed()
// ===========
bits(M) FPToFixed(bits(N) operand, integer M, integer fraction_bits, boolean unsigned,

boolean round_towards_zero, boolean fpscr_controlled)
if round_towards_zero then fpscr_val<23:22> = '11';
// For NaNs and infinities, FPUnpack() has produced a value that will round to the
// required result of the conversion. Also, the value produced for infinities will
// cause the conversion to overflow and signal an Invalid Operation floating-point
// exception as required. NaNs must also generate such a floating-point exception.
// Scale value by specified number of fraction bits, then start rounding to an integer
// and determine the rounding error.
value = value * 2^fraction_bits;
int_result = RoundDown(value);
error = value - int_result;
// Apply the specified rounding mode.

case fpscr_val<23:22> of
when '00' // Round to Nearest (rounding to even if exactly halfway)
round_up = (error > 0.5 || (error == 0.5 && int_result<0> == '1'));
when '01' // Round towards Plus Infinity
round_up = (error != 0.0);
when '10' // Round towards Minus Infinity
round_up = FALSE;
when '11' // Round towards Zero
round_up = (error != 0.0 && int_result < 0);
if round_up then int_result = int_result + 1;
// Bitstring result is the integer result saturated to the destination size, with
// saturation indicating overflow of the conversion (signaled as an Invalid
// Operation floating-point exception).
(result, overflow) = SatQ(int_result, M, unsigned);
if overflow then
elsif error != 0.0 then
FPProcessException(FPExc_Inexact, fpscr_val);
return result;
// FixedToFP()
// ===========
bits(N) FixedToFP(bits(M) operand, integer N, integer fraction_bits, boolean unsigned,

boolean round_to_nearest, boolean fpscr_controlled)
if round_to_nearest then fpscr_val<23:22> = '00';
int_operand = if unsigned then UInt(operand) else SInt(operand);
real_operand = int_operand / 2^fraction_bits;
if real_operand == 0.0 then
result = FPZero('0', N);
else
result = FPRound(real_operand, N, fpscr_val);
return result;
A2.8 Polynomial arithmetic over {0, 1}
A2.8 Polynomial arithmetic over {0, 1}

Some Advanced SIMD instructions can operate on polynomials over {0, 1}, see Data types supported by the
Advanced SIMD Extension on page A2-59. The polynomial data type represents a polynomial in x of the form
bn–1xn–1 + … + b1x + b0 where bk is bit[k] of the value.
The coefficients 0 and 1 are manipulated using the rules of Boolean arithmetic:
• 0 + 0 = 1 + 1 = 0.
• 0 + 1 = 1 + 0 = 1.
• 0 × 0 = 0 × 1 = 1 × 0 = 0.
• 1 × 1 = 1.
That is:
• Adding two polynomials over {0, 1} is the same as a bitwise exclusive OR.
• Multiplying two polynomials over {0, 1} is the same as integer multiplication except that partial products are
exclusive-ORed instead of being added.
Note
The instructions that can perform polynomials arithmetic over {0, 1} are VMUL and VMULL, see VMUL, VMULL
(integer and polynomial) on page A8-959.
A2.8.1 Pseudocode details of polynomial multiplication

In pseudocode, polynomial addition is described by the EOR operation on bitstrings.
Polynomial multiplication is described by the PolynomialMult() function:
// PolynomialMult()
// ================
bits(M+N) PolynomialMult(bits(M) op1, bits(N) op2)

result = Zeros(M+N);
extended_op2 = Zeros(M) : op2;
for i=0 to M-1
if op1<i> == '1' then
result = result EOR LSL(extended_op2, i);
return result;
A2.9 Coprocessor support
A2.9 Coprocessor support

The ARM architecture supports coprocessors, to extend the functionality of an ARM processor. The coprocessor
instructions summarized in Coprocessor instructions on page A4-178 provide access to sixteen coprocessors,
described as CP0 to CP15. The following coprocessors are reserved by ARM for specific purposes:
• Coprocessor 15 (CP15) provides system control functionality. This includes architecture and feature
identification, as well as control, status information and configuration support.
For a VMSA implementation, the following sections give a general description of CP15:
— About the system control registers for VMSA on page B3-1440.
— Organization of the CP15 registers in a VMSA implementation on page B3-1465.
— Functional grouping of VMSAv7 system control registers on page B3-1486.
For a PMSA implementation, the following sections give a general description of CP15:
— About the system control registers for PMSA on page B5-1766.
— Organization of the CP15 registers in a PMSA implementation on page B5-1779.
— Functional grouping of PMSAv7 system control registers on page B5-1791.
CP15 also provides performance monitor registers, see Chapter C12 The Performance Monitors Extension.
• Coprocessor 14 (CP14) supports:

— Debug, see Chapter C6 Debug Register Interfaces.
— The Thumb Execution Environment, see Thumb Execution Environment on page A2-94.
— Direct Java bytecode execution, see Jazelle direct bytecode execution support on page A2-96.
• Coprocessors 10 and 11 (CP10 and CP11) together support floating-point and vector operations, and the
control and configuration of the Floating-point and Advanced SIMD architecture extensions.
• Coprocessors 8, 9, 12, and 13 are reserved for future use by ARM. Any coprocessor access instruction
attempting to access one of these coprocessors is UNDEFINED.
Note
In an implementation that includes either or both of the Advanced SIMD Extension and the Floating-point (VFP)
Extension, to permit execution of any floating-point or Advanced SIMD instructions, software must enable access
to both CP10 and CP11, see Enabling Advanced SIMD and floating-point support on page B1-1228.
The following sections give information more information about permitted accesses to coprocessors CP14 and
CP15:
• UNPREDICTABLE and UNDEFINED behavior for CP14 and CP15 accesses on page B3-1442, for a VMSA
implementation.
• UNPREDICTABLE and UNDEFINED behavior for CP14 and CP15 accesses on page B5-1768, for a PMSA
implementation.
Most CP14 and CP15 functions cannot be accessed by software executing at PL0. This manual clearly identifies
those functions that can be accessed at PL0.
Software executing at PL1 can enable the unprivileged execution of all load, store, branch and data operation
instructions associated with floating-point, Advanced SIMD and execution environment support.
Coprocessors 0 to 7 can provide vendor-specific features.
A2.10 Thumb Execution Environment

Thumb Execution Environment (ThumbEE) is a variant of the Thumb instruction set designed as a target for
dynamically generated code. This is code that is compiled on the device, from a portable bytecode or other
intermediate or native representation, either shortly before or during execution. ThumbEE provides support for
Just-In-Time (JIT), Dynamic Adaptive Compilation (DAC), and Ahead-Of-Time (AOT) compilers, but cannot
interwork freely with the ARM and Thumb instruction sets.
ThumbEE is particularly suited to languages that feature managed pointers and array types. The processor executes
ThumbEE instructions when it is in the ThumbEE instruction set state. For information about instruction set states
see Instruction set state register, ISETSTATE on page A2-50.
ThumbEE is both the name of the instruction set and the name of the extension that provides support for that
instruction set. The ThumbEE Extension is:
• Required in implementations of the ARMv7-A profile.
• Optional in implementations of the ARMv7-R profile.
See Thumb Execution Environment on page B1-1239 for system level information about ThumbEE.
A2.10.1 ThumbEE instructions

In ThumbEE state, the processor executes almost the same instruction set as in Thumb state. However some
instructions behave differently, some are removed, and some ThumbEE instructions are added.
The key differences are:

• Additional instructions to change instruction set in both Thumb state and ThumbEE state.
• New ThumbEE instructions to branch to handlers.
• Null pointer checking on load/store instructions executed in ThumbEE state.
• An additional instruction in ThumbEE state to check array bounds.
• Some other modifications to load, store, and control flow instructions.
For more information about the ThumbEE instructions see Chapter A9 The ThumbEE Instruction Set.
A2.10.2 ThumbEE configuration

ThumbEE introduces two new CP14 registers, that Table A2-14 shows. These are 32-bit registers:
Table A2-14 ThumbEE register summary
Name, VMSA a Name, PMSA a CRn opc1 CRm opc2 Width Type Description
TEECR TEECR c0 6 c0 0 32-bit RW ThumbEE Configuration Register
TEEHBR TEEHBR c1 6 c0 0 32-bit RW ThumbEE Handler Base Register
a. VMSA and PMSA definitions of the register fields are identical. These columns link to the descriptions in Chapter B4 and in Chapter B6.
ThumbEE is an unprivileged, user-level facility, and there are no special provisions for using it securely. For more
information, see ThumbEE and the Security Extensions and Virtualization Extensions on page B1-1239.
Use of HandlerBase
ThumbEE handlers are entered by reference to a HandlerBase address, defined by the TEEHBR. In addition to the
handlers for IndexCheck and NullCheck, there are 256 handlers, Handler_00 to Handler_FF, at 32-byte offsets from
HandlerBase. Table A2-15 shows the arrangement of handlers relative to the value of HandlerBase:
Table A2-15 Access to ThumbEE handlers
Offset from HandlerBase Name Value stored
-0x0008 IndexCheck Branch to IndexCheck handler
-0x0004 NullCheck Branch to NullCheck handler
0x0000 Handler_00 Implementation of Handler_00
0x0020 Handler_01 Implementation of Handler_01
… … …
0x1FC0 Handler_FE Implementation of Handler_FE
0x1FE0 Handler_FF Implementation of Handler_FF
The IndexCheck occurs when a CHKA instruction detects an index out of range. For more information, see CHKA on
page A9-1124.
The NullCheck occurs when any memory access instruction is executed with a value of 0 in the base register. For
more information, see Null checking on page A9-1113.
Note
Checks are similar to conditional branches, with the added property that they clear the IT bits when taken.
The other handlers are called using explicit handler call instructions:
• HB and HBL can call any handler, that is, can call Handler_00-Handler_FF.
• HBLP and HBP can call only Handler_00-Handler_31.
For more information see the following instruction descriptions:

• HB, HBL on page A9-1125.
• HBLP on page A9-1126.
• HBP on page A9-1127.
A2.11 Jazelle direct bytecode execution support

From ARMv5TEJ, the architecture requires every system to include an implementation of the Jazelle extension. The
Jazelle extension provides architectural support for hardware acceleration of bytecode execution by a Java Virtual
Machine (JVM).
In the simplest implementations of the Jazelle extension, the processor does not accelerate the execution of any
bytecodes, and the JVM uses software routines to execute all bytecodes. Such an implementation is called a trivial
implementation of the Jazelle extension, and has minimal additional cost compared with not implementing the
Jazelle extension at all. An implementation that provides hardware acceleration of bytecode execution is a
non-trivial Jazelle implementation.
The Virtualization Extensions require that the Jazelle implementation is the trivial Jazelle implementation.
These requirements for the Jazelle extension mean a JVM can be written to both:
• Function correctly on all processors that include a Jazelle extension implementation.
• Automatically take advantage of the accelerated bytecode execution provided by a processor that includes a
non-trivial implementation.
A non-trivial implementation of the Jazelle extension implements a subset of the bytecodes in hardware, choosing
bytecodes that:
• Can have simple hardware implementations.
• Account for a large percentage of bytecode execution time.
The required features of a non-trivial implementation are:

• Provision of the Jazelle state.
• A new instruction, BXJ, to enter Jazelle state.
• System support that enables an operating system to regulate the use of the Jazelle extension hardware.
• System support that enables a JVM to configure the Jazelle extension hardware to its specific needs.
The required features of a trivial implementation are:
• Normally, the Jazelle instruction set state is never entered. In some implementations, an incorrect exception
return can cause entry to the Jazelle instruction set state. If this happens, the next instruction executed is
treated as UNDEFINED. For more information, see Unimplemented instruction sets on page B1-1155.
• The BXJ instruction behaves as a BX instruction.
• Configuration support that maintains the interface to the Jazelle extension is permanently disabled.
For more information about trivial implementations see Trivial implementation of the Jazelle extension on
page B1-1244.
A JVM that has been written to take advantage automatically of hardware-accelerated bytecode execution is called
an Enabled JVM (EJVM).
A2.11.1 Subarchitectures
A processor implementation that includes the Jazelle extension expects the ARM core register values and other
resources of the ARM processor to conform to an interface standard defined by the Jazelle implementation when
Jazelle state is entered and exited. For example, a specific ARM core register might be reserved for use as the pointer
to the current bytecode.
For an EJVM, and any associated debug support, to function correctly, it must be written to comply with the
interface standard defined by the acceleration hardware at Jazelle state execution entry and exit points.
An implementation of the Jazelle extension might define other configuration registers in addition to the
architecturally defined ones.
The interface standard and any additional configuration registers used for communication with the Jazelle extension
are known collectively as the subarchitecture of the implementation. They are not described in this manual. Only
EJVM implementations and debug or similar software can depend on the subarchitecture. All other software must
rely only on the architectural definition of the Jazelle extension given in this manual. A particular subarchitecture
is identified by reading the JIDR.
A2.11.2 Jazelle state

While the processor is in Jazelle state, it executes bytecode programs. A bytecode program is defined as an
executable object that comprises one or more class files, or is derived from and functionally equivalent to one or
more class files. See The Java Virtual Machine Specification for the definition of class files.
While the processor is in Jazelle state, the PC identifies the next JVM bytecode to be executed. A JVM bytecode is
a bytecode defined in The Java Virtual Machine Specification, or a functionally equivalent transformed version of
a bytecode defined in that specification.
For the Jazelle extension, the functionality of Native methods, as described in The Java Virtual Machine
Specification, must be specified using only instructions from the ARM, Thumb, and ThumbEE instruction sets.
An implementation of the Jazelle extension must not be documented or promoted as performing any task while it is
in Jazelle state other than the acceleration of bytecode programs in accordance with this section and the descriptions
in The Java Virtual Machine Specification.
A2.11.3 Jazelle state entry instruction, BXJ

ARMv7 includes an ARM instruction similar to BX. The BXJ instruction has a single register operand that specifies
a target instruction set state, ARM state or Thumb state, and branch target address for use if entry to Jazelle state is
not available. For more information, see BXJ on page A8-352.
Correct entry into Jazelle state involves the EJVM executing the BXJ instruction at a time when both:
• The Jazelle extension Control and Configuration registers are initialized correctly, see Application level
configuration and control of the Jazelle extension on page A2-98.
• Application level registers and any additional configuration registers are initialized as required by the
subarchitecture of the implementation.
Executing BXJ with Jazelle extension enabled

Executing a BXJ instruction when the JMCR.JE bit is 1 causes the Jazelle hardware to do one of the following:
• Enter Jazelle state and start executing bytecodes directly from a SUBARCHITECTURE DEFINED address.
• Branch to a SUBARCHITECTURE DEFINED handler.
Which of these occurs is SUBARCHITECTURE DEFINED.
The Jazelle subarchitecture can use Application level registers, but not System level registers, to transfer
information between the Jazelle extension and the EJVM. There are SUBARCHITECTURE DEFINED restrictions on
what Application level registers must contain when a BXJ instruction is executed, and Application level registers
have SUBARCHITECTURE DEFINED values when Jazelle state execution ends and ARM or Thumb state execution
resumes.
Jazelle subarchitectures and implementations must not use any unallocated bits in Application level registers such
as the CPSR or FPSCR. All such bits are reserved for future expansion of the ARM architecture.
Executing BXJ with Jazelle extension disabled

If a BXJ instruction is executed when the JMCR.JE bit is 0, it is executed identically to a BX instruction with the same
register operand.
This means that BXJ instructions can be executed freely when the JMCR.JE bit is 0. In particular, if an EJVM
determines that it is executing on a processor whose Jazelle extension implementation is trivial or uses an
incompatible subarchitecture, it can set JE to 0 and execute correctly. In this case it executes without the benefit of
any Jazelle hardware acceleration that might be present.
A2.11.4 Application level configuration and control of the Jazelle extension

The Jazelle extension registers are implemented as CP14 registers. Table A2-16 summarizes the
architecturally-defined Jazelle registers. Additional SUBARCHITECTURE DEFINED configuration registers might be
provided.
Table A2-16 Jazelle architecturally-defined registers summary
Name, VMSA a Name, PMSA a CRn opc1 CRm opc2 Width Type b Description
JIDR JIDR c0 7 c0 0 32-bit RO Jazelle ID Register
JOSCR JOSCR c1 7 c0 0 32-bit RW Jazelle OS Control Register
JMCR JMCR c2 7 c0 0 32-bit RW Jazelle Main Configuration Register
a. VMSA and PMSA definitions of the register fields are identical. These columns link to the descriptions in Chapter B4 and Chapter B6.
b. Type, for a non-trivial Jazelle implementation. Trivial implementation of the Jazelle extension on page B1-1244 describes the register
requirements for a trivial Jazelle implementation.
An EJVM can read the JIDR to determine the architecture and subarchitecture under which it is running, and:
• The JMCR gives application level control of Jazelle operation.
• The JOSCR gives OS level control of Jazelle operation.
The following rules apply to all Jazelle extension control and configuration registers, including any
SUBARCHITECTURE DEFINED registers:
• Registers are accessed by CP14 MRC and MCR instructions with <opc1> set to 7.
• The values contained in configuration registers are changed only by the execution of MCR instructions. In
particular, they are never changed by Jazelle state execution of bytecodes.
• The access policy for each architecturally-defined register is fully defined in the register description. The
access policy of other configuration registers is SUBARCHITECTURE DEFINED.
When execution is unprivileged, MRC and MCR accesses that are restricted to execution at PL1 or higher are
UNDEFINED.
For more information see Access to Jazelle registers on page A2-99.
• In an implementation that includes the Security Extensions, the registers are Common registers, meaning
they are common to the Secure and Non-secure security states. For more information, see Classification of
system control registers on page B3-1447.
• When a configuration register is readable, reading the register:

— Returns the last value written to it.
— Has no side-effects.
When a configuration register is not readable, attempting to read it returns an UNKNOWN value.
• When a configuration register can be written, the effect of writing to it must be idempotent. That is, the
overall effect of writing the same value more than once must not differ from the effect of writing it once.
Changes to these CP14 registers have the same synchronization requirements as changes to the CP15 registers.
These are described in:
• Synchronization of changes to system control registers on page B3-1457 for a VMSA implementation.
• Synchronization of changes to system control registers on page B5-1771 for a PMSA implementation.
For more information, see Jazelle state configuration and control on page B1-1242.
A2.11.5 Access to Jazelle registers

For a non-trivial Jazelle implementation, Table A2-17 shows the access permissions for the Jazelle registers, and
how unprivileged access to the registers depends on the value of the JOSCR.
Table A2-17 Access to Jazelle registers in a non-trivial Jazelle implementation
Jazelle register Unprivileged access

Access at PL1
VMSA PMSA JOSCR.CD is 0 JOSCR.CD is 1
Read and write access Read and write access Read and write access permitted
JOSCR JOSCR
UNDEFINED UNDEFINED
Read access permitted Read access UNDEFINED Read access permitted

JIDR JIDR
Write access UNDEFINED Write access UNDEFINED Write access UNPREDICTABLE
Read access UNDEFINED Read and write access

JMCR JMCR Read and write access permitted
UNDEFINED
Write access permitted
SUBARCHITECTURE DEFINED
Read access UNDEFINED Read and write access Read access SUBARCHITECTURE DEFINED
configuration registers Write access permitted UNDEFINED
Write access permitted
Trivial implementation of the Jazelle extension on page B1-1244 describes the required behavior of Jazelle register
accesses for a trivial Jazelle implementation.
A2.11.6 EJVM operation

The following subsections summarize how an EJVM must operate, to meet the requirements of the architecture:
• Initialization.
• Bytecode execution.
• Jazelle exception conditions on page A2-100.
• Other considerations on page A2-100.
Initialization
During initialization, the EJVM must first check which subarchitecture is present, by checking the Implementer and
Subarchitecture codes in the value read from the JIDR.
If the EJVM is incompatible with the subarchitecture, it must do one of the following:
• Write to the JMCR with JE set to 0.
• If unaccelerated bytecode execution is unacceptable, generate an error.
If the EJVM is compatible with the subarchitecture, it must write its required configuration to the JMCR and any
SUBARCHITECTURE DEFINED configuration registers.
Bytecode execution
The EJVM must contain a handler for each bytecode.
The EJVM initiates bytecode execution by executing a BXJ instruction with:

• The register operand specifying the target address of the bytecode handler for the first bytecode of the
program.
• The Application level registers set up in accordance with the SUBARCHITECTURE DEFINED interface standard.
The bytecode handler:
• Performs the data-processing operations required by the bytecode indicated
• Determines the address of the next bytecode to be executed.
• Determines the address of the handler for that bytecode.
• Performs a BXJ to that handler address with the registers again set up to the SUBARCHITECTURE DEFINED
interface standard.
Jazelle exception conditions

During bytecode execution, the EJVM might encounter SUBARCHITECTURE DEFINED Jazelle exception conditions
that must be resolved by a software handler. For example, in the case of a configuration invalid handler, the handler
rewrites the desired configuration to the JMCR and to any SUBARCHITECTURE DEFINED configuration registers.
On entry to a Jazelle exception condition handler the contents of the Application level registers are
SUBARCHITECTURE DEFINED. This interface to the Jazelle exception condition handler might differ from the
interface standard for the bytecode handler, in order to supply information about the Jazelle exception condition.
The Jazelle exception condition handler:
• Resolves the Jazelle exception condition.
• Determines the address of the next bytecode to be executed.
• Determines the address of the handler for that bytecode.
• Performs a BXJ to that handler address with the registers again set up to the SUBARCHITECTURE DEFINED
interface standard.
Other considerations
To ensure application execution and correct interaction with an operating system, an EJVM must only perform
operations that are permitted in unprivileged operation. In particular, for register accesses they must only:
• Read the JIDR.
• Write to the JMCR, and other configuration registers.
An EJVM must not attempt to access the JOSCR.
A2.12 Exceptions, debug events and checks

ARMv7 uses the following terms to describe various types of exceptional condition:
Exceptions In the ARM architecture, an exception causes entry into a processor mode that executes software at
PL1 or PL2, and execution of a software handler for the exception.
Note
The terms floating-point exception and Jazelle exception condition do not use this meaning of
exception. These terms are described later in this list.
Exceptions include:
• Reset.
• Interrupts.
• Memory system aborts.
• Undefined instructions.
• Supervisor calls (SVCs), Secure Monitor calls (SMCs), and hypervisor calls (HVCs).
Most details of exception handling are not visible to application level software, and are described in
Exception handling on page B1-1164. Aspects that are visible to application level software are:
• The SVC instruction causes a Supervisor Call exception. This provides a mechanism for
unprivileged software to make a call to the operating system, or other system component that
is accessible only at PL1.
• In an implementation that includes the Security Extensions, the SMC instruction causes a
Secure Monitor Call exception, but only if software execution is at PL1 or higher.
Unprivileged software can only cause a Secure Monitor Call exception by methods defined
by the operating system, or by another component of the software system that executes at PL1
or higher.
• In an implementation that includes the Virtualization Extensions, the HVC instruction causes a
Hypervisor Call exception, but only if software execution is at PL1 or higher. Unprivileged
software can only cause a Hypervisor Call exception by methods defined by the hypervisor,
or by another component of the software system that executes at PL1 or higher.
• The WFI instruction provides a hint that nothing needs to be done until the processor takes an
interrupt or similar exception, see Wait For Interrupt on page B1-1202. This permits the
processor to enter a low-power state until that happens.
• The WFE instruction provides a hint that nothing needs to be done until either an SEV instruction
generates an event, or the processor takes an interrupt or similar exception, see Wait For
Event and Send Event on page B1-1199. This permits the processor to enter a low-power state
until one of these happens.
Floating-point exceptions
These relate to exceptional conditions encountered during floating-point arithmetic, such as division
by zero or overflow. For more information see:
• Floating-point exceptions on page A2-69.
• FPSCR, Floating-point Status and Control Register, VMSA on page B4-1566, or FPSCR,
Floating-point Status and Control Register, PMSA on page B6-1839.
• ANSI/IEEE Std. 754, IEEE Standard for Binary Floating-Point Arithmetic.
Jazelle exception conditions

These are conditions that cause Jazelle hardware acceleration to exit into a software handler, as
described in Jazelle exception conditions on page A2-100.
Debug events These are conditions that cause a debug system to take action. Most aspects of debug events are not
visible to application level software, and are described in Chapter C3 Debug Events. Aspects that
are visible to application level software include:
• The BKPT instruction causes a BKPT instruction debug event to occur, see BKPT instruction
debug events on page C3-2026.
• The DBG instruction provides a hint to the debug system.
Checks These are provided in the ThumbEE Extension. A check causes an unconditional branch to a
specific handler entry point. The base address of the ThumbEE check handlers is held in the
TEEHBR.
Chapter A3
Application Level Memory Model
This chapter gives an application level view of the memory model. It contains the following sections:
• Address space on page A3-104.
• Alignment support on page A3-106.
• Endian support on page A3-108.
• Synchronization and semaphores on page A3-112.
• Memory types and attributes and the memory order model on page A3-123.
• Access rights on page A3-139.
• Virtual and physical addressing on page A3-142.
• Memory access order on page A3-143.
• Caches and memory hierarchy on page A3-153.
Note
Registers in a VMSA implementation, for example SCTLR. If the register is included in a PMSA implementation,
A3 Application Level Memory Model
A3.1 Address space
A3.1 Address space

The ARM architecture Application level memory model uses a single, flat address space of 232 8-bit bytes, covering
4GBytes. Byte addresses are treated as unsigned numbers, running from 0 to 232 - 1. The address space is also
regarded as:
• 230 32-bit words:

— The address of each word is word-aligned, meaning that the address is divisible by 4 and the least
significant bits of the address are 0b00.
— The word at word-aligned address A consists of the four bytes with addresses A, A+1, A+2 and A+3.
• 231 16-bit halfwords:

— The address of each halfword is halfword-aligned, meaning that the address is divisible by 2 and the
least significant bit of the address is 0.
— The halfword at halfword-aligned address A consists of the two bytes with addresses A and A+1.
In some situations the ARM architecture supports accesses to halfwords and words that are not aligned to the
appropriate access size, see Alignment support on page A3-106.
Normally, address calculations are performed using ordinary integer instructions. This means that the address wraps
around if the calculation overflows or underflows the address space. Another way of describing this is that any
address calculation is reduced modulo 232.
A3.1.1 Address space overflow or underflow

Address space overflow occurs when the memory address increments beyond the top byte of the address space at
0xFFFFFFFF. When this happens, the address wraps round, so that, for example, incrementing 0xFFFFFFFF by 2 gives
a result of 0x00000001.
Address space underflow occurs when the memory address decrements below the first byte of the address space at
0x00000000. When this happens, the address wraps round, so that, for example, decrementing 0x00000002 by 4 gives
a result of 0xFFFFFFFE.
When a processor performs normal sequential execution of instructions, after each instruction it finds the address
of the next instruction by calculating:
(address_of_current_instruction) + (size_of_executed_instruction).
This calculation can result in address space overflow.
Note
The size of the executed instruction depends on the current instruction set, and can depend on the instruction
executed.
Any multi-byte memory access that depends on address space overflow or underflow is UNPREDICTABLE. This
applies to both data and instruction accesses.
The following rules define the accesses that are UNPREDICTABLE:
1. If the processor executes an instruction for which the instruction address, size, and alignment mean it contains
the bytes 0xFFFFFFFF and 0x00000000, the result is UNPREDICTABLE.
Examples of this UNPREDICTABLE behavior include:
• Relying on sequential execution of the instruction at 0x00000000 after any of:
— Executing a 4-byte instruction at 0xFFFFFFFC.
— Executing a 2-byte instruction at 0xFFFFFFFE.
— Executing a 1-byte instruction at 0xFFFFFFFF.
• Attempting to execute an instruction that spans the top of memory, for example:
— A 4-byte instruction at 0xFFFFFFFE.
A3.1 Address space
— A 2-byte instruction at 0xFFFFFFFF.
2. If the processor executes a load or store instruction for which the computed address, total access size, and
alignment mean it accesses the bytes 0xFFFFFFFF and 0x00000000, the result is UNPREDICTABLE.
Examples of this UNPREDICTABLE behavior include:
• Attempting to perform an unaligned load or store operation that spans the top of memory, for example:
— A word load or store from or to address 0xFFFFFFFD.
— A halfword load or store from or to address 0xFFFFFFFF.
• Attempting to perform a multiple load or store operation that spans the top of memory, for example:
— A two-word load or store from or to addresses 0xFFFFFFFC and 0x00000000.
— An Advanced SIMD multiple-element load or store that includes bytes 0xFFFFFFFF and
0x00000000.
This UNPREDICTABLE behavior only applies to instructions that are executed, including those that fail their condition
code check. Most ARM implementations fetch instructions ahead of the currently-executing instruction. If this
prefetching overflows the top of the address space, it does not cause UNPREDICTABLE behavior unless the prefetched
instruction with an overflowed address is executed.
Note
In some cases, instructions that operate on multiple words can decrement the memory address by 4 after each word
access. If this calculation underflows the address space, the result is UNPREDICTABLE.
A3.2 Alignment support

Instructions in the ARM architecture are aligned as follows:
• ARM instructions are word-aligned.
• Thumb and ThumbEE instructions are halfword-aligned.
• Java bytecodes are byte-aligned.
In the ARMv7 architecture, some load and store instructions support unaligned data accesses, as described in
Unaligned data access.
For more information about the alignment support in previous versions of the ARM architecture, see Alignment on
page D12-2492.
A3.2.1 Unaligned data access

An ARMv7 implementation must support unaligned data accesses to Normal memory by some load and store
instructions, as Table A3-1 shows. Software can set the SCTLR.A bit to control whether a misaligned access to
Normal memory by one of these instructions causes an Alignment fault Data Abort exception.
Table A3-1 Alignment requirements of load/store instructions
Result if check fails when:

Alignment
Instructions
check
SCTLR.A is 0 SCTLR.A is 1
LDRB, LDREXB, LDRBT, LDRSB, LDRSBT, STRB, STREXB, STRBT, SWPB, TBB None - -
LDRH, LDRHT, LDRSH, LDRSHT, STRH, STRHT, TBH Halfword Unaligned access Alignment fault
LDREXH, STREXH Halfword Alignment fault Alignment fault
LDR, LDRT, STR, STRT Word Unaligned access Alignment fault

PUSH, encodings T3 and A2 only
POP, encodings T3 and A2 only
LDREX, STREX Word Alignment fault Alignment fault
LDREXD, STREXD Doubleword Alignment fault Alignment fault
All forms of LDM and STM, LDRD, RFE, SRS, STRD, SWP Word Alignment fault Alignment fault
PUSH, except for encodings T3 and A2
POP, except for encodings T3 and A2
LDC, LDC2, STC, STC2 Word Alignment fault Alignment fault
VLDM, VLDR, VPOP, VPUSH, VSTM, VSTR Word Alignment fault Alignment fault
VLD1, VLD2, VLD3, VLD4, VST1, VST2, VST3, VST4, all with standard alignment a Element size Unaligned access Alignment fault
VLD1, VLD2, VLD3, VLD4, VST1, VST2, VST3, VST4, all with :<align> specified a, b As specified Alignment fault Alignment fault
by :<align>
a. These element and structure load/store instructions are only in the Advanced SIMD Extension to the ARMv7 ARM and Thumb instruction
sets. ARMv7 does not support the pre-ARMv6 alignment model, so software cannot use that model with these instructions.
b. Previous versions of this document used @<align> to specify alignment. Both forms are supported, see Advanced SIMD addressing mode
on page A7-275 for more information.
Note
In an implementation that includes the Virtualization Extensions, an unaligned access to Device or Strongly-ordered
memory always causes an Alignment fault Data Abort exception. For implementations that do not include the
Virtualization Extensions, see Cases where unaligned accesses are UNPREDICTABLE.
A3.2.2 Cases where unaligned accesses are UNPREDICTABLE

The following cases cause the resulting unaligned accesses to be UNPREDICTABLE, and overrule any permitted load
or store behavior shown in Table A3-1 on page A3-106:
• Any load instruction that is not faulted by the alignment restrictions shown in Table A3-1 on page A3-106
and that loads the PC has UNPREDICTABLE behavior if the address it loads from is not word-aligned.
• In an implementation that does not include the Virtualization Extensions, any unaligned access that is not
faulted by the alignment restrictions shown in Table A3-1 on page A3-106 and that accesses memory with
the Strongly-ordered or Device memory attribute has UNPREDICTABLE behavior.
Note
— In an implementation that includes the Virtualization Extensions, such an unaligned access to Device
or Strongly-ordered memory generates an Alignment fault, see Alignment faults on page B3-1399.
— Memory types and attributes and the memory order model on page A3-123 describes the
Strongly-ordered and Device memory attributes.
A3.2.3 Unaligned data access restrictions in ARMv7 and ARMv6

ARMv7 and ARMv6 have the following restrictions on unaligned data accesses:
• Accesses are not guaranteed to be single-copy atomic except at the byte access level, see Atomicity in the
ARM architecture on page A3-125. An access can be synthesized out of a series of aligned operations in a
shared memory system without guaranteeing locked transaction cycles.
• Unaligned accesses typically take a number of additional cycles to complete compared to a naturally aligned
transfer. The real-time implications must be analyzed carefully and key data structures might need to have
their alignment adjusted for optimum performance.
• An operation that performs an unaligned access can abort on any memory access that it makes, and can abort
on more than one access. This means that an unaligned access that occurs across a page boundary can
generate an abort on either side of the boundary, or on both sides of the boundary.
Shared memory schemes must not rely on seeing single-copy atomic updates of unaligned data of loads and stores
for data items larger than byte wide. For more information, see Atomicity in the ARM architecture on page A3-125.
Unaligned access operations must not be used for accessing memory-mapped registers in a Device or
Strongly-ordered memory region.
A3.3 Endian support
A3.3 Endian support

The rules in Address space on page A3-104 require that for a word-aligned address A:
• The doubleword at address A comprises the bytes at addresses A, A+1, A+2, A+3, A+4, A+5, A+6, and A+7.
• The word:
— At address A comprises the bytes at addresses A, A+1, A+2 and A+3.
— At address A+4 comprises the bytes at addresses A+4, A+5, A+6 and A+7.
• The halfword:
— At address A comprises the bytes at addresses A and A+1.
— At address A+2 comprises the bytes at addresses A+2 and A+3.
• This means that:

— The doubleword at address A comprises the words at addresses A and A+4.
— The word at address A comprises the halfwords at addresses A and A+2.
— The word at address A+4 comprises the halfwords at addresses A+4 and A+6.
However, this does not specify completely the mappings between words, halfwords, and bytes.
A memory system uses one of the two following mapping schemes. This choice is called the endianness of the
memory system.
In a little-endian memory system:
• The byte, halfword, or word at an address is the least significant byte, halfword, or word in the doubleword
at that address.
• The byte or halfword at an address is the least significant byte or halfword in the word at that address.
• The byte at an address is the least significant byte in the halfword at that address.
In a big-endian memory system:
• The byte, halfword, or word at an address is the most significant byte, halfword, or word in the doubleword
at that address.
• The byte or halfword at an address is the most significant byte or halfword in the word at that address.
• The byte at an address is the most significant byte in the halfword at that address.
For an address A, Figure A3-1 on page A3-109 shows, for big-endian and little-endian memory systems, the
relationship between:
• The doubleword at address A.
• The words at addresses A and A+4.
• The halfwords at addresses A, A+2, A+4, and A+6.
• The bytes at addresses A, A+1, A+2, A+3, A+4, A+5, A+6, and A+7.
A3.3 Endian support
Big-endian memory system

MSByte MSByte-1 MSByte-2 MSByte-3 LSByte+3 LSByte+2 LSByte+1 LSByte
Doubleword at address A
Word at address A Word at address A+4
Halfword at address A Halfword at address A+2 Halfword at address A+4 Halfword at address A+6
Byte, A Byte, A+1 Byte, A+2 Byte, A+3 Byte, A+4 Byte, A+5 Byte, A+6 Byte, A+7
Little-endian memory system

MSByte MSByte-1 MSByte-2 MSByte-3 LSByte+3 LSByte+2 LSByte+1 LSByte
Doubleword at address A
Word at address A+4 Word at address A
Halfword at address A+6 Halfword at address A+4 Halfword at address A+2 Halfword at address A
Byte, A+7 Byte, A+6 Byte, A+5 Byte, A+4 Byte, A+3 Byte, A+2 Byte, A+1 Byte, A
In this figure, Byte, A+1 is an abbreviation for Byte at address A+1
Figure A3-1 Endianness relationships
The big-endian and little-endian mapping schemes determine the order in which the bytes of a doubleword, word
or halfword are interpreted. For example, a load of a word from address 0x1000 always results in an access to the
bytes at memory locations 0x1000, 0x1001, 0x1002, and 0x1003. The endianness mapping scheme determines the
significance of these four bytes.
A3.3.1 Instruction endianness

In ARMv7-A, the mapping of instruction memory is always little-endian. In ARMv7-R, instruction endianness can
be controlled at the system level, see Instruction endianness static configuration, ARMv7-R only on page A3-110.
Note
For information about data memory endianness control, see Endianness mapping register, ENDIANSTATE on
page A2-53.
Before ARMv7, the ARM architecture included legacy support for an alternative big-endian memory model,
described as BE-32 and controlled by SCTLR.B bit, bit[7] of the register, see Endian configuration and control on
page D12-2503. ARMv7 does not support BE-32 operation, and bit SCTLR[7] is RAZ/SBZP.
Where legacy object code for ARM processors contains instructions with a big-endian byte order, the removal of
support for BE-32 operation requires the instructions in the object files to have their bytes reversed for the code to
be executed on an ARMv7 processor. This means that:
• Each Thumb instruction, whether a 32-bit Thumb instruction or a 16-bit Thumb instruction, must have the
byte order of each halfword of instruction reversed.
• Each ARM instruction must have the byte order of each word of instruction reversed.
For most situations, this can be handled in the link stage of a tool-flow, provided the object files include sufficient
information to permit this to happen. In practice, this is the situation for all applications with the ARMv7-A profile.
For applications of the ARMv7-R profile, there are some legacy code situations where the arrangement of the bytes
in the object files cannot be adjusted by the linker. For these object files to be used by an ARMv7-R processor the
byte order of the instructions must be reversed by the processor at runtime. Therefore, the ARMv7-R profile permits
configuration of the instruction endianness.
A3.3 Endian support
Instruction endianness static configuration, ARMv7-R only

To provide support for legacy big-endian object code, the ARMv7-R profile supports optional byte order reversal
hardware as a static option from reset. The ARMv7-R profile includes a read-only bit in the CP15 Control Register,
SCTLR.IE, bit[31], that indicates the instruction endianness configuration.
A3.3.2 Element size and endianness

The effect of the endianness mapping on data transfers depends on the size of the data element or elements
transferred by the load/store instructions. Table A3-2 lists the element sizes of all the load/store instructions, for all
instruction sets.
Table A3-2 Element size of load/store instructions
Instructions Element size
LDRB, LDREXB, LDRBT, LDRSB, LDRSBT, STRB, STREXB, STRBT, SWPB, TBB Byte
LDRH, LDREXH, LDRHT, LDRSH, LDRSHT, STRH, STREXH, STRHT, TBH Halfword
LDR, LDRT, LDREX, STR, STRT, STREX Word
LDRD, LDREXD, STRD, STREXD Word
All forms of LDM, PUSH, POP, RFE, SRS, all forms of STM, SWP Word
LDC, LDC2, STC, STC2 Word
Forms of VLDM, VLDR, VPOP, VPUSH, VSTM, VSTR that transfer 32-bit Si registers Word
Forms of VLDM, VLDR, VPOP, VPUSH, VSTM, VSTR that transfer 64-bit Di registers Doubleword
VLD1, VLD2, VLD3, VLD4, VST1, VST2, VST3, VST4 Element size of the Advanced SIMD access
A3.3.3 Instructions to reverse bytes in an ARM core register

An application or device driver might have to interface to memory-mapped peripheral registers or shared memory
structures that are not the same endianness as the internal data structures. Similarly, the endianness of the operating
system might not match that of the peripheral registers or shared memory. In these cases, the processor requires an
efficient method to transform explicitly the endianness of the data.
In ARMv7, in the ARM and Thumb instruction sets, the following instructions provide this functionality:
REV Reverse word (four bytes) register, for transforming big-endian and little-endian 32-bit
representations, see REV on page A8-563.
REVSH Reverse halfword and sign-extend, for transforming signed 16-bit representations, see REVSH on
page A8-567.
REV16 Reverse packed halfwords in a register for transforming big-endian and little-endian 16-bit
representations, see REV16 on page A8-565.
A3.3.4 Endianness in Advanced SIMD

Advanced SIMD element load/store instructions transfer vectors of elements between memory and the Advanced
SIMD register bank. An instruction specifies both the length of the transfer and the size of the data elements being
transferred. This information is used by the processor to load and store data correctly in both big-endian and
little-endian systems.
Consider, for example, the instruction:
VLD1.16 {D0}, [R1]
A3.3 Endian support
This loads a 64-bit register with four 16-bit values. The four elements appear in the register in array order, with the
lowest indexed element fetched from the lowest address. The order of bytes in the elements depends on the
endianness configuration, as shown in Figure A3-2. Therefore, the order of the elements in the registers is the same
regardless of the endianness configuration.
64-bit register containing four 16-bit elements
D[15:8] D[7:0] C[15:8] C[7:0] B[15:8] B[7:0] A[15:8] A[7:0]
0 A[7:0] 0 A[15:8]
1 A[15:8] 1 A[7:0]
2 B[7:0] 2 B[15:8]
3 B[15:8] 3 B[7:0]
4 C[7:0] VLD1.16 {D0}, [R1] VLD1.16 {D0}, [R1] 4 C[15:8]
5 C[15:8] 5 C[7:0]
6 D[7:0] 6 D[15:8]
7 D[15:8] 7 D[7:0]
Memory system with Memory system with
little-endian addressing (LE) big-endian addressing (BE)
Figure A3-2 Advanced SIMD byte order example
For information about the alignment of Advanced SIMD instructions see Unaligned data access on page A3-106.
A3.4 Synchronization and semaphores

In architecture versions before ARMv6, support for the synchronization of shared memory depends on the SWP and
SWPB instructions. These are read-locked-write operations that swap register contents with memory, and are
described in SWP, SWPB on page A8-723. These instructions support basic busy/free semaphore mechanisms, but
do not support mechanisms that require calculation to be performed on the semaphore between the read and write
phases.
From ARMv6, ARM deprecates any use of SWP or SWPB, and the ARMv7 Virtualization Extensions make these
instructions OPTIONAL and deprecated.
Note
• ARM strongly recommends that all software uses the synchronization primitives described in this section,
rather than SWP or SWPB.
• If an implementation does not support the SWP and SWPB instructions, the ID_ISAR0.Swap_instrs and
ID_ISAR4.SWP_frac fields are zero, see About the Instruction Set Attribute registers on page B7-1940.
ARMv6 introduced a new mechanism to support more comprehensive non-blocking synchronization of shared
memory, using synchronization primitives that scale for multiprocessor system designs. ARMv7 extends support for
this mechanism, and provides the following synchronization primitives in the ARM and Thumb instruction sets:
• Load-Exclusives:
— LDREX, see LDREX on page A8-433.
— LDREXB, see LDREXB on page A8-435.
— LDREXD, see LDREXD on page A8-437.
— LDREXH, see LDREXH on page A8-439.
• Store-Exclusives:
— STREX, see STREX on page A8-691.
— STREXB, see STREXB on page A8-693.
— STREXD, see STREXD on page A8-695.
— STREXH, see STREXH on page A8-697.
• Clear-Exclusive, CLREX, see CLREX on page A8-358.
Note
This section describes the operation of a Load-Exclusive/Store-Exclusive pair of synchronization primitives using,
as examples, the LDREX and STREX instructions. The same description applies to any other pair of synchronization
primitives:
• LDREXB used with STREXB.
• LDREXD used with STREXD.
• LDREXH used with STREXH.
Software must use a Load-Exclusive instruction only with the corresponding Store-Exclusive instruction.
The model for the use of a Load-Exclusive/Store-Exclusive instruction pair, accessing a non-aborting memory
address x is:
• The Load-Exclusive instruction reads a value from memory address x.
• The corresponding Store-Exclusive instruction succeeds in writing back to memory address x only if no other
observer, process, or thread has performed a more recent store to address x. The Store-Exclusive operation
returns a status bit that indicates whether the memory write succeeded.
A Load-Exclusive instruction tags a small block of memory for exclusive access. The size of the tagged block is
IMPLEMENTATION DEFINED, see Tagging and the size of the tagged memory block on page A3-119. A
Store-Exclusive instruction to the same address clears the tag.
Note
In this section, the term processor includes any observer that can generate a Load-Exclusive or a Store-Exclusive.
A3.4.1 Exclusive access instructions and Non-shareable memory regions

For memory regions that do not have the Shareable attribute, the exclusive access instructions rely on a local
monitor that tags any address from which the processor executes a Load-Exclusive. Any non-aborted attempt by the
same processor to use a Store-Exclusive to modify any address is guaranteed to clear the tag.
A Load-Exclusive performs a load from memory, and:

• The executing processor tags the physical memory address for exclusive access.
• The local monitor of the executing processor transitions to the Exclusive Access state.
A Store-Exclusive performs a conditional store to memory, that depends on the state of the local monitor:
If the local monitor is in the Exclusive Access state

• If the address of the Store-Exclusive is the same as the address that has been tagged in the
monitor by an earlier Load-Exclusive, then the store occurs, otherwise it is IMPLEMENTATION
DEFINED whether the store occurs.
• A status value is returned to a register:

— If the store took place, the status value is 0.
— Otherwise, the status value is 1.
• The local monitor of the executing processor transitions to the Open Access state.
If the local monitor is in the Open Access state

• No store takes place.
• A status value of 1 is returned to a register.
• The local monitor remains in the Open Access state.
The Store-Exclusive instruction defines the register to which the status value is returned.
When a processor writes using any instruction other than a Store-Exclusive it is IMPLEMENTATION DEFINED whether
the write affects the state of the local monitor.
If the local monitor is in the Exclusive Access state and the processor performs a Store-Exclusive to any address
other than the last one from which it performed a Load-Exclusive, it is IMPLEMENTATION DEFINED whether the store
updates memory, but in all cases the local monitor is reset to the Open Access state. This mechanism:
• Is used on a context switch, see Context switch support on page A3-119.
• Must be treated as a software programming error in all other cases.
Note
It is IMPLEMENTATION DEFINED whether a store to a tagged physical address causes a tag in the local monitor to be
cleared if that store is by an observer other than the one that caused the physical address to be tagged.
Figure A3-3 on page A3-114 shows the state machine for the local monitor. Table A3-3 on page A3-114 shows the
effect of each of the operations shown in the figure.
LoadExcl(x) LoadExcl(x)
Open Exclusive
Access Access
CLREX CLREX Store(!Tagged_address)*

StoreExcl(x) Store(!Tagged_address)* Store(Tagged_address)*
Store(x) Store(Tagged_address)*
StoreExcl(Tagged_address)
StoreExcl(!Tagged_address)
Operations marked * are possible alternative IMPLEMENTATION DEFINED options.
In the diagram: LoadExcl represents any Load-Exclusive instruction
StoreExcl represents any Store-Exclusive instruction
Store represents any other store instruction.
Any LoadExcl operation updates the tagged address to the most significant bits of the address x used for the operation.
Figure A3-3 Local monitor state machine diagram
For more information about tagging, see Tagging and the size of the tagged memory block on page A3-119.
Note
For the local monitor state machine, as shown in Figure A3-3:
• The IMPLEMENTATION DEFINED options for the local monitor are consistent with the local monitor being
constructed so that it does not hold any physical address, but instead treats any access as matching the address
of the previous LoadExcl.
• A local monitor implementation can be unaware of Load-Exclusive and Store-Exclusive operations from
other processors.
• The architecture does not require a load instruction by another processor, that is not a Load-Exclusive
instruction, to have any effect on the local monitor.
• It is IMPLEMENTATION DEFINED whether the transition from Exclusive Access to Open Access state occurs
when the Store or StoreExcl is from another observer.
Table A3-3 shows the effect of the operations shown in Figure A3-3.
Table A3-3 Effect of Exclusive instructions and write operations on the local monitor
Initial state Operation a Effect Final state
Open Access CLREX No effect Open Access
StoreExcl(x) Does not update memory, returns status 1 Open Access
LoadExcl(x) Loads value from memory, tags address x Exclusive Access
Store(x) Updates memory, no effect on monitor Open Access
Exclusive Access CLREX Clears tagged address Open Access
StoreExcl(t) Updates memory, returns status 0 Open Access
Updates memory, returns status 0 b

StoreExcl(!t) Open Access
Does not update memory, returns status 1 b
LoadExcl(x) Loads value from memory, changes tag to address x Exclusive Access
Table A3-3 Effect of Exclusive instructions and write operations on the local monitor (continued)
Exclusive Access Exclusive Access b

Store(!t) Updates memory
Open Access b
Exclusive Access b
Store(t) Updates memory
Open Access b
a. In the table:
LoadExcl represents any Load-Exclusive instruction.
StoreExcl represents any Store-Exclusive instruction.
Store represents any store operation other than a Store-Exclusive operation.
t is the tagged address, bits[31:a] of the address of the last Load-Exclusive instruction. For more information, see
Tagging and the size of the tagged memory block on page A3-119.
b. IMPLEMENTATION DEFINED alternative actions.
Note
Normal memory that is Inner Non-cacheable, Outer Non-cacheable is inherently coherent between different
processors, and it is IMPLEMENTATION DEFINED whether such memory, if it does not have the Shareable attribute, is
treated as Non-shareable or as Shareable.
Changes to the local monitor state resulting from speculative execution

The architecture permits a local monitor to transition to the Open Access state as a result of speculation, or from
some other cause. This is in addition to the transitions to Open Access state caused by the architectural execution
of an operation shown in Table A3-3 on page A3-114.
An implementation must ensure that:
• The local monitor cannot be seen to transition to the Exclusive Access state except as a result of the
architectural execution of one of the operations shown in Table A3-3 on page A3-114.
• Any transition of the local monitor to the Open Access state not caused by the architectural execution of an
operation shown in Table A3-3 on page A3-114 must not indefinitely delay forward progress of execution.
A3.4.2 Exclusive access instructions and Shareable memory regions

For memory regions that have the Shareable attribute, exclusive access instructions rely on:
• A local monitor for each processor in the system, that tags any address from which the processor executes a
Load-Exclusive. The local monitor operates as described in Exclusive access instructions and Non-shareable
memory regions on page A3-113, except that for Shareable memory any Store-Exclusive is then subject to
checking by the global monitor if it is described in that section as doing at least one of:
— Updating memory.
— Returning a status value of 0.
The local monitor can ignore accesses from other processors in the system.
• A global monitor that tags a physical address as exclusive access for a particular processor. This tag is used
later to determine whether a Store-Exclusive to that address that has not been failed by the local monitor can
occur. Any successful write to the tagged address by any other observer in the shareability domain of the
memory location is guaranteed to clear the tag. For each processor in the system, the global monitor:
— Can hold at least one tagged address.
— Maintains a state machine for each tagged address it can hold.
Note
For each processor, the architecture only requires global monitor support for a single tagged address. Any
situation that might benefit from the use of multiple tagged addresses on a single processor is
UNPREDICTABLE, see Load-Exclusive and Store-Exclusive usage restrictions on page A3-120.
In addition, in an implementation that includes the Large Physical Address Extension, when the implementation is
using the Short-descriptor translation table format, it is IMPLEMENTATION DEFINED whether Load-Exclusive and
Store-Exclusive accesses to Non-shareable regions with the Normal, Inner Non-cacheable, Outer Non-cacheable
attribute use the global monitor in addition to the local monitor.
Note
The global monitor can either reside in a processor block or exist as a secondary monitor at the memory interfaces.
The IMPLEMENTATION DEFINED aspects of the monitors mean that the global monitor and local monitor can be
combined into a single unit, provided that unit performs the global monitor and local monitor functions defined in
this manual.
For Shareable regions of memory, in some implementations and for some memory types, the properties of the global
monitor can be met only by functionality outside the processor. Some system implementations might not implement
this functionality for all regions of memory. In particular, this can apply to:
• Any type of memory in the system implementation that does not support hardware cache coherency.
• Non-cacheable memory, or memory treated as Non-cacheable, in an implementation that does support

hardware cache coherency.
In such a system, it is defined by the system:

• Whether the global monitor is implemented.
• If the global monitor is implemented, which address ranges or memory types it monitors.
The behavior of Load Exclusive and Store Exclusive instructions when accessing a memory address not monitored
by the global monitor is UNPREDICTABLE.
Note
An implementation can combine the functionality of the global and local monitors into a single unit.
Operation of the global monitor

A Load-Exclusive from Shareable memory performs a load from memory, and causes the physical address of the
access to be tagged as exclusive access for the requesting processor. This access also causes the exclusive access
tag to be removed from any other physical address that has been tagged by the requesting processor.
The global monitor only supports a single outstanding exclusive access to Shareable memory per processor. A
Load-Exclusive by one processor has no effect on the global monitor state for any other processor.
Store-Exclusive performs a conditional store to memory:
• The store is guaranteed to succeed only if the physical address accessed is tagged as exclusive access for the
requesting processor and both the local monitor and the global monitor state machines for the requesting
processor are in the Exclusive Access state. In this case:
— A status value of 0 is returned to a register to acknowledge the successful store.
— The final state of the global monitor state machine for the requesting processor is IMPLEMENTATION
DEFINED.
— If the address accessed is tagged for exclusive access in the global monitor state machine for any other
processor, then that state machine transitions to Open Access state.
• If no address is tagged as exclusive access for the requesting processor, the store does not succeed:
— A status value of 1 is returned to a register to indicate that the store failed.
— The global monitor is not affected and remains in Open Access state for the requesting processor.
• If a different physical address is tagged as exclusive access for the requesting processor, it is
IMPLEMENTATION DEFINED whether the store succeeds or not:
— If the store succeeds a status value of 0 is returned to a register, otherwise a value of 1 is returned.
— If the global monitor state machine for the processor was in the Exclusive Access state before the
Store-Exclusive it is IMPLEMENTATION DEFINED whether that state machine transitions to the Open
Access state.
The Store-Exclusive instruction defines the register to which the status value is returned.
In a shared memory system, the global monitor implements a separate state machine for each processor in the
system. The state machine for accesses to Shareable memory by processor (n) can respond to all the Shareable
memory accesses visible to it. This means it responds to:
• Accesses generated by the associated processor (n).
• Accesses generated by the other observers in the shareability domain of the memory location (!n).
In a shared memory system, the global monitor implements a separate state machine for each observer that can
generate a Load-Exclusive or a Store-Exclusive in the system.
Figure A3-4 shows the state machine for processor(n) in a global monitor. Table A3-4 on page A3-118 shows the
effect of each of the operations shown in the figure.
LoadExcl(x,n) LoadExcl(x,n)
Open Exclusive
Access Access
CLREX(n) StoreExcl(Tagged_address,!n)‡ StoreExcl(Tagged_address,!n)‡

CLREX(!n) Store(Tagged_address,!n) Store(!Tagged_address,n)
LoadExcl(x,!n) StoreExcl(Tagged_address,n)* StoreExcl(Tagged_address,n)*
StoreExcl(x,n) StoreExcl(!Tagged_address,n)* StoreExcl(!Tagged_address,n)*
StoreExcl(x,!n) Store(Tagged_address,n)* Store(Tagged_address,n)*
Store(x,n) CLREX(n)* CLREX(n)*
Store(x,!n) StoreExcl(!Tagged_address,!n)
Store(!Tagged_address,!n)
CLREX(!n)
‡StoreExcl(Tagged_Address,!n) clears the monitor only if the StoreExcl updates memory
Operations marked * are possible alternative IMPLEMENTATION DEFINED options.
In the diagram: LoadExcl represents any Load-Exclusive instruction
StoreExcl represents any Store-Exclusive instruction
Store represents any other store instruction.
Any LoadExcl operation updates the tagged address to the most significant bits of the address x used for the operation.
Figure A3-4 Global monitor state machine diagram for processor(n) in a multiprocessor system
For more information about tagging, see Tagging and the size of the tagged memory block on page A3-119.
Note
For the global monitor state machine, as shown in Figure A3-4:
• The architecture does not require a load instruction by another processor, that is not a Load-Exclusive
instruction, to have any effect on the global monitor.
• Whether a Store-Exclusive successfully updates memory or not depends on whether the address accessed
matches the tagged Shareable memory address for the processor issuing the Store-Exclusive instruction. For
this reason, Figure A3-4 and Table A3-4 on page A3-118 only show how the (!n) entries cause state
transitions of the state machine for processor(n).
• A Load-Exclusive can only update the tagged Shareable memory address for the processor issuing the
Load-Exclusive instruction.
• The effect of the CLREX instruction on the global monitor is IMPLEMENTATION DEFINED.
• It is IMPLEMENTATION DEFINED:
— Whether a modification to a non-shareable memory location can cause a global monitor to transition
from Exclusive Access to Open Access state.
— Whether a Load-Exclusive to a non-shareable memory location can cause a global monitor to
transition from Open Access to Exclusive Access state.
Table A3-4 shows the effect of the operations shown in Figure A3-4 on page A3-117.
Table A3-4 Effect of load/store operations on global monitor for processor(n)
Exclusive LoadExcl(x, n) Loads value from memory, tags address x Exclusive Access
Access
Exclusive Access d
CLREX(n) None. Effect on the final state is IMPLEMENTATION DEFINED.
Open Access d
CLREX(!n) None Exclusive Access
Updates memory, returns status 0 b Open Access

StoreExcl(t, !n)
Does not update memory, returns status 1 b Exclusive Access
Open Access
StoreExcl(t, n) Updates memory, returns status 0 c
Exclusive Access
Open Access
Updates memory, returns status 0 d
Exclusive Access
StoreExcl(!t, n)
Open Access
Does not update memory, returns status 1 d
Exclusive Access
StoreExcl(!t, !n) Depends on state machine and tag address for processor issuing STREX Exclusive Access
Exclusive Access d
Store(t, n) Updates memory
Open Access d
Store(t, !n) Updates memory Open Access
Store(!t, n), Updates memory, no effect on monitor Exclusive Access

Store(!t, !n)
Table A3-4 Effect of load/store operations on global monitor for processor(n) (continued)
Open Access CLREX(n), None Open Access

CLREX(!n)
StoreExcl(x, n) Does not update memory, returns status 1 Open Access
LoadExcl(x, !n) Loads value from memory, no effect on tag address for processor(n) Open Access
StoreExcl(x, !n) Depends on state machine and tag address for processor issuing STREX b Open Access
Store(x, n), Updates memory, no effect on monitor Open Access

Store(x, !n)
LoadExcl(x, n) Loads value from memory, tags address x Exclusive Access
a. In the table:
LoadExcl represents any Load-Exclusive instruction.
StoreExcl represents any Store-Exclusive instruction.
Store represents any store operation other than a Store-Exclusive operation.
t is the tagged address for processor(n), bits[31:a] of the address of the last Load-Exclusive instruction issued by processor(n), see Tagging
and the size of the tagged memory block.
b. The result of a STREX(x, !n) or a STREX(t, !n) operation depends on the state machine and tagged address for the processor issuing the STREX
instruction. This table shows how each possible outcome affects the state machine for processor(n).
c. After a successful STREX to the tagged address, the state of the state machine is IMPLEMENTATION DEFINED. However, this state has no effect
on the subsequent operation of the global monitor.
d. Effect is IMPLEMENTATION DEFINED. The table shows all permitted implementations.
A3.4.3 Tagging and the size of the tagged memory block

As stated in the footnotes to Table A3-3 on page A3-114 and Table A3-4 on page A3-118, when a Load-Exclusive
instruction is executed, the resulting tag address ignores the least significant bits of the memory address.
Tagged_address = Memory_address[31:a]
The value of a in this assignment is IMPLEMENTATION DEFINED, between a minimum value of 3 and a maximum
value of 11. For example, in an implementation where a is 4, a successful LDREX of address 0x000341B4 gives a tag
value of bits[31:4] of the address, giving 0x000341B. This means that the four words of memory from 0x000341B0 to
0x000341BF are tagged for exclusive access.
The size of the tagged memory block is called the Exclusives Reservation Granule. The Exclusives Reservation
Granule is IMPLEMENTATION DEFINED in the range 2-512 words:
• 2 words in an implementation where a is 3.
• 512 words in an implementation where a is 11.
In some implementations the CTR identifies the Exclusives Reservation Granule, see either:
• CTR, Cache Type Register, VMSA on page B4-1552.
• CTR, Cache Type Register, PMSA on page B6-1827.
A3.4.4 Context switch support

After a context switch, software must ensure that the local monitor is in the Open Access state. This requires it to
either:
• Execute a CLREX instruction.
• Execute a dummy STREX to a memory address allocated for this purpose.
Note
• Using a dummy STREX for this purpose is backwards-compatible with the ARMv6 implementation of the
exclusive operations. The CLREX instruction is introduced in ARMv6K.
• Context switching is not an application level operation. However, this information is included here to
complete the description of the exclusive operations.
The STREX or CLREX instruction that follows a context switch might cause a subsequent Store-Exclusive to fail,
requiring a Load-Exclusive … Store-Exclusive sequence to be repeated. To minimize the possibility of this
happening, ARM recommends that the Store-Exclusive instruction is kept as close as possible to the associated
Load-Exclusive instruction, see Load-Exclusive and Store-Exclusive usage restrictions.
A3.4.5 Load-Exclusive and Store-Exclusive usage restrictions

The Load-Exclusive and Store-Exclusive instructions are intended to work together, as a pair, for example a
LDREX/STREX pair or an LDREXB/STREXB pair. To support different implementations of these functions, software must
follow the notes and restrictions given here.
These notes describe use of an LDREX/STREX pair, but apply equally to any other Load-Exclusive/Store-Exclusive pair:
• The exclusives support a single outstanding exclusive access for each processor thread that is executed. The
architecture makes use of this by not requiring an address or size check as part of the IsExclusiveLocal()
function. If the target virtual address of an STREX is different from the virtual address of the preceding LDREX
in the same thread of execution, behavior can be UNPREDICTABLE. As a result, an LDREX/STREX pair can only
be relied upon to eventually succeed if they are executed with the same virtual address. Where a context
switch or exception might change the thread of execution, a CLREX instruction or a dummy STREX instruction
must be executed to avoid unwanted effects, as described in Context switch support on page A3-119. Using
an STREX in this way is the only occasion where software can program an STREX with a different address from
the previously executed LDREX.
• If two STREX instructions are executed without an intervening LDREX the second STREX returns a status value
of 1. This means that:
— ARM recommends that, in a given thread of execution, every STREX has a preceding LDREX associated
with it.
— It is not necessary for every LDREX to have a subsequent STREX.
• An implementation of the Load-Exclusive and Store-Exclusive instructions can require that, in any thread of
execution, the transaction size of a Store-Exclusive is the same as the transaction size of the preceding
Load-Exclusive executed in that thread. If the transaction size of a Store-Exclusive is different from the
preceding Load-Exclusive in the same thread of execution, behavior can be UNPREDICTABLE. As a result,
software can rely on an LDREX/STREX pair to eventually succeed only if they have the same size. Where a
context switch or exception might change the thread of execution, the software must execute a CLREX
instruction, or a dummy STREX instruction, to avoid unwanted effects, as described in Context switch support
on page A3-119. Using an STREX in this way is the only occasion where software can use a Store-Exclusive
instruction with a different transaction size from the previously executed Load-Exclusive instruction.
• An implementation might clear an exclusive monitor between the LDREX and the STREX, without any
application-related cause. For example, this might happen because of cache evictions. Software written for
such an implementation must, in any single thread of execution, avoid having any explicit memory accesses,
System control register updates, or cache maintenance operations between the LDREX instruction and the
associated STREX instruction.
• In some implementations, an access to Strongly-ordered or Device memory might clear the exclusive
monitor. Therefore, software must not place a load or a store to Strongly-ordered or Device memory between
an LDREX and an STREX in a single thread of execution.
• Implementations can benefit from keeping the LDREX and STREX operations close together in a single thread of
execution. This minimizes the likelihood of the exclusive monitor state being cleared between the LDREX
instruction and the STREX instruction. Therefore, for best performance, ARM strongly recommends a limit of
128 bytes between LDREX and STREX instructions in a single thread of execution.
• The architecture sets an upper limit of 2048 bytes on the size of a region that can be marked as exclusive.
Software can read the implemented size of the Exclusives reservation granule from the CTR.ERG field, see:
— CTR, Cache Type Register, VMSA on page B4-1552 for a VMSA implementation.
— CTR, Cache Type Register, PMSA on page B6-1827 for a PMSA implementation.
In a heavily contended system, having multiple objects that are in the same exclusive reservation granule
accessed by exclusive accesses can lead to starvation of a process accessing that granule. Therefore, in such
systems, ARM recommends that objects that are accessed by exclusive accesses are separated by the size of
the Exclusive Reservation Granule.
• It is IMPLEMENTATION DEFINED whether LDREX and STREX operations can be performed to a memory region
with the Device or Strongly-ordered memory attribute. Unless the implementation documentation explicitly
states that LDREX and STREX operations to a memory region with the Device or Strongly-ordered attribute are
permitted, the effect of such operations is UNPREDICTABLE.
• After taking a Data Abort exception, the state of the exclusive monitors is UNKNOWN. Therefore ARM
strongly recommends that the abort handling software performs a CLREX instruction, or a dummy STREX
instruction, to clear the monitor state.
• For the memory location being accessed by a LoadExcl/StoreExcl pair, if the memory attributes for the
LoadExcl instruction differ from the memory attributes for the StoreExcl instruction, behavior is
UNPREDICTABLE.
This can occur either:

— Because the translation of the accessed address changes between the LoadExcl and the StoreExcl.
— As a result of using different virtual addresses, with different attributes, that point to the same physical
address. This case is covered by another bullet point in this list.
If the memory attributes for the memory being accessed by an LDREX/STREX pair are changed between the LDREX
and the STREX, behavior is UNPREDICTABLE.
• The effect of a data or unified cache invalidate, cache clean, or cache clean and invalidate instruction on a
local or global exclusive monitor that is in the Exclusive Access state is UNPREDICTABLE. Execution of the
instruction might clear the monitor, or it might leave it in the Exclusive Access state. For address-based
maintenance instructions, this also applies to the monitors of other processors in the same shareability domain
as the processor executing the cache maintenance instruction, as determined by the shareability domain of
the address being maintained.
Note
ARM strongly recommends that implementations ensure that the use of such maintenance operations by a
processor in the Non-secure state cannot cause a denial of service on a processor in the Secure state.
• If the mapping of the virtual to physical address is changed between the LDREX instruction and the STREX
instruction, and the change is performed using a break-before-make sequence as described in General TLB
maintenance requirements on page B3-1377, if the STREX is performed after another write to the same
physical address as the STREX, and that other write was performed after the old translation was properly
invalidated and that invalidation was properly synchronized, then the STREX will not pass its monitor check.
Note
ARM expects that, in many implementations, either:
— The TLB invalidation will clear either the local or global monitor.
— The physical address will be checked between the LDREX and STREX.
Note
In the event of repeatedly-contending load-exclusive/store-exclusive sequences from multiple processors, an
implementation must ensure that forward progress is made by at least one processor.
A3.4.6 Semaphores
The Swap (SWP) and Swap Byte (SWPB) instructions must be used with care to ensure that expected behavior is
observed. Two examples are as follows:
1. A system with multiple bus masters that uses Swap instructions to implement semaphores that control
interactions between different bus masters.
In this case, the semaphores must be placed in an uncached region of memory, where any buffering of writes
occurs at a point common to all bus masters using the mechanism. The Swap instruction then causes a locked
read-write bus transaction.
2. A system with multiple threads running on a uniprocessor that uses Swap instructions to implement
semaphores that control interaction of the threads.
In this case, the semaphores can be placed in a cached region of memory, and a locked read-write bus
transaction might or might not occur. The Swap and Swap Byte instructions are likely to have better
performance on such a system than they do on a system with multiple bus masters, such as that described in
example 1.
Note
From ARMv6, ARM deprecates use of the Swap and Swap Byte instructions, and strongly recommends that all new
software uses the Load-Exclusive and Store-Exclusive synchronization primitives described in Synchronization and
semaphores on page A3-112, for example LDREX and STREX.
A3.4.7 Synchronization primitives and the memory order model

The synchronization primitives follow the memory order model of the memory type accessed by the instructions.
For this reason:
• Portable software for claiming a spin-lock must include a Data Memory Barrier (DMB) operation, performed
by a DMB instruction, between claiming the spin-lock and making any access that makes use of the spin-lock.
• Portable software for releasing a spin-lock must include a DMB instruction before writing to clear the spin-lock.
This requirement applies to software using:

• The Load-Exclusive/Store-Exclusive instruction pairs, for example LDREX/STREX.
• The deprecated synchronization primitives, SWP/SWPB.
A3.4.8 Use of WFE and SEV instructions by spin-locks

ARMv7 and ARMv6K provide Wait For Event and Send Event instructions, WFE and SEV, that can assist with
reducing power consumption and bus contention caused by processors repeatedly attempting to obtain a spin-lock.
These instructions can be used at the application level, but a complete understanding of what they do depends on
system level understanding of exceptions. They are described in Wait For Event and Send Event on page B1-1199.
A3.5 Memory types and attributes and the memory order model
ARMv6 defined a set of memory attributes with the characteristics required to support the memory and devices in
the system memory map. In ARMv7, this set of attributes is extended by the addition of the Outer Shareable attribute
for Normal memory and, in an implementation that does not include the Large Physical Address Extension, for
Device memory.
Note
Whether an ARMv7 implementation distinguishes between Inner Shareable and Outer Shareable memory is
IMPLEMENTATION DEFINED.
The ordering of accesses for regions of memory, referred to as the memory order model, is defined by the memory
attributes. This model is described in the following sections:
• Memory types.
• Summary of ARMv7 memory attributes on page A3-124.
• Atomicity in the ARM architecture on page A3-125.
• Concurrent modification and execution of instructions on page A3-127.
• Normal memory on page A3-129.
• Device and Strongly-ordered memory on page A3-133.
• Memory access restrictions on page A3-135.
• The effect of the Security Extensions on page A3-138.
A3.5.1 Memory types

For each memory region, the most significant memory attribute specifies the memory type. There are three mutually
exclusive memory types:
• Normal.
• Device.
• Strongly-ordered.
Normal and Device memory regions have additional attributes.
Usually, memory used for programs and for data storage is suitable for access using the Normal memory attribute.
Examples of memory technologies for which the Normal memory attribute is appropriate are:
• Programmed Flash ROM.
Note
During programming, Flash memory can be ordered more strictly than Normal memory.
• ROM.
• SRAM.
• DRAM and DDR memory.
System peripherals (I/O) generally conform to different access rules. Examples of I/O accesses are:
• FIFOs where consecutive accesses:

— Add queued values on write accesses.
— Remove queued values on read accesses.
• Interrupt controller registers where an access can be used as an interrupt acknowledge, changing the state of
the controller itself.
• Memory controller configuration registers that are used for setting up the timing and correctness of areas of
Normal memory.
• Memory-mapped peripherals, where accessing a memory location can cause side-effects in the system.
In ARMv7, the Strongly-ordered or Device memory attribute provides suitable access control for such peripherals.
To ensure correct system behavior, the access rules for Device and Strongly-ordered memory are more restrictive
than those for Normal memory, so that:
• Neither read nor write accesses can be performed speculatively.
Note
However, translation table walks can be made speculatively to memory marked as Device or
Strongly-ordered, see Device and Strongly-ordered memory on page A3-133.
• Read and write accesses cannot be repeated, for example, on return from an exception.
• The number, order and sizes of the accesses are maintained.
For more information, see Device and Strongly-ordered memory on page A3-133.
A3.5.2 Summary of ARMv7 memory attributes

Table A3-5 summarizes the memory attributes. For more information about these attributes, see:
• Normal memory on page A3-129 and Shareable attribute for Device memory regions on page A3-134, for
the shareability attribute.
• Write-Through Cacheable, Write-Back Cacheable and Non-cacheable Normal memory on page A3-131, for
cacheability and cache allocation hint attributes.
Note
The cacheability and cache allocation hint attributes apply only to Normal memory. Device and Strongly-ordered
memory regions are Non-cacheable.
In this table:
Shareability Applies only to Normal memory, and to Device memory in an implementation that does not include
the Large Physical Address Extension. In an implementation that includes the Large Physical
Address Extension, Device memory is always Outer Shareable,
When it is possible to assign a shareability attribute to Device memory, ARM deprecates assigning
any attribute other than Shareable or Outer Shareable, see Shareable attribute for Device memory
regions on page A3-134
Whether an ARMv7 implementation distinguishes between Inner Shareable and Outer Shareable
memory is IMPLEMENTATION DEFINED.
Cacheability Applies only to Normal memory, and can be defined independently for Inner and Outer cache
regions. Some cacheability attributes can be complemented by a cache allocation hint. This is an
indication to the memory system of whether allocating a value to a cache is likely to improve
performance. For more information, see Cacheability and cache allocation hint attributes on
page B2-1262.
An implementation might not make any distinction between memory regions with attributes that
differ only in their cache allocation hint.
Table A3-5 Memory attribute summary
Memory type Implementation includes LPAE a? Shareability Cacheability
Strongly- ordered - - -
Table A3-5 Memory attribute summary (continued)
Memory type Implementation includes LPAE a? Shareability Cacheability
Device Yes Outer Shareable -
No Outer Shareable
Inner Shareable
Non-shareable
Normal - Outer Shareable One of:

• Non-cacheable
Inner Shareable
• Write-Through Cacheable
Non-shareable • Write-Back Cacheable.
a. LPAE means the Large Physical Address Extension.
Memory model and memory ordering on page D15-2579 compares these attributes with the memory attributes in
architecture versions before ARMv6.
A3.5.3 Atomicity in the ARM architecture

Atomicity is a feature of memory accesses, described as atomic accesses. The ARM architecture description refers
to two types of atomicity, defined in:
• Single-copy atomicity.
• Multi-copy atomicity on page A3-127.
Single-copy atomicity
A read or write operation that is single-copy atomic has the following properties:
• For a single-copy atomic store, if the store overlaps another single-copy atomic store, then all of the writes
from one of the stores are inserted into the Coherence order of each overlapping byte before any of the writes
of the other store are inserted into the Coherence order of the overlapping bytes.
• If a single-copy atomic load overlaps a single-copy atomic store and for any of the overlapping bytes the load
returns the data written by the write inserted into the Coherence order of that byte by the single-copy atomic
store then the load must return data from a point in the Coherence order no earlier than the writes inserted
into the Coherence order by the single-copy atomic store of all of the overlapping bytes.
In ARMv7, the single-copy atomic processor accesses are:

• All byte accesses.
• All halfword accesses to halfword-aligned locations.
• All word accesses to word-aligned locations.
• Memory accesses caused by an LDREXD/STREXD to a doubleword-aligned location for which the STREXD
succeeds cause single-copy atomic updates of the doubleword being accessed.
Note
The way to atomically load two 32-bit quantities is to perform an LDREXD/STREXD sequence, reading and writing
the same value, for which the STREXD succeeds, and use the read values.
LDM, LDC, LDC2, LDRD, STM, STC, STC2, STRD, PUSH, POP, RFE, SRS, VLDM, VLDR, VSTM, and VSTR instructions are executed as a
sequence of word-aligned word accesses. Each 32-bit word access is guaranteed to be single-copy atomic. The
architecture does not require subsequences of two or more word accesses from the sequence to be single-copy
atomic.
In an implementation that includes the Large Physical Address Extension, LDRD, and STRD accesses to 64-bit aligned
locations are 64-bit single-copy atomic as seen by translation table walks and accesses to translation tables.
Note
The Large Physical Address Extension adds this requirement to avoid the need for complex measures to avoid
atomicity issues when changing translation table entries, without creating a requirement that all locations in the
memory system are 64-bit single-copy atomic. This addition means:
• The system designer must ensure that all writable memory locations that might be used to hold translations,
such as bulk SDRAM, can be accessed with 64-bit single-copy atomicity.
• Software must ensure that translation tables are not held in memory locations that cannot meet this atomicity
requirement, such as peripherals that are typically accessed using a narrow bus.
This requirement places no burden on read-only memory locations for which reads have no side effects, since it is
impossible to detect the size of memory accesses to such locations.
Advanced SIMD element and structure loads and stores are executed as a sequence of accesses of the element or
structure size. The architecture requires the element accesses to be single-copy atomic if and only if both:
• The element size is 32 bits, or smaller.
• The elements are naturally aligned.
Accesses to 64-bit elements or structures that are at least word-aligned are executed as a sequence of 32-bit accesses,
each of which is single-copy atomic. The architecture does not require subsequences of two or more 32-bit accesses
from the sequence to be single-copy atomic.
When an access is not single-copy atomic by the rules described in this section, it is executed as a sequence of one
or more accesses that aggregate to size of the access. Each of the accesses in this sequence is single-copy atomic, at
least at the byte level.
Note
In this section, the terms before the write operation and after the write operation mean before or after the write
operation has had its effect on the coherence order of the bytes of the memory location accessed by the write
operation.
If, according to these rules, an instruction is executed as a sequence of accesses, some exceptions can be taken
during that sequence. Such an exception causes execution of the instruction to be abandoned. These exceptions are:
• Synchronous Data Abort exceptions.
• The following, if low interrupt latency configuration is selected and the accesses are to Normal memory:
— IRQ interrupts.
— FIQ interrupts.
— Asynchronous aborts.
For more information about this configuration, see Low interrupt latency configuration on page B1-1197.
If such an instruction is abandoned as a result of an asynchronous exception, then:
• For a load:
— Any register being loaded other than one used in the generation of the address by the instruction, might
contain an UNKNOWN value.
— Registers used in the generation of the address are restored to their initial value.
• For a store, any data location being stored to can contain an UNKNOWN value.
If such an instruction is abandoned as a result of a Synchronous Data Abort exception, then see Data Abort
exception on page B1-1214.
If any of these exceptions are returned from using their preferred return address, the instruction that generated the
sequence of accesses is re-executed and so any access that had been performed before the exception was taken is
repeated.
Note
The exception behavior for these multiple access instructions means they are not suitable for use for writes to
memory for the purpose of software synchronization.
For implicit accesses:
• Cache linefills and evictions have no effect on the single-copy atomicity of explicit transactions or instruction
fetches.
• Instruction fetches are single-copy atomic:

— At 32-bit granularity in ARM state.
— At 16-bit granularity in Thumb and ThumbEE states.
— At 8-bit granularity in Jazelle state.
Concurrent modification and execution of instructions describes additional constraints on the behavior of
instruction fetches.
• Translation table walks are performed using accesses that are single-copy atomic:
— At 32-bit granularity when using Short-descriptor format translation tables.
— At 64-bit granularity when using Long-descriptor format translation tables.
Multi-copy atomicity
In a multiprocessing system, writes to a memory location are multi-copy atomic if the following conditions are both
true:
• All writes to the same location are serialized, meaning they are observed in the same order by all observers,
although some observers might not observe all of the writes.
• A read of a location does not return the value of a write until all observers observe that write.
Writes to Normal memory are not multi-copy atomic.
All writes to Device and Strongly-ordered memory that are single-copy atomic are also multi-copy atomic.
Note
All coherent write accesses to the same location are serialized, regardless of whether or not they are multi-copy
atomic. For Normal memory, write accesses can be repeated up to the point that another write to the same address
is observed, and serialization does not prohibit the merging of writes.
A3.5.4 Concurrent modification and execution of instructions

The ARMv7 architecture limits the set of instructions that can be executed by one thread of execution as they are
being modified by another thread of execution without requiring explicit synchronization.
Except for the instructions identified in this section, the effect of the concurrent modification and execution of an
instruction is UNPREDICTABLE.
For the following instructions only, the architecture guarantees that, after modification of the instruction, behavior
is consistent with execution of either:
• The instruction originally fetched.
• A fetch of the new instruction. That is, a fetch of the instruction that results from the modification.
The instructions to which this guarantee applies are:
In the Thumb instruction set

The 16-bit encodings of the B, NOP, BKPT, and SVC instructions.
In addition:
• The most-significant halfword of a BL instruction can be concurrently modified to the most
significant halfword of another BL instruction.
The most-significant halfword of a BLX instruction can be concurrently modified to the most
significant halfword of another BLX instruction.
These cases mean that the most significant bits of the immediate value can be modified.
• The most-significant halfword of a BL or BLX instruction can be concurrently modified to a
16-bit B, BKPT, or SVC instruction.
• The least-significant halfword of a BL instruction can be concurrently modified to the least
significant halfword of another BL instruction.
The least-significant halfword of a BLX instruction can be concurrently modified to the least
significant halfword of another BLX instruction.
These cases mean that the least significant bits of the immediate value can be modified.
• The least-significant halfword of a 32-bit B immediate instruction:
— With a condition field, can be concurrently modified to the least significant halfword
of another 32-bit B immediate instruction with a condition field.
— Without a condition field, can be concurrently modified to the least significant
halfword of another 32-bit B immediate instruction without a condition field.
These cases mean that the least significant bits of the immediate value can be modified.
• A 16-bit B, BKPT, or SVC instruction can be concurrently modified to the most-significant
halfword of a BL instruction.
Note
In the Thumb instruction set:
• The only encodings of BKPT and SVC are 16-bit.
• The only encoding of BL is 32-bit.
In the ARM instruction set

The B, BL, NOP, BKPT, SVC, HVC, and SMC instructions.
For all other instructions, to avoid UNPREDICTABLE behavior, instruction modifications must be explicitly
synchronized before they are executed. The required synchronization is as follows:
1. To ensure that the modified instructions are observable, the thread of execution that is modifying the
instructions must issue the following sequence of instructions and operations:
DCCMVAU [instruction location] ; Clean data cache by MVA to point of unification
DSB ; Ensure visibility of the data cleaned from the cache
ICIMVAU [instruction location] ; Invalidate instruction cache by MVA to PoU
BPIMVAU [instruction location] ; Invalidate branch predictor by MVA to PoU
DSB ; Ensure completion of the invalidations
2. Once the modified instructions are observable, the thread of execution that is executing the modified
instructions must issue the following instructions or operations to ensure execution of the modified
instructions:
ISB ; Synchronize fetched instruction stream
Note
Issue C.a of this manual first describes this behavior, but the description applies to all ARMv7 implementations.
In addition, for both instruction sets, if one thread of execution changes a conditional branch instruction to another
conditional branch instruction, and the change affects both the condition field and the branch target, execution of
the changed instruction by another thread of execution before the change is synchronized can lead to either:
• The old condition being associated with the new target address.
• The new condition being associated with the old target address.
These possibilities apply regardless of whether the condition, either before or after the change to the branch
instruction, is the always condition.
A3.5.5 Normal memory

Accesses to normal memory region are idempotent, meaning that they exhibit the following properties:
• Read accesses can be repeated with no side-effects.
• Repeated read accesses return the last value written to the resource being read.
• Read accesses can fetch additional memory locations with no side-effects.
• Write accesses can be repeated with no side-effects in the following cases:
— If the contents of the location accessed are unchanged between the repeated writes.
— As the result of an exception, as described in this section.
• Unaligned accesses can be supported.
• Accesses can be merged before accessing the target memory system.
Normal memory can be read/write or read-only, and a Normal memory region is defined as being either Shareable
or Non-shareable. For Shareable Normal memory, whether a VMSA implementation distinguishes between Inner
Shareable and Outer Shareable is IMPLEMENTATION DEFINED. A PMSA implementation makes no distinction
between Inner Shareable and Outer Shareable regions.
The Normal memory type attribute applies to most memory used in a system.
Accesses to Normal memory have a weakly consistent model of memory ordering. See a standard text describing
memory ordering issues for a description of weakly consistent memory models, for example chapter 2 of Memory
Consistency Models for Shared Memory-Multiprocessors. In general, for Normal memory, barrier operations are
required where the order of memory accesses observed by other observers must be controlled. This requirement
applies regardless of the cacheability and shareability attributes of the Normal memory region.
The ordering requirements of accesses described in Ordering requirements for memory accesses on page A3-146
apply to all explicit accesses.
An instruction that generates a sequence of accesses as described in Atomicity in the ARM architecture on
page A3-125 might be abandoned as a result of an exception being taken during the sequence of accesses. On return
from the exception, the instruction is restarted, and therefore one or more of the memory locations might be accessed
multiple times. This can result in repeated write accesses to a location that has been changed between the write
accesses.
The architecture permits speculative accesses to memory locations marked as Normal if the access permissions and
domain permit an access to the locations.
A Normal memory region has shareability attributes that define the data coherency properties of the region. These
attributes do not affect the coherency requirements of:
• Instruction fetches, see Instruction coherency issues on page A3-155.
• Translation table walks for VMSA implementations of:

— ARMv7-A without the Multiprocessing Extensions.
— Versions of the architecture before ARMv7.
For more information, see TLB maintenance operations and the memory order model on page B3-1379.
Non-shareable Normal memory

For a Normal memory region, the Non-shareable attribute identifies Normal memory that is likely to be accessed
only by a single processor.
A region of Normal memory with the Non-shareable attribute does not have any requirement to make data accesses
by different observers coherent, unless the memory is Non-cacheable. If other observers share the memory system,
software must use cache maintenance operations if the presence of caches might lead to coherency issues when
communicating between the observers. This cache maintenance requirement is in addition to the barrier operations
that are required to ensure memory ordering.
For Non-shareable Normal memory, it is IMPLEMENTATION DEFINED whether the Load-Exclusive and
Store-Exclusive synchronization primitives take account of the possibility of accesses by more than one observer.
Shareable, Inner Shareable, and Outer Shareable Normal memory

For Normal memory, the Shareable and Outer Shareable memory attributes describe Normal memory that is
expected to be accessed by multiple processors or other system masters:
• In a VMSA implementation, Normal memory that has the Shareable attribute but not the Outer Shareable
attribute assigned is described as having the Inner Shareable attribute.
• In a PMSA implementation, no distinction is made between Inner Shareable and Outer Shareable Normal
memory.
A region of Normal memory with the Shareable attribute is one for which data accesses to memory by different
observers within the same shareability domain are coherent.
The Outer Shareable attribute is introduced in ARMv7, and can be applied only to a Normal memory region in a
VMSA implementation that has the Shareable attribute assigned. It creates three levels of shareability for a Normal
memory region:
Non-shareable A Normal memory region that does not have the Shareable attribute assigned.
Inner Shareable A Normal memory region that has the Shareable attribute assigned, but not the Outer
Shareable attribute.
Outer Shareable A Normal memory region that has both the Shareable and the Outer Shareable attributes
assigned.
These attributes can define sets of observers for which the shareability attributes make the data or unified caches
transparent for data accesses. The sets of observers that are affected by the shareability attributes are described as
shareability domains. The details of the use of these attributes are system-specific. Example A3-1 shows how they
might be used:
Example A3-1 Use of shareability attributes
In a VMSA implementation, a particular subsystem with two clusters of processors has the requirement that:
• In each cluster, the data or unified caches of the processors in the cluster are transparent for all data accesses
with the Inner Shareable attribute.
• However, between the two clusters, the caches:

— Are not transparent for data accesses that have only the Inner Shareable attribute.
— Are transparent for data accesses that have the Outer Shareable attribute.
In this system, each cluster is in a different shareability domain for the Inner Shareable attribute, but all components
of the subsystem are in the same shareability domain for the Outer Shareable attribute.
A system might implement two such subsystems. If the data or unified caches of one subsystem are not transparent
to the accesses from the other subsystem, this system has two Outer Shareable shareability domains.
However, for a Normal memory region that is Non-cacheable, as described in Write-Through Cacheable,
Write-Back Cacheable and Non-cacheable Normal memory on page A3-131, the only significance of the
Shareability attribute is the behavior of Load-Exclusive and Store-Exclusive instructions. For more information
about this behavior see Synchronization and semaphores on page A3-112.
Having two levels of shareability attribute means system designers can reduce the performance and power overhead
for shared memory regions that do not need to be part of the Outer Shareable shareability domain.
In a VMSA implementation, for Shareable Normal memory, whether there is a distinction between Inner Shareable
and Outer Shareable is IMPLEMENTATION DEFINED.
For Shareable Normal memory, the Load-Exclusive and Store-Exclusive synchronization primitives take account
of the possibility of accesses by more than one observer in the same Shareability domain.
Note
• System designers can use the Shareable concept to specify the locations in Normal memory that must have
coherency requirements. However, to facilitate porting of software, software developers must not assume that
specifying a memory region as Non-shareable permits software to make assumptions about the incoherency
of memory locations between different processors in a shared memory system. Such assumptions are not
portable between different multiprocessing implementations that make use of the Shareable concept. Any
multiprocessing implementation might implement caches that, inherently, are shared between different
processing elements.
• This architecture is written with an expectation that all processors using the same operating system or
hypervisor are in the same Inner Shareable shareability domain.
Write-Through Cacheable, Write-Back Cacheable and Non-cacheable Normal memory

In addition to being Outer Shareable, Inner Shareable or Non-shareable, each region of Normal memory is assigned
a cacheability attribute that is one of:
• Write-Through Cacheable.
• Write-Back Cacheable.
• Non-cacheable.
Also, for cacheable Normal memory regions:
• A region might be assigned a cache allocation hint.
• In an ARMv7-A implementation that includes the Large Physical Address Extension, it is IMPLEMENTATION
DEFINED whether the Write-Through Cacheable and Write-Back Cacheable attributes can have an additional
attribute of Transient or Non-transient, see Transient cacheability attribute, Large Physical Address
Extension on page A3-132.
A memory location can be marked as having different cacheability attributes, for example when using aliases in a
virtual to physical address mapping:
• If the attributes differ only in the cache allocation hint this does not affect the behavior of accesses to that
location.
• For other cases see Mismatched memory attributes on page A3-136.
The cacheability attributes provide a mechanism of coherency control with observers that lie outside the shareability
domain of a region of memory. In some cases, the use of Write-Through Cacheable or Non-cacheable regions of
memory might provide a better mechanism for controlling coherency than the use of hardware coherency
mechanisms or the use of cache maintenance routines. To this end, the architecture requires the following properties
for Non-cacheable or Write-Through Cacheable memory:
• A completed write to a memory location that is Non-cacheable or Write-Through Cacheable for a level of
cache made by an observer accessing the memory system inside the level of cache is visible to all observers
accessing the memory system outside the level of cache without the need of explicit cache maintenance.
• A completed write to a memory location that is Non-cacheable for a level of cache made by an observer
accessing the memory system outside the level of cache is visible to all observers accessing the memory
system inside the level of cache without the need of explicit cache maintenance.
Note
Implementations can use the cache allocation hints to indicate a probable performance benefit of caching. For
example, a programmer might know that a piece of memory is not going to be accessed again and would be better
treated as Non-cacheable. The distinction between memory regions with attributes that differ only in the cache
allocation hints exists only as a hint for performance.
The ARM architecture provides independent cacheability attributes for Normal memory for two conceptual levels
of cache, the inner and the outer cache. The relationship between these conceptual levels of cache and the
implemented physical levels of cache is IMPLEMENTATION DEFINED, and can differ from the boundaries between the
Inner and Outer Shareability domains. However:
• Inner refers to the innermost caches, and always includes the lowest level of cache.
• No cache controlled by the Inner cacheability attributes can lie outside a cache controlled by the Outer
cacheability attributes.
• An implementation might not have any outer cache.
Example A3-2, Example A3-3, and Example A3-4 describe the possible ways of implementing a system with three
levels of cache, level 1 (L1) to level 3 (L3).
Note
• L1 cache is the level closest to the processor, see Memory hierarchy on page A3-153.
• When managing coherency, system designs must consider both the inner and outer cacheability attributes, as
well as the shareability attributes. This is because hardware might have to manage the coherency of caches
at one conceptual level, even when another conceptual level has the Non-cacheable attribute.
Example A3-2 Implementation with two inner and one outer cache levels
Implement the three levels of cache in the system, L1 to L3, with:

• The Inner cacheability attribute applied to L1 and L2 cache.
• The Outer cacheability attribute applied to L3 cache.
Example A3-3 Implementation with three inner and no outer cache levels
Implement the three levels of cache in the system, L1 to L3, with the Inner cacheability attribute applied to L1, L2,
and L3 cache. Do not use the Outer cacheability attribute.
Example A3-4 Implementation with one inner and two outer cache levels
Implement the three levels of cache in the system, L1 to L3, with:

• The Inner cacheability attribute applied to L1 cache.
• The Outer cacheability attribute applied to L2 and L3 cache.
Transient cacheability attribute, Large Physical Address Extension
For an ARMv7-A implementation that includes the Large Physical Address Extension, it is IMPLEMENTATION
DEFINED whether a Transient attribute is supported for cacheable Normal memory regions. If an implementation
supports this attribute, the set of possible cacheability attributes for a Normal memory region becomes:
• Write-Through Cacheable, Non-transient.
• Write-Back Cacheable, Non-transient.

• Write-Through Cacheable, Transient.
• Write-Back Cacheable, Transient.
• Non-cacheable.
The cacheability attribute can be defined independently for the inner and outer levels of caching.
The transient attribute indicates that the benefit of caching is for a relatively short period, and that therefore it might
be better to restrict allocation, to avoid possibly casting-out other, less transient, entries.
Note
The architecture does not specify what is meant by a relatively short period.
The description of the MAIRn registers includes the assignment of the Transient attribute in an implementation that
supports this option.
A3.5.6 Device and Strongly-ordered memory

The Device and Strongly-ordered memory type attributes define memory locations where an access to the location
can cause side-effects, or where the value returned for a load can vary depending on the number of loads performed.
In ARMv7, Device and Strongly-ordered memory differ only in their shareability options, as this section describes.
Note
See Ordering of instructions that change the CPSR interrupt masks on page D12-2494 for additional requirements
that apply to accesses to Strongly-ordered memory in ARMv6.
Examples of memory regions normally marked as being Device or Strongly-ordered memory are Memory-mapped
peripherals and I/O locations.
For explicit accesses from the processor to memory marked as Device or Strongly-ordered:
• All accesses occur at their program size.
• The number of accesses is the number specified by the program.
An implementation must not perform more accesses to a Device or Strongly-ordered memory location than are
specified by a simple sequential execution of the program, except as a result of an exception. This section describes
this permitted effect of an exception.
The architecture does not permit speculative data accesses to memory marked as Device or Strongly-ordered.
However, it does not prohibit speculative translation table walks to Device or Strongly-ordered memory.
Note
• For an implementation that includes the Virtualization Extensions, for accesses from an application running
in Non-secure state, a speculative translation table walk to Device or Strongly-ordered memory might result
from the second stage of address translation defined by a hypervisor. For more information, see Overlaying
the memory type attribute on page B3-1372.
• For information about restrictions on speculative instruction fetching, see:

— Execute-never restrictions on instruction fetching on page B3-1355 for a VMSA implementation.
— The XN (Execute-never) attribute and instruction fetching on page B5-1753 for a PMSA
implementation.
The architecture permits an Advanced SIMD element or structure load instruction to access bytes in Device or
Strongly-ordered memory that are not explicitly accessed by the instruction, provided the bytes accessed are in a
16-byte window, aligned to 16-bytes, that contains at least one byte that is explicitly accessed by the instruction.
Address locations marked as Device or Strongly-ordered are never held in a cache.
Address locations marked as Strongly-ordered, and on an implementation that includes the Large Physical Address
Extension, address locations marked as Device, are always treated as Shareable. For more information about the
effect of the Large Physical Address Extension on the shareability of these locations see Device and
Strongly-ordered memory shareability, Large Physical Address Extension on page A3-135.
On an implementation that does not include the Large Physical Address Extension, the shareability of an address
location marked as Device is configurable, as described in Shareable attribute for Device memory regions.
All explicit accesses to Device or Strongly-ordered memory must comply with the ordering requirements of
accesses described in Ordering requirements for memory accesses on page A3-146. On an implementation that does
not include the Large Physical Address Extension, the requirements for Device memory depend on the shareability
of the Device memory locations.
An instruction that generates a sequence of accesses as described in Atomicity in the ARM architecture on
page A3-125 might be abandoned as a result of an exception being taken during the sequence of accesses. On return
from the exception the instruction is restarted, and therefore one or more of the memory locations might be accessed
multiple times. This can result in repeated write accesses to a location that has been changed between the write
accesses.
Note
Software must not use an instruction that generates a sequence of accesses to access Device or Strongly-ordered
memory if the instruction might generate a synchronous Data Abort exception on any access other than the first one.
The only architecturally-required difference between Device and Strongly-ordered memory is that:
• A write to Strongly-ordered memory can complete only when it reaches the peripheral or memory component
accessed by the write.
• A write to Device memory is permitted to complete before it reaches the peripheral or memory component
accessed by the write.
Note
In addition, as described in Shareable attribute for Device memory regions, in an implementation that does not
include the Large Physical Address Extension, Device memory has Shareability attributes, the interpretation of
which is IMPLEMENTATION DEFINED, and might mean a Device memory region is not shareable.
The architecture does not permit unaligned accesses to Strongly-ordered or Device memory. Memory access
restrictions on page A3-135 summarizes the behavior of such accesses.
Shareable attribute for Device memory regions

In an implementation that does not include the Large Physical Address Extension, Device memory regions can be
given the Shareable attribute. When a Device memory region is give the Shareable attribute it can also be given the
Outer Shareable attribute. This means that a region of Device memory can be described as one of:
• Outer Shareable Device memory.
• Inner Shareable Device memory.
• Non-shareable Device memory.
Some implementations make no distinction between Outer Shareable Device memory and Inner Shareable Device
memory, and refer to both memory types as Shareable Device memory.
Some implementations make no distinction between Shareable Device memory and Non-shareable Device memory,
and refer to both memory types as Shareable Device memory.
For Device memory regions, the significance of shareability is IMPLEMENTATION DEFINED. However, an example
of a system supporting Shareable and Non-shareable Device memory is an implementation that supports both:
• A local bus for its private peripherals.
• System peripherals implemented on the main shared system bus.
Such a system might have more predictable access times for local peripherals such as watchdog timers or interrupt
controllers. In particular, a specific address in a Non-shareable Device memory region might access a different
physical peripheral for each processor.
ARM deprecates the marking of Device memory with a shareability attribute other than Outer Shareable or
Shareable. This means ARM strongly recommends that Device memory is never assigned a shareability attribute of
Non-shareable or Inner Shareable.
Device and Strongly-ordered memory shareability, Large Physical Address Extension

In an implementation that includes the Large Physical Address Extension, the Long-descriptor translation table
format does not distinguish between Shareable and Non-shareable Device memory.
In an implementation that includes the Large Physical Address Extension and is using the Short-descriptor
translation table format:
• An address-based cache maintenance operation for an address in a region with the Strongly-ordered or
Device memory type applies to all processors in the same Outer Shareable domain, regardless of any
shareability attributes applied to the region.
• Device memory transactions to a single peripheral must not be reordered, regardless of any shareability
attributes that are applied to the corresponding Device memory region.
Any single peripheral has an IMPLEMENTATION DEFINED size of not less than 1KB.
A3.5.7 Memory access restrictions

The following restrictions apply to memory accesses:
• For accesses to any two bytes, p and q, that are generated by the same instruction:
— The bytes p and q must have the same memory type and shareability attributes, otherwise the results
are UNPREDICTABLE. For example, an LDC, LDM, LDRD, STC, STM, STRD, or unaligned load or store that spans
a boundary between Normal and Device memory is UNPREDICTABLE.
— Except for possible differences in the cache allocation hints, ARM deprecates having different
cacheability attributes for the bytes p and q.
• Unaligned data access on page A3-106 identifies the instructions that can make an unaligned memory
access, and the required configuration setting. If such an access is to Device or Strongly-ordered memory
then:
— If the implementation does not include the Virtualization Extensions, the effect is UNPREDICTABLE.
— If the implementation includes the Virtualization Extensions, the access generates an Alignment fault.
• The accesses of an instruction that causes multiple accesses to Device or Strongly-ordered memory must not
cross a 4KB address boundary, otherwise the effect is UNPREDICTABLE. For this reason, it is important that
an access to a volatile memory device is not made using a single instruction that crosses a 4KB address
boundary.
Note
This situation is UNPREDICTABLE even if the cause of the accesses is an unaligned access to Device or
Strongly-ordered memory in an implementation that includes the Virtualization Extensions.
ARM expects this restriction to impose constraints on the placing of volatile memory devices in the memory
map of a system, rather than expecting a compiler to be aware of the alignment of memory accesses.
• For any instruction that generates accesses to Device or Strongly-ordered memory, implementations must not
change the sequence of accesses specified by the pseudocode of the instruction. This includes not changing:
— How many accesses there are.
— The time order of the accesses at any particular memory-mapped peripheral.
— The data size and other properties of each access.
In addition, processor implementations expect any attached memory system to be able to identify the memory
type of accesses, and to obey similar restrictions with regard to the number, time order, data sizes and other
properties of the accesses.
Exceptions to this rule are:
— An implementation of a processor can break this rule, provided that the original number, time order,
and other details of the accesses can be reconstructed from the information it supplies to the memory
system. In addition, the implementation must place a requirement on attached memory systems to do
this reconstruction when the accesses are to Device or Strongly-ordered memory.
For example, an implementation with a 64-bit bus might pair the word loads generated by an LDM into
64-bit accesses. This is because the instruction semantics ensure that the 64-bit access is always a word
load from the lower address followed by a word load from the higher address. However the
implementation must permit the memory systems to unpack the two word loads when the access is to
Device or Strongly-ordered memory.
— An Advanced SIMD element or structure load instruction can access bytes in Device or
Strongly-ordered memory that are not explicitly accessed by the instruction, provided the bytes
accessed are within a 16-byte window, aligned to 16-bytes, that contains at least one byte that is
explicitly accessed by the instruction.
— There is no requirement for the memory system to be able to identify the size of the elements accessed
by an Advanced SIMD element or structure load/store instruction.
• In a PMSA implementation, and in a VMSA implementation when any associated MMU is enabled, any
multi-access instruction that loads or stores the PC must access only Normal memory. If the instruction
accesses Device or Strongly-ordered memory the result is UNPREDICTABLE.
• Any instruction fetch must access only Normal memory. If it accesses Device or Strongly-ordered memory,
the result is UNPREDICTABLE.
• If a single physical memory location has more than one set of attributes assigned to it, ARM strongly
recommends that software ensures that the sets of attributes are identical. For more information see
Mismatched memory attributes.
An example of where multiple sets of attributes might be assigned to the same physical memory location is
the use of aliases in a virtual to physical address mapping.
Mismatched memory attributes

A physical memory location is accessed with mismatched attributes if all accesses to the location do not use a
common definition of all of the following attributes of that location:
• Memory type, Strongly-ordered, Device, or Normal.
• Shareability.
• Cacheability, for both the inner and outer levels of cache, but excluding any cache allocation hints.
The following rules apply when a physical memory location is accessed with mismatched attributes:
1. When a memory location is accessed with mismatched attributes the only software visible effects are one or
more of the following:
• Uniprocessor semantics for reads and writes to that memory location might be lost. This means:
— A read of the memory location by a thread of execution might not return the value most recently
written to that memory location by that thread of execution.
— Multiple writes to the memory location by a thread of execution, that use different memory
attributes, might not be ordered in program order.
• There might be a loss of coherency when multiple threads of execution attempt to access a memory
location.
• There might be a loss of properties derived from the memory type, see rule 2.
• If multiple threads of execution attempt to use Load-Exclusive or Store-Exclusive instructions to
access a location with different memory attributes, the exclusive monitor state becomes UNKNOWN.
2. The loss of properties associated with mismatched memory type attributes refers only to the following
properties of Strongly-ordered or Device memory, that are additional to the properties of Normal memory:
• Prohibition of speculative accesses.
• Preservation of the size of accesses.
• Preservation of the order of accesses.
• The guarantee that the write acknowledgement comes from the endpoint of the access.
If the only memory type mismatch is between Strongly-ordered and Device memory, then the only property
that can be lost is:
• The guarantee that the write acknowledgement comes from the endpoint of the access.
3. If all aliases of a memory location that permit write access to the location assign the same shareability and
cacheability attributes to that location, and all these aliases use a definition of the shareability attribute that
includes all the threads of execution that can access the location, then any thread of execution that reads the
memory location using these shareability and cacheability attributes accesses it coherently, to the extent
required by that common definition of the memory attributes.
4. The possible loss of properties caused by mismatched attributes for a memory location are defined more
precisely if all of the mismatched attributes define the memory location as one of:
• Strongly-ordered memory.
• Device memory.
• Normal Inner Non-cacheable, Outer Non-cacheable memory.
In these cases, the only possible software-visible effects of the mismatched attributes are one or more of:
• Possible loss of properties derived from the memory type when multiple threads of execution attempt
to access the memory location.
• Possible re-ordering of memory transactions to the memory location that use different memory
attributes, potentially leading to a loss of coherency or uniprocessor semantics. Any possible loss of
coherency or uniprocessor semantics can be avoided by inserting DMB barrier instructions between
accesses to the same memory location that might use different attributes.
5. If the mismatched attributes for a memory location all assign the same shareability attribute to the location,
any loss of coherency within a shareability domain can be avoided. To do so, software must use the
techniques that are required for the software management of the coherency of cacheable locations between
threads of execution in different shareability domains. This means:
• If any thread of execution might have written to the location with the write-back attribute, before
writing to the location not using the write-back attribute, a thread of execution must invalidate, or
clean, the location from the caches. This avoids the possibility of overwriting the location with stale
data.
• After writing to the location with the write-back attribute, a thread of execution must clean the location
from the caches, to make the write visible to external memory.
• Before reading the location with a cacheable attribute, a thread of execution must invalidate the
location from the caches, to ensure that any value held in the caches reflects the last value made visible
in external memory.
In all cases:
• Location refers to any byte within the current coherency granule.
• A clean and invalidate operation can be used instead of a clean operation, or instead of an invalidate
operation.
• To ensure coherency, all cache maintenance and memory transactions must be completed, or ordered
by the use of barrier operations.
Note
With software management of coherency, race conditions can cause loss of data. A race condition occurs
when different threads of execution write simultaneously to bytes that are in the same location, and the
(invalidate or clean), write, clean sequence of one thread overlaps the equivalent sequence of another thread.
6. If the mismatched attributes for a location mean that multiple cacheable accesses to the location might be
made with different shareability attributes, then coherency is guaranteed only if each thread of execution that
accesses the location with a cacheable attribute performs a clean and invalidate of the location.
Note
The Note in rule 5, about possible race conditions, also applies to this rule.
ARM strongly recommends that software does not use mismatched attributes for aliases of the same location. An
implementation might not optimize the performance of a system that uses mismatched aliases.
A3.5.8 The effect of the Security Extensions

The Security Extensions can be included as part of an ARMv7-A implementation, with a VMSA. They provide two
distinct 4GByte virtual memory spaces:
• A Secure virtual memory space.
• A Non-secure virtual memory space.
The Secure virtual memory space is accessed by memory accesses in the Secure state, and the Non-secure virtual
memory space is accessed by memory accesses in the Non-secure state.
By providing different virtual memory spaces, the Security Extensions permit memory accesses made from the
Non-secure state to be distinguished from those made from the Secure state.
A3.6 Access rights
A3.6 Access rights

ARMv7 defines additional memory region attributes, that define access permissions that can:
• Restrict data accesses, based on the privilege level of the access. See Privilege level access controls for data
accesses on page A3-140.
• Restrict instruction fetches, based on the privilege level of the process or thread making the fetch. See
Privilege level access controls for instruction accesses on page A3-140.
• On a system that implements the Security Extensions, restrict accesses so that only memory accesses with
the Secure memory attribute are permitted. See Memory region security status on page A3-141.
These attributes are defined:
• In a VMSA implementation, in the MMU, see Memory access control on page B3-1352, Memory region
attributes on page B3-1362, and The effects of disabling MMUs on VMSA behavior on page B3-1312.
• In a PMSA implementation, in the MPU, see Memory access control on page B5-1753 and Memory region
attributes on page B5-1754.
A3.6.1 Processor privilege levels, execution privilege, and access privilege

As introduced in About the Application level programmers’ model on page A2-38, within a security state, the
ARMv7 architecture defines different levels of execution privilege:
• In Secure state, the privilege levels are PL1 and PL0.
• In Non-secure state, the privilege levels are PL2, PL1, and PL0.
PL0 indicates unprivileged execution in the current security state.
The current processor mode determines the execution privilege level, and therefore the execution privilege level can
be described as the processor privilege level.
Every memory access has an access privilege, that is either unprivileged or privileged.
The characteristics of the privilege levels are:
PL0 The privilege level of application software, that executes in User mode. Therefore, software
executed in User mode is described as unprivileged software. This software cannot access some
features of the architecture. In particular, it cannot change many of the configuration settings.
Software executing at PL0 makes only unprivileged memory accesses.
PL1 Software execution in all modes other than User mode and Hyp mode is at PL1. Normally, operating
system software executes at PL1. Software executing at PL1 can access all features of the
architecture, and can change the configuration settings for those features, except for some features
added by the Virtualization Extensions that are only accessible at PL2.
Note
In many implementation models, system software is unaware of the PL2 level of privilege, and of
whether the implementation includes the Virtualization Extensions.
The PL1 modes refers to all the modes other than User mode and Hyp mode.
Software executing at PL1 makes privileged memory accesses by default, but can also make
unprivileged accesses.
PL2 Software executing in Hyp mode executes at PL2.

Software executing at PL2 can perform all of the operations accessible at PL1, and can access some
additional functionality.
Hyp mode is normally used by a hypervisor, that controls, and can switch between, Guest OSs, that
execute at PL1.
A3.6 Access rights
Hyp mode is implemented only as part of the Virtualization Extensions, and only in Non-secure
state. This means that:
• Implementations that do not include the Virtualization Extensions have only two privilege
levels, PL0 and PL1.
• Execution in Secure state has only two privilege levels, PL0 and PL1.
In an implementation that includes the Security Extensions, the execution privilege levels are defined independently
in each security state, and there is no relationship between the Secure and Non-secure privilege levels.
Note
The fact that Non-secure Hyp mode executes at PL2 does not indicate that it is more privileged than the Secure PL1
modes. Secure PL1 modes can change the configuration and control settings for Non-secure operation in all modes,
but Non-secure modes can never change the configuration and control settings for Secure operation.
Memory access permissions can be assigned:

• At PL1, for accesses made at PL1 and at PL0.
• In Non-secure state, at PL2, independently for:
— Non-secure accesses made at PL2.
— Non-secure accesses made at PL1, and at PL0.
A3.6.2 Privilege level access controls for data accesses

The memory access permissions assigned at PL1 can define that a memory region is:
• Not accessible to any accesses.
• Accessible only to accesses at PL1.
• Accessible to accesses at any level of privilege.
In Non-secure state, separate memory access permissions can be assigned at PL2 for:
• Accesses made at PL1 and PL0.
• Accesses made at PL2.
The access privilege level is defined separately for explicit read and explicit write accesses. However, a system that
specifies the memory attributes is not required to support all combinations of memory attributes for read and write
accesses.
A privileged memory access is an access made during execution at PL1 or higher, as a result of a load or store
operation other than LDRT, STRT, LDRBT, STRBT, LDRHT, STRHT, LDRSHT, or LDRSBT.
An unprivileged memory access is an access made as a result of load or store operation performed in one of these
cases:
• When the processor is at PL0.
• When the processor is at PL1, and the access is made as a result of an LDRT, STRT, LDRBT, STRBT, LDRHT, STRHT,
LDRSHT, or LDRSBT instruction.
A Data Abort exception is generated if the processor attempts a data access that the access rights do not permit. For
example, a Data Abort exception is generated if the processor is at PL0 and attempts to access a memory region that
is marked as only accessible to privileged memory accesses.
A3.6.3 Privilege level access controls for instruction accesses

Memory attributes access permissions assigned at PL1 can define that a memory region is:
• Not accessible for execution.
• Not accessible for execution at PL1 Only implementations that include the Large Physical Address Extension
support this attribute.
A3.6 Access rights
• Accessible for execution only at PL1.
• Accessible for execution at any level of privilege.
In Non-secure state, in an implementation that includes the Virtualization Extensions, separate memory access
permissions can be assigned at PL2 for:
• Accesses made at PL1 and PL0.
• Accesses made at PL2.
To define the instruction access rights to a memory region, the memory attributes describe, separately, for the
region:
• Its read access rights. These are equivalent to the read access rights described in Privilege level access
controls for data accesses on page A3-140.
• Whether software can be executed from the region. This is indicated by whether or not an Execute-never
(XN) attribute is assigned to the region.
• For an implementation that includes the Large Physical Address Extension, whether software can be
executed at PL1 from the region. This is indicated by whether or not a Privileged execute-never (PXN)
attribute is assigned to the region.
This means that there is a linkage between the memory attributes that define the accessibility of a region to data
accesses, and those that define whether instructions can be executed from the region. For example, a region that is
accessible for execution only at PL1 or higher:
• Has the memory attribute indicating that it is accessible only to read accesses at PL1 or higher.
• Does not have the Execute-never attribute
• If the implementation includes the Large Physical Address Extension, does not have the Privileged
execute-never attribute.
Any attempt to execute an instruction from a memory location with an applicable execute-never attribute generates
a memory fault.
A3.6.4 Memory region security status

If an implementation includes the Security Extensions, an additional memory attribute determines whether the
memory region is Secure or Non-secure. Such an implementation checks this attribute, to ensure that a region of
memory that the system designates as Secure is not accessed by memory accesses with the Non-secure memory
attribute. For more information, see Memory region attributes on page B3-1362.
A3.7 Virtual and physical addressing
A3.7 Virtual and physical addressing

ARMv7 provides three alternative architectural profiles, ARMv7-A, ARMv7-R and ARMv7-M. Each of the
profiles specifies a different memory system. This manual describes two of these profiles:
ARMv7-A profile
The ARMv7-A memory system incorporates a Memory Management Unit (MMU), controlled by
CP15 registers. The memory system supports virtual addressing, with the MMU performing virtual
to physical address translation, in hardware, as part of program execution.
An ARMv7-A processor that implements the Virtualization Extensions provides two stages of
address translation for processes running at the Application level:
• The operating system defines the mappings from virtual addresses to intermediate physical
addresses (IPAs). When it does this, it believes it is mapping virtual addresses to physical
addresses.
• The hypervisor defines the mappings from IPAs to physical addresses. These translations are
invisible to the operating system.
For more information see About address translation on page B3-1309.
ARMv7-R profile
The ARMv7-R memory system incorporates a Memory Protection Unit (MPU), controlled by CP15
registers. The MPU does not support virtual addressing.
At the Application level, the difference between the ARMv7-A and ARMv7-R memory systems is transparent.
Regardless of which profile is implemented, an application accesses the memory map described in Address space
on page A3-104, and the implemented memory system makes the features described in this chapter available to the
application.
For a system level description of the ARMv7-A and ARMv7-R memory models see:
• Chapter B2 Common Memory System Architecture Features.
• Chapter B3 Virtual Memory System Architecture (VMSA).
• Chapter B5 Protected Memory System Architecture (PMSA).
Note
This manual does not describe the ARMv7-M profile. For details of this profile see the ARMv7-M Architecture
Reference Manual.
A3.8 Memory access order

ARMv7 provides a set of three memory types, Normal, Device, and Strongly-ordered, with well-defined memory
access properties.
The ARMv7 application level view of the memory attributes is described in:
• Memory types and attributes and the memory order model on page A3-123.
• Access rights on page A3-139.
When considering memory access ordering, an important feature of the ARMv7 memory model is the Shareable
memory attribute, that indicates whether a region of memory appears coherent for data accesses made by multiple
observers.
The key issues with the memory order model depend on the target audience:
• For software programmers, considering the model at the Application level, the key factor is that for accesses
to Normal memory barriers are required in some situations where the order of accesses observed by other
observers must be controlled.
• For silicon implementers, considering the model at the system level, the Strongly-ordered and Device
memory attributes place certain restrictions on the system designer in terms of what can be built and when to
indicate completion of an access.
Note
Implementations remain free to choose the mechanisms required to implement the functionality of the
memory model.
More information about the memory order model is given in the following subsections:
• Reads and writes.
• Ordering requirements for memory accesses on page A3-146.
• Memory barriers on page A3-148.
Additional attributes and behaviors relate to the memory system architecture. These features are defined in the
system level section of this manual:
• Virtual memory systems based on an MMU, described in Chapter B3 Virtual Memory System Architecture
(VMSA).
• Protected memory systems based on an MPU, described in Chapter B5 Protected Memory System
Architecture (PMSA).
• Caches, described in Caches and branch predictors on page B2-1264.
Note
In these system level descriptions, some attributes are described in relation to an MMU. In general, these
descriptions can also be applied to an MPU based system.
A3.8.1 Reads and writes

Each memory access is either a read or a write. Explicit memory accesses are the memory accesses required by the
function of an instruction. The following can cause memory accesses that are not explicit:
• Instruction fetches.
• Cache loads and write-backs.
• Translation table walks.
Except where otherwise stated, the memory ordering requirements only apply to explicit memory accesses.
Reads
Reads are defined as memory operations that have the semantics of a load.
The memory accesses of the following instructions are reads:

• LDR, LDRB, LDRH, LDRSB, and LDRSH.
• LDRT, LDRBT, LDRHT, LDRSBT, and LDRSHT.
• LDREX, LDREXB, LDREXD, and LDREXH.
• LDM, LDRD, POP, and RFE.
• LDC, LDC2, VLDM, VLDR, VLD1, VLD2, VLD3, VLD4, and VPOP.
• The return of status values by STREX, STREXB, STREXD, and STREXH.
• SWP and SWPB. These instructions are available only in the ARM instruction set.
• TBB and TBH. These instructions are available only in the Thumb instruction set.
Hardware-accelerated opcode execution by the Jazelle extension can cause a number of reads to occur, according
to the state of the operand stack and the implementation of the Jazelle hardware acceleration.
Writes
Writes are defined as memory operations that have the semantics of a store.
The memory accesses of the following instructions are Writes:

• STR, STRB, and STRH.
• STRT, STRBT, and STRHT.
• STREX, STREXB, STREXD, and STREXH.
• STM, STRD, PUSH, and SRS.
• STC, STC2, VPUSH, VSTM, VSTR, VST1, VST2, VST3, and VST4.
• SWP and SWPB. These instructions are available only in the ARM instruction set.
Hardware-accelerated opcode execution by the Jazelle extension can cause a number of writes to occur, according
to the state of the operand stack and the implementation of the Jazelle hardware acceleration.
Synchronization primitives
Synchronization primitives must ensure correct operation of system semaphores in the memory order model. The
synchronization primitive instructions are defined as those instructions that are executed to ensure memory
synchronization. They are the following instructions:
• LDREX, STREX, LDREXB, STREXB, LDREXD, STREXD, LDREXH, STREXH.
• SWP, SWPB. From ARMv6, ARM deprecates the use of these instructions.
Observability and completion

An observer is an agent in the system that can access memory. For a processor, the following mechanisms must be
treated as independent observers:
• The mechanism that performs reads or writes to memory.
• A mechanism that causes an instruction cache to be filled from memory or that fetches instructions to be
executed directly from memory.
• A mechanism that performs translation table walks.
The set of observers that can observe a memory access is defined by the system.
In the definitions in this subsection, subsequent means whichever of the following is appropriate to the context:
• After the point in time where the location is observed by that observer.
• After the point in time where the location is globally observed.
For all memory:
• A write to a location in memory is said to be observed by an observer when:

— A subsequent read of the location by the same observer will return the value written by the observed
write, or written by a write to that location by any observer that is sequenced in the Coherence order
of the location after the observed write.
— A subsequent write of the location by the same observer will be sequenced in the Coherence order of
the location after the observed write
• A write to a location in memory is said to be globally observed for a shareability domain when:
— A subsequent read of the location by any observer in that shareability domain will return the value
written by the globally observed write, or written by a write to that location by any observer that is
sequenced in the Coherence order of the location after the globally observed write.
— A subsequent write of the location by any observer in that shareability domain will be sequenced in
the Coherence order of the location after the globally observed write
• A read of a location in memory is said to be observed by an observer when a subsequent write to the location
by the same observer will have no effect on the value returned by the read.
• A read of a location in memory is said to be globally observed for a shareability domain when a subsequent
write to the location by any observer in that shareability domain will have no effect on the value returned by
the read.
Additionally, for Strongly-ordered memory:
• A read or write of a memory-mapped location in a peripheral that exhibits side-effects is said to be observed,
and globally observed, only when the read or write:
— Meets the general conditions listed.
— Can begin to affect the state of the memory-mapped peripheral.
— Can trigger all associated side-effects, whether they affect other peripheral devices, processors, or
memory.
Note
This definition is consistent with the memory access having reached the peripheral.
For all memory, the completion rules are defined as:
• A read or write is complete for a shareability domain when all of the following are true:
— The read or write is globally observed for that shareability domain.
— Any translation table walks associated with the read or write are complete for that shareability domain.
• A translation table walk is complete for a shareability domain when the memory accesses associated with the
translation table walk are globally observed for that shareability domain, and the TLB is updated.
• A cache, branch predictor, or TLB maintenance operation is complete for a shareability domain when the
effects of the operation are globally observed for that shareability domain, and any translation table walks
that arise from the operation are complete for that shareability domain.
The completion of any cache, branch predictor, or TLB maintenance operation includes its completion on all
processors that are affected by both the operation and the DSB operation that is required to guarantee
visibility of the maintenance operation.
Completion of side-effects of accesses to Strongly-ordered and Device memory
The completion of a memory access to Strongly-ordered or Device memory is not guaranteed to be sufficient to
determine that the side-effects of the memory access are visible to all observers. The mechanism that ensures the
visibility of side-effects of a memory access is IMPLEMENTATION DEFINED.
A3.8.2 Ordering requirements for memory accesses

ARMv7 and ARMv6 define access restrictions in the permitted ordering of memory accesses. These restrictions
depend on the memory attributes of the accesses involved.
Two terms used in describing the memory access ordering requirements are:
Address dependency
An address dependency exists when the value returned by a read access is used for the computation
of the virtual address of a subsequent read or write access. An address dependency exists even if the
value read by the first read access does not change the virtual address of the second read or write
access. This might be the case if the value returned is masked off before it is used, or if it has no
effect on the predicted address value for the second access.
Control dependency
A control dependency exists when the data value returned by a read access determines the condition
flags, and the values of the flags are used in the condition code checking that determines the address
of a subsequent read access. This address determination might be through conditional execution, or
through the evaluation of a branch.
Figure A3-5 shows the memory ordering between two explicit accesses A1 and A2, where A1 occurs before A2 in
program order. In the figure, an access refers to a read or a write access to the specified memory type. For example,
Normal access refers to a read or write access to Normal memory. The symbols used in the figure are as follows:
< Accesses must arrive at any particular memory-mapped peripheral or block of memory in program
order, that is, A1 must arrive before A2. There are no ordering restrictions about when accesses
arrive at different peripherals or blocks of memory, provided that accesses follow the general
ordering rules given in this section.
- Accesses can arrive at any memory-mapped peripheral or block of memory in any order, provided
that the accesses follow the general ordering rules given in this section.
The size of a memory mapped peripheral, or a block of memory, is IMPLEMENTATION DEFINED, but is not smaller
than 1KByte.
Note
This implies that the maximum memory-mapped peripheral size for which the architecture guarantees order for all
implementations is 1KB.
A2 Normal access Device access ‡ Strongly-ordered access ‡

A1
Normal access - - -
Device access ‡ - < <
Strongly-ordered access ‡ - < <
‡ The ordering requirements for Device and Strongly-ordered accesses are identical.
Figure A3-5 Memory ordering restrictions
There are no ordering requirements for implicit accesses to any type of memory.
The following additional restrictions apply to the ordering of all memory accesses:
• For all accesses from a single observer, the requirements of uniprocessor semantics must be maintained, for
example:
— Respecting dependencies between instructions in a single processor.
— Coherency.
• If there is an address dependency then the two memory accesses are observed in program order by any
observer in the common shareability domain of the two accesses.
This ordering restriction does not apply if there is only a control dependency between the two read accesses.
If there is both an address dependency and a control dependency between two read accesses the ordering
requirements of the address dependency apply.
• If the value returned by a read access is used as data written by a subsequent write access, then the two
memory accesses are observed in program order by any observer in the common shareability domain of the
two accesses.
• The only stores by an observer that can be observed by another observer are those stores that have been
Architecturally executed. Speculative writes by an observer cannot be observed by another observer. For the
purposes of this requirement, speculative writes are all of:
— Writes generated by store instructions that appear in the Execution stream after a branch that is not
architecturally resolved.
— Writes generated by store instructions that appear in the Execution stream after an instruction where a
synchronous exception condition has not been architecturally resolved.
— Writes generated by conditional store instructions for which the conditions for the instruction have not
been architecturally resolved.
— Writes generated by store instructions for which the data being written comes from a register that has
not been architecturally committed.
• It is impossible for an observer in the shareability domain of a memory location to observe two reads to the
same memory location performed by the same observer in an order that would not occur in a sequential
execution of a program.
• For an implementation that does not include the Multiprocessing Extensions, it is IMPLEMENTATION DEFINED
whether all writes complete in a finite period of time, or whether some writes require the execution of a DSB
instruction to guarantee their completion.
• For an implementation that includes the Multiprocessing Extensions, all writes complete in a finite period of
time.
Note
This applies for all writes, including repeated writes to the same location.
Program order for instruction execution

The program order of instruction execution is the order of the instructions in a simple sequential execution of the
program.
Explicit memory accesses in an execution can be either:

Strictly Ordered
Denoted by <. Must occur strictly in order.
Ordered Denoted by <=. Can occur either in order or simultaneously.
Load/store multiple instructions, such as LDM, LDRD, STM, and STRD, generate multiple word accesses, each of which is
a separate access for the purpose of determining ordering.
The rules for determining program order for two accesses A1 and A2 are:
If A1 and A2 are generated by two different instructions:

• A1 < A2 if the instruction that generates A1 occurs before the instruction that generates A2 in program order.
• A2 < A1 if the instruction that generates A2 occurs before the instruction that generates A1 in program order.
If A1 and A2 are generated by the same instruction:
• If A1 and A2 are the load and store generated by a SWP or SWPB instruction:
— A1 < A2 if A1 is the load and A2 is the store.
— A2 < A1 if A2 is the load and A1 is the store.
• In these descriptions:
— An LDM-class instruction is any form of LDM, LDMDA, LDMDB, or LDMIB, or a POP instruction that operates
on more than one register.
— An LDC-class instruction is an LDC, VLDM, VLDR, or VPOP instruction.
— An STM-class instruction is any form of STM, STMDA, STMDB, or STMIB, or a PUSH instruction that operates
on more than one register.
— An STC-class instruction is an STC, VSTM, VSTR, or VPUSH instruction.
If A1 and A2 are two word loads generated by an LDC-class or LDM-class instruction, or two word stores
generated by an STC-class or STM-class instruction, excluding LDM-class and STM-class instructions with
a register list that includes the PC:
— A1 <= A2 if the address of A1 is less than the address of A2.
— A2 <= A1 if the address of A2 is less than the address of A1.
If A1 and A2 are two word loads generated by an LDM-class instruction with a register list that includes the
PC or two word stores generated by an STM-class instruction with a register list that includes the PC, the
program order of the memory accesses is not defined.
• If A1 and A2 are two word loads generated by an LDRD instruction or two word stores generated by an STRD
instruction, the program order of the memory accesses is not defined.
• If A1 and A2 are load or store accesses generated by Advanced SIMD element or structure load/store
instructions, the program order of the memory accesses is not defined.
• For any instruction or operation not explicitly mentioned in this section, if the single-copy atomicity rules
described in Single-copy atomicity on page A3-125 mean the operation becomes a sequence of accesses, then
the time-ordering of those accesses is not defined.
A3.8.3 Memory barriers

Memory barrier is the general term applied to an instruction, or sequence of instructions, that forces synchronization
events by a processor with respect to retiring load/store instructions. The ARM architecture defines a number of
memory barriers that provide a range of functionality, including:
• Ordering of load/store instructions.
• Completion of load/store instructions.
• Context synchronization.
ARMv7 and ARMv6 require three explicit memory barriers to support the memory order model described in this
chapter. In ARMv7 the memory barriers are provided as instructions that are available in the ARM and Thumb
instruction sets, and in ARMv6 the memory barriers are performed by CP15 register writes. The three memory
barriers are:
• Data Memory Barrier, see Data Memory Barrier (DMB) on page A3-149.
• Data Synchronization Barrier, see Data Synchronization Barrier (DSB) on page A3-150.
• Instruction Synchronization Barrier, see Instruction Synchronization Barrier (ISB) on page A3-150.
Note
Depending on the required synchronization, a program might use memory barriers on their own, or it might use them
in conjunction with cache and memory management maintenance operations that are only available when software
execution is at PL1 or higher.
The DMB and DSB memory barriers affect reads and writes to the memory system generated by load/store
instructions and data or unified cache maintenance operations being executed by the processor. Instruction fetches
or accesses caused by a hardware translation table access are not explicit accesses.
Data Memory Barrier (DMB)

The DMB instruction is a data memory barrier. The processor that executes the DMB instruction is referred to as the
executing processor, Pe. The DMB instruction takes the required shareability domain and required access types as
arguments, see Shareability and access limitations on the data barrier operations on page A3-150. If the required
shareability is Full system then the operation applies to all observers within the system.
A DMB creates two groups of memory accesses, Group A and Group B:
Group A Contains:
• All explicit memory accesses of the required access types from observers in the same
required shareability domain as Pe that are observed by Pe before the DMB instruction. These
accesses include any accesses of the required access types performed by Pe.
• All loads of required access types from an observer Px in the same required shareability
domain as Pe that have been observed by any given different observer, Py, in the same
required shareability domain as Pe before Py has performed a memory access that is a
member of Group A.
Group B Contains:
• All explicit memory accesses of the required access types by Pe that occur in program order
after the DMB instruction.
• All explicit memory accesses of the required access types by any given observer Px in the
same required shareability domain as Pe that can only occur after a load by Px has returned
the result of a store that is a member of Group B.
Any observer with the same required shareability domain as Pe observes all members of Group A before it observes
any member of Group B to the extent that those group members are required to be observed, as determined by the
shareability and cacheability of the memory locations accessed by the group members.
Where members of Group A and members of Group B access the same memory-mapped peripheral of arbitrary
system-defined size, then members of Group A that are accessing Strongly-ordered, Device, or Normal
Non-cacheable memory arrive at that peripheral before members of Group B that are accessing Strongly-ordered,
Device, or Normal Non-cacheable memory. If the memory accesses are not to a peripheral, then there are no
restrictions from this paragraph.
Note
• Where the members of Group A and Group B that must be ordered are from the same processor, a DMB NSH is
sufficient for this guarantee.
• A memory access might be in neither Group A nor Group B. The DMB does not affect the order of
observation of such a memory access.
• The second part of the definition of Group A is recursive. Ultimately, membership of Group A derives from
the observation by Py of a load before Py performs an access that is a member of Group A as a result of the
first part of the definition of Group A.
• The second part of the definition of Group B is recursive. Ultimately, membership of Group B derives from
the observation by any observer of an access by Pe that is a member of Group B as a result of the first part of
the definition of Group B.
DMB only affects memory accesses and data and unified cache maintenance operations, see Cache and branch
predictor maintenance operations on page B2-1276. It has no effect on the ordering of any other instructions
executing on the processor.
For details of the DMB instruction in the Thumb and ARM instruction sets, see DMB on page A8-379.
Data Synchronization Barrier (DSB)

The DSB instruction is a special memory barrier, that synchronizes the execution stream with memory accesses. The
DSB instruction takes the required shareability domain and required access types as arguments, see Shareability and
access limitations on the data barrier operations. If the required shareability is Full system, then the operation
applies to all observers within the system.
A DSB behaves as a DMB with the same arguments, and also has the additional properties defined here.
A DSB completes when:
• All explicit memory accesses that are observed by Pe before the DSB is executed, are of the required access
types, and are from observers in the same required shareability domain as Pe, are complete for the set of
observers in the required shareability domain.
• If the required accesses types of the DSB is reads and writes, all cache and branch predictor maintenance
operations issued by Pe before the DSB are complete for the required shareability domain.
• If the required accesses types of the DSB is reads and writes, all TLB maintenance operations issued by Pe
before the DSB are complete for the required shareability domain.
In addition, no instruction that appears in program order after the DSB instruction can execute until the DSB completes.
For details of the DSB instruction in the Thumb and ARM instruction sets, see DSB on page A8-381.
Note
Historically, this operation was referred to as Drain Write Buffer or Data Write Barrier (DWB). From ARMv6, these
names and the use of DWB were deprecated in favor of the new Data Synchronization Barrier name and DSB
abbreviation. DSB better reflects the functionality provided from ARMv6, because DSB is architecturally defined
to include all cache, TLB and branch prediction maintenance operations as well as explicit memory operations.
Instruction Synchronization Barrier (ISB)

An ISB instruction flushes the pipeline in the processor, so that all instructions that come after the ISB instruction in
program order are fetched from cache or memory only after the ISB instruction has completed. Using an ISB ensures
that the effects of context-changing operations executed before the ISB are visible to the instructions fetched after
the ISB instruction. Examples of context-changing operations that require the insertion of an ISB instruction to ensure
the effects of the operation are visible to instructions fetched after the ISB instruction are:
• Completed cache, TLB, and branch predictor maintenance operations.
• Changes to system control registers.
Any context-changing operations appearing in program order after the ISB instruction only take effect after the ISB
has been executed.
For more information about the ISB instruction in the Thumb and ARM instruction sets, see ISB on page A8-390.
Shareability and access limitations on the data barrier operations

The DMB and DSB instructions can each take an optional limitation argument that specifies:
• The shareability domain over which the instruction must operate, as one of:
— Full system.
— Outer Shareable.
— Inner Shareable.
— Non-shareable.
• The accesses for which the instruction operates, as one of:
— Read and write accesses.
— Write accesses only.
By default, each instruction operates for read and write accesses, over the full system, and whether an
implementation supports any other options is IMPLEMENTATION DEFINED. See the instruction descriptions for more
information about these arguments.
Note
ISB also supports an optional limitation argument, but supports only one value for that argument, that corresponds
to full system operation.
In an implementation that includes the Virtualization Extensions, and supports shareability limitations on the data
barrier operations, the HCR.BSU field can upgrade the required shareability of the operation for an instruction that
is executed in a Non-secure PL1 or PL0 mode. Table A3-6 shows the encoding of this field:
Table A3-6 HCR.BSU encoding
HCR.BSU Minimum shareability of instruction
00 No effect, shareability is as specified by the instruction
01 Inner Shareable
10 Outer Shareable
11 Full system
For an instruction executed in a Non-secure PL1 or PL0 mode, Table A3-7 shows how HCR.BSU upgrades the
shareability specified by the argument of the DMB or DSB instruction:
Table A3-7 Upgrading the shareability of data barrier operations
Shareability from DMB or DSB argument HCR.BSU Resultant shareability
Full system Any Full system
Outer Shareable 00, 01, or 10 Outer Shareable
11, Full system Full system
Inner Shareable 00 or 01 Inner Shareable
10, Outer Shareable Outer Shareable
Non-shareable 00, No effect Non-shareable
01, Inner Shareable Inner Shareable
10, Outer Shareable Outer Shareable
Pseudocode details of memory barriers

The following types define the required shareability domains and required access types used as arguments for DMB
and DSB instructions:
enumeration MBReqDomain {MBReqDomain_FullSystem,

MBReqDomain_OuterShareable,
MBReqDomain_InnerShareable,
MBReqDomain_Nonshareable};
enumeration MBReqTypes {MBReqTypes_All, MBReqTypes_Writes};
The following procedures perform the memory barriers:
DataMemoryBarrier(MBReqDomain domain, MBReqTypes types)
DataSynchronizationBarrier(MBReqDomain domain, MBReqTypes types)
InstructionSynchronizationBarrier()
A3.9 Caches and memory hierarchy

The implementation of a memory system depends heavily on the microarchitecture and therefore the details of the
system are IMPLEMENTATION DEFINED. ARMv7 defines the application level interface to the memory system, and
supports a hierarchical memory system with multiple levels of cache. This section provides an application level
view of this system. It contains the subsections:
• Introduction to caches.
• Memory hierarchy.
• Implication of caches for the application programmer on page A3-154.
• Preloading caches on page A3-155.
A3.9.1 Introduction to caches

A cache is a block of high-speed memory that contains a number of entries, each consisting of:
• Main memory address information, commonly called a tag.
• The associated data.
Caches increase the average speed of a memory access. Cache operation takes account of two principles of locality:
Spatial locality
An access to one location is likely to be followed by accesses to adjacent locations. Examples of this
principle are:
• Sequential instruction execution.
• Accessing a data structure.
Temporal locality
An access to an area of memory is likely to be repeated in a short time period. An example of this
principle is the execution of a software loop.
To minimize the quantity of control information stored, the spatial locality property groups several locations
together under the same tag. This logical block is commonly called a cache line. When data is loaded into a cache,
access times for subsequent loads and stores are reduced, resulting in overall performance benefits. An access to
information already in a cache is called a cache hit, and other accesses are called cache misses.
Normally, caches are self-managing, with the updates occurring automatically. Whenever the processor wants to
access a cacheable location, the cache is checked. If the access is a cache hit, the access occurs in the cache,
otherwise a location is allocated and the cache line loaded from memory. Different cache topologies and access
policies are possible, however, they must comply with the memory coherency model of the underlying architecture.
Caches introduce a number of potential problems, mainly because of:

• Memory accesses occurring at times other than when the programmer would otherwise expect them.
• There being multiple physical locations where a data item can be held.
A3.9.2 Memory hierarchy

Memory close to a processor has very low latency, but is limited in size and expensive to implement. Further from
the processor it is easier to implement larger blocks of memory but these have increased latency. To optimize overall
performance, an ARMv7 memory system can include multiple levels of cache in a hierarchical memory system.
Figure A3-6 on page A3-154 shows such a system, in an ARMv7-A implementation of a VMSA, supporting virtual
addressing.
Virtual
address Address Physical address
translation
CP15 configuration
and control
Level 1 Level 2 Level 3

Processor
Cache Cache
R15 Instruction DRAM
fetch SRAM
Load Flash Level 4
R0 ROM for example,
Store
CF card, disk
Figure A3-6 Multiple levels of cache in a memory hierarchy
Note
In this manual, in a hierarchical memory system, Level 1 refers to the level closest to the processor, as shown in
Figure A3-6.
A3.9.3 Implication of caches for the application programmer

In normal operation, the caches are largely invisible to the application programmer. However they can become
visible when there is a breakdown in the coherency of the caches. Such a breakdown can occur:
• When memory locations are updated by other agents in the system.
• When memory updates made from the application software must be made visible to other agents in the
system.
For example:
• In a system with a DMA controller that reads memory locations that are held in the data cache of a processor,
a breakdown of coherency occurs when the processor has written new data in the data cache, but the DMA
controller reads the old data held in memory.
• In a Harvard architecture of caches, where there are separate instruction and data caches, a breakdown of
coherency occurs when new instruction data has been written into the data cache, but the instruction cache
still contains the old instruction data.
Data coherency issues

Software can ensure the data coherency of caches in the following ways:
• By not using the caches in situations where coherency issues can arise. This can be achieved by:
— Using Non-cacheable or, in some cases, Write-Through Cacheable memory.
— Not enabling caches in the system.
• By using cache maintenance operations to manage the coherency issues in software, see About ARMv7 cache
and branch predictor maintenance functionality on page B2-1272. Many of these operations are only
available to system software.
• By using hardware coherency mechanisms to ensure the coherency of data accesses to memory for cacheable
locations by observers within the different shareability domains, see Non-shareable Normal memory on
page A3-129 and Shareable, Inner Shareable, and Outer Shareable Normal memory on page A3-130.
The performance of these hardware coherency mechanisms is highly implementation-specific. In some

implementations, the mechanism suppresses the ability to cache shareable locations. In other
implementations, cache coherency hardware can hold data in caches while managing coherency between
observers within the shareability domains.
Instruction coherency issues

How far ahead of the current point of execution instructions are fetched from is IMPLEMENTATION DEFINED. Such
prefetching can be either a fixed or a dynamically varying number of instructions, and can follow any or all possible
future execution paths. For all types of memory:
• The processor might have fetched the instructions from memory at any time since the last context
synchronization operation on that processor.
• Any instructions fetched in this way might be executed multiple times, if this is required by the execution of
the program, without being refetched from memory.
Note
See Context synchronization operation for the definition of this term.
In addition, the ARM architecture does not require the hardware to ensure coherency between instruction caches
and memory, even for regions of memory with Shareable attributes. This means that for cacheable regions of
memory, an instruction cache can hold instructions that were fetched from memory before the context
synchronization operation.
If software requires coherency between instruction execution and memory, it must manage this coherency using the
ISB and DSB memory barriers and cache maintenance operations, see Ordering of cache and branch predictor
maintenance operations on page B2-1287. Many of these operations are only available to system software.
A3.9.4 Preloading caches

The ARM architecture provides memory system hints PLD (Preload Data), PLDW (Preload Data with intent to write),
and PLI (Preload Instruction) to permit software to communicate the expected use of memory locations to the
hardware. The memory system can respond by taking actions that are expected to speed up the memory accesses if
and when they do occur. The effect of these memory system hints is IMPLEMENTATION DEFINED. Typically,
implementations use this information to bring the data or instruction locations into caches that have faster access
times than normal memory.
The Preload instructions are hints, and so implementations can treat them as NOPs without affecting the functional
behavior of the device. The instructions do not generate synchronous Data Abort exceptions, but the memory system
operations might, under exceptional circumstances, generate asynchronous aborts. For more information, see Data
Abort exception on page B1-1214.
For more information about the operation of these instructions, see Behavior of Preload Data (PLD, PLDW) and
Preload Instruction (PLI) with caches on page B2-1267.
Hardware implementations can provide other implementation-specific mechanisms to fetch memory locations in
the cache. These must comply with the general cache behavior described in Cache behavior on page B2-1265.
Chapter A4
The Instruction Sets
This chapter describes the ARM and Thumb instruction sets. It contains the following sections:
• About the instruction sets on page A4-158.
• Unified Assembler Language on page A4-160.
• Branch instructions on page A4-162.
• Data-processing instructions on page A4-163.
• Status register access instructions on page A4-172.
• Load/store instructions on page A4-173.
• Load/store multiple instructions on page A4-175.
• Miscellaneous instructions on page A4-176.
• Exception-generating and exception-handling instructions on page A4-177.
• Coprocessor instructions on page A4-178.
• Advanced SIMD and Floating-point load/store instructions on page A4-179.
• Advanced SIMD and Floating-point register transfer instructions on page A4-181.
• Advanced SIMD data-processing instructions on page A4-182.
• Floating-point data-processing instructions on page A4-189.
A4 The Instruction Sets
A4.1 About the instruction sets

ARMv7 contains two main instruction sets, the ARM and Thumb instruction sets. Much of the functionality
available is identical in the two instruction sets. This chapter describes the functionality available in the instruction
sets, and the Unified Assembler Language (UAL) that can be assembled to either instruction set.
The two instruction sets differ in how instructions are encoded:
• Thumb instructions are either 16-bit or 32-bit, and are aligned on a two-byte boundary. 16-bit and 32-bit
instructions can be intermixed freely. Many common operations are most efficiently executed using 16-bit
instructions. However:
— Most 16-bit instructions can only access the first eight of the ARM core registers, R0-R7. These are
called the low registers. A small number of 16-bit instructions can also access the high registers,
R8-R15.
— Many operations that would require two or more 16-bit instructions can be more efficiently executed
with a single 32-bit instruction.
— All 32-bit instructions can access all of the ARM core registers, R0-R15.
• ARM instructions are always 32-bit, and are aligned on a four-byte boundary.
The ARM and Thumb instruction sets can interwork freely, that is, different procedures can be compiled or
assembled to different instruction sets, and still be able to call each other efficiently.
ThumbEE is a variant of the Thumb instruction set that is designed as a target for dynamically generated code.
However, it cannot interwork freely with the ARM and Thumb instruction sets.
In an implementation that includes a non-trivial Jazelle Extension, the processor can execute some Java bytecodes
in hardware. For more information, see Jazelle direct bytecode execution support on page A2-96. The processor
executes Java bytecodes when it is in Jazelle state. However, this execution is outside the scope of this manual.
See:
• Chapter A5 ARM Instruction Set Encoding for encoding details of the ARM instruction set.
• Chapter A6 Thumb Instruction Set Encoding for encoding details of the Thumb instruction set.
• Chapter A8 Instruction Descriptions for detailed descriptions of the instructions.
• Chapter A9 The ThumbEE Instruction Set for encoding details of the ThumbEE instruction set.
A4.1.1 Changing between Thumb state and ARM state

A processor in ARM state executes ARM instructions, and a processor in Thumb state executes Thumb instructions.
A processor in Thumb state can enter ARM state by executing any of the following instructions: BX, BLX, or an LDR
or LDM that loads the PC.
A processor in ARM state can enter Thumb state by executing any of the same instructions.
In ARMv7, a processor in ARM state can also enter Thumb state by executing an ADC, ADD, AND, ASR, BIC, EOR, LSL,
LSR, MOV, MVN, ORR, ROR, RRX, RSB, RSC, SBC, or SUB instruction that has the PC as destination register and does not set the
condition flags.
Note
This permits calls and returns between ARM code written for ARMv4 processors and Thumb code running on
ARMv7 processors to function correctly. ARM recommends that new software uses BX or BLX instructions instead.
In particular, ARM recommends that software uses BX LR to return from a procedure, not MOV PC, LR.
The target instruction set is either encoded directly in the instruction (for the immediate offset version of BLX), or is
held as bit[0] of an interworking address. For details, see the description of the BXWritePC() function in Pseudocode
details of operations on ARM core registers on page A2-46.
Exception entries and returns can also change between ARM and Thumb states. For details see Exception handling
on page B1-1164.
A4.1.2 Conditional execution

In the ARM and Thumb instruction sets, most instructions can be conditionally executed.
In the ARM instruction set, conditional execution means that an instruction only has its normal effect on the
programmers’ model operation, memory and coprocessors if the N, Z, C and V condition flags in the APSR satisfy
a condition specified by the cond field in the instruction encoding. If the flags do not satisfy this condition, the
instruction acts as a NOP, that is, execution advances to the next instruction as normal, including any relevant checks
for exceptions being taken, but has no other effect.
In the Thumb instruction set, different mechanisms control conditional execution:
• For the following Thumb encodings, conditional execution is controlled in a similar way to the ARM
instructions:
— A 16-bit conditional branch instruction encoding, with a branch range of –256 to +254 bytes. Before
ARMv6T2, this was the only mechanism for conditional execution in Thumb code.
— A 32-bit conditional branch instruction encoding, with a branch range of approximately ±1MB.
For more information about these encodings, see B on page A8-332.
• The CBZ and CBNZ instructions, Compare and Branch on Zero, and Compare and Branch on Nonzero, are 16-bit
conditional instructions with a branch range of +4 to +130 bytes. For details see CBNZ, CBZ on page A8-354.
• The 16-bit If-Then instruction makes up to four following instructions conditional, and can make most other
Thumb instructions conditional. For details, see IT on page A8-391. The instructions that are made
conditional by an IT instruction are called its IT block. For any IT block, either:
— All instructions have the same condition.
— Some instructions have one condition, and the other instructions have the inverse condition.
ARM deprecates the conditional execution of any instruction encoding provided by the Advanced SIMD Extension
that is not also provided by the Floating-point (VFP) Extension, and strongly recommends that any such instruction
that can be conditionally executed is specified with the <c> field omitted or set to AL. For more information, see
Conditional execution on page A8-286.
For more information about conditional execution, see Conditional execution on page A8-286.
A4.1.3 Writing to the PC

Writing to the PC on page A2-45 gives an overview of instructions that write to the PC, including the required
behavior of these writes. This information is also given in the appropriate sections of this chapter.
A4.1.4 Permanently UNDEFINED encodings

All versions of the ARM architecture define some encodings as permanently UNDEFINED. That is, permanently
UNDEFINED encodings are defined in the ARM instruction set encodings, and in the 16-bit and 32-bit Thumb
encodings. From issue C.a of this manual, ARM defines an assembler mnemonic for the unconditional forms of
these instructions, see UDF on page A8-759.
A4.2 Unified Assembler Language

This document uses the ARM Unified Assembler Language (UAL). This assembly language syntax provides a
canonical form for all ARM and Thumb instructions.
UAL describes the syntax for the mnemonic and the operands of each instruction. In addition, it assumes that
instructions and data items can be given labels. It does not specify the syntax to be used for labels, nor what
assembler directives and options are available. See your assembler documentation for these details.
Most earlier ARM assembly language mnemonics are still supported as synonyms, as described in the instruction
details.
Note
Most earlier Thumb assembly language mnemonics are not supported. For more information, see Appendix D8
Legacy Instruction Mnemonics.
UAL includes instruction selection rules that specify which instruction encoding is selected when more than one
can provide the required functionality. For example, both 16-bit and 32-bit encodings exist for an ADD R0, R1, R2
instruction. The most common instruction selection rule is that when both a 16-bit encoding and a 32-bit encoding
are available, the 16-bit encoding is selected, to optimize code density.
Syntax options exist to override the normal instruction selection rules and ensure that a particular encoding is
selected. These are useful when disassembling code, to ensure that subsequent assembly produces the original code,
and in some other situations.
A4.2.1 Conditional instructions

For maximum portability of UAL assembly language between the ARM and Thumb instruction sets, ARM
recommends that:
• IT instructions are written before conditional instructions in the correct way for the Thumb instruction set.
• When assembling to the ARM instruction set, assemblers check that any IT instructions are correct, but do
not generate any code for them.
Although other Thumb instructions are unconditional, all instructions that are made conditional by an IT instruction
must be written with a condition. These conditions must match the conditions imposed by the IT instruction. For
example, an ITTEE EQ instruction imposes the EQ condition on the first two following instructions, and the NE
condition on the next two. Those four instructions must be written with EQ, EQ, NE and NE conditions respectively.
Some instructions cannot be made conditional by an IT instruction. Some instructions can be conditional if they are
the last instruction in the IT block, but not otherwise.
The branch instruction encodings that include a condition code field cannot be made conditional by an IT
instruction. If the assembler syntax indicates a conditional branch that correctly matches a preceding IT instruction,
it is assembled using a branch instruction encoding that does not include a condition code field.
A4.2.2 Use of labels in UAL instruction syntax

The UAL syntax for some instructions includes the label of an instruction or a literal data item that is at a fixed offset
from the instruction being specified. The assembler must:
1. Calculate the PC or Align(PC, 4) value of the instruction. The PC value of an instruction is its address plus 4
for a Thumb instruction, or plus 8 for an ARM instruction. The Align(PC, 4) value of an instruction is its PC
value ANDed with 0xFFFFFFFC to force it to be word-aligned. There is no difference between the PC and
Align(PC, 4) values for an ARM instruction, but there can be for a Thumb instruction.
2. Calculate the offset from the PC or Align(PC, 4) value of the instruction to the address of the labeled
instruction or literal data item.
3. Assemble a PC-relative encoding of the instruction, that is, one that reads its PC or Align(PC, 4) value and
adds the calculated offset to form the required address.
Note
For instructions that can encode a subtraction operation, if the instruction cannot encode the calculated offset
but can encode minus the calculated offset, the instruction encoding specifies a subtraction of minus the
calculated offset.
The syntax of the following instructions includes a label:
• B, BL, and BLX (immediate). The assembler syntax for these instructions always specifies the label of the
instruction that they branch to. Their encodings specify a sign-extended immediate offset that is added to the
PC value of the instruction to form the target address of the branch.
• CBNZ and CBZ. The assembler syntax for these instructions always specifies the label of the instruction that they
branch to. Their encodings specify a zero-extended immediate offset that is added to the PC value of the
instruction to form the target address of the branch. They do not support backward branches.
• LDC, LDC2, LDR, LDRB, LDRD, LDRH, LDRSB, LDRSH, PLD, PLDW, PLI, and VLDR. The normal assembler syntax of these
load instructions can specify the label of a literal data item that is to be loaded. The encodings of these
instructions specify a zero-extended immediate offset that is either added to or subtracted from the
Align(PC, 4) value of the instruction to form the address of the data item. A few such encodings perform a
fixed addition or a fixed subtraction and must only be used when that operation is required, but most contain
a bit that specifies whether the offset is to be added or subtracted.
When the assembler calculates an offset of 0 for the normal syntax of these instructions, it must assemble an
encoding that adds 0 to the Align(PC, 4) value of the instruction. Encodings that subtract 0 from the Align(PC,
4) value cannot be specified by the normal syntax.
There is an alternative syntax for these instructions that specifies the addition or subtraction and the
immediate offset explicitly. In this syntax, the label is replaced by [PC, #+/-<imm>], where:
+/- Is + or omitted to specify that the immediate offset is to be added to the Align(PC, 4) value, or -
if it is to be subtracted.
<imm> Is the immediate offset.
This alternative syntax makes it possible to assemble the encodings that subtract 0 from the Align(PC, 4)
value, and to disassemble them to a syntax that can be re-assembled correctly.
• ADR. The normal assembler syntax for this instruction can specify the label of an instruction or literal data item
whose address is to be calculated. Its encoding specifies a zero-extended immediate offset that is either added
to or subtracted from the Align(PC, 4) value of the instruction to form the address of the data item, and some
opcode bits that determine whether it is an addition or subtraction.
When the assembler calculates an offset of 0 for the normal syntax of this instruction, it must assemble the
encoding that adds 0 to the Align(PC, 4) value of the instruction. The encoding that subtracts 0 from the
Align(PC, 4) value cannot be specified by the normal syntax.
There is an alternative syntax for this instruction that specifies the addition or subtraction and the immediate
value explicitly, by writing them as additions ADD <Rd>, PC, #<imm> or subtractions SUB <Rd>, PC, #<imm>.
This alternative syntax makes it possible to assemble the encoding that subtracts 0 from the Align(PC, 4)
value, and to disassemble it to a syntax that can be re-assembled correctly.
Note
ARM recommends that where possible, software avoids using:
• The alternative syntax for the ADR, LDC, LDC2, LDR, LDRB, LDRD, LDRH, LDRSB, LDRSH, PLD, PLI, PLDW, and VLDR
instructions.
• The encodings of these instructions that subtract 0 from the Align(PC, 4) value.
A4.3 Branch instructions
A4.3 Branch instructions

Table A4-1 summarizes the branch instructions in the ARM and Thumb instruction sets. In addition to providing
for changes in the flow of execution, some branch instructions can change instruction set.
Table A4-1 Branch instructions
Instruction See Range, Thumb Range, ARM
Branch to target address B on page A8-332 ±16MB ±32MB
Compare and Branch on Nonzero, CBNZ, CBZ on page A8-354 0-126 bytes a
Compare and Branch on Zero
Call a subroutine BL, BLX (immediate) on ±16MB ±32MB

Call a subroutine, change instruction set b page A8-346 ±16MB ±32MB
Call a subroutine, optionally change instruction set BLX (register) on page A8-348 Any Any
Branch to target address, change instruction set BX on page A8-350 Any Any
Change to Jazelle state BXJ on page A8-352 - -
Table Branch (byte offsets) TBB, TBH on page A8-737 0-510 bytes a
Table Branch (halfword offsets) 0-131070 bytes
a. These instructions do not exist in the ARM instruction set.

b. The range is determined by the instruction set of the BLX instruction, not of the instruction it branches to.
Branches to loaded and calculated addresses can be performed by LDR, LDM and data-processing instructions. For
details, see Load/store instructions on page A4-173, Load/store multiple instructions on page A4-175, Standard
data-processing instructions on page A4-163, and Shift instructions on page A4-165.
In addition to the branch instructions shown in Table A4-1:
• In the ARM instruction set, a data-processing instruction that targets the PC behaves as a branch instruction.
For more information, see Data-processing instructions on page A4-163.
• In the ARM and Thumb instruction sets, a load instruction that targets the PC behaves as a branch instruction.
For more information, see Load/store instructions on page A4-173.
A4.4 Data-processing instructions

Core data-processing instructions belong to one of the following groups:
• Standard data-processing instructions.
These instructions perform basic data-processing operations, and share a common format with some
variations.
• Shift instructions on page A4-165.
• Multiply instructions on page A4-165.
• Saturating instructions on page A4-167.
• Saturating addition and subtraction instructions on page A4-167.
• Packing and unpacking instructions on page A4-168.
• Parallel addition and subtraction instructions on page A4-169.
• Divide instructions on page A4-170.
• Miscellaneous data-processing instructions on page A4-171.
For extension data-processing instructions, see Advanced SIMD data-processing instructions on page A4-182 and
Floating-point data-processing instructions on page A4-189.
A4.4.1 Standard data-processing instructions

These instructions generally have a destination register Rd, a first operand register Rn, and a second operand. The
second operand can be another register Rm, or an immediate constant.
If the second operand is an immediate constant, it can be:
• Encoded directly in the instruction.
• A modified immediate constant that uses 12 bits of the instruction to encode a range of constants. Thumb and
ARM instructions have slightly different ranges of modified immediate constants. For more information, see
Modified immediate constants in Thumb instructions on page A6-230 and Modified immediate constants in
ARM instructions on page A5-197.
If the second operand is another register, it can optionally be shifted in any of the following ways:
LSL Logical Shift Left by 1-31 bits.
LSR Logical Shift Right by 1-32 bits.
ASR Arithmetic Shift Right by 1-32 bits.
ROR Rotate Right by 1-31 bits.
RRX Rotate Right with Extend. For details see Shift and rotate operations on page A2-41.
In Thumb code, the amount to shift by is always a constant encoded in the instruction. In ARM code, the amount to
shift by is either a constant encoded in the instruction, or the value of a register, Rs.
For instructions other than CMN, CMP, TEQ, and TST, the result of the data-processing operation is placed in the
destination register. In the ARM instruction set, the destination register can be the PC, causing the result to be treated
as a branch address. In the Thumb instruction set, this is only permitted for some 16-bit forms of the ADD and MOV
instructions.
These instructions can optionally set the condition flags, according to the result of the operation. If they do not set
the flags, existing flag settings from a previous instruction are preserved.
Table A4-2 on page A4-164 summarizes the main data-processing instructions in the Thumb and ARM instruction
sets. Generally, each of these instructions is described in three sections in Chapter A8 Instruction Descriptions, one
section for each of the following:
• INSTRUCTION (immediate) where the second operand is a modified immediate constant.
• INSTRUCTION (register) where the second operand is a register, or a register shifted by a constant.
• INSTRUCTION (register-shifted register) where the second operand is a register shifted by a value obtained from
another register. These are only available in the ARM instruction set.
Table A4-2 Standard data-processing instructions
Instruction Mnemonic Notes
Add with Carry ADC -
Add ADD Thumb instruction set permits use of a modified immediate constant or a
zero-extended 12-bit immediate constant.
Form PC-relative Address ADR First operand is the PC. Second operand is an immediate constant. Thumb instruction
set uses a zero-extended 12-bit immediate constant. Operation is an addition or a
subtraction.
Bitwise AND AND -
Bitwise Bit Clear BIC -
Compare Negative CMN Sets flags. Like ADD but with no destination register.
Compare CMP Sets flags. Like SUB but with no destination register.
Bitwise Exclusive OR EOR -
Copy operand to destination MOV Has only one operand, with the same options as the second operand in most of these
instructions. If the operand is a shifted register, the instruction is an LSL, LSR, ASR, or
ROR instruction instead. For details, see Shift instructions on page A4-165.
The ARM and Thumb instruction sets permit use of a modified immediate constant
or a zero-extended 16-bit immediate constant.
Bitwise NOT MVN Has only one operand, with the same options as the second operand in most of these
instructions.
Bitwise OR NOT ORN Not available in the ARM instruction set.
Bitwise OR ORR -
Reverse Subtract RSB Subtracts first operand from second operand. This permits subtraction from constants
and shifted registers.
Reverse Subtract with Carry RSC Not available in the Thumb instruction set.
Subtract with Carry SBC -
Subtract SUB Thumb instruction set permits use of a modified immediate constant or a
zero-extended 12-bit immediate constant.
Test Equivalence TEQ Sets flags. Like EOR but with no destination register.
Test TST Sets flags. Like AND but with no destination register.
A4.4.2 Shift instructions

Table A4-3 lists the shift instructions in the ARM and Thumb instruction sets.
Table A4-3 Shift instructions
Instruction See
Arithmetic Shift Right ASR (immediate) on page A8-328
Arithmetic Shift Right ASR (register) on page A8-330
Logical Shift Left LSL (immediate) on page A8-469
Logical Shift Left LSL (register) on page A8-471
Logical Shift Right LSR (immediate) on page A8-473
Logical Shift Right LSR (register) on page A8-475
Rotate Right ROR (immediate) on page A8-569
Rotate Right ROR (register) on page A8-571
Rotate Right with Extend RRX on page A8-573
In the ARM instruction set only, the destination register of these instructions can be the PC, causing the result to be
treated as an address to branch to.
A4.4.3 Multiply instructions

These instructions can operate on signed or unsigned quantities. In some types of operation, the results are same
whether the operands are signed or unsigned.
• Table A4-4 summarizes the multiply instructions where there is no distinction between signed and unsigned
quantities.
The least significant 32 bits of the result are used. More significant bits are discarded.
• Table A4-5 on page A4-166 summarizes the signed multiply instructions.
• Table A4-6 on page A4-166 summarizes the unsigned multiply instructions.
Table A4-4 General multiply instructions
Instruction See Operation (number of bits)
Multiply Accumulate MLA on page A8-481 32 = 32 + 32 × 32
Multiply and Subtract MLS on page A8-483 32 = 32 – 32 × 32
Multiply MUL on page A8-503 32 = 32 × 32
Table A4-5 Signed multiply instructions
Signed Multiply Accumulate (halfwords) SMLABB, SMLABT, SMLATB, SMLATT 32 = 32 + 16 × 16

on page A8-621
Signed Multiply Accumulate Dual SMLAD on page A8-623 32 = 32 + 16 × 16 + 16 × 16
Signed Multiply Accumulate Long SMLAL on page A8-625 64 = 64 + 32 × 32
Signed Multiply Accumulate Long (halfwords) SMLALBB, SMLALBT, SMLALTB, 64 = 64 + 16 × 16

SMLALTT on page A8-627
Signed Multiply Accumulate Long Dual SMLALD on page A8-629 64 = 64 + 16 × 16 + 16 × 16
Signed Multiply Accumulate (word by halfword) SMLAWB, SMLAWT on page A8-631 32 = 32 + 32 × 16 a
Signed Multiply Subtract Dual SMLSD on page A8-633 32 = 32 + 16 × 16 – 16 × 16
Signed Multiply Subtract Long Dual SMLSLD on page A8-635 64 = 64 + 16 × 16 – 16 × 16
Signed Most Significant Word Multiply Accumulate SMMLA on page A8-637 32 = 32 + 32 × 32 b
Signed Most Significant Word Multiply Subtract SMMLS on page A8-639 32 = 32 – 32 × 32 b
Signed Most Significant Word Multiply SMMUL on page A8-641 32 = 32 × 32 b
Signed Dual Multiply Add SMUAD on page A8-643 32 = 16 × 16 + 16 × 16
Signed Multiply (halfwords) SMULBB, SMULBT, SMULTB, SMULTT 32 = 16 × 16

on page A8-645
Signed Multiply Long SMULL on page A8-647 64 = 32 × 32
Signed Multiply (word by halfword) SMULWB, SMULWT on page A8-649 32 = 32 × 16 a
Signed Dual Multiply Subtract SMUSD on page A8-651 32 = 16 × 16 – 16 × 16
a. The most significant 32 bits of the 48-bit product are used. Less significant bits are discarded.
b. The most significant 32 bits of the 64-bit product are used. Less significant bits are discarded.
Table A4-6 Unsigned multiply instructions
Unsigned Multiply Accumulate Accumulate Long UMAAL on page A8-775 64 = 32 + 32 + 32 × 32
Unsigned Multiply Accumulate Long UMLAL on page A8-777 64 = 64 + 32 × 32
Unsigned Multiply Long UMULL on page A8-779 64 = 32 × 32
A4.4.4 Saturating instructions

Table A4-7 lists the saturating instructions in the ARM and Thumb instruction sets. For more information, see
Pseudocode details of saturation on page A2-44.
Table A4-7 Saturating instructions
Instruction See Operation
Signed Saturate SSAT on page A8-653 Saturates optionally shifted 32-bit value to selected range
Signed Saturate 16 SSAT16 on page A8-655 Saturates two 16-bit values to selected range
Unsigned Saturate USAT on page A8-797 Saturates optionally shifted 32-bit value to selected range
Unsigned Saturate 16 USAT16 on page A8-799 Saturates two 16-bit values to selected range
A4.4.5 Saturating addition and subtraction instructions

Table A4-8 lists the saturating addition and subtraction instructions in the ARM and Thumb instruction sets. For
more information, see Pseudocode details of saturation on page A2-44.
Table A4-8 Saturating addition and subtraction instructions
Saturating Add QADD on page A8-541 Add, saturating result to the 32-bit signed integer range
Saturating Subtract QSUB on page A8-555 Subtract, saturating result to the 32-bit signed integer range
Saturating Double and Add QDADD on page A8-549 Doubles one value and adds a second value, saturating the doubling and
the addition to the 32-bit signed integer range
Saturating Double and QDSUB on page A8-551 Doubles one value and subtracts the result from a second value, saturating
Subtract the doubling and the subtraction to the 32-bit signed integer range
A4.4.6 Packing and unpacking instructions

Table A4-9 lists the packing and unpacking instructions in the ARM and Thumb instruction sets. These are all
available from ARMv6T2 in the Thumb instruction set, and from ARMv6 onwards in the ARM instruction set.
Table A4-9 Packing and unpacking instructions
Pack Halfword PKH on page A8-523 Combine halfwords
Signed Extend and Add Byte SXTAB on page A8-725 Extend 8 bits to 32 and add
Signed Extend and Add Byte 16 SXTAB16 on page A8-727 Dual extend 8 bits to 16 and add
Signed Extend and Add Halfword SXTAH on page A8-729 Extend 16 bits to 32 and add
Signed Extend Byte SXTB on page A8-731 Extend 8 bits to 32
Signed Extend Byte 16 SXTB16 on page A8-733 Dual extend 8 bits to 16
Signed Extend Halfword SXTH on page A8-735 Extend 16 bits to 32
Unsigned Extend and Add Byte UXTAB on page A8-807 Extend 8 bits to 32 and add
Unsigned Extend and Add Byte 16 UXTAB16 on page A8-809 Dual extend 8 bits to 16 and add
Unsigned Extend and Add Halfword UXTAH on page A8-811 Extend 16 bits to 32 and add
Unsigned Extend Byte UXTB on page A8-813 Extend 8 bits to 32
Unsigned Extend Byte 16 UXTB16 on page A8-815 Dual extend 8 bits to 16
Unsigned Extend Halfword UXTH on page A8-817 Extend 16 bits to 32
A4.4.7 Parallel addition and subtraction instructions

These instructions perform additions and subtractions on the values of two registers and write the result to a
destination register, treating the register values as sets of two halfwords or four bytes. That is, they perform SIMD
additions or subtractions on the registers. They are available in ARMv6 and above.
These instructions consist of a prefix followed by a main instruction mnemonic. The prefixes are as follows:
S Signed arithmetic modulo 28 or 216.
Q Signed saturating arithmetic.
SH Signed arithmetic, halving the results.
U Unsigned arithmetic modulo 28 or 216.
UQ Unsigned saturating arithmetic.
UH Unsigned arithmetic, halving the results.
The main instruction mnemonics are as follows:
ADD16 Adds the top halfwords of two operands to form the top halfword of the result, and the bottom
halfwords of the same two operands to form the bottom halfword of the result.
ASX Exchanges halfwords of the second operand, and then adds top halfwords and subtracts bottom
halfwords.
SAX Exchanges halfwords of the second operand, and then subtracts top halfwords and adds bottom
halfwords.
SUB16 Subtracts each halfword of the second operand from the corresponding halfword of the first operand
to form the corresponding halfword of the result.
ADD8 Adds each byte of the second operand to the corresponding byte of the first operand to form the
corresponding byte of the result.
SUB8 Subtracts each byte of the second operand from the corresponding byte of the first operand to form
the corresponding byte of the result.
The instruction set permits all 36 combinations of prefix and main instruction operand, as Table A4-10 shows.
See also Advanced SIMD parallel addition and subtraction on page A4-183.
Table A4-10 Parallel addition and subtraction instructions
Signed Unsigned Unsigned

Main instruction Signed Saturating Unsigned
halving saturating halving
ADD16, add, two halfwords SADD16 QADD16 SHADD16 UADD16 UQADD16 UHADD16
ASX, add and subtract with exchange SASX QASX SHASX UASX UQASX UHASX
SAX, subtract and add with exchange SSAX QSAX SHSAX USAX UQSAX UHSAX
SUB16, subtract, two halfwords SSUB16 QSUB16 SHSUB16 USUB16 UQSUB16 UHSUB16
ADD8, add, four bytes SADD8 QADD8 SHADD8 UADD8 UQADD8 UHADD8
SUB8, subtract, four bytes SSUB8 QSUB8 SHSUB8 USUB8 UQSUB8 UHSUB8
A4.4.8 Divide instructions

The ARMv7-R profile introduces support for signed and unsigned integer divide instructions, implemented in
hardware, in the Thumb instruction set. For more information, see ARMv7 implementation requirements and options
for the divide instructions.
For descriptions of the instructions, see:

• SDIV on page A8-601.
• UDIV on page A8-761.
Note
• The Virtualization Extensions introduce the requirement for an ARMv7-A implementation to include SDIV
and UDIV.
• The ARMv7-M profile also includes the SDIV and UDIV instructions.
In the ARMv7-R profile, the SCTLR.DZ bit enables divide by zero fault detection:
SCTLR.DZ == 0 Divide-by-zero returns a zero result.
SCTLR.DZ == 1 SDIV and UDIV generate an Undefined Instruction exception on a divide-by-zero.
The SCTLR.DZ bit is cleared to zero on reset.
In an ARMv7-A profile implementation that supports the SDIV and UDIV instructions, divide-by-zero always returns
a zero result.
ARMv7 implementation requirements and options for the divide instructions

Any implementation of the ARMv7-R profile must include the SDIV and UDIV instructions in the Thumb instruction
set.
Any implementation of the Virtualization Extensions must include the SDIV and UDIV instructions in the Thumb and
ARM instruction sets.
In the ARMv7-R profile, the implementation of SDIV and UDIV in the ARM instruction set is OPTIONAL.
In an ARMv7-A implementation that does not include the Virtualization Extensions, the implementation of SDIV and
UDIV in both instruction sets is OPTIONAL, but the architecture permits an ARMv7-A implementation to not
implement SDIV and UDIV.
Note
Previous issues of this document have stated that a VMSAv7 implementation might implement SDIV and UDIV in the
Thumb instruction set but not in the ARM instruction set. ARM strongly recommends against this implementation
option.
The ID_ISAR0.Divide_instrs field indicates the level of support for these instructions, see ID_ISAR0, Instruction
Set Attribute Register 0, VMSA on page B4-1603 or ID_ISAR0, Instruction Set Attribute Register 0, PMSA on
page B6-1848:
• A field value of 0b0001 indicates they are implemented in the Thumb instruction set.
• A field value of 0b0010 indicates they are implemented in both the Thumb and ARM instruction sets.
A4.4.9 Miscellaneous data-processing instructions

Table A4-11 lists the miscellaneous data-processing instructions in the ARM and Thumb instruction sets.
Immediate values in these instructions are simple binary numbers.
Table A4-11 Miscellaneous data-processing instructions
Instruction See Notes
Bit Field Clear BFC on page A8-334 -
Bit Field Insert BFI on page A8-336 -
Count Leading Zeros CLZ on page A8-360 -
Move Top MOVT on page A8-492 Moves 16-bit immediate value to top
halfword. Bottom halfword unchanged.
Reverse Bits RBIT on page A8-561 -
Byte-Reverse Word REV on page A8-563 -
Byte-Reverse Packed Halfword REV16 on page A8-565 -
Byte-Reverse Signed Halfword REVSH on page A8-567 -
Signed Bit Field Extract SBFX on page A8-599 -
Select Bytes using GE flags SEL on page A8-603 -
Unsigned Bit Field Extract UBFX on page A8-757 -
Unsigned Sum of Absolute Differences USAD8 on page A8-793 -
Unsigned Sum of Absolute Differences and Accumulate USADA8 on page A8-795 -
A4.5 Status register access instructions
A4.5 Status register access instructions

The MRS and MSR instructions move the contents of the Application Program Status Register (APSR) to or from an
ARM core register, see:
• MRS on page A8-497.
• MSR (immediate) on page A8-499.
• MSR (register) on page A8-501.
The Application Program Status Register (APSR) on page A2-49 described the APSR.
The condition flags in the APSR are normally set by executing data-processing instructions, and normally control
the execution of conditional instructions. However, software can set the condition flags explicitly using the MSR
instruction, and can read the current state of the condition flags explicitly using the MRS instruction.
At system level, software can also:
• Use these instructions to access the SPSR of the current mode.
• Use the CPS instruction to change the CPSR.M field and the CPSR.{A, I, F} interrupt mask bits.
For details of the system level use of status register access instructions CPS, MRS, and MSR, see:
• CPS (Thumb) on page B9-1964.
• CPS (ARM) on page B9-1966.
• MRS on page B9-1976.
• MSR (immediate) on page B9-1982.
• MSR (register) on page B9-1984.
A4.5.1 Banked register access instructions

In a processor that implements the Virtualization Extensions, in all modes except User mode, the MRS (Banked
register) and MSR (Banked register) instructions move the contents of a Banked ARM core register, the SPSR, or the
ELR_hyp, to or from an ARM core register. For instruction descriptions, see:
• MRS (Banked register) on page B9-1978.
• MSR (Banked register) on page B9-1980.
Note
These are system level instructions.
A4.6 Load/store instructions

Table A4-12 summarizes the ARM core register load/store instructions in the ARM and Thumb instruction sets. See
also:
• Load/store multiple instructions on page A4-175.
• Advanced SIMD and Floating-point load/store instructions on page A4-179.
Load/store instructions have several options for addressing memory. For more information, see Addressing modes
on page A4-174.
Table A4-12 Load/store instructions
Load Store Load- Store-

Data type Load Store
unprivileged unprivileged Exclusive Exclusive
32-bit word LDR STR LDRT STRT LDREX STREX
16-bit halfword - STRH - STRHT - STREXH
16-bit unsigned halfword LDRH - LDRHT - LDREXH -
16-bit signed halfword LDRSH - LDRSHT - - -
8-bit byte - STRB - STRBT - STREXB
8-bit unsigned byte LDRB - LDRBT - LDREXB -
8-bit signed byte LDRSB - LDRSBT - - -
Two 32-bit words LDRD STRD - - - -
64-bit doubleword - - - - LDREXD STREXD
A4.6.1 Loads to the PC

The LDR instruction can load a value into the PC. The value loaded is treated as an interworking address, as described
by the LoadWritePC() pseudocode function in Pseudocode details of operations on ARM core registers on
page A2-46.
A4.6.2 Halfword and byte loads and stores

Halfword and byte stores store the least significant halfword or byte from the register, to 16 bits or 8 bits of memory
respectively. There is no distinction between signed and unsigned stores.
Halfword and byte loads load 16 bits or 8 bits from memory into the least significant halfword or byte of a register.
Unsigned loads zero-extend the loaded value to 32 bits, and signed loads sign-extend the value to 32 bits.
A4.6.3 Load unprivileged and Store unprivileged

When executing at PL0, a Load unprivileged or Store unprivileged instruction operates in exactly the same way as
the corresponding ordinary load or store instruction. For example, an LDRT instruction executes in exactly the same
way as the equivalent LDR instruction. When executed at PL1, Load unprivileged and Store unprivileged instructions
behave as they would if they were executed at PL0. For example, an LDRT instruction executes in exactly the way
that the equivalent LDR instruction would execute at PL0. In particular, the instructions make unprivileged memory
accesses.
The Load unprivileged and Store unprivileged instructions are UNPREDICTABLE if executed at PL2.
For more information, see Privilege level access controls for data accesses on page A3-140.
A4.6.4 Exclusive loads and stores

Exclusive loads and stores provide shared memory synchronization. For more information, see Synchronization and
semaphores on page A3-112.
A4.6.5 Addressing modes

The address for a load or store is formed from two parts: a value from a base register, and an offset.
The base register can be any one of the ARM core registers R0-R12, SP, or LR.
For loads, the base register can be the PC. This permits PC-relative addressing for position-independent code.
Instructions marked (literal) in their title in Chapter A8 Instruction Descriptions are PC-relative loads.
The offset takes one of three formats:
Immediate The offset is an unsigned number that can be added to or subtracted from the base register
value. Immediate offset addressing is useful for accessing data elements that are a fixed
distance from the start of the data object, such as structure fields, stack offsets, and
input/output registers.
Register The offset is a value from an ARM core register. This register cannot be the PC. The value
can be added to, or subtracted from, the base register value. Register offsets are useful for
accessing arrays or blocks of data.
Scaled register The offset is an ARM core register, other than the PC, shifted by an immediate value, then
added to or subtracted from the base register. This means an array index can be scaled by
the size of each array element.
The offset and base register can be used in three different ways to form the memory address. The addressing modes
are described as follows:
Offset The offset is added to or subtracted from the base register to form the memory address.
Pre-indexed The offset is added to or subtracted from the base register to form the memory address. The
base register is then updated with this new address, to permit automatic indexing through an
array or memory block.
Post-indexed The value of the base register alone is used as the memory address. The offset is then added
to or subtracted from the base register. The result is stored back in the base register, to permit
automatic indexing through an array or memory block.
Note
Not every variant is available for every instruction, and the range of permitted immediate values and the options for
scaled registers vary from instruction to instruction. See Chapter A8 Instruction Descriptions for full details for
each instruction.
A4.7 Load/store multiple instructions
A4.7 Load/store multiple instructions

Load Multiple instructions load a subset, or possibly all, of the ARM core registers from memory.
Store Multiple instructions store a subset, or possibly all, of the ARM core registers to memory.
The memory locations are consecutive word-aligned words. The addresses used are obtained from a base register,
and can be either above or below the value in the base register. The base register can optionally be updated by the
total size of the data transferred.
Table A4-13 summarizes the load/store multiple instructions in the ARM and Thumb instruction sets.
Table A4-13 Load/store multiple instructions
Instruction See
Load Multiple, Increment After or Full Descending LDM/LDMIA/LDMFD (Thumb) on page A8-397
LDM/LDMIA/LDMFD (ARM) on page A8-399
Load Multiple, Decrement After or Full Ascending a LDMDA/LDMFA on page A8-401
Load Multiple, Decrement Before or Empty Ascending LDMDB/LDMEA on page A8-403
Load Multiple, Increment Before or Empty Descending a LDMIB/LDMED on page A8-405
Pop multiple registers off the stack b POP (Thumb) on page A8-535
POP (ARM) on page A8-537
Push multiple registers onto the stack c PUSH on page A8-539
Store Multiple, Increment After or Empty Ascending STM (STMIA, STMEA) on page A8-665
Store Multiple, Decrement After or Empty Descending a STMDA (STMED) on page A8-667
Store Multiple, Decrement Before or Full Descending STMDB (STMFD) on page A8-669
Store Multiple, Increment Before or Full Ascending a STMIB (STMFA) on page A8-671
a. Not available in the Thumb instruction set.

b. This instruction is equivalent to an LDM instruction with the SP as base register, and base register updating.
c. This instruction is equivalent to an STMDB instruction with the SP as base register, and base register updating.
When executing at PL1, variants of the LDM and STM instructions load and store User mode registers. Another
system level variant of the LDM instruction performs an exception return. For details of these variants, see Chapter B9
System Instructions.
A4.7.1 Loads to the PC

The LDM, LDMDA, LDMDB, LDMIB, and POP instructions can load a value into the PC. The value loaded is treated as an
interworking address, as described by the LoadWritePC() pseudocode function in Pseudocode details of operations
on ARM core registers on page A2-46.
A4.8 Miscellaneous instructions
A4.8 Miscellaneous instructions

Table A4-14 summarizes the miscellaneous instructions in the ARM and Thumb instruction sets.
Table A4-14 Miscellaneous instructions
Instruction See
Clear-Exclusive CLREX on page A8-358
Debug Hint DBG on page A8-378
Data Memory Barrier DMB on page A8-379
Data Synchronization Barrier DSB on page A8-381
Instruction Synchronization Barrier ISB on page A8-390
If-Then IT on page A8-391
No Operation NOP on page A8-511
Preload Data PLD, PLDW (immediate) on page A8-525

PLD (literal) on page A8-527
PLD, PLDW (register) on page A8-529
Preload Instruction PLI (immediate, literal) on page A8-531

PLI (register) on page A8-533
Set Endianness SETEND on page A8-605
Send Event SEV on page A8-607
Swap, Swap Byte. Deprecated. a SWP, SWPB on page A8-723
Wait For Event WFE on page A8-1105
Wait For Interrupt WFI on page A8-1107
Yield YIELD on page A8-1109
a. Use Load/Store-Exclusive instructions instead, see Load/store instructions on page A4-173.
A4.8.1 The Yield instruction

In a Symmetric Multi-Threading (SMT) design, a thread can use the YIELD instruction to give a hint to the processor
that it is running on. The YIELD hint indicates that whatever the thread is currently doing is of low importance, and
so could yield. For example, the thread might be sitting in a spin-lock. A similar use might be in modifying the
arbitration priority of the snoop bus in a multiprocessor (MP) system. Defining such an instruction permits binary
compatibility between SMT and SMP systems.
ARMv7 defines a YIELD instruction as a specific NOP (No Operation) hint instruction.
The YIELD instruction has no effect in a single-threaded system, but developers of such systems can use the
instruction to flag its intended use on migration to a multiprocessor or multithreading system. Operating systems
can use YIELD in places where a yield hint is wanted, knowing that it will be treated as a NOP if there is no
implementation benefit.
A4.9 Exception-generating and exception-handling instructions
A4.9 Exception-generating and exception-handling instructions

The following instructions are intended specifically to cause a synchronous processor exception to occur:
• The SVC instruction generates a Supervisor Call exception. For more information, see Supervisor Call (SVC)
• The Breakpoint instruction BKPT provides software breakpoints. For more information, see About debug
events on page C3-2024.
• In a processor that implements the Security Extensions, when executing at PL1 or higher, the SMC instruction
generates a Secure Monitor Call exception. For more information, see Secure Monitor Call (SMC) exception
on page B1-1210.
• In a processor that implements the Virtualization Extensions, in software executing in a Non-secure PL1
mode, the HVC instruction generates a Hypervisor Call exception. For more information, see Hypervisor Call
(HVC) exception on page B1-1211.
For an exception taken to a PL1 mode:
• The system level variants of the SUBS and LDM instructions perform a return from an exception.
Note
The variants of SUBS include MOVS. See the references to SUBS PC, LR in Table A4-15 for more information.
• From ARMv6, the SRS instruction can be used near the start of the handler, to store return information. The
RFE instruction can then perform a return from the exception using the stored return information.
In a processor that implements the Virtualization Extensions, the ERET instruction performs a return from an
exception taken to Hyp mode.
For more information, see Exception return on page B1-1193.
Table A4-15 summarizes the instructions, in the ARM and Thumb instruction sets, for generating or handling an
exception. Except for BKPT and SVC, these are system level instructions.
Table A4-15 Exception-generating and exception-handling instructions
Instruction See
Supervisor Call SVC (previously SWI) on page A8-721
Breakpoint BKPT on page A8-344
Secure Monitor Call SMC (previously SMI) on page B9-1988
Return From Exception RFE on page B9-1986
Subtract (exception return) SUBS PC, LR (Thumb) on page B9-1996

SUBS PC, LR and related instructions (ARM) on page B9-1998
Hypervisor Call HVC on page B9-1970
Exception Return ERET on page B9-1968
Load Multiple (exception return) LDM (exception return) on page B9-1972
Store Return State SRS (Thumb) on page B9-1990

SRS (ARM) on page B9-1992
A4.10 Coprocessor instructions
A4.10 Coprocessor instructions

There are three types of instruction for communicating with coprocessors. These permit the processor to:
• Initiate a coprocessor data-processing operation. For details see CDP, CDP2 on page A8-356.
• Transfer ARM core registers to and from coprocessor registers. For details, see:
— MCR, MCR2 on page A8-477.
— MCRR, MCRR2 on page A8-479.
— MRC, MRC2 on page A8-493.
— MRRC, MRRC2 on page A8-495.
• Load or store the values of coprocessor registers. For details, see:

— LDC, LDC2 (immediate) on page A8-393.
— LDC, LDC2 (literal) on page A8-395.
— STC, STC2 on page A8-663.
The instruction set distinguishes up to 16 coprocessors with a 4-bit field in each coprocessor instruction, so each
coprocessor is assigned a particular number.
Note
One coprocessor can use more than one of the 16 numbers if a large coprocessor instruction set is required.
Coprocessors 10 and 11 are used, together, for Floating-point Extension and some Advanced SIMD Extension
functionality. There are different instructions for accessing these coprocessors, of similar types to the instructions
for the other coprocessors, that is, to:
• Initiate a coprocessor data-processing operation. For details see Floating-point data-processing instructions
on page A4-189.
• Transfer ARM core registers to and from coprocessor registers. For details, see Advanced SIMD and
Floating-point register transfer instructions on page A4-181.
• Load or store the values of coprocessor registers. For details, see Advanced SIMD and Floating-point
load/store instructions on page A4-179.
Coprocessors execute the same instruction stream as the processor, ignoring non-coprocessor instructions and
coprocessor instructions for other coprocessors. Coprocessor instructions that cannot be executed by any
coprocessor hardware cause an Undefined Instruction exception.
Coprocessors 8, 9, 12, and 13 are reserved for future use by ARM. Any coprocessor access instruction attempting
to access one of these coprocessors is UNDEFINED.
For more information about specific coprocessors, see Coprocessor support on page A2-93.
A4.11 Advanced SIMD and Floating-point load/store instructions

Table A4-16 summarizes the extension register load/store instructions in the Advanced SIMD and Floating-point
(VFP) instruction sets.
Advanced SIMD also provides instructions for loading and storing multiple elements, or structures of elements, see
Element and structure load/store instructions.
Table A4-16 Extension register load/store instructions
Vector Load Multiple VLDM on page A8-923 Load 1-16 consecutive 64-bit registers, Advanced SIMD and Floating-point
Load 1-16 consecutive 32-bit registers, Floating-point only
Vector Load Register VLDR on page A8-925 Load one 64-bit register, Advanced SIMD and Floating-point
Load one 32-bit register, Floating-point only
Vector Store Multiple VSTM on page A8-1081 Store 1-16 consecutive 64-bit registers, Advanced SIMD and Floating-point
Store 1-16 consecutive 32-bit registers, Floating-point only
Vector Store Register VSTR on page A8-1083 Store one 64-bit register, Advanced SIMD and Floating-point
Store one 32-bit register, Floating-point only
A4.11.1 Element and structure load/store instructions

Table A4-17 shows the element and structure load/store instructions available in the Advanced SIMD instruction
set. Loading and storing structures of more than one element automatically de-interleaves or interleaves the
elements, see Figure A4-1 on page A4-180 for an example of de-interleaving. Interleaving is the inverse process.
Table A4-17 Element and structure load/store instructions
Instruction See
Load single element
Multiple elements VLD1 (multiple single elements) on page A8-899
To one lane VLD1 (single element to one lane) on page A8-901
To all lanes VLD1 (single element to all lanes) on page A8-903
Load 2-element structure
Multiple structures VLD2 (multiple 2-element structures) on page A8-905
To one lane VLD2 (single 2-element structure to one lane) on page A8-907
To all lanes VLD2 (single 2-element structure to all lanes) on page A8-909
Table A4-17 Element and structure load/store instructions (continued)
Instruction See
Store single element
Multiple elements VST1 (multiple single elements) on page A8-1065
From one lane VST1 (single element from one lane) on page A8-1067
Store 2-element structure
Multiple structures VST2 (multiple 2-element structures) on page A8-1069
From one lane VST2 (single 2-element structure from one lane) on page A8-1071
Figure A4-1 shows the de-interleaving of a VLD3.16 (multiple 3-element structures) instruction:
Memory
A[0].x
A[0].y
A[0].z
A[1].x
A is a packed array of A[1].y
3-element structures. A[1].z
Each element is a 16-bit A[2].x
halfword. A[2].y
A[2].z
A[3].x
A[3].y X3 X2 X1 X0 D0
A[3].z Y3 Y2 Y1 Y0 D1 Registers
Z3 Z2 Z1 Z0 D2
Figure A4-1 De-interleaving an array of 3-element structures
Figure A4-1 shows the VLD3.16 instruction operating to three 64-bit registers that comprise four 16-bit elements:
• Different instructions in this group would produce similar figures, but operate on different numbers of
registers. For example, VLD4 and VST4 instructions operate on four registers.
• Different element sizes would produce similar figures but with 8-bit or 32-bit elements.
• These instructions operate only on doubleword (64-bit) registers.
A4.12 Advanced SIMD and Floating-point register transfer instructions
A4.12 Advanced SIMD and Floating-point register transfer instructions

Table A4-18 summarizes the extension register transfer instructions in the Advanced SIMD and Floating-point
(VFP) instruction sets. These instructions transfer data from ARM core registers to extension registers, or from
extension registers to ARM core registers.
Advanced SIMD vectors, and single-precision and double-precision Floating-point registers, are all views of the
same extension register set. For details, see Advanced SIMD and Floating-point Extension registers on page A2-56.
Table A4-18 Extension register transfer instructions
Instruction See
Copy element from ARM core register to every element of Advanced SIMD vector VDUP (ARM core register) on page A8-887
Copy byte, halfword, or word from ARM core register to extension register VMOV (ARM core register to scalar) on
page A8-941
Copy byte, halfword, or word from extension register to ARM core register VMOV (scalar to ARM core register) on
page A8-943
Copy from single-precision Floating-point register to ARM core register, or from VMOV (between ARM core register and
ARM core register to single-precision Floating-point register single-precision register) on page A8-945
Copy two words from ARM core registers to consecutive single-precision VMOV (between two ARM core registers and
Floating-point registers, or from consecutive single-precision Floating-point two single-precision registers) on page A8-947
registers to ARM core registers
Copy two words from ARM core registers to doubleword extension register, or from VMOV (between two ARM core registers and a
doubleword extension register to ARM core registers doubleword extension register) on page A8-949
Copy from Advanced SIMD and Floating-point Extension System Register to ARM VMRS on page A8-955
core register VMRS on page B9-2000 (system level view)
Copy from ARM core register to Advanced SIMD and Floating-point Extension VMSR on page A8-957
System Register VMSR on page B9-2002 (system level view)
A4.13 Advanced SIMD data-processing instructions

Advanced SIMD data-processing instructions process registers containing vectors of elements of the same type
packed together, enabling the same operation to be performed on multiple items in parallel.
Instructions operate on vectors held in 64-bit or 128-bit registers. Figure A4-2 shows an operation on two 64-bit
operand vectors, generating a 64-bit vector result.
Note
Figure A4-2 and other similar figures show 64-bit vectors that consist of four 16-bit elements, and 128-bit vectors
that consist of four 32-bit elements. Other element sizes produce similar figures, but with one, two, eight, or sixteen
operations performed in parallel instead of four.
Dn
Dm
Op Op Op Op
Dd
Figure A4-2 Advanced SIMD instruction operating on 64-bit registers
Many Advanced SIMD instructions have variants that produce vectors of elements double the size of the inputs. In
this case, the number of elements in the result vector is the same as the number of elements in the operand vectors,
but each element, and the whole vector, is double the size.
Figure A4-3 shows an example of an Advanced SIMD instruction operating on 64-bit registers, and generating a
128-bit result.
Dn
Dm
Op Op Op Op
Qd
Figure A4-3 Advanced SIMD instruction producing wider result
There are also Advanced SIMD instructions that have variants that produce vectors containing elements half the
size of the inputs. Figure A4-4 on page A4-183 shows an example of an Advanced SIMD instruction operating on
one 128-bit register, and generating a 64-bit result.
Qn
Op Op Op Op
Dd
Figure A4-4 Advanced SIMD instruction producing narrower result
Some Advanced SIMD instructions do not conform to these standard patterns. Their operation patterns are
described in the individual instruction descriptions.
Advanced SIMD instructions that perform floating-point arithmetic use the ARM standard floating-point arithmetic
defined in Floating-point data types and arithmetic on page A2-62.
A4.13.1 Advanced SIMD parallel addition and subtraction

Table A4-19 shows the Advanced SIMD parallel add and subtract instructions.
Table A4-19 Advanced SIMD parallel add and subtract instructions
Instruction See
Vector Add VADD (integer) on page A8-829

VADD (floating-point) on page A8-831
Vector Add and Narrow, returning High Half VADDHN on page A8-833
Vector Add Long, Vector Add Wide VADDL, VADDW on page A8-835
Vector Halving Add, Vector Halving Subtract VHADD, VHSUB on page A8-897
Vector Pairwise Add and Accumulate Long VPADAL on page A8-979
Vector Pairwise Add VPADD (integer) on page A8-981

VPADD (floating-point) on page A8-983
Vector Pairwise Add Long VPADDL on page A8-985
Vector Rounding Add and Narrow, returning High Half VRADDHN on page A8-1023
Vector Rounding Halving Add VRHADD on page A8-1031
Vector Rounding Subtract and Narrow, returning High Half VRSUBHN on page A8-1045
Vector Saturating Add VQADD on page A8-997
Vector Saturating Subtract VQSUB on page A8-1021
Vector Subtract VSUB (integer) on page A8-1085

VSUB (floating-point) on page A8-1087
Vector Subtract and Narrow, returning High Half VSUBHN on page A8-1089
Vector Subtract Long, Vector Subtract Wide VSUBL, VSUBW on page A8-1091
A4.13.2 Bitwise Advanced SIMD data-processing instructions

Table A4-20 shows bitwise Advanced SIMD data-processing instructions. These operate on the doubleword
(64-bit) or quadword (128-bit) extension registers, and there is no division into vector elements.
Table A4-20 Bitwise Advanced SIMD data-processing instructions
Instruction See
Vector Bitwise AND VAND (register) on page A8-837
Vector Bitwise Bit Clear (AND complement) VBIC (immediate) on page A8-839
VBIC (register) on page A8-841
Vector Bitwise Exclusive OR VEOR on page A8-889
Vector Bitwise Insert if False

VBIF, VBIT, VBSL on page A8-843
Vector Bitwise Insert if True
Vector Bitwise Move VMOV (immediate) on page A8-937

VMOV (register) on page A8-939
Vector Bitwise NOT VMVN (immediate) on page A8-965

VMVN (register) on page A8-967
Vector Bitwise OR VORR (immediate) on page A8-975

VORR (register) on page A8-977
Vector Bitwise OR NOT VORN (register) on page A8-973
Vector Bitwise Select VBIF, VBIT, VBSL on page A8-843
A4.13.3 Advanced SIMD comparison instructions

Table A4-21 shows Advanced SIMD comparison instructions.
Table A4-21 Advanced SIMD comparison instructions
Instruction See
Vector Absolute Compare VACGE, VACGT, VACLE, VACLT on page A8-827
Vector Compare Equal VCEQ (register) on page A8-845
Vector Compare Equal to Zero VCEQ (immediate #0) on page A8-847
Vector Compare Greater Than or Equal VCGE (register) on page A8-849
Vector Compare Greater Than or Equal to Zero VCGE (immediate #0) on page A8-851
Vector Compare Greater Than VCGT (register) on page A8-853
Vector Compare Greater Than Zero VCGT (immediate #0) on page A8-855
Vector Compare Less Than or Equal to Zero VCLE (immediate #0) on page A8-857
Vector Compare Less Than Zero VCLT (immediate #0) on page A8-861
Vector Test Bits VTST on page A8-1099
A4.13.4 Advanced SIMD shift instructions

Table A4-22 lists the shift instructions in the Advanced SIMD instruction set.
Table A4-22 Advanced SIMD shift instructions
Instruction See
Vector Saturating Rounding Shift Left VQRSHL on page A8-1011
Vector Saturating Rounding Shift Right and Narrow VQRSHRN, VQRSHRUN on page A8-1013
Vector Saturating Shift Left VQSHL (register) on page A8-1015

VQSHL, VQSHLU (immediate) on page A8-1017
Vector Saturating Shift Right and Narrow VQSHRN, VQSHRUN on page A8-1019
Vector Rounding Shift Left VRSHL on page A8-1033
Vector Rounding Shift Right VRSHR on page A8-1035
Vector Rounding Shift Right and Accumulate VRSRA on page A8-1043
Vector Rounding Shift Right and Narrow VRSHRN on page A8-1037
Vector Shift Left VSHL (immediate) on page A8-1047

VSHL (register) on page A8-1049
Vector Shift Left Long VSHLL on page A8-1051
Vector Shift Right VSHR on page A8-1053
Vector Shift Right and Narrow VSHRN on page A8-1055
Vector Shift Left and Insert VSLI on page A8-1057
Vector Shift Right and Accumulate VSRA on page A8-1061
Vector Shift Right and Insert VSRI on page A8-1063
A4.13.5 Advanced SIMD multiply instructions

Table A4-23 summarizes the Advanced SIMD multiply instructions.
Table A4-23 Advanced SIMD multiply instructions
Instruction See
Vector Multiply Accumulate
Vector Multiply Accumulate Long VMLA, VMLAL, VMLS, VMLSL (integer) on page A8-931
VMLA, VMLS (floating-point) on page A8-933
Vector Multiply Subtract VMLA, VMLAL, VMLS, VMLSL (by scalar) on page A8-935
Vector Multiply Subtract Long
Vector Multiply VMUL, VMULL (integer and polynomial) on page A8-959

VMUL (floating-point) on page A8-961
Vector Multiply Long
VMUL, VMULL (by scalar) on page A8-963
Vector Fused Multiply Accumulate VFMA, VFMS on page A8-893
Vector Fused Multiply Subtract
Vector Saturating Doubling Multiply Accumulate Long

VQDMLAL, VQDMLSL on page A8-999
Vector Saturating Doubling Multiply Subtract Long
Vector Saturating Doubling Multiply Returning High Half VQDMULH on page A8-1001
Vector Saturating Rounding Doubling Multiply Returning High Half VQRDMULH on page A8-1009
Vector Saturating Doubling Multiply Long VQDMULL on page A8-1003
Advanced SIMD multiply instructions can operate on vectors of:
• 8-bit, 16-bit, or 32-bit unsigned integers.
• 8-bit, 16-bit, or 32-bit signed integers.
• 8-bit polynomials over {0, 1}. VMUL and VMULL are the only instructions that operate on polynomials. VMULL
produces a 16-bit polynomial over {0, 1}.
• Single-precision (32-bit) floating-point numbers.
They can also act on one vector and one scalar.
Long instructions have doubleword (64-bit) operands, and produce quadword (128-bit) results. Other Advanced
SIMD multiply instructions can have either doubleword or quadword operands, and produce results of the same
size.
Floating-point multiply instructions can operate on:

• Single-precision (32-bit) floating-point numbers.
• Double-precision (64-bit) floating-point numbers.
Some Floating-point Extension implementations do not support double-precision numbers.
A4.13.6 Miscellaneous Advanced SIMD data-processing instructions

Table A4-24 shows miscellaneous Advanced SIMD data-processing instructions.
Table A4-24 Miscellaneous Advanced SIMD data-processing instructions
Instruction See
Vector Absolute Difference and Accumulate VABA, VABAL on page A8-819
Vector Absolute Difference VABD, VABDL (integer) on page A8-821

VABD (floating-point) on page A8-823
Vector Absolute VABS on page A8-825
Vector Convert between floating-point and fixed VCVT (between floating-point and fixed-point, Advanced SIMD) on
point page A8-873
Vector Convert between floating-point and integer VCVT (between floating-point and integer, Advanced SIMD) on page A8-869
Vector Convert between half-precision and VCVT (between half-precision and single-precision, Advanced SIMD) on
single-precision page A8-879
Vector Count Leading Sign Bits VCLS on page A8-859
Vector Count Leading Zeros VCLZ on page A8-863
Vector Count Set Bits VCNT on page A8-867
Vector Duplicate scalar VDUP (scalar) on page A8-885
Vector Extract VEXT on page A8-891
Vector Move and Narrow VMOVN on page A8-953
Vector Move Long VMOVL on page A8-951
Vector Maximum, Minimum VMAX, VMIN (integer) on page A8-927

VMAX, VMIN (floating-point) on page A8-929
Vector Negate VNEG on page A8-969
Vector Pairwise Maximum, Minimum VPMAX, VPMIN (integer) on page A8-987

VPMAX, VPMIN (floating-point) on page A8-989
Vector Reciprocal Estimate VRECPE on page A8-1025
Vector Reciprocal Step VRECPS on page A8-1027
Vector Reciprocal Square Root Estimate VRSQRTE on page A8-1039
Vector Reciprocal Square Root Step VRSQRTS on page A8-1041
Vector Reverse VREV16, VREV32, VREV64 on page A8-1029
Vector Saturating Absolute VQABS on page A8-995
Vector Saturating Move and Narrow VQMOVN, VQMOVUN on page A8-1005
Vector Saturating Negate VQNEG on page A8-1007
Vector Swap VSWP on page A8-1093
Vector Table Lookup VTBL, VTBX on page A8-1095
Table A4-24 Miscellaneous Advanced SIMD data-processing instructions (continued)
Instruction See
Vector Transpose VTRN on page A8-1097
Vector Unzip VUZP on page A8-1101
Vector Zip VZIP on page A8-1103
A4.14 Floating-point data-processing instructions

Table A4-25 summarizes the data-processing instructions in the Floating-point (VFP) instruction set.
For details of the floating-point arithmetic used by Floating-point instructions, see Floating-point data types and
arithmetic on page A2-62.
Table A4-25 Floating-point data-processing instructions
Instruction See
Absolute value VABS on page A8-825
Add VADD (floating-point) on page A8-831
Compare, optionally with exceptions enabled VCMP, VCMPE on page A8-865
Convert between floating-point and integer VCVT, VCVTR (between floating-point and integer, Floating-point) on
page A8-871
Convert between floating-point and fixed-point VCVT (between floating-point and fixed-point, Floating-point) on
page A8-875
Convert between double-precision and single-precision VCVT (between double-precision and single-precision) on page A8-877
Convert between half-precision and single-precision VCVTB, VCVTT on page A8-881
Divide VDIV on page A8-883
Multiply Accumulate VMLA, VMLS (floating-point) on page A8-933
Multiply Subtract
Fused Multiply Accumulate VFMA, VFMS on page A8-893
Fused Multiply Subtract
Move immediate value to extension register VMOV (immediate) on page A8-937
Copy from one extension register to another VMOV (register) on page A8-939
Multiply VMUL (floating-point) on page A8-961
Negate, by inverting the sign bit VNEG on page A8-969
Multiply Accumulate and Negate VNMLA, VNMLS, VNMUL on page A8-971
Multiply Subtract and Negate
Multiply and Negate
Fused Negate Multiply Accumulate VFNMA, VFNMS on page A8-895
Fused Negate Multiply Subtract
Square Root VSQRT on page A8-1059
Subtract VSUB (floating-point) on page A8-1087
Chapter A5
ARM Instruction Set Encoding
This chapter describes the encoding of the ARM instruction set. It contains the following sections:
• ARM instruction set encoding on page A5-192.
• Data-processing and miscellaneous instructions on page A5-194.
• Load/store word and unsigned byte on page A5-206.
• Media instructions on page A5-207.
• Branch, branch with link, and block data transfer on page A5-212.
• Coprocessor instructions, and Supervisor Call on page A5-213.
• Unconditional instructions on page A5-214.
Note
• Architecture variant information in this chapter describes the architecture variant or extension in which the
instruction encoding was introduced into the ARM instruction set. All means that the instruction encoding
was introduced in ARMv4 or earlier, and so is in all variants of the ARM instruction set covered by this
manual.
• In the decode tables in this chapter, an entry of - for a field value means the value of the field does not affect
the decoding.
A5 ARM Instruction Set Encoding
A5.1 ARM instruction set encoding

The ARM instruction stream is a sequence of word-aligned words. Each ARM instruction is a single 32-bit word in
that stream. The encoding of an ARM instruction is:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond op1 op
Table A5-1 shows the major subdivisions of the ARM instruction set, determined by bits[31:25, 4].
Most ARM instructions can be conditional, with a condition determined by bits[31:28] of the instruction, the cond
field. For more information, see The condition code field. This applies to all instructions except those with the cond
field equal to 0b1111.
Table A5-1 ARM instruction encoding
cond op1 op Instruction classes
not 1111 00x - Data-processing and miscellaneous instructions on page A5-194.
010 - Load/store word and unsigned byte on page A5-206.
011 0 Load/store word and unsigned byte on page A5-206.
1 Media instructions on page A5-207.
10x - Branch, branch with link, and block data transfer on page A5-212.
11x - Coprocessor instructions, and Supervisor Call on page A5-213.

Includes Floating-point instructions and Advanced SIMD data transfers, see Chapter A7 Advanced SIMD
and Floating-point Instruction Encoding.
1111 - - If the cond field is 0b1111, the instruction can only be executed unconditionally, see Unconditional
instructions on page A5-214.
Includes Advanced SIMD instructions, see Chapter A7 Advanced SIMD and Floating-point
Instruction Encoding.
A5.1.1 The condition code field

Every conditional instruction contains a 4-bit condition code field, the cond field, in bits 31 to 28:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond
This field contains one of the values 0b0000-0b1110, as shown in Table A8-1 on page A8-286. Most instruction
mnemonics can be extended with the letters defined in the mnemonic extension column of this table.
If the always (AL) condition is specified, the instruction is executed irrespective of the value of the condition flags.
The absence of a condition code on an instruction mnemonic implies the AL condition code.
A5.1.2 UNDEFINED and UNPREDICTABLE instruction set space

An attempt to execute an unallocated instruction results in either:
• Unpredictable behavior. The instruction is described as UNPREDICTABLE.
• An Undefined Instruction exception. The instruction is described as UNDEFINED.
An instruction is UNDEFINED if it is declared as UNDEFINED in an instruction description, or in this chapter.
An instruction is UNPREDICTABLE if:
• It is declared as UNPREDICTABLE in an instruction description or in this chapter.
• The pseudocode for that encoding does not indicate that a different special case applies, and a bit marked (0)
or (1) in the encoding diagram of an instruction is not 0 or 1 respectively.
For more information about UNDEFINED and UNPREDICTABLE instruction behavior, see Undefined Instruction
Unless otherwise specified:
• ARM instructions introduced in an architecture variant are UNDEFINED in earlier architecture variants.
• ARM instructions introduced in one or more architecture extensions are UNDEFINED in an implementation
that does not include any of those extensions.
A5.1.3 The PC and the use of 0b1111 as a register specifier

In ARM instructions, the use of 0b1111 as a register specifier specifies the PC.
Many instructions are UNPREDICTABLE if they use 0b1111 as a register specifier. This is specified by pseudocode in
the instruction description.
Note
In ARMv7, ARM deprecates use of the PC as the base register in any store instruction.
A5.1.4 The SP and the use of 0b1101 as a register specifier

In ARM instructions, the use of 0b1101 as a register specifier specifies the SP.
ARM deprecates using SP for any purpose other than as a stack pointer.
A5.2 Data-processing and miscellaneous instructions

The encoding of ARM data-processing instructions, and some miscellaneous instructions is:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 op op1 op2
Table A5-2 shows the allocation of encodings in this space.
Table A5-2 Data-processing and miscellaneous instructions
op op1 op2 Instruction or instruction class Variant
0 not 10xx0 xxx0 Data-processing (register) on page A5-195 -
0xx1 Data-processing (register-shifted register) on page A5-195 -
10xx0 0xxx Miscellaneous instructions on page A5-205 -
1xx0 Halfword multiply and multiply accumulate on page A5-200 -
0xxxx 1001 Multiply and multiply accumulate on page A5-200 -
1xxxx 1001 Synchronization primitives on page A5-203 -
not 0xx1x 1011 Extra load/store instructions on page A5-201 -
11x1 Extra load/store instructions on page A5-201 -
0xx10 11x1 Extra load/store instructions on page A5-201 -
0xx1x 1011 Extra load/store instructions, unprivileged on page A5-202 -
0xx11 11x1 Extra load/store instructions, unprivileged on page A5-202 -
1 not 10xx0 - Data-processing (immediate) on page A5-197 -
10000 - 16-bit immediate load, MOV (immediate) on page A8-485 v6T2
10100 - High halfword 16-bit immediate load, MOVT on page A8-492 v6T2
10x10 - MSR (immediate), and hints on page A5-204 -
A5.2.1 Data-processing (register)

The encoding of ARM data-processing (register) instructions is:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 op imm5 op2 0
Table A5-3 shows the allocation of encodings in this space. These encodings are in all architecture variants.
Table A5-3 Data-processing (register) instructions
op op2 imm5 Instruction See
0000x - - Bitwise AND AND (register) on page A8-324
0001x - - Bitwise Exclusive OR EOR (register) on page A8-385
0010x - - Subtract SUB (register) on page A8-713
0011x - - Reverse Subtract RSB (register) on page A8-577
0100x - - Add ADD (register, ARM) on page A8-310
0101x - - Add with Carry ADC (register) on page A8-300
0110x - - Subtract with Carry SBC (register) on page A8-595
0111x - - Reverse Subtract with Carry RSC (register) on page A8-583
10xx0 - - See Data-processing and miscellaneous instructions on page A5-194
10001 - - Test TST (register) on page A8-747
10011 - - Test Equivalence TEQ (register) on page A8-741
10101 - - Compare CMP (register) on page A8-370
10111 - - Compare Negative CMN (register) on page A8-364
1100x - - Bitwise OR ORR (register) on page A8-519
1101x 00 00000 Move MOV (register, ARM) on page A8-489
not 00000 Logical Shift Left LSL (immediate) on page A8-469
01 - Logical Shift Right LSR (immediate) on page A8-473
10 - Arithmetic Shift Right ASR (immediate) on page A8-328
11 00000 Rotate Right with Extend RRX on page A8-573
not 00000 Rotate Right ROR (immediate) on page A8-569
1110x - - Bitwise Bit Clear BIC (register) on page A8-340
1111x - - Bitwise NOT MVN (register) on page A8-507
A5.2.2 Data-processing (register-shifted register)

The encoding of ARM data-processing (register-shifted register) instructions is:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 op1 0 op2 1
Table A5-4 Data-processing (register-shifted register) instructions
op1 op2 Instruction See
0000x - Bitwise AND AND (register-shifted register) on page A8-326
0001x - Bitwise Exclusive OR EOR (register-shifted register) on page A8-387
0010x - Subtract SUB (register-shifted register) on page A8-715
0011x - Reverse Subtract RSB (register-shifted register) on page A8-579
0100x - Add ADD (register-shifted register) on page A8-312
0101x - Add with Carry ADC (register-shifted register) on page A8-302
0110x - Subtract with Carry SBC (register-shifted register) on page A8-597
0111x - Reverse Subtract with Carry RSC (register-shifted register) on page A8-585
10xx0 - See Data-processing and miscellaneous instructions on page A5-194
10001 - Test TST (register-shifted register) on page A8-749
10011 - Test Equivalence TEQ (register-shifted register) on page A8-743
10101 - Compare CMP (register-shifted register) on page A8-372
10111 - Compare Negative CMN (register-shifted register) on page A8-366
1100x - Bitwise OR ORR (register-shifted register) on page A8-521
1101x 00 Logical Shift Left LSL (register) on page A8-471
01 Logical Shift Right LSR (register) on page A8-475
10 Arithmetic Shift Right ASR (register) on page A8-330
11 Rotate Right ROR (register) on page A8-571
1110x - Bitwise Bit Clear BIC (register-shifted register) on page A8-342
1111x - Bitwise NOT MVN (register-shifted register) on page A8-509
A5.2.3 Data-processing (immediate)

The encoding of ARM data-processing (immediate) instructions is:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 op Rn
Table A5-5 Data-processing (immediate) instructions
op Rn Instruction See
0000x - Bitwise AND AND (immediate) on page A8-322
0001x - Bitwise Exclusive OR EOR (immediate) on page A8-383
0010x not 1111 Subtract SUB (immediate, ARM) on page A8-711
1111 Form PC-relative address ADR on page A8-320
0011x - Reverse Subtract RSB (immediate) on page A8-575
0100x not 1111 Add ADD (immediate, ARM) on page A8-306
1111 Form PC-relative address ADR on page A8-320
0101x - Add with Carry ADC (immediate) on page A8-298
0110x - Subtract with Carry SBC (immediate) on page A8-593
0111x - Reverse Subtract with Carry RSC (immediate) on page A8-581
10xx0 - See Data-processing and miscellaneous instructions on page A5-194
10001 - Test TST (immediate) on page A8-745
10011 - Test Equivalence TEQ (immediate) on page A8-739
10101 - Compare CMP (immediate) on page A8-368
10111 - Compare Negative CMN (immediate) on page A8-362
1100x - Bitwise OR ORR (immediate) on page A8-517
1101x - Move MOV (immediate) on page A8-485
1110x - Bitwise Bit Clear BIC (immediate) on page A8-338
1111x - Bitwise NOT MVN (immediate) on page A8-505
These instructions all have modified immediate constants, rather than a simple 12-bit binary number. This provides
a more useful range of values. For details, see Modified immediate constants in ARM instructions.
A5.2.4 Modified immediate constants in ARM instructions

The encoding of a modified immediate constant in an ARM instruction is:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
rotation a b c d e f g h
Table A5-6 shows the range of modified immediate constants available in ARM data-processing instructions, and
their encoding in the a, b, c, d, e, f, g, and h bits and the rotation field in the instruction.
Table A5-6 Encoding of modified immediates in ARM processing instructions
rotation <const> a
0000 00000000 00000000 00000000 abcdefgh
0001 gh000000 00000000 00000000 00abcdef
0010 efgh0000 00000000 00000000 0000abcd
0011 cdefgh00 00000000 00000000 000000ab
0100 abcdefgh 00000000 00000000 00000000
. .
. . 8-bit values shifted to other even-numbered positions
. .
1001 00000000 00abcdef gh000000 00000000
. .
. . 8-bit values shifted to other even-numbered positions
. .
1110 00000000 00000000 0000abcd efgh0000
1111 00000000 00000000 000000ab cdefgh00
a. This table shows the immediate constant value in binary form, to relate abcdefgh to the encoding diagram.
In assembly syntax, the immediate value is specified in the usual way (a decimal number by default).
Note
The range of values available in ARM modified immediate constants is slightly different from the range of values
available in 32-bit Thumb instructions. See Modified immediate constants in Thumb instructions on page A6-230.
Carry out
A logical instruction with the rotation field set to 0b0000 does not affect APSR.C. Otherwise, a logical flag-setting
instruction sets APSR.C to the value of bit[31] of the modified immediate constant.
Constants with multiple encodings

Some constant values have multiple possible encodings. In this case, a UAL assembler must select the encoding
with the lowest unsigned value of the rotation field. This is the encoding that appears first in Table A5-6. For
example, the constant #3 must be encoded with (rotation, abcdefgh) == (0b0000, 0b00000011), not (0b0001,
0b00001100), (0b0010, 0b00110000), or (0b0011, 0b11000000).
In particular, this means that all constants in the range 0-255 are encoded with rotation == 0b0000, and permitted
constants outside that range are encoded with rotation != 0b0000. A flag-setting logical instruction with a modified
immediate constant therefore leaves APSR.C unchanged if the constant is in the range 0-255 and sets it to the most
significant bit of the constant otherwise. This matches the behavior of Thumb modified immediate constants for all
constants that are permitted in both the ARM and Thumb instruction sets.
An alternative syntax is available for a modified immediate constant that permits the programmer to specify the
encoding directly. In this syntax, #<const> is instead written as #<byte>, #<rot>, where:
<byte> Is the numeric value of abcdefgh, in the range 0-255.
<rot> Is twice the numeric value of rotation, an even number in the range 0-30.
This syntax permits all ARM data-processing instructions with modified immediate constants to be disassembled
to assembler syntax that assembles to the original instruction.
This syntax also makes it possible to write variants of some flag-setting logical instructions that have different
effects on APSR.C to those obtained with the normal #<const> syntax. For example, ANDS R1, R2, #12, #2 has the
same behavior as ANDS R1, R2, #3 except that it sets APSR.C to 0 instead of leaving it unchanged. Such variants of
flag-setting logical instructions do not have equivalents in the Thumb instruction set, and ARM deprecates their use.
Operation of modified immediate constants, ARM instructions

// ARMExpandImm()
// ==============
bits(32) ARMExpandImm(bits(12) imm12)
// APSR.C argument to following function call does not affect the imm32 result.
(imm32, -) = ARMExpandImm_C(imm12, APSR.C);
return imm32;
// ARMExpandImm_C()
// ================
(bits(32), bit) ARMExpandImm_C(bits(12) imm12, bit carry_in)
unrotated_value = ZeroExtend(imm12<7:0>, 32);

(imm32, carry_out) = Shift_C(unrotated_value, SRType_ROR, 2*UInt(imm12<11:8>), carry_in);
return (imm32, carry_out);
A5.2.5 Multiply and multiply accumulate

The encoding of ARM multiply and multiply accumulate instructions is:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 0 op 1 0 0 1
Table A5-7 Multiply and multiply accumulate instructions
op Instruction See Variant
000x Multiply MUL on page A8-503 All
001x Multiply Accumulate MLA on page A8-481 All
0100 Unsigned Multiply Accumulate Accumulate Long UMAAL on page A8-775 v6
0101 UNDEFINED - -
0110 Multiply and Subtract MLS on page A8-483 v6T2
0111 UNDEFINED - -
100x Unsigned Multiply Long UMULL on page A8-779 All
101x Unsigned Multiply Accumulate Long UMLAL on page A8-777 All
110x Signed Multiply Long SMULL on page A8-647 All
111x Signed Multiply Accumulate Long SMLAL on page A8-625 All
A5.2.6 Saturating addition and subtraction

The encoding of ARM saturating addition and subtraction instructions is:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 0 op 0 0 1 0 1
Table A5-8 shows the allocation of encodings in this space. These encodings are all available in ARMv5TE and
above, and are UNDEFINED in earlier variants of the architecture.
Table A5-8 Saturating addition and subtraction instructions
op Instruction See
00 Saturating Add QADD on page A8-541
01 Saturating Subtract QSUB on page A8-555
10 Saturating Double and Add QDADD on page A8-549
11 Saturating Double and Subtract QDSUB on page A8-551
A5.2.7 Halfword multiply and multiply accumulate

The encoding of ARM halfword multiply and multiply accumulate instructions is:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 0 op1 0 1 op 0
These encodings are signed multiply (SMUL) and signed multiply accumulate (SMLA) instructions, operating on 16-bit
values, or mixed 16-bit and 32-bit values. The results and accumulators are 32-bit or 64-bit.
These encodings are all available in ARMv5TE and above, and are UNDEFINED in earlier variants of the architecture.
Table A5-9 Halfword multiply and multiply accumulate instructions
op1 op Instruction See
00 - Signed 16-bit multiply, 32-bit accumulate SMLABB, SMLABT, SMLATB, SMLATT on page A8-621
01 0 Signed 16-bit × 32-bit multiply, 32-bit accumulate SMLAWB, SMLAWT on page A8-631
1 Signed 16-bit × 32-bit multiply, 32-bit result SMULWB, SMULWT on page A8-649
10 - Signed 16-bit multiply, 64-bit accumulate SMLALBB, SMLALBT, SMLALTB, SMLALTT on page A8-627
11 - Signed 16-bit multiply, 32-bit result SMULBB, SMULBT, SMULTB, SMULTT on page A8-645
A5.2.8 Extra load/store instructions

The encoding of extra ARM load/store instructions is:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 op1 Rn 1 op2 1
If (op2 == 0b00), then see Data-processing and miscellaneous instructions on page A5-194.
If ((op1 == 0b0xx10) && (op2 == 0b01)) or ((op1 == 0b0xx11) && (op2 != 0b00)) then see Extra load/store
instructions, unprivileged on page A5-202.
Otherwise, Table A5-10 shows the allocation of encodings in this space.
Table A5-10 Extra load/store instructions
op2 op1 Rn Instruction See Variant
01 xx0x0 - Store Halfword STRH (register) on page A8-703 All
xx0x1 - Load Halfword LDRH (register) on page A8-447 All
xx1x0 - Store Halfword STRH (immediate, ARM) on page A8-701 All
xx1x1 not 1111 Load Halfword LDRH (immediate, ARM) on page A8-443 All
1111 Load Halfword LDRH (literal) on page A8-445 All
10 xx0x0 - Load Dual LDRD (register) on page A8-431 v5TE
xx0x1 - Load Signed Byte LDRSB (register) on page A8-455 All
xx1x0 not 1111 Load Dual LDRD (immediate) on page A8-427 v5TE
1111 Load Dual LDRD (literal) on page A8-429 v5TE
xx1x1 not 1111 Load Signed Byte LDRSB (immediate) on page A8-451 All
1111 Load Signed Byte LDRSB (literal) on page A8-453 All
Table A5-10 Extra load/store instructions (continued)
11 xx0x0 - Store Dual STRD (register) on page A8-689 All
xx0x1 - Load Signed Halfword LDRSH (register) on page A8-463 All
xx1x0 - Store Dual STRD (immediate) on page A8-687 All
xx1x1 not 1111 Load Signed Halfword LDRSH (immediate) on page A8-459 All
1111 Load Signed Halfword LDRSH (literal) on page A8-461 All
A5.2.9 Extra load/store instructions, unprivileged

The encoding of unprivileged extra ARM load/store instructions is:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 0 1 op 1 op2 1
If op2 == 0b00 then see Data-processing and miscellaneous instructions on page A5-194.
If (op == 0b0 && op2 == 0b1x) then see Extra load/store instructions on page A5-201.
Table A5-11 Extra load/store instructions, unprivileged
op2 op Instruction See Variant
01 0 Store Halfword Unprivileged STRHT on page A8-705 v6T2
1 Load Halfword Unprivileged LDRHT on page A8-449 v6T2
10 1 Load Signed Byte Unprivileged LDRSBT on page A8-457 v6T2
11 1 Load Signed Halfword Unprivileged LDRSHT on page A8-465 v6T2
A5.2.10 Synchronization primitives

The encoding of ARM synchronization primitive instructions is:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 op 1 0 0 1
Other encodings in this space are UNDEFINED.
Table A5-12 Synchronization primitives
0x00 Swap Word, Swap Byte SWP, SWPB on page A8-723 a All
1000 Store Register Exclusive STREX on page A8-691 v6
1001 Load Register Exclusive LDREX on page A8-433 v6
1010 Store Register Exclusive Doubleword STREXD on page A8-695 v6K
1011 Load Register Exclusive Doubleword LDREXD on page A8-437 v6K
1100 Store Register Exclusive Byte STREXB on page A8-693 v6K
1101 Load Register Exclusive Byte LDREXB on page A8-435 v6K
1110 Store Register Exclusive Halfword STREXH on page A8-697 v6K
1111 Load Register Exclusive Halfword LDREXH on page A8-439 v6K
a. ARM deprecates the use of these instructions.
A5.2.11 MSR (immediate), and hints

The encoding of ARM MSR (immediate) and hint instructions is:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 1 0 op 1 0 op1 op2
Table A5-13 shows the allocation of encodings in this space. Encodings with op set to 0, op1 set to 0b0000, and a
value of op2 that is not shown in the table, are unallocated hints and behave as if op2 is set to 0b00000000. These
unallocated hint encodings are reserved and software must not use them.
Table A5-13 MSR (immediate), and hints
op op1 op2 Instruction See Variant
0 0000 00000000 No Operation hint NOP on page A8-511 v6K, v6T2
00000001 Yield hint YIELD on page A8-1109 v6K
00000010 Wait For Event hint WFE on page A8-1105 v6K
00000011 Wait For Interrupt hint WFI on page A8-1107 v6K
00000100 Send Event hint SEV on page A8-607 v6K
00010100 Consumption of Speculative Data Barrier CSDB on page A8-376 All
1111xxxx Debug hint DBG on page A8-378 v7
0100 - Move to Special register, Application level MSR (immediate) on page A8-499 All
1x00
xx01 - Move to Special register, System level MSR (immediate) on page B9-1982 All
xx1x
1 - - Move to Special register, System level MSR (immediate) on page B9-1982 All
A5.2.12 Miscellaneous instructions

The encoding of some miscellaneous ARM instructions is:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 0 op 0 op1 B 0 op2
Table A5-14 shows the allocation of encodings in this space. Other encodings in this space are UNDEFINED.
Table A5-14 Miscellaneous instructions
op2 B op op1 Instruction or instruction class See Variant
000 1 x0 xxxx Move from Banked or Special register MRS (Banked register) on page B9-1978 v7VE
x1 xxxx Move to Banked or Special register MSR (Banked register) on page B9-1980 v7VE
0 x0 xxxx Move from Special register MRS on page A8-497 All

MRS on page B9-1976
01 xx00 Move to Special register, Application level MSR (register) on page A8-501 All
xx01 Move to Special register, System level MSR (register) on page B9-1984 All
xx1x
11 - Move to Special register, System level MSR (register) on page B9-1984 All
001 - 01 - Branch and Exchange BX on page A8-350 v4T
11 - Count Leading Zeros CLZ on page A8-360 v5T
010 - 01 - Branch and Exchange Jazelle BXJ on page A8-352 v5TEJ
011 - 01 - Branch with Link and Exchange BLX (register) on page A8-348 v5T
101 - - - Saturating addition and subtraction Saturating addition and subtraction on -

page A5-200
110 - 11 - Exception Return ERET on page B9-1968 v7VE
111 - 01 - Breakpoint BKPT on page A8-344 v5T
10 - Hypervisor Call HVC on page B9-1970 v7VE
11 - Secure Monitor Call SMC (previously SMI) on page B9-1988 Security

Extensions
A5.3 Load/store word and unsigned byte
A5.3 Load/store word and unsigned byte

The encoding of ARM load/store word and unsigned byte instructions is:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 A op1 Rn B
These instructions have either A == 0 or B == 0. For instructions with A == 1 and B == 1, see Media instructions
on page A5-207.
Otherwise, Table A5-15 shows the allocation of encodings in this space. These encodings are in all architecture
variants.
Table A5-15 Single data transfer instructions
A op1 B Rn Instruction See
0 xx0x0 not 0x010 - - Store Register STR (immediate, ARM) on page A8-675
1 xx0x0 not 0x010 0 - Store Register STR (register) on page A8-677
0 0x010 - - Store Register Unprivileged STRT on page A8-707
1 0x010 0 -
0 xx0x1 not 0x011 - not 1111 Load Register (immediate) LDR (immediate, ARM) on page A8-409
1111 Load Register (literal) LDR (literal) on page A8-411
1 xx0x1 not 0x011 0 - Load Register LDR (register, ARM) on page A8-415
0 0x011 - - Load Register Unprivileged LDRT on page A8-467
1 0x011 0 -
0 xx1x0 not 0x110 - - Store Register Byte (immediate) STRB (immediate, ARM) on page A8-681
1 xx1x0 not 0x110 0 - Store Register Byte (register) STRB (register) on page A8-683
0 0x110 - - Store Register Byte Unprivileged STRBT on page A8-685
1 0x110 0 -
0 xx1x1 not 0x111 - not 1111 Load Register Byte (immediate) LDRB (immediate, ARM) on page A8-419
1111 Load Register Byte (literal) LDRB (literal) on page A8-421
1 xx1x1 not 0x111 0 - Load Register Byte (register) LDRB (register) on page A8-423
0 0x111 - - Load Register Byte Unprivileged LDRBT on page A8-425
1 0x111 0 -
A5.4 Media instructions

The encoding of ARM media instructions is:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 op1 Rd op2 1 Rn
Table A5-16 Media instructions
op1 op2 Rd Rn cond Instructions See Variant
000xx - - - - - Parallel addition and subtraction, signed on

page A5-208
001xx - - - - - Parallel addition and subtraction, unsigned on

page A5-208
01xxx - - - - - Packing, unpacking, saturation, and reversal

on page A5-209
10xxx - - - - - Signed multiply, signed and unsigned divide on

page A5-211
11000 000 1111 - - Unsigned Sum of Absolute Differences USAD8 on page A8-793 v6
000 not - - Unsigned Sum of Absolute Differences USADA8 on page A8-795 v6

1111 and Accumulate
1101x x10 - - - Signed Bit Field Extract SBFX on page A8-599 v6T2
1110x x00 - 1111 - Bit Field Clear BFC on page A8-334 v6T2
not - Bit Field Insert BFI on page A8-336 v6T2

1111
1111x x10 - - - Unsigned Bit Field Extract UBFX on page A8-757 v6T2
11111 111 - - 1110 Permanently UNDEFINED UDF on page A8-759 All a
not -a All
1110
a. Issue C.a of this manual first defines an assembler mnemonic for this encoding. This mnemonic applies only to the unconditional encoding,
with cond set to 0b1110.
A5.4.1 Parallel addition and subtraction, signed

The encoding of ARM signed parallel addition and subtraction instructions is:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 0 op1 op2 1
Table A5-17 shows the allocation of encodings in this space. These encodings are all available in ARMv6 and
Table A5-17 Signed parallel addition and subtraction instructions
01 000 Add 16-bit SADD16 on page A8-587
001 Add and Subtract with Exchange, 16-bit SASX on page A8-591
010 Subtract and Add with Exchange, 16-bit SSAX on page A8-657
011 Subtract 16-bit SSUB16 on page A8-659
100 Add 8-bit SADD8 on page A8-589
111 Subtract 8-bit SSUB8 on page A8-661
Saturating instructions
10 000 Saturating Add 16-bit QADD16 on page A8-543
001 Saturating Add and Subtract with Exchange, 16-bit QASX on page A8-547
010 Saturating Subtract and Add with Exchange, 16-bit QSAX on page A8-553
011 Saturating Subtract 16-bit QSUB16 on page A8-557
100 Saturating Add 8-bit QADD8 on page A8-545
111 Saturating Subtract 8-bit QSUB8 on page A8-559
Halving instructions
11 000 Halving Add 16-bit SHADD16 on page A8-609
001 Halving Add and Subtract with Exchange, 16-bit SHASX on page A8-613
010 Halving Subtract and Add with Exchange, 16-bit SHSAX on page A8-615
011 Halving Subtract 16-bit SHSUB16 on page A8-617
100 Halving Add 8-bit SHADD8 on page A8-611
111 Halving Subtract 8-bit SHSUB8 on page A8-619
A5.4.2 Parallel addition and subtraction, unsigned

The encoding of ARM unsigned parallel addition and subtraction instructions is:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 1 op1 op2 1
Table A5-18 shows the allocation of encodings in this space. These encodings are all available in ARMv6 and
Table A5-18 Unsigned parallel addition and subtractions instructions
01 000 Add 16-bit UADD16 on page A8-751
001 Add and Subtract with Exchange, 16-bit UASX on page A8-755
010 Subtract and Add with Exchange, 16-bit USAX on page A8-801
011 Subtract 16-bit USUB16 on page A8-803
100 Add 8-bit UADD8 on page A8-753
111 Subtract 8-bit USUB8 on page A8-805
10 000 Saturating Add 16-bit UQADD16 on page A8-781
001 Saturating Add and Subtract with Exchange, 16-bit UQASX on page A8-785
010 Saturating Subtract and Add with Exchange, 16-bit UQSAX on page A8-787
011 Saturating Subtract 16-bit UQSUB16 on page A8-789
100 Saturating Add 8-bit UQADD8 on page A8-783
111 Saturating Subtract 8-bit UQSUB8 on page A8-791
11 000 Halving Add 16-bit UHADD16 on page A8-763
001 Halving Add and Subtract with Exchange, 16-bit UHASX on page A8-767
010 Halving Subtract and Add with Exchange, 16-bit UHSAX on page A8-769
011 Halving Subtract 16-bit UHSUB16 on page A8-771
100 Halving Add 8-bit UHADD8 on page A8-765
111 Halving Subtract 8-bit UHSUB8 on page A8-773
A5.4.3 Packing, unpacking, saturation, and reversal

The encoding of ARM packing, unpacking, saturation, and reversal instructions is:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 1 op1 A op2 1
Table A5-19 on page A5-210 shows the allocation of encodings in this space.
Table A5-19 Packing, unpacking, saturation, and reversal instructions
op1 op2 A Instructions See Variant
000 xx0 - Pack Halfword PKH on page A8-523 v6
011 not 1111 Signed Extend and Add Byte 16-bit SXTAB16 on page A8-727 v6
1111 Signed Extend Byte 16-bit SXTB16 on page A8-733 v6
101 - Select Bytes SEL on page A8-603 v6
01x xx0 - Signed Saturate SSAT on page A8-653 v6
010 001 - Signed Saturate, two 16-bit SSAT16 on page A8-655 v6
011 not 1111 Signed Extend and Add Byte SXTAB on page A8-725 v6
1111 Signed Extend Byte SXTB on page A8-731 v6
011 001 - Byte-Reverse Word REV on page A8-563 v6
011 not 1111 Signed Extend and Add Halfword SXTAH on page A8-729 v6
1111 Signed Extend Halfword SXTH on page A8-735 v6
101 - Byte-Reverse Packed Halfword REV16 on page A8-565 v6
100 011 not 1111 Unsigned Extend and Add Byte 16-bit UXTAB16 on page A8-809 v6
1111 Unsigned Extend Byte 16-bit UXTB16 on page A8-815 v6
11x xx0 - Unsigned Saturate USAT on page A8-797 v6
110 001 - Unsigned Saturate, two 16-bit USAT16 on page A8-799 v6
011 not 1111 Unsigned Extend and Add Byte UXTAB on page A8-807 v6
1111 Unsigned Extend Byte UXTB on page A8-813 v6
111 001 - Reverse Bits RBIT on page A8-561 v6T2
011 not 1111 Unsigned Extend and Add Halfword UXTAH on page A8-811 v6
1111 Unsigned Extend Halfword UXTH on page A8-817 v6
101 - Byte-Reverse Signed Halfword REVSH on page A8-567 v6
A5.4.4 Signed multiply, signed and unsigned divide

The encoding of ARM signed multiply and divide instructions is:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 1 0 op1 A op2 1
Table A5-20 Signed multiply instructions
op1 op2 A Instruction See Variant
000 00x not 1111 Signed Multiply Accumulate Dual SMLAD on page A8-623 v6
1111 Signed Dual Multiply Add SMUAD on page A8-643 v6
01x not 1111 Signed Multiply Subtract Dual SMLSD on page A8-633 v6
1111 Signed Dual Multiply Subtract SMUSD on page A8-651 v6
001 000 - Signed Divide SDIV on page A8-601 v7 a
011 000 - Unsigned Divide UDIV on page A8-761 v7 a
100 00x - Signed Multiply Accumulate Long Dual SMLALD on page A8-629 v6
01x - Signed Multiply Subtract Long Dual SMLSLD on page A8-635 v6
101 00x not 1111 Signed Most Significant Word Multiply Accumulate SMMLA on page A8-637 v6
1111 Signed Most Significant Word Multiply SMMUL on page A8-641 v6
11x - Signed Most Significant Word Multiply Subtract SMMLS on page A8-639 v6
a. Optional in some ARMv7 implementations, see ARMv7 implementation requirements and options for the divide instructions on
page A4-170.
A5.5 Branch, branch with link, and block data transfer
A5.5 Branch, branch with link, and block data transfer

The encoding of ARM branch, branch with link, and block data transfer instructions is:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 0 op Rn R
Table A5-21 Branch, branch with link, and block data transfer instructions
op R Rn Instructions See
0000x0 - - Store Multiple Decrement After STMDA (STMED) on page A8-667
0000x1 - - Load Multiple Decrement After LDMDA/LDMFA on page A8-401
0010x0 - - Store Multiple Increment After STM (STMIA, STMEA) on page A8-665
001001 - - Load Multiple Increment After LDM/LDMIA/LDMFD (ARM) on page A8-399
001011 - not 1101 Load Multiple Increment After LDM/LDMIA/LDMFD (ARM) on page A8-399
1101 Pop multiple registers POP (ARM) on page A8-537
010000 - - Store Multiple Decrement Before STMDB (STMFD) on page A8-669
010010 - not 1101 Store Multiple Decrement Before STMDB (STMFD) on page A8-669
- 1101 Push multiple registers PUSH on page A8-539
0100x1 - - Load Multiple Decrement Before LDMDB/LDMEA on page A8-403
0110x0 - - Store Multiple Increment Before STMIB (STMFA) on page A8-671
0110x1 - - Load Multiple Increment Before LDMIB/LDMED on page A8-405
0xx1x0 - - Store Multiple (user registers) STM (User registers) on page B9-1994
0xx1x1 0 - Load Multiple (user registers) LDM (User registers) on page B9-1974
1 - Load Multiple (exception return) LDM (exception return) on page B9-1972
10xxxx - - Branch B on page A8-332
11xxxx - - Branch with Link BL, BLX (immediate) on page A8-346
A5.6 Coprocessor instructions, and Supervisor Call
A5.6 Coprocessor instructions, and Supervisor Call

The encoding of ARM coprocessor instructions and the Supervisor Call instruction is:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 op1 Rn coproc op
Table A5-22 shows the allocation of encodings in this space:
Table A5-22 Coprocessor instructions, and Supervisor Call
coproc op1 op Rn Instructions See Variant
- 00000x - - UNDEFINED - -
11xxxx - - Supervisor Call SVC (previously SWI) on page A8-721 All
not 0xxxx0 - - Store Coprocessor STC, STC2 on page A8-663 All

101x not 000x00
0xxxx1 - not 1111 Load Coprocessor (immediate) LDC, LDC2 (immediate) on page A8-393 All
not 000x01
1111 Load Coprocessor (literal) LDC, LDC2 (literal) on page A8-395 All
000100 - - Move to Coprocessor from two MCRR, MCRR2 on page A8-479 v5TE
ARM core registers
000101 - - Move to two ARM core MRRC, MRRC2 on page A8-495 v5TE
registers from Coprocessor
10xxxx 0 - Coprocessor data operations CDP, CDP2 on page A8-356 All
10xxx0 1 - Move to Coprocessor from MCR, MCR2 on page A8-477 All

ARM core register
10xxx1 1 - Move to ARM core register MRC, MRC2 on page A8-493 All
from Coprocessor
101x 0xxxxx - - Advanced SIMD, Extension register load/store instructions on

not 000x0x Floating-point page A7-272
00010x - - Advanced SIMD, 64-bit transfers between ARM core and extension
Floating-point registers on page A7-277
10xxxx 0 - Floating-point data processing Floating-point data-processing instructions on

page A7-270
10xxxx 1 - Advanced SIMD, 8, 16, and 32-bit transfer between ARM core and
Floating-point extension registers on page A7-276
For more information about specific coprocessors see Coprocessor support on page A2-93.
A5.7 Unconditional instructions

The encoding of ARM unconditional instructions is:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 op1 Rn op
Other encodings in this space are UNDEFINED in ARMv5 and above.
All encodings in this space are UNPREDICTABLE in ARMv4 and ARMv4T.
Table A5-23 Unconditional instructions
op1 op Rn Instruction See Variant
0xxxxxxx - - - Memory hints, Advanced SIMD instructions, and

miscellaneous instructions on page A5-215
100xx1x0 - - Store Return State SRS (ARM) on page B9-1992 v6
100xx0x1 - - Return From Exception RFE on page B9-1986 v6
101xxxxx - - Branch with Link and Exchange BL, BLX (immediate) on page A8-346 v5
110xxxx0 - - Store Coprocessor STC, STC2 on page A8-663 v5

not 11000x00
110xxxx1 - not 1111 Load Coprocessor (immediate) LDC, LDC2 (immediate) on page A8-393 v5
not 11000x01
1111 Load Coprocessor (literal) LDC, LDC2 (literal) on page A8-395 v5
11000100 - - Move to Coprocessor from two ARM MCRR, MCRR2 on page A8-479 v6
core registers
11000101 - - Move to two ARM core registers MRRC, MRRC2 on page A8-495 v6
from Coprocessor
1110xxxx 0 - Coprocessor data operations CDP, CDP2 on page A8-356 v5
1110xxx0 1 - Move to Coprocessor from ARM MCR, MCR2 on page A8-477 v5

core register
1110xxx1 1 - Move to ARM core register from MRC, MRC2 on page A8-493 v5
Coprocessor
A5.7.1 Memory hints, Advanced SIMD instructions, and miscellaneous instructions

The encoding of ARM memory hint and Advanced SIMD instructions, and some miscellaneous instruction is:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 op1 Rn op2
Other encodings in this space are UNDEFINED in ARMv5 and above. All these encodings are UNPREDICTABLE in
ARMv4 and ARMv4T.
Table A5-24 Hints, and Advanced SIMD instructions
0010000 xx0x xxx0 Change Processor State CPS (ARM) on page B9-1966 v6
0010000 0000 xxx1 Set Endianness SETEND on page A8-605 v6
0010010 0111 - UNPREDICTABLE - v5T
01xxxxx - - See Advanced SIMD data-processing instructions on page A7-259 v7
100xxx0 - - See Advanced SIMD element or structure load/store instructions on page A7-273 v7
100x001 - - Unallocated memory hint (treat as NOP) MP Ext a
100x101 - - Preload Instruction PLI (immediate, literal) on page A8-531 v7
100xx11 - - UNPREDICTABLE - -
101x001 - not 1111 Preload Data with intent to Write PLD, PLDW (immediate) on page A8-525 MP Ext a
1111 UNPREDICTABLE - -
101x101 - not 1111 Preload Data PLD, PLDW (immediate) on page A8-525 v5TE
1111 Preload Data PLD (literal) on page A8-527 v5TE
1010011 - - UNPREDICTABLE - -
1010111 0000 - UNPREDICTABLE - -
0001 - Clear-Exclusive CLREX on page A8-358 v6K
001x - UNPREDICTABLE - -
0100 - Data Synchronization Barrier DSB on page A8-381 v6T2
0101 - Data Memory Barrier DMB on page A8-379 v7
0110 - Instruction Synchronization Barrier ISB on page A8-390 v6T2
0111 - UNPREDICTABLE - -
1xxx - UNPREDICTABLE - -
1011x11 - - UNPREDICTABLE -
110x001 xxx0 - Unallocated memory hint (treat as NOP) MP Ext a
110x101 xxx0 - Preload Instruction PLI (register) on page A8-533 v7
111x001 xxx0 - Preload Data with intent to Write PLD, PLDW (register) on page A8-529 MP Ext a
Table A5-24 Hints, and Advanced SIMD instructions (continued)
111x101 xxx0 - Preload Data PLD, PLDW (register) on page A8-529 v5TE
11xxx11 xxx0 - UNPREDICTABLE - -
1111111 1111 Permanently UNDEFINED b - v5
a. Multiprocessing Extensions.
b. See Table A5-16 on page A5-207 for the full range of encodings in this permanently UNDEFINED group.
Chapter A6
Thumb Instruction Set Encoding
This chapter introduces the Thumb instruction set and describes how it uses the ARM programmers’ model. It
contains the following sections:
• Thumb instruction set encoding on page A6-218.
• 16-bit Thumb instruction encoding on page A6-221.
• 32-bit Thumb instruction encoding on page A6-228.
For details of the differences between the Thumb and ThumbEE instruction sets, see Chapter A9 The ThumbEE
Instruction Set.
Note
• Architecture variant information in this chapter describes the architecture variant or extension in which the
instruction encoding was introduced into the Thumb instruction set.
the decoding.
A6 Thumb Instruction Set Encoding
A6.1 Thumb instruction set encoding

The Thumb instruction stream is a sequence of halfword-aligned halfwords. Each Thumb instruction is either a
single 16-bit halfword in that stream, or a 32-bit instruction consisting of two consecutive halfwords in that stream.
If the value of bits[15:11] of the halfword being decoded is one of the following, the halfword is the first halfword
of a 32-bit instruction:
• 0b11101.
• 0b11110.
• 0b11111.
Otherwise, the halfword is a 16-bit instruction.
For details of the encoding of 16-bit Thumb instructions, see 16-bit Thumb instruction encoding on page A6-221.
For details of the encoding of 32-bit Thumb instructions, see 32-bit Thumb instruction encoding on page A6-228.
A6.1.1 UNDEFINED and UNPREDICTABLE instruction set space

An attempt to execute an unallocated instruction results in either:
• Unpredictable behavior. The instruction is described as UNPREDICTABLE.
• An Undefined Instruction exception. The instruction is described as UNDEFINED.
An instruction is UNDEFINED if it is declared as UNDEFINED in an instruction description, or in this chapter.
An instruction is UNPREDICTABLE if:

• A bit marked (0) in the encoding diagram of an instruction is not 0, and the pseudocode for that encoding
does not indicate that a different special case applies when that bit is not 0.
• A bit marked (1) in the encoding diagram of an instruction is not 1, and the pseudocode for that encoding
does not indicate that a different special case applies when that bit is not 1.
• It is declared as UNPREDICTABLE in an instruction description or in this chapter.
For more information about UNDEFINED and UNPREDICTABLE instruction behavior, see Undefined Instruction
Unless otherwise specified:
• Thumb instructions introduced in an architecture variant are either UNPREDICTABLE or UNDEFINED in earlier
architecture variants.
• A Thumb instruction that is provided by one or more of the architecture extensions is either UNPREDICTABLE
or UNDEFINED in an implementation that does not include any of those extensions.
In both cases, the instruction is UNPREDICTABLE if it is a 32-bit instruction in an architecture variant before
ARMv6T2, and UNDEFINED otherwise.
A6.1.2 Use of the PC, and use of 0b1111 as a register specifier

The use of 0b1111 as a register specifier is not normally permitted in Thumb instructions. When a value of 0b1111 is
permitted, a variety of meanings is possible. For register reads, these meanings include:
• Read the PC value, that is, the address of the current instruction + 4. The base register of the table branch
instructions TBB and TBH can be the PC. This means branch tables can be placed in memory immediately after
the instruction.
• Read the word-aligned PC value, that is, the address of the current instruction + 4, with bits[1:0] forced to
zero. The base register of LDC, LDR, LDRB, LDRD (pre-indexed, no writeback), LDRH, LDRSB, and LDRSH instructions
can be the word-aligned PC. This provides PC-relative data addressing. In addition, some encodings of the
ADD and SUB instructions permit their source registers to be 0b1111 for the same purpose.
• Read zero. This is done in some cases when one instruction is a special case of another, more general
instruction, but with one operand zero. In these cases, the instructions are listed on separate pages, with a
special case in the pseudocode for the more general instruction cross-referencing the other page.
For register writes, these meanings include:
• The PC can be specified as the destination register of an LDR instruction. This is done by encoding Rt as
0b1111. The loaded value is treated as an address, and the effect of execution is a branch to that address. Bit[0]
of the loaded value selects whether to execute ARM or Thumb instructions after the branch.
• Some other instructions write the PC in similar ways. An instruction can specify that the PC is written:
— Implicitly, for example, branch instructions.
— Explicitly by a register specifier of 0b1111, for example 16-bit MOV (register) instructions.
— Explicitly by using a register mask, for example LDM instructions.
The address to branch to can be:
— A loaded value, for example, RFE.
— A register value, for example, BX.
— The result of a calculation, for example, TBB or TBH.
The method of choosing the instruction set used after the branch can be:
— Similar to the LDR case, for example, LDM or BX.
— A fixed instruction set other than the one currently being used, for example, the immediate form of BLX.
— Unchanged, for example, branch instructions or 16-bit MOV (register) instructions.
— Set from the {J, T} bits of the SPSR, for RFE and SUBS PC, LR, #imm8.
• Discard the result of a calculation. This is done in some cases when one instruction is a special case of
another, more general instruction, but with the result discarded. In these cases, the instructions are listed on
separate pages, with a special case in the pseudocode for the more general instruction cross-referencing the
other page.
• If the destination register specifier of an LDRB, LDRH, LDRSB, or LDRSH instruction is 0b1111, the instruction is a
memory hint instead of a load operation.
• If the destination register specifier of an MRC instruction is 0b1111, bits[31:28] of the value transferred from
the coprocessor are written to the N, Z, C, and V condition flags in the APSR, and bits[27:0] are discarded.
A6.1.3 Use of the SP, and use of 0b1101 as a register specifier

R13 is defined in the Thumb instruction set so that its use is primarily as a stack pointer, and R13 is normally
identified as SP in Thumb instructions. In 32-bit Thumb instructions, if software uses R13 as a general-purpose
register beyond the architecturally defined constraints described in this section, the results are UNPREDICTABLE.
The restrictions applicable to R13 are described in:

• R13[1:0] definition.
• 32-bit Thumb instruction support for R13.
See also 16-bit Thumb instruction support for R13 on page A6-220.
R13[1:0] definition
Bits[1:0] of R13 are SBZP. Writing a nonzero value to bits[1:0] causes UNPREDICTABLE behavior.
32-bit Thumb instruction support for R13

R13 instruction support is restricted to the following:
• R13 as the source or destination register of a MOV instruction. Only register to register transfers without shifts
are supported, with no flag-setting:
MOV SP, <Rm>
MOV <Rn>, SP
• Using the following instructions to adjust R13 up or down by a multiple of 4:

ADD{W} SP, SP, #<imm>
SUB{W} SP, SP, #<imm>
ADD SP, SP, <Rm>
ADD SP, SP, <Rm>, LSL #<n> ; For <n> = 1, 2, 3
SUB SP, SP, <Rm>
SUB SP, SP, <Rm>, LSL #<n> ; For <n> = 1, 2, 3
• R13 as a base register <Rn> of any load/store instruction. This supports SP-based addressing for load, store,
or memory hint instructions, with positive or negative offsets, with and without writeback.
• R13 as the first operand <Rn> in any ADD{S}, CMN, CMP, or SUB{S} instruction. The add and subtract instructions
support SP-based address generation, with the address going into an ARM core register, R0-R12, or R14. CMN
and CMP are useful for stack checking in some circumstances.
• R13 as the transferred register <Rt> in any LDR or STR instruction.
16-bit Thumb instruction support for R13

For 16-bit data-processing instructions that affect high registers, R13 can only be used as described in 32-bit Thumb
instruction support for R13 on page A6-219. ARM deprecates any other use. This affects the high register forms of
CMP and ADD, where ARM deprecates the use of R13 as <Rm>.
A6.2 16-bit Thumb instruction encoding

The encoding of a 16-bit Thumb instruction is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Opcode
Table A6-1 shows the allocation of 16-bit instruction encodings.
Table A6-1 16-bit Thumb instruction encoding
Opcode Instruction or instruction class Variant
00xxxx Shift (immediate), add, subtract, move, and compare on page A6-222 -
010000 Data-processing on page A6-223 -
010001 Special data instructions and branch and exchange on page A6-224 -
01001x Load from Literal Pool, see LDR (literal) on page A8-411 v4T
0101xx Load/store single data item on page A6-225 -

011xxx
100xxx
10100x Generate PC-relative address, see ADR on page A8-320 v4T
10101x Generate SP-relative address, see ADD (SP plus immediate) on page A8-314 v4T
1011xx Miscellaneous 16-bit instructions on page A6-226 -
11000x Store multiple registers, see STM (STMIA, STMEA) on page A8-665 a v4T
11001x Load multiple registers, see LDM/LDMIA/LDMFD (Thumb) on page A8-397 a v4T
1101xx Conditional branch, and Supervisor Call on page A6-227 -
11100x Unconditional Branch, see B on page A8-332 v4T
a. In ThumbEE, 16-bit load/store multiple instructions are not available. This encoding is used for special
ThumbEE instructions. For details, see Chapter A9 The ThumbEE Instruction Set.
A6.2.1 Shift (immediate), add, subtract, move, and compare

The encoding of 16-bit Thumb shift (immediate), add, subtract, move, and compare instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 Opcode
All these instructions are available since the Thumb instruction set was introduced in ARMv4T.
Table A6-2 16-bit Thumb shift (immediate), add, subtract, move, and compare instructions
Opcode Instruction See
000xx Logical Shift Left a LSL (immediate) on page A8-469
001xx Logical Shift Right LSR (immediate) on page A8-473
010xx Arithmetic Shift Right ASR (immediate) on page A8-328
01100 Add register ADD (register, Thumb) on page A8-308
01101 Subtract register SUB (register) on page A8-713
01110 Add 3-bit immediate ADD (immediate, Thumb) on page A8-304
01111 Subtract 3-bit immediate SUB (immediate, Thumb) on page A8-709
100xx Move MOV (immediate) on page A8-485
101xx Compare CMP (immediate) on page A8-368
110xx Add 8-bit immediate ADD (immediate, Thumb) on page A8-304
111xx Subtract 8-bit immediate SUB (immediate, Thumb) on page A8-709
a. When Opcode is 0b00000, and bits[8:6] are 0b000, this is an encoding for MOV, see
MOV (register, Thumb) on page A8-487.
A6.2.2 Data-processing
The encoding of 16-bit Thumb data-processing instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 0 0 Opcode
Table A6-3 16-bit Thumb data-processing instructions
0000 Bitwise AND AND (register) on page A8-324
0001 Bitwise Exclusive OR EOR (register) on page A8-385
0010 Logical Shift Left LSL (register) on page A8-471
0011 Logical Shift Right LSR (register) on page A8-475
0100 Arithmetic Shift Right ASR (register) on page A8-330
0101 Add with Carry ADC (register) on page A8-300
0110 Subtract with Carry SBC (register) on page A8-595
0111 Rotate Right ROR (register) on page A8-571
1000 Test TST (register) on page A8-747
1001 Reverse Subtract from 0 RSB (immediate) on page A8-575
1010 Compare CMP (register) on page A8-370
1011 Compare Negative CMN (register) on page A8-364
1100 Bitwise OR ORR (register) on page A8-519
1101 Multiply MUL on page A8-503
1110 Bitwise Bit Clear BIC (register) on page A8-340
1111 Bitwise NOT MVN (register) on page A8-507
A6.2.3 Special data instructions and branch and exchange

The encoding of 16-bit Thumb special data instructions and branch and exchange instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 0 1 Opcode
Table A6-4 16-bit Thumb special data instructions and branch and exchange
Opcode Instruction See Variant
0000 Add Low Registers ADD (register, Thumb) on page A8-308 v6T2 a
0001 Add High Registers ADD (register, Thumb) on page A8-308 v4T
001x
01xx Compare High Registers CMP (register) on page A8-370 v4T
1000 Move Low Registers MOV (register, Thumb) on page A8-487 v6 a
1001 Move High Registers MOV (register, Thumb) on page A8-487 v4T
101x
110x Branch and Exchange BX on page A8-350 v4T
111x Branch with Link and Exchange BLX (register) on page A8-348 v5T a
a. UNPREDICTABLE in earlier variants.
A6.2.4 Load/store single data item

The encoding of 16-bit Thumb instructions that load or store a single data item is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
opA opB
These instructions have one of the following values of opA:

• 0b0101
• 0b011x
• 0b100x.
Table A6-5 16-bit Thumb Load/store single data item instructions
opA opB Instruction See
0101 000 Store Register STR (register) on page A8-677
001 Store Register Halfword STRH (register) on page A8-703
010 Store Register Byte STRB (register) on page A8-683
011 Load Register Signed Byte LDRSB (register) on page A8-455
100 Load Register LDR (register, Thumb) on page A8-413
101 Load Register Halfword LDRH (register) on page A8-447
110 Load Register Byte LDRB (register) on page A8-423
111 Load Register Signed Halfword LDRSH (register) on page A8-463
0110 0xx Store Register STR (immediate, Thumb) on page A8-673
1xx Load Register LDR (immediate, Thumb) on page A8-407
0111 0xx Store Register Byte STRB (immediate, Thumb) on page A8-679
1xx Load Register Byte LDRB (immediate, Thumb) on page A8-417
1000 0xx Store Register Halfword STRH (immediate, Thumb) on page A8-699
1xx Load Register Halfword LDRH (immediate, Thumb) on page A8-441
1001 0xx Store Register SP relative STR (immediate, Thumb) on page A8-673
1xx Load Register SP relative LDR (immediate, Thumb) on page A8-407
A6.2.5 Miscellaneous 16-bit instructions

The encoding of 16-bit Thumb miscellaneous instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 1 Opcode
Table A6-6 Miscellaneous 16-bit instructions
Opcode Instruction See Variant
00000xx Add Immediate to SP ADD (SP plus immediate) on page A8-314 v4T
00001xx Subtract Immediate from SP SUB (SP minus immediate) on page A8-717 v4T
0001xxx Compare and Branch on Zero CBNZ, CBZ on page A8-354 v6T2
001000x Signed Extend Halfword SXTH on page A8-735 v6
001001x Signed Extend Byte SXTB on page A8-731 v6
001010x Unsigned Extend Halfword UXTH on page A8-817 v6
001011x Unsigned Extend Byte UXTB on page A8-813 v6
0011xxx Compare and Branch on Zero CBNZ, CBZ on page A8-354 v6T2
010xxxx Push Multiple Registers PUSH on page A8-539 v4T
0110010 Set Endianness SETEND on page A8-605 v6
0110011 Change Processor State CPS (Thumb) on page B9-1964 v6
1001xxx Compare and Branch on Nonzero CBNZ, CBZ on page A8-354 v6T2
101000x Byte-Reverse Word REV on page A8-563 v6
101001x Byte-Reverse Packed Halfword REV16 on page A8-565 v6
101011x Byte-Reverse Signed Halfword REVSH on page A8-567 v6
1011xxx Compare and Branch on Nonzero CBNZ, CBZ on page A8-354 v6T2
110xxxx Pop Multiple Registers POP (Thumb) on page A8-535 v4T
1110xxx Breakpoint BKPT on page A8-344 v5
1111xxx If-Then, and hints If-Then, and hints on page A6-227 -
If-Then, and hints

The encoding of 16-bit Thumb If-Then and hint instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 1 1 1 1 1 opA opB
Other encodings in this space are unallocated hints. They execute as NOPs, but software must not use them.
Table A6-7 16-bit If-Then and hint instructions
opA opB Instruction See Variant
- not 0000 If-Then IT on page A8-391 v6T2
0000 0000 No Operation hint NOP on page A8-511 v6T2
0001 0000 Yield hint YIELD on page A8-1109 v7
0010 0000 Wait For Event hint WFE on page A8-1105 v7
0011 0000 Wait For Interrupt hint WFI on page A8-1107 v7
0100 0000 Send Event hint SEV on page A8-607 v7
A6.2.6 Conditional branch, and Supervisor Call

The encoding of 16-bit Thumb conditional branch and Supervisor Call instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 0 1 Opcode
Table A6-8 Conditional branch and Supervisor Call instructions
not 111x Conditional branch B on page A8-332
1110 Permanently UNDEFINED UDF on page A8-759 a
1111 Supervisor Call SVC (previously SWI) on page A8-721
a. Issue C.a of this manual first defines an assembler mnemonic for this encoding.

The encoding of a 32-bit Thumb instruction is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 op1 op2 op
If op1 == 0b00, a 16-bit instruction is encoded, see 16-bit Thumb instruction encoding on page A6-221.
Table A6-9 32-bit Thumb instruction encoding
op1 op2 op Instruction class, see
01 00xx0xx - Load/store multiple on page A6-235
00xx1xx - Load/store dual, load/store exclusive, table branch on page A6-236
01xxxxx - Data-processing (shifted register) on page A6-241
1xxxxxx - Coprocessor, Advanced SIMD, and Floating-point instructions on page A6-249
10 x0xxxxx 0 Data-processing (modified immediate) on page A6-229
x1xxxxx 0 Data-processing (plain binary immediate) on page A6-232
- 1 Branches and miscellaneous control on page A6-233
11 000xxx0 - Store single data item on page A6-240
00xx001 - Load byte, memory hints on page A6-239
00xx011 - Load halfword, memory hints on page A6-238
00xx101 - Load word on page A6-237
00xx111 - UNDEFINED
001xxx0 - Advanced SIMD element or structure load/store instructions on page A7-273
010xxxx - Data-processing (register) on page A6-243
0110xxx - Multiply, multiply accumulate, and absolute difference on page A6-247
0111xxx - Long multiply, long multiply accumulate, and divide on page A6-248
1xxxxxx - Coprocessor, Advanced SIMD, and Floating-point instructions on page A6-249
A6.3.1 Data-processing (modified immediate)

The encoding of the 32-bit Thumb data-processing (modified immediate) instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 op S Rn 0 Rd
These encodings are all available in ARMv6T2 and above.
Table A6-10 32-bit modified immediate data-processing instructions
op Rn Rd:S Instruction See
0000 - not 11111 Bitwise AND AND (immediate) on page A8-322
11111 Test TST (immediate) on page A8-745
0001 - - Bitwise Bit Clear BIC (immediate) on page A8-338
0010 not 1111 - Bitwise OR ORR (immediate) on page A8-517
1111 - Move MOV (immediate) on page A8-485
0011 not 1111 - Bitwise OR NOT ORN (immediate) on page A8-513
1111 - Bitwise NOT MVN (immediate) on page A8-505
0100 - not 11111 Bitwise Exclusive OR EOR (immediate) on page A8-383
11111 Test Equivalence TEQ (immediate) on page A8-739
1000 - not 11111 Add ADD (immediate, Thumb) on page A8-304
11111 Compare Negative CMN (immediate) on page A8-362
1010 - - Add with Carry ADC (immediate) on page A8-298
1011 - - Subtract with Carry SBC (immediate) on page A8-593
1101 - not 11111 Subtract SUB (immediate, Thumb) on page A8-709
11111 Compare CMP (immediate) on page A8-368
1110 - - Reverse Subtract RSB (immediate) on page A8-575
These instructions all have modified immediate constants, rather than a simple 12-bit binary number. This provides
a more useful range of values. For details, see Modified immediate constants in Thumb instructions on page A6-230.
A6.3.2 Modified immediate constants in Thumb instructions

The encoding of a modified immediate constant in a 32-bit Thumb instruction is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
i imm3 a b c d e f g h
Table A6-11 shows the range of modified immediate constants available in Thumb data-processing instructions, and
their encoding in the a, b, c, d, e, f, g, h, and i bits, and the imm3 field, in the instruction.
Table A6-11 Encoding of modified immediates in Thumb data-processing instructions
i:imm3:a <const> a
0000x 00000000 00000000 00000000 abcdefgh
0001x 00000000 abcdefgh 00000000 abcdefgh b
0010x abcdefgh 00000000 abcdefgh 00000000 b
0011x abcdefgh abcdefgh abcdefgh abcdefgh b
01000 1bcdefgh 00000000 00000000 00000000
01001 01bcdefg h0000000 00000000 00000000 c
01010 001bcdef gh000000 00000000 00000000
01011 0001bcde fgh00000 00000000 00000000 c
. .
. . 8-bit values shifted to other positions
. .
11101 00000000 00000000 000001bc defgh000 c
11110 00000000 00000000 0000001b cdefgh00
11111 00000000 00000000 00000001 bcdefgh0 c
a. This table shows the immediate constant value in binary form, to relate abcdefgh to the encoding diagram.
In assembly syntax, the immediate value is specified in the usual way (a decimal number by default).
b. Not available in ARM instructions. UNPREDICTABLE if abcdefgh == 00000000.
c. Not available in ARM instructions if h == 1.
Note
As the footnotes to Table A6-11 show, the range of values available in Thumb modified immediate constants is
slightly different from the range of values available in ARM instructions. See Modified immediate constants in ARM
instructions on page A5-197 for the ARM values.
Carry out
A logical instruction with i:imm3:a == '00xxx' does not affect the Carry flag. Otherwise, a logical flag-setting
instruction sets the Carry flag to the value of bit[31] of the modified immediate constant.
Operation of modified immediate constants, Thumb instructions

// ThumbExpandImm()
// ================
bits(32) ThumbExpandImm(bits(12) imm12)
// APSR.C argument to following function call does not affect the imm32 result.
(imm32, -) = ThumbExpandImm_C(imm12, APSR.C);
return imm32;
// ThumbExpandImm_C()
// ==================
(bits(32), bit) ThumbExpandImm_C(bits(12) imm12, bit carry_in)
if imm12<11:10> == '00' then
case imm12<9:8> of
when '00'
imm32 = ZeroExtend(imm12<7:0>, 32);
when '01'
if imm12<7:0> == '00000000' then UNPREDICTABLE;
imm32 = '00000000' : imm12<7:0> : '00000000' : imm12<7:0>;
when '10'
imm32 = imm12<7:0> : '00000000' : imm12<7:0> : '00000000';
when '11'
imm32 = imm12<7:0> : imm12<7:0> : imm12<7:0> : imm12<7:0>;
carry_out = carry_in;
else
unrotated_value = ZeroExtend('1':imm12<6:0>, 32);

(imm32, carry_out) = ROR_C(unrotated_value, UInt(imm12<11:7>));
return (imm32, carry_out);
A6.3.3 Data-processing (plain binary immediate)

The encoding of the 32-bit Thumb data-processing (plain binary immediate) instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 1 op Rn 0
Table A6-12 32-bit unmodified immediate data-processing instructions
op Rn Instruction See
00000 not 1111 Add Wide (12-bit) ADD (immediate, Thumb) on page A8-304
1111 Form PC-relative Address ADR on page A8-320
00100 - Move Wide (16-bit) MOV (immediate) on page A8-485
01010 not 1111 Subtract Wide (12-bit) SUB (immediate, Thumb) on page A8-709
1111 Form PC-relative Address ADR on page A8-320
01100 - Move Top (16-bit) MOVT on page A8-492
10000 - Signed Saturate SSAT on page A8-653

10010 a
10010 b - Signed Saturate, two 16-bit SSAT16 on page A8-655
10100 - Signed Bit Field Extract SBFX on page A8-599
10110 not 1111 Bit Field Insert BFI on page A8-336
1111 Bit Field Clear BFC on page A8-334
11000 - Unsigned Saturate USAT on page A8-797

11010 a
11010 b - Unsigned Saturate, two 16-bit USAT16 on page A8-799
11100 - Unsigned Bit Field Extract UBFX on page A8-757
a. In the second halfword of the instruction, bits[14:12, 7:6] != 0b00000.

b. In the second halfword of the instruction, bits[14:12, 7:6] == 0b00000.
A6.3.4 Branches and miscellaneous control

The encoding of the 32-bit Thumb branch instructions and miscellaneous control instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 op 1 op1 op2 imm8
Table A6-13 Branches and miscellaneous control instructions
op1 imm8 op op2 Instruction See Variant
0x0 - not - Conditional branch B on page A8-332 v6T2

x111xxx
xx1xxxxx 011100x - Move to Banked or Special register MSR (Banked register) on v7VE
page B9-1980
xx0xxxxx 0111000 xx00 Move to Special register, Application MSR (register) on page A8-501 All
level
xx01 Move to Special register, MSR (register) on page B9-1984 All

xx1x System level
0111001 - Move to Special register, MSR (register) on page B9-1984 All

System level
- 0111010 - - Change Processor State, and hints on page A6-234
- 0111011 - - Miscellaneous control instructions on page A6-235
- 0111100 - Branch and Exchange Jazelle BXJ on page A8-352 v6T2
00000000 0111101 - Exception Return ERET on page B9-1968 v6T2 a
not 0111101 - Exception Return SUBS PC, LR (Thumb) on v6T2

00000000 page B9-1996
xx1xxxxx 011111x - Move from Banked or Special MRS (Banked register) on v7VE
register page B9-1978
xx0xxxxx 0111110 - Move from Special register, MRS on page A8-497 v6T2
Application level
0111111 - Move from Special register, System MRS on page B9-1976 v6T2
level
000 - 1111110 - Hypervisor Call HVC on page B9-1970 v7VE
1111111 - Secure Monitor Call SMC (previously SMI) on Security

page B9-1988 Extensions
0x1 - - - Branch B on page A8-332 v6T2
010 - 1111111 - Permanently UNDEFINED UDF on page A8-759 All b
Table A6-13 Branches and miscellaneous control instructions (continued)
op1 imm8 op op2 Instruction See Variant
1x0 - - - Branch with Link and Exchange BL, BLX (immediate) on v5T c
page A8-346
1x1 - - - Branch with Link BL, BLX (immediate) on v4T

page A8-346
a. v7VE, that is, ARMv7 with the Virtualization Extensions, first defines ERET as an assembler mnemonic for this encoding. From ARMv6T2
this is an encoding for SUBS PC, LR (Thumb) on page B9-1996 with an imm8 value of zero. The Virtualization Extensions do not change
the behavior of the encoded instruction when it is executed at PL1.
b. Issue C.a of this manual first defines an assembler mnemonic for this encoding.
c. UNDEFINED in ARMv4T.
Change Processor State, and hints

The encoding of 32-bit Thumb Change Processor State and hint instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 0 1 0 1 0 0 op1 op2
Table A6-14 shows the allocation of encodings in this space. Encodings with op1 set to 0b000 and a value of op2 that
is not shown in the table are unallocated hints, and behave as if op2 is set to 0b00000000. These unallocated hint
encodings are reserved and software must not use them.
Table A6-14 Change Processor State, and hint instructions
op1 op2 Instruction See Variant
not 000 - Change Processor State CPS (Thumb) on page B9-1964 v6T2
000 00000000 No Operation hint NOP on page A8-511 v6T2
00000001 Yield hint YIELD on page A8-1109 v7
00000010 Wait For Event hint WFE on page A8-1105 v7
00000011 Wait For Interrupt hint WFI on page A8-1107 v7
00000100 Send Event hint SEV on page A8-607 v7
00010100 Consumption of Speculative Data Barrier CSDB on page A8-376 v6T2
1111xxxx Debug hint DBG on page A8-378 v7
Miscellaneous control instructions

The encoding of some 32-bit Thumb miscellaneous control instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 0 1 1 1 0 0 op
Table A6-15 shows the allocation of encodings in this space. Other encodings in this space are UNDEFINED in
ARMv7. They are UNPREDICTABLE in ARMv6T2.
Table A6-15 Miscellaneous control instructions
0000 Exit ThumbEE state a ENTERX, LEAVEX on page A9-1116 ThumbEE
0001 Enter ThumbEE state ENTERX, LEAVEX on page A9-1116 ThumbEE
0010 Clear-Exclusive CLREX on page A8-358 v7
0100 Data Synchronization Barrier DSB on page A8-381 v7
0101 Data Memory Barrier DMB on page A8-379 v7
0110 Instruction Synchronization Barrier ISB on page A8-390 v7
a. This instruction is a NOP in Thumb state.
A6.3.5 Load/store multiple

The encoding of 32-bit Thumb load/store multiple instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 0 op 0 W L Rn
Table A6-16 Load/store multiple instructions
op L W:Rn Instruction See
00 0 - Store Return State SRS (Thumb) on page B9-1990
1 - Return From Exception RFE on page B9-1986
01 0 - Store Multiple (Increment After, Empty Ascending) STM (STMIA, STMEA) on page A8-665
1 not 11101 Load Multiple (Increment After, Full Descending) LDM/LDMIA/LDMFD (Thumb) on page A8-397
11101 Pop Multiple Registers from the stack POP (Thumb) on page A8-535
10 0 not 11101 Store Multiple (Decrement Before, Full Descending) STMDB (STMFD) on page A8-669
11101 Push Multiple Registers to the stack. PUSH on page A8-539
1 - Load Multiple (Decrement Before, Empty Ascending) LDMDB/LDMEA on page A8-403
11 0 - Store Return State SRS (Thumb) on page B9-1990
1 - Return From Exception RFE on page B9-1986
A6.3.6 Load/store dual, load/store exclusive, table branch

The encoding of 32-bit Thumb load/store dual, load/store exclusive and table branch instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 0 op1 1 op2 Rn op3
Table A6-17 Load/store double or exclusive, table branch
op1 op2 op3 Rn Instruction See Variant
00 00 - - Store Register Exclusive STREX on page A8-691 v6T2
01 - - Load Register Exclusive LDREX on page A8-433 v6T2
0x 10 - - Store Register Dual STRD (immediate) on page A8-687 v6T2
1x x0 - -
0x 11 - not 1111 Load Register Dual (immediate) LDRD (immediate) on page A8-427 v6T2
1x x1 - not 1111
0x 11 - 1111 Load Register Dual (literal) LDRD (literal) on page A8-429 v6T2
1x x1 - 1111
01 00 0100 - Store Register Exclusive Byte STREXB on page A8-693 v7
0101 - Store Register Exclusive Halfword STREXH on page A8-697 v7
0111 - Store Register Exclusive Doubleword STREXD on page A8-695 v7
01 0000 - Table Branch Byte TBB, TBH on page A8-737 v6T2
0001 - Table Branch Halfword TBB, TBH on page A8-737 v6T2
0100 - Load Register Exclusive Byte LDREXB on page A8-435 v7
0101 - Load Register Exclusive Halfword LDREXH on page A8-439 v7
0111 - Load Register Exclusive Doubleword LDREXD on page A8-437 v7
A6.3.7 Load word

The encoding of 32-bit Thumb load word instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 op1 1 0 1 Rn op2
Table A6-18 Load word
op1 op2 Rn Instruction See
00 000000 not 1111 Load Register LDR (register, Thumb) on page A8-413
00 1xx1xx not 1111 Load Register LDR (immediate, Thumb) on page A8-407
1100xx not 1111
01 - not 1111
00 1110xx not 1111 Load Register Unprivileged LDRT on page A8-467
0x - 1111 Load Register LDR (literal) on page A8-411
A6.3.8 Load halfword, memory hints

The encoding of 32-bit Thumb load halfword instructions and some memory hint instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 op1 0 1 1 Rn Rt op2
Except where otherwise noted, these encodings are available in ARMv6T2 and above.
Table A6-19 Load halfword, preload
op1 op2 Rn Rt Instruction See
0x - 1111 not 1111 Load Register Halfword LDRH (literal) on page A8-445
1111 Preload Data PLD (literal) on page A8-527
00 1xx1xx not 1111 - Load Register Halfword LDRH (immediate, Thumb) on

page A8-441
1100xx not 1111 not 1111
01 - not 1111 not 1111
00 000000 not 1111 not 1111 Load Register Halfword LDRH (register) on page A8-447
1110xx not 1111 - Load Register Halfword Unprivileged LDRHT on page A8-449
000000 not 1111 1111 Preload Data with intent to Write a PLD, PLDW (register) on page A8-529
1100xx not 1111 1111 Preload Data with intent to Write a PLD, PLDW (immediate) on
page A8-525
01 - not 1111 1111
10 1xx1xx not 1111 - Load Register Signed Halfword LDRSH (immediate) on page A8-459
1100xx not 1111 not 1111
11 - not 1111 not 1111
1x - 1111 not 1111 Load Register Signed Halfword LDRSH (literal) on page A8-461
10 000000 not 1111 not 1111 Load Register Signed Halfword LDRSH (register) on page A8-463
1110xx not 1111 - Load Register Signed Halfword Unprivileged LDRSHT on page A8-465
10 000000 not 1111 1111 Unallocated memory hint (treat as NOP) -
1100xx not 1111 1111
1x - 1111 1111
11 - not 1111 1111 Unallocated memory hint (treat as NOP) -
a. Available in ARMv7 with the Multiprocessing Extensions. In an ARMv7 implementation that does not include the Multiprocessing
Extensions, and in ARMv6T2, these are unallocated memory hints, that are treated as NOPs.
A6.3.9 Load byte, memory hints

The encoding of 32-bit Thumb load byte instructions and some memory hint instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 op1 0 0 1 Rn Rt op2
Table A6-20 Load byte, memory hints
op1 op2 Rn Rt Instruction See
00 000000 not 1111 not 1111 Load Register Byte LDRB (register) on page A8-423
1111 Preload Data PLD, PLDW (register) on page A8-529
0x - 1111 not 1111 Load Register Byte LDRB (literal) on page A8-421
1111 Preload Data PLD (literal) on page A8-527
00 1xx1xx not 1111 - Load Register Byte LDRB (immediate, Thumb) on page A8-417
1100xx not 1111 not 1111 Load Register Byte
1111 Preload Data PLD, PLDW (immediate) on page A8-525
1110xx not 1111 - Load Register Byte Unprivileged LDRBT on page A8-425
01 - not 1111 not 1111 Load Register Byte LDRB (immediate, Thumb) on page A8-417
1111 Preload Data PLD, PLDW (immediate) on page A8-525
10 000000 not 1111 not 1111 Load Register Signed Byte LDRSB (register) on page A8-455
1111 Preload Instruction PLI (register) on page A8-533
1x - 1111 not 1111 Load Register Signed Byte LDRSB (literal) on page A8-453
1111 Preload Instruction PLI (immediate, literal) on page A8-531
10 1xx1xx not 1111 - Load Register Signed Byte LDRSB (immediate) on page A8-451
1100xx not 1111 not 1111 Load Register Signed Byte LDRSB (immediate) on page A8-451
1110xx not 1111 - Load Register Signed Byte Unprivileged LDRSBT on page A8-457
11 - not 1111 not 1111 Load Register Signed Byte LDRSB (immediate) on page A8-451
A6.3.10 Store single data item

The encoding of 32-bit Thumb store single data item instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 op1 0 op2
Table A6-21 show the allocation of encodings in this space. Other encodings in this space are UNDEFINED.
Table A6-21 Store single data item
000 1xx1xx Store Register Byte STRB (immediate, Thumb) on page A8-679
1100xx
100 -
000 000000 Store Register Byte STRB (register) on page A8-683
1110xx Store Register Byte Unprivileged STRBT on page A8-685
001 1xx1xx Store Register Halfword STRH (immediate, Thumb) on page A8-699
1100xx
101 -
001 000000 Store Register Halfword STRH (register) on page A8-703
1110xx Store Register Halfword Unprivileged STRHT on page A8-705
010 1xx1xx Store Register STR (immediate, Thumb) on page A8-673
1100xx
110 -
010 000000 Store Register STR (register) on page A8-677
1110xx Store Register Unprivileged STRT on page A8-707
A6.3.11 Data-processing (shifted register)

The encoding of 32-bit Thumb data-processing (shifted register) instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 1 op S Rn Rd
Table A6-22 Data-processing (shifted register)
op Rn Rd:S Instruction See
0000 - not 11111 Bitwise AND AND (register) on page A8-324
11111 Test TST (register) on page A8-747
0001 - - Bitwise Bit Clear BIC (register) on page A8-340
0010 not 1111 - Bitwise OR ORR (register) on page A8-519
1111 - - Move register and immediate shifts
0011 not 1111 - Bitwise OR NOT ORN (register) on page A8-515
1111 - Bitwise NOT MVN (register) on page A8-507
0100 - not 11111 Bitwise Exclusive OR EOR (register) on page A8-385
11111 Test Equivalence TEQ (register) on page A8-741
0110 - - Pack Halfword PKH on page A8-523
1000 - not 11111 Add ADD (register, Thumb) on page A8-308
11111 Compare Negative CMN (register) on page A8-364
1010 - - Add with Carry ADC (register) on page A8-300
1011 - - Subtract with Carry SBC (register) on page A8-595
1101 - not 11111 Subtract SUB (register) on page A8-713
11111 Compare CMP (register) on page A8-370
1110 - - Reverse Subtract RSB (register) on page A8-577
Move register and immediate shifts

The encoding of the 32-bit Thumb move register and immediate shift instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 1 0 0 1 0 1 1 1 1 imm3 imm2 type
Table A6-23 on page A6-242 shows the allocation of encodings in this space.
Table A6-23 Move register and immediate shifts
type imm3:imm2 Instruction See
00 00000 Move MOV (register, Thumb) on page A8-487
not 00000 Logical Shift Left LSL (immediate) on page A8-469
01 - Logical Shift Right LSR (immediate) on page A8-473
10 - Arithmetic Shift Right ASR (immediate) on page A8-328
11 00000 Rotate Right with Extend RRX on page A8-573
not 00000 Rotate Right ROR (immediate) on page A8-569
A6.3.12 Data-processing (register)

The encoding of 32-bit Thumb data-processing (register) instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 op1 Rn 1 1 1 1 op2
If, in the second halfword of the instruction, bits[15:12] != 0b1111, the instruction is UNDEFINED.
Table A6-24 Data-processing (register)
op1 op2 Rn Instruction See
000x 0000 - Logical Shift Left LSL (register) on page A8-471
001x 0000 - Logical Shift Right LSR (register) on page A8-475
010x 0000 - Arithmetic Shift Right ASR (register) on page A8-330
011x 0000 - Rotate Right ROR (register) on page A8-571
0000 1xxx not 1111 Signed Extend and Add Halfword SXTAH on page A8-729
1111 Signed Extend Halfword SXTH on page A8-735
0001 1xxx not 1111 Unsigned Extend and Add Halfword UXTAH on page A8-811
1111 Unsigned Extend Halfword UXTH on page A8-817
0010 1xxx not 1111 Signed Extend and Add Byte 16-bit SXTAB16 on page A8-727
1111 Signed Extend Byte 16-bit SXTB16 on page A8-733
0011 1xxx not 1111 Unsigned Extend and Add Byte 16-bit UXTAB16 on page A8-809
1111 Unsigned Extend Byte 16-bit UXTB16 on page A8-815
0100 1xxx not 1111 Signed Extend and Add Byte SXTAB on page A8-725
1111 Signed Extend Byte SXTB on page A8-731
0101 1xxx not 1111 Unsigned Extend and Add Byte UXTAB on page A8-807
1111 Unsigned Extend Byte UXTB on page A8-813
1xxx 00xx - - Parallel addition and subtraction, signed
1xxx 01xx - - Parallel addition and subtraction, unsigned on page A6-244
10xx 10xx - - Miscellaneous operations on page A6-246
A6.3.13 Parallel addition and subtraction, signed

The encoding of 32-bit Thumb signed parallel addition and subtraction instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 op1 1 1 1 1 0 0 op2
Table A6-25 shows the allocation of encodings in this space. Other encodings in this space are UNDEFINED. These
encodings are all available in ARMv6T2 and above.
Table A6-25 Signed parallel addition and subtraction instructions
010 00 Add and Subtract with Exchange, 16-bit SASX on page A8-591
110 00 Subtract and Add with Exchange, 16-bit SSAX on page A8-657
101 00 Subtract 16-bit SSUB16 on page A8-659
100 00 Subtract 8-bit SSUB8 on page A8-661
010 01 Saturating Add and Subtract with Exchange, 16-bit QASX on page A8-547
110 01 Saturating Subtract and Add with Exchange, 16-bit QSAX on page A8-553
101 01 Saturating Subtract 16-bit QSUB16 on page A8-557
100 01 Saturating Subtract 8-bit QSUB8 on page A8-559
010 10 Halving Add and Subtract with Exchange, 16-bit SHASX on page A8-613
110 10 Halving Subtract and Add with Exchange, 16-bit SHSAX on page A8-615
101 10 Halving Subtract 16-bit SHSUB16 on page A8-617
100 10 Halving Subtract 8-bit SHSUB8 on page A8-619
A6.3.14 Parallel addition and subtraction, unsigned

The encoding of 32-bit Thumb unsigned parallel addition and subtraction instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 op1 1 1 1 1 0 1 op2
Table A6-26 Unsigned parallel addition and subtraction instructions
010 00 Add and Subtract with Exchange, 16-bit UASX on page A8-755
110 00 Subtract and Add with Exchange, 16-bit USAX on page A8-801
101 00 Subtract 16-bit USUB16 on page A8-803
100 00 Subtract 8-bit USUB8 on page A8-805
010 01 Saturating Add and Subtract with Exchange, 16-bit UQASX on page A8-785
110 01 Saturating Subtract and Add with Exchange, 16-bit UQSAX on page A8-787
101 01 Saturating Subtract 16-bit UQSUB16 on page A8-789
100 01 Saturating Subtract 8-bit UQSUB8 on page A8-791
010 10 Halving Add and Subtract with Exchange, 16-bit UHASX on page A8-767
110 10 Halving Subtract and Add with Exchange, 16-bit UHSAX on page A8-769
101 10 Halving Subtract 16-bit UHSUB16 on page A8-771
100 10 Halving Subtract 8-bit UHSUB8 on page A8-773
A6.3.15 Miscellaneous operations

The encoding of some 32-bit Thumb miscellaneous instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 op1 1 1 1 1 1 0 op2
Table A6-27 Miscellaneous operations
00 00 Saturating Add QADD on page A8-541
01 Saturating Double and Add QDADD on page A8-549
10 Saturating Subtract QSUB on page A8-555
11 Saturating Double and Subtract QDSUB on page A8-551
01 00 Byte-Reverse Word REV on page A8-563
01 Byte-Reverse Packed Halfword REV16 on page A8-565
10 Reverse Bits RBIT on page A8-561
11 Byte-Reverse Signed Halfword REVSH on page A8-567
10 00 Select Bytes SEL on page A8-603
11 00 Count Leading Zeros CLZ on page A8-360
A6.3.16 Multiply, multiply accumulate, and absolute difference

The encoding of 32-bit Thumb multiply, multiply accumulate, and absolute difference instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 0 op1 Ra 0 0 op2
Table A6-28 Multiply, multiply accumulate, and absolute difference operations
op1 op2 Ra Instruction See
000 00 not 1111 Multiply Accumulate MLA on page A8-481
1111 Multiply MUL on page A8-503
01 - Multiply and Subtract MLS on page A8-483
001 - not 1111 Signed Multiply Accumulate (Halfwords) SMLABB, SMLABT, SMLATB, SMLATT on
page A8-621
1111 Signed Multiply (Halfwords) SMULBB, SMULBT, SMULTB, SMULTT on

page A8-645
010 0x not 1111 Signed Multiply Accumulate Dual SMLAD on page A8-623
1111 Signed Dual Multiply Add SMUAD on page A8-643
011 0x not 1111 Signed Multiply Accumulate (Word by halfword) SMLAWB, SMLAWT on page A8-631
1111 Signed Multiply (Word by halfword) SMULWB, SMULWT on page A8-649
100 0x not 1111 Signed Multiply Subtract Dual SMLSD on page A8-633
1111 Signed Dual Multiply Subtract SMUSD on page A8-651
101 0x not 1111 Signed Most Significant Word Multiply Accumulate SMMLA on page A8-637
1111 Signed Most Significant Word Multiply SMMUL on page A8-641
110 0x - Signed Most Significant Word Multiply Subtract SMMLS on page A8-639
111 00 not 1111 Unsigned Sum of Absolute Differences, Accumulate USADA8 on page A8-795
1111 Unsigned Sum of Absolute Differences USAD8 on page A8-793
A6.3.17 Long multiply, long multiply accumulate, and divide

The encoding of 32-bit Thumb long multiply, long multiply accumulate, and divide instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 1 op1 op2
Table A6-29 Multiply, multiply accumulate, and absolute difference operations
op1 op2 Instruction See Variant
000 0000 Signed Multiply Long SMULL on page A8-647 v6T2
001 1111 Signed Divide SDIV on page A8-601 v7-R a
010 0000 Unsigned Multiply Long UMULL on page A8-779 v6T2
011 1111 Unsigned Divide UDIV on page A8-761 v7-R a
100 0000 Signed Multiply Accumulate Long SMLAL on page A8-625 v6T2
10xx Signed Multiply Accumulate Long (Halfwords) SMLALBB, SMLALBT, SMLALTB, SMLALTT on v6T2
page A8-627
110x Signed Multiply Accumulate Long Dual SMLALD on page A8-629 v6T2
101 110x Signed Multiply Subtract Long Dual SMLSLD on page A8-635 v6T2
110 0000 Unsigned Multiply Accumulate Long UMLAL on page A8-777 v6T2
0110 Unsigned Multiply Accumulate Accumulate Long UMAAL on page A8-775 v6T2
a. Optional in some ARMv7 implementations, see ARMv7 implementation requirements and options for the divide instructions on
page A4-170.
A6.3.18 Coprocessor, Advanced SIMD, and Floating-point instructions

The encoding of 32-bit Thumb coprocessor instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 op1 Rn coproc op
Table A6-30 shows the allocation of encodings in this space. These encodings are all available in ARMv6T2 and
above:
Table A6-30 Coprocessor, Advanced SIMD, and Floating-point instructions
coproc op1 op Rn Instructions See
- 00000x - - UNDEFINED -
11xxxx - - Advanced SIMD Advanced SIMD data-processing instructions on

page A7-259
not 101x 0xxxx0 - - Store Coprocessor STC, STC2 on page A8-663

not 000x0x
0xxxx1 - not 1111 Load Coprocessor (immediate) LDC, LDC2 (immediate) on page A8-393
not 000x0x
1111 Load Coprocessor (literal) LDC, LDC2 (literal) on page A8-395
000100 - - Move to Coprocessor from two MCRR, MCRR2 on page A8-479

ARM core registers
000101 - - Move to two ARM core MRRC, MRRC2 on page A8-495

registers from Coprocessor
10xxxx 0 - Coprocessor data operations CDP, CDP2 on page A8-356
10xxx0 1 - Move to Coprocessor from MCR, MCR2 on page A8-477

ARM core register
10xxx1 1 - Move to ARM core register MRC, MRC2 on page A8-493

from Coprocessor
101x 0xxxxx - - Advanced SIMD, Extension register load/store instructions on

not 000x0x Floating-point page A7-272
00010x - - Advanced SIMD, 64-bit transfers between ARM core and extension
Floating-point registers on page A7-277
10xxxx 0 - Floating-point data processing Floating-point data-processing instructions on

page A7-270
10xxxx 1 - Advanced SIMD, 8, 16, and 32-bit transfer between ARM core and
Floating-point extension registers on page A7-276
For more information about specific coprocessors see Coprocessor support on page A2-93.
Chapter A7
Advanced SIMD and Floating-point
Instruction Encoding
This chapter gives an overview of the Advanced SIMD and Floating-point (VFP) instruction sets. It contains the
following sections:
• Overview on page A7-252.
• Advanced SIMD and Floating-point instruction syntax on page A7-253.
• Register encoding on page A7-257.
• Extension register load/store instructions on page A7-272.
• Advanced SIMD element or structure load/store instructions on page A7-273.
• 8, 16, and 32-bit transfer between ARM core and extension registers on page A7-276.
• 64-bit transfers between ARM core and extension registers on page A7-277.
Note
• The Advanced SIMD architecture extension, its associated implementations, and supporting software, are
commonly referred to as NEON™ technology.
the decoding.
A7 Advanced SIMD and Floating-point Instruction Encoding
A7.1 Overview
A7.1 Overview
All Advanced SIMD and Floating-point instructions are available in both ARM state and Thumb state.
A7.1.1 Advanced SIMD

The following sections describe the classes of instruction in the Advanced SIMD Extension:
• Advanced SIMD element or structure load/store instructions on page A7-273.
A7.1.2 Floating-point
The following sections describe the classes of instruction in the Floating-point Extension:
A7.2 Advanced SIMD and Floating-point instruction syntax

Advanced SIMD and Floating-point (VFP) instructions use the general conventions of the ARM instruction set.
Advanced SIMD and Floating-point data-processing instructions use the following general format:
V{<modifier>}<operation>{<shape>}{<c>}{<q>}{.<dt>} {<dest>,} <src1>, <src2>
All Advanced SIMD and Floating-point instructions begin with a V. This distinguishes Advanced SIMD vector and
Floating-point instructions from ARM scalar instructions.
The main operation is specified in the <operation> field. It is usually a three letter mnemonic the same as or similar
to the corresponding scalar integer instruction.
The <c> and <q> fields are standard assembler syntax fields. For details, see Standard assembler syntax fields on
page A8-285.
A7.2.1 Advanced SIMD instruction modifiers

The <modifier> field provides additional variants of some instructions. Table A7-1 provides definitions of the
modifiers. Modifiers are not available for every instruction.
Table A7-1 Advanced SIMD instruction modifiers
<modifier> Meaning
Q The operation uses saturating arithmetic.
R The operation performs rounding.
D The operation doubles the result (before accumulation, if any).
H The operation halves the result.
A7.2.2 Advanced SIMD operand shapes

The <shape> field provides additional variants of some instructions. Table A7-2 provides definitions of the shapes.
Operand shapes are not available for every instruction.
Table A7-2 Advanced SIMD operand shapes
<shape> Meaning Typical register shape
(none) The operands and result are all the same width. Dd, Dn, Dm Qd, Qn, Qm
L Long operation - result is twice the width of both operands Qd, Dn, Dm
N Narrow operation - result is half the width of both operands Dd, Qn, Qm
W Wide operation - result and first operand are twice the width of the second operand Qd, Qn, Dm
Note
• Some assemblers support a Q shape specifier, that requires all operands to be Q registers. An example of
using this specifier is VADDQ.S32 q0, q1, q2. This is not standard UAL, and ARM recommends that
programmers do not use a Q shape specifier.
• A disassembler must not generate any shape specifier not shown in Table A7-2.
A7.2.3 Data type specifiers

The <dt> field normally contains one data type specifier. Unless the assembler syntax description for the instruction
indicates otherwise, this indicates the data type contained in:
• The second operand, if any.
• The operand, if there is no second operand.
• The result, if there are no operand registers.
The data types of the other operand and result are implied by the <dt> field combined with the instruction shape. For
information about data type formats see Data types supported by the Advanced SIMD Extension on page A2-59.
In the instruction syntax descriptions in Chapter A8 Instruction Descriptions, the <dt> field is usually specified as
a single field. However, where more convenient, it is sometimes specified as a concatenation of two fields,
<type><size>.
Syntax flexibility
There is some flexibility in the data type specifier syntax:
• Software can specify three data types, specifying the result and both operand data types. For example:
VSUBW.I16.I16.S8 Q3, Q5, D0 instead of VSUBW.S8 Q3, Q5, D0
• Software can specify two data types, specifying the data types of the two operands. The data type of the result
is implied by the instruction shape. For example:
VSUBW.I16.S8 Q3, Q5, D0 instead of VSUBW.S8 Q3, Q5, D0
• Software can specify two data types, specifying the data types of the single operand and the result. For
example:
VMOVN.I16.I32 D0, Q1 instead of VMOVN.I32 D0, Q1
• Where an instruction requires a less specific data type, software can instead specify a more specific type, as
shown in Table A7-3.
• Where an instruction does not require a data type, software can provide one.
• The F32 data type can be abbreviated to F.
• The F64 data type can be abbreviated to D.
In all cases, if software provides additional information, the additional information must match the instruction
shape. Disassembly does not regenerate this additional information.
Table A7-3 Data type specification flexibility
Specified data type Permitted more specific data types
None Any
.I<size> - .S<size> .U<size> - -
.8 .I8 .S8 .U8 .P8 -
.16 .I16 .S16 .U16 .P16 .F16
.32 .I32 .S32 .U32 - .F32 or .F
.64 .I64 .S64 .U64 - .F64 or .D
A7.2.4 Register specifiers

The <dest>, <src1>, and <src2> fields contain register specifiers, or in some cases scalar specifiers or register lists.
Table A7-4 shows the register and scalar specifier formats that appear in the instruction descriptions.
If <dest> is omitted, it is the same as <src1>.
Table A7-4 Advanced SIMD and Floating-point register specifier formats
<specifier> Usual meaning a Used in
<Qd> A quadword destination register for the result vector. Advanced SIMD
<Qn> A quadword source register for the first operand vector. Advanced SIMD
<Qm> A quadword source register for the second operand vector. Advanced SIMD
<Dd> A doubleword destination register for the result vector. Both
<Dn> A doubleword source register for the first operand vector. Both
<Dm> A doubleword source register for the second operand vector. Both
<Sd> A singleword destination register for the result vector. Floating-point
<Sn> A singleword source register for the first operand vector. Floating-point
<Sm> A singleword source register for the second operand vector. Floating-point
<Dd[x]> A destination scalar for the result. Element x of vector <Dd>. Advanced SIMD
<Dn[x]> A source scalar for the first operand. Element x of vector <Dn>. Both b
<Dm[x]> A source scalar for the second operand. Element x of vector <Dm>. Advanced SIMD
<Rt> An ARM core register, used for a source or destination address. Both
<Rt2> An ARM core register, used for a source or destination address. Both
<Rn> An ARM core register, used as a load or store base address. Both
<Rm> An ARM core register, used as a post-indexed address source. Both

a. In some instructions, the roles of registers are different.
b. In the Floating-point Extension, <Dn[x]> is used only in VMOV (scalar to ARM core register), see VMOV
(scalar to ARM core register) on page A8-943.
A7.2.5 Register lists

A register list is a list of register specifiers separated by commas and enclosed in brackets { and }. There are
restrictions on what registers can appear in a register list. These restrictions are described in the individual
instruction descriptions. Table A7-5 shows some register list formats, with examples of actual register lists
corresponding to those formats.
Note
Register lists must not wrap around the end of the register bank.
Syntax flexibility
There is some flexibility in the register list syntax:
• Where a register list contains consecutive registers, they can be specified as a range, instead of listing every
register, for example {D0-D3} instead of {D0, D1, D2, D3}.
• Where a register list contains an even number of consecutive doubleword registers starting with an
even-numbered register, it can be written as a list of quadword registers instead, for example {Q1, Q2} instead
of {D2-D5}.
• Where a register list contains only one register, the enclosing braces can be omitted, for example
VLD1.8 D0, [R0] instead of VLD1.8 {D0}, [R0].
Table A7-5 Example register lists
Format Example Alternative
{<Dd>} {D3} D3
{<Dd>, <Dd+1>, <Dd+2>} {D3, D4, D5} {D3-D5}
{<Dd[x]>, <Dd+2[x]} {D0[3], D2[3]} -
{<Dd[]>} {D7[]} D7[]
A7.3 Register encoding

An Advanced SIMD register is either:
• Quadword, meaning it is 128 bits wide.
• Doubleword, meaning it is 64 bits wide.
Some instructions have options for either doubleword or quadword registers. This is normally encoded in Q, bit[6],
as Q = 0 for doubleword operations, or Q = 1 for quadword operations.
A Floating-point register is either:

• Double-precision, meaning it is 64 bits wide.
• Single-precision, meaning it is 32 bits wide.
This is encoded in the sz field, bit[8], as sz = 1 for double-precision operations, or sz = 0 for single-precision
operations.
The Thumb instruction encoding of Advanced SIMD or Floating-point registers is:

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
D Vn Vd sz N Q M Vm
The ARM instruction encoding of Advanced SIMD or Floating-point registers is:

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
D Vn Vd sz N Q M Vm
Some instructions use only one or two registers, and use the unused register fields as additional opcode bits.
Table A7-6 shows the encodings for the registers.
Table A7-6 Encoding of register numbers
Register Register number

Usual usage Notes a Used in
mnemonic encoded in a
<Qd> Destination (quadword) D, Vd (bits[22, 15:13]) bit[12] == 0 b Advanced SIMD
<Qn> First operand (quadword) N, Vn (bits[7, 19:17]) bit[16] == 0 b Advanced SIMD
<Qm> Second operand (quadword) M, Vm (bits[5, 3:1]) bit[0] == 0 b Advanced SIMD
<Dd> Destination (doubleword) D, Vd (bits[22, 15:12]) - Both
<Dn> First operand (doubleword) N, Vn (bits[7, 19:16]) - Both
<Dm> Second operand (doubleword) M, Vm (bits[5, 3:0]) - Both
<Sd> Destination (single-precision) Vd, D (bits[15:12, 22]) - Floating-point
<Sn> First operand (single-precision) Vn, N (bits[19:16, 7]) - Floating-point
<Sm> Second operand (single-precision) Vm, M (bits[3:0, 5]) - Floating-point
a. Bit numbers given for the ARM instruction encoding. See the figures in this section for the equivalent bits in the Thumb
encoding.
b. If this bit is 1, the instruction is UNDEFINED.
A7.3.1 Advanced SIMD scalars

Advanced SIMD scalars can be 8-bit, 16-bit, 32-bit, or 64-bit. Instructions other than multiply instructions can
access any element in the register set. The instruction syntax refers to the scalars using an index into a doubleword
vector. The descriptions of the individual instructions contain details of the encodings.
Table A7-7 shows the form of encoding for scalars used in multiply instructions. These instructions cannot access
scalars in some registers. The descriptions of the individual instructions contain cross references to this section
where appropriate.
32-bit Advanced SIMD scalars, when used as single-precision floating-point numbers, are equivalent to
Floating-point single-precision registers. That is, Dm[x] in a 32-bit context (0 <= m <= 15, 0 <= x <=1) is equivalent
to S[2m + x].
Table A7-7 Encoding of scalars in multiply instructions
Scalar Scalar Register Index Accessible

Usual usage
mnemonic size specifier specifier registers
<Dm[x]> Second operand 16-bit Vm[2:0] M, Vm[3] D0-D7
32-bit Vm[3:0] M D0-D15

The Thumb encoding of Advanced SIMD data processing instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 U 1 1 1 1 A B C
The ARM encoding of Advanced SIMD data processing instructions is:

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 U A B C
Table A7-8 shows the encoding for Advanced SIMD data-processing instructions. Other encodings in this space are
UNDEFINED.
In these instructions, the U bit is in a different location in ARM and Thumb instructions. This is bit[12] of the first
halfword in the Thumb encoding, and bit[24] in the ARM encoding. Other variable bits are in identical locations in
the two encodings, after adjusting for the fact that the ARM encoding is held in memory as a single word and the
Thumb encoding is held as two consecutive halfwords.
The ARM instructions can only be executed unconditionally. The Thumb instructions can be executed conditionally
by using the IT instruction. For details, see IT on page A8-391.
Table A7-8 Data-processing instructions
U A B C See
- 0xxxx - - Three registers of the same length
1x000 - 0xx1 One register and a modified immediate value on page A7-267
1x001 - 0xx1 Two registers and a shift amount on page A7-264
1x01x - 0xx1
1x1xx - 0xx1
1xxxx - 1xx1
1x0xx - x0x0 Three registers of different lengths on page A7-262
1x10x - x0x0
1x0xx - x1x0 Two registers and a scalar on page A7-263
1x10x - x1x0
0 1x11x - xxx0 Vector Extract, VEXT on page A8-891
1 1x11x 0xxx xxx0 Two registers, miscellaneous on page A7-264
10xx xxx0 Vector Table Lookup, VTBL, VTBX on page A8-1095
1100 0xx0 Vector Duplicate, VDUP (scalar) on page A8-885
A7.4.1 Three registers of the same length

The Thumb encoding of these instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 U 1 1 1 1 0 C A B
The ARM encoding of these instructions is:

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 U 0 C A B
Table A7-9 Three registers of the same length
A B U C Instruction See Variant a
0000 0 - - Vector Halving Add VHADD, VHSUB on page A8-897 ASIMD
1 - - Vector Saturating Add VQADD on page A8-997 ASIMD
0001 0 - - Vector Rounding Halving Add VRHADD on page A8-1031 ASIMD
1 0 00 Vector Bitwise AND VAND (register) on page A8-837 ASIMD
01 Vector Bitwise Bit Clear, AND complement VBIC (register) on page A8-841 ASIMD
10 Vector Bitwise OR, if source registers differ VORR (register) on page A8-977 ASIMD
Vector Move, if source registers identical VMOV (register) on page A8-939 ASIMD
11 Vector Bitwise OR NOT VORN (register) on page A8-973 ASIMD
0001 1 1 00 Vector Bitwise Exclusive OR VEOR on page A8-889 ASIMD
01 Vector Bitwise Select VBIF, VBIT, VBSL on page A8-843 ASIMD
10 Vector Bitwise Insert if True VBIF, VBIT, VBSL on page A8-843 ASIMD
11 Vector Bitwise Insert if False VBIF, VBIT, VBSL on page A8-843 ASIMD
0010 0 - - Vector Halving Subtract VHADD, VHSUB on page A8-897 ASIMD
1 - - Vector Saturating Subtract VQSUB on page A8-1021 ASIMD
0011 0 - - Vector Compare Greater Than VCGT (register) on page A8-853 ASIMD
1 - - Vector Compare Greater Than or Equal VCGE (register) on page A8-849 ASIMD
0100 0 - - Vector Shift Left VSHL (register) on page A8-1049 ASIMD
1 - - Vector Saturating Shift Left VQSHL (register) on page A8-1015 ASIMD
0101 0 - - Vector Rounding Shift Left VRSHL on page A8-1033 ASIMD
1 - - Vector Saturating Rounding Shift Left VQRSHL on page A8-1011 ASIMD
0110 - - - Vector Maximum or Minimum VMAX, VMIN (integer) on page A8-927 ASIMD
0111 0 - - Vector Absolute Difference VABD, VABDL (integer) on page A8-821 ASIMD
1 - - Vector Absolute Difference and Accumulate VABA, VABAL on page A8-819 ASIMD
1000 0 0 - Vector Add VADD (integer) on page A8-829 ASIMD
1 - Vector Subtract VSUB (integer) on page A8-1085 ASIMD
1 0 - Vector Test Bits VTST on page A8-1099 ASIMD
1 - Vector Compare Equal VCEQ (register) on page A8-845 ASIMD
Table A7-9 Three registers of the same length (continued)
A B U C Instruction See Variant a
1001 0 - - Vector Multiply Accumulate or Subtract VMLA, VMLAL, VMLS, VMLSL (integer) ASIMD
on page A8-931
1 - - Vector Multiply VMUL, VMULL (integer and polynomial) ASIMD

on page A8-959
1010 - - - Vector Pairwise Maximum or Minimum VPMAX, VPMIN (integer) on ASIMD

page A8-987
1011 0 0 - Vector Saturating Doubling Multiply Returning VQDMULH on page A8-1001 ASIMD
High Half
1 - Vector Saturating Rounding Doubling Multiply VQRDMULH on page A8-1009 ASIMD

Returning High Half
1 0 - Vector Pairwise Add VPADD (integer) on page A8-981 ASIMD
1100 1 0 - Vector Fused Multiply Accumulate or Subtract VFMA, VFMS on page A8-893 ASIMDv2
1101 0 0 0x Vector Add VADD (floating-point) on page A8-831 ASIMD
1x Vector Subtract VSUB (floating-point) on page A8-1087 ASIMD
1 0x Vector Pairwise Add VPADD (floating-point) on page A8-983 ASIMD
1x Vector Absolute Difference VABD (floating-point) on page A8-823 ASIMD
1 0 - Vector Multiply Accumulate or Subtract VMLA, VMLS (floating-point) on ASIMD

page A8-933
1 0x Vector Multiply VMUL (floating-point) on page A8-961 ASIMD
1110 0 0 0x Vector Compare Equal VCEQ (register) on page A8-845 ASIMD
1 0x Vector Compare Greater Than or Equal VCGE (register) on page A8-849 ASIMD
1x Vector Compare Greater Than VCGT (register) on page A8-853 ASIMD
1 1 - Vector Absolute Compare Greater or Less Than VACGE, VACGT, VACLE, VACLT on ASIMD
(or Equal) page A8-827
1111 0 0 - Vector Maximum or Minimum VMAX, VMIN (floating-point) on ASIMD

page A8-929
1 - Vector Pairwise Maximum or Minimum VPMAX, VPMIN (floating-point) on ASIMD

page A8-989
1 0 0x Vector Reciprocal Step VRECPS on page A8-1027 ASIMD
0 1x Vector Reciprocal Square Root Step VRSQRTS on page A8-1041 ASIMD
a. In this column, ASIMD indicates Advanced SIMD, and ASIMDv2 indicates Advanced SIMDv2.
A7.4.2 Three registers of different lengths

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 U 1 1 1 1 1 B A 0 0

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 U 1 B A 0 0
If B == 0b11, see Advanced SIMD data-processing instructions on page A7-259.
Otherwise, Table A7-10 shows the allocation of encodings in this space. Other encodings in this space are
UNDEFINED.
Table A7-10 Data-processing instructions with three registers of different lengths
A U Instruction See
000x - Vector Add Long or Wide VADDL, VADDW on page A8-835
001x - Vector Subtract Long or Wide VSUBL, VSUBW on page A8-1091
0100 0 Vector Add and Narrow, returning High Half VADDHN on page A8-833
1 Vector Rounding Add and Narrow, returning High Half VRADDHN on page A8-1023
0101 - Vector Absolute Difference and Accumulate VABA, VABAL on page A8-819
0110 0 Vector Subtract and Narrow, returning High Half VSUBHN on page A8-1089
1 Vector Rounding Subtract and Narrow, returning High Half VRSUBHN on page A8-1045
0111 - Vector Absolute Difference VABD, VABDL (integer) on page A8-821
10x0 - Vector Multiply Accumulate or Subtract VMLA, VMLAL, VMLS, VMLSL (integer) on page A8-931
10x1 0 Vector Saturating Doubling Multiply Accumulate or VQDMLAL, VQDMLSL on page A8-999
Subtract Long
1100 - Vector Multiply (integer) VMUL, VMULL (integer and polynomial) on page A8-959
1101 0 Vector Saturating Doubling Multiply Long VQDMULL on page A8-1003
1110 - Vector Multiply (polynomial) VMUL, VMULL (integer and polynomial) on page A8-959
A7.4.3 Two registers and a scalar

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 U 1 1 1 1 1 B A 1 0

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 U 1 B A 1 0
If B == 0b11, see Advanced SIMD data-processing instructions on page A7-259.
UNDEFINED.
Table A7-11 Data-processing instructions with two registers and a scalar
A U Instruction See
0x0x - Vector Multiply Accumulate or Subtract VMLA, VMLAL, VMLS, VMLSL (by scalar) on page A8-935
0x10 - Vector Multiply Accumulate or Subtract Long VMLA, VMLAL, VMLS, VMLSL (by scalar) on page A8-935
0x11 0 Vector Saturating Doubling Multiply Accumulate or VQDMLAL, VQDMLSL on page A8-999
Subtract Long
100x - Vector Multiply VMUL, VMULL (by scalar) on page A8-963
1010 - Vector Multiply Long VMUL, VMULL (by scalar) on page A8-963
1011 0 Vector Saturating Doubling Multiply Long VQDMULL on page A8-1003
1100 - Vector Saturating Doubling Multiply returning High VQDMULH on page A8-1001
Half
1101 - Vector Saturating Rounding Doubling Multiply VQRDMULH on page A8-1009

returning High Half
A7.4.4 Two registers and a shift amount

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 U 1 1 1 1 1 imm3 A L B 1

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 U 1 imm3 A L B 1
If [L, imm3] == 0b0000, see One register and a modified immediate value on page A7-267.
UNDEFINED.
Table A7-12 Data-processing instructions with two registers and a shift amount
A U B L Instruction See
0000 - - - Vector Shift Right VSHR on page A8-1053
0001 - - - Vector Shift Right and Accumulate VSRA on page A8-1061
0010 - - - Vector Rounding Shift Right VRSHR on page A8-1035
0011 - - - Vector Rounding Shift Right and Accumulate VRSRA on page A8-1043
0100 1 - - Vector Shift Right and Insert VSRI on page A8-1063
0101 0 - - Vector Shift Left VSHL (immediate) on page A8-1047
1 - - Vector Shift Left and Insert VSLI on page A8-1057
011x - - - Vector Saturating Shift Left VQSHL, VQSHLU (immediate) on page A8-1017
1000 0 0 0 Vector Shift Right Narrow VSHRN on page A8-1055
1 0 Vector Rounding Shift Right Narrow VRSHRN on page A8-1037
1 0 0 Vector Saturating Shift Right, Unsigned Narrow VQSHRN, VQSHRUN on page A8-1019
1 0 Vector Saturating Shift Right, Rounded Unsigned VQRSHRN, VQRSHRUN on page A8-1013
Narrow
1001 - 0 0 Vector Saturating Shift Right, Narrow VQSHRN, VQSHRUN on page A8-1019
1 0 Vector Saturating Shift Right, Rounded Narrow VQRSHRN, VQRSHRUN on page A8-1013
1010 - 0 0 Vector Shift Left Long VSHLL on page A8-1051
Vector Move Long VMOVL on page A8-951
111x - - 0 Vector Convert VCVT (between floating-point and fixed-point,

Advanced SIMD) on page A8-873
A7.4.5 Two registers, miscellaneous

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 1 1 A 0 B 0

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 1 1 A 0 B 0
The allocation of encodings in this space is shown in Table A7-13. Other encodings in this space are UNDEFINED.
Table A7-13 Instructions with two registers, miscellaneous
A B Instruction See
00 0000x Vector Reverse in doublewords VREV16, VREV32, VREV64 on page A8-1029
0001x Vector Reverse in words VREV16, VREV32, VREV64 on page A8-1029
0010x Vector Reverse in halfwords VREV16, VREV32, VREV64 on page A8-1029
010xx Vector Pairwise Add Long VPADDL on page A8-985
1000x Vector Count Leading Sign Bits VCLS on page A8-859
1001x Vector Count Leading Zeros VCLZ on page A8-863
1010x Vector Count VCNT on page A8-867
1011x Vector Bitwise NOT VMVN (register) on page A8-967
110xx Vector Pairwise Add and Accumulate Long VPADAL on page A8-979
00 1110x Vector Saturating Absolute VQABS on page A8-995
1111x Vector Saturating Negate VQNEG on page A8-1007
01 x000x Vector Compare Greater Than Zero VCGT (immediate #0) on page A8-855
x001x Vector Compare Greater Than or Equal to Zero VCGE (immediate #0) on page A8-851
x010x Vector Compare Equal to zero VCEQ (immediate #0) on page A8-847
x011x Vector Compare Less Than or Equal to Zero VCLE (immediate #0) on page A8-857
x100x Vector Compare Less Than Zero VCLT (immediate #0) on page A8-861
x110x Vector Absolute VABS on page A8-825
x111x Vector Negate VNEG on page A8-969
10 0000x Vector Swap VSWP on page A8-1093
0001x Vector Transpose VTRN on page A8-1097
0010x Vector Unzip VUZP on page A8-1101
0011x Vector Zip VZIP on page A8-1103
01000 Vector Move and Narrow VMOVN on page A8-953
01001 Vector Saturating Move and Unsigned Narrow VQMOVN, VQMOVUN on page A8-1005
0101x Vector Saturating Move and Narrow VQMOVN, VQMOVUN on page A8-1005
01100 Vector Shift Left Long (maximum shift) VSHLL on page A8-1051
11x00 Vector Convert VCVT (between half-precision and single-precision, Advanced

SIMD) on page A8-879
Table A7-13 Instructions with two registers, miscellaneous (continued)
A B Instruction See
11 10x0x Vector Reciprocal Estimate VRECPE on page A8-1025
10x1x Vector Reciprocal Square Root Estimate VRSQRTE on page A8-1039
11xxx Vector Convert VCVT (between floating-point and integer, Advanced SIMD) on
page A8-869
A7.4.6 One register and a modified immediate value

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 a 1 1 1 1 1 0 0 0 b c d cmode 0 op 1 e f g h

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 a 1 0 0 0 b c d cmode 0 op 1 e f g h
Table A7-14 Data-processing instructions with one register and a modified immediate value
op cmode Instruction See
0 0xx0 Vector Move VMOV (immediate) on page A8-937
0xx1 Vector Bitwise OR VORR (immediate) on page A8-975
10x0 Vector Move VMOV (immediate) on page A8-937
10x1 Vector Bitwise OR VORR (immediate) on page A8-975
11xx Vector Move VMOV (immediate) on page A8-937
1 0xx0 Vector Bitwise NOT VMVN (immediate) on page A8-965
0xx1 Vector Bit Clear VBIC (immediate) on page A8-839
10x0 Vector Bitwise NOT VMVN (immediate) on page A8-965
10x1 Vector Bit Clear VBIC (immediate) on page A8-839
110x Vector Bitwise NOT VMVN (immediate) on page A8-965
1110 Vector Move VMOV (immediate) on page A8-937
1111 UNDEFINED -
Table A7-15 shows the modified immediate constants available with these instructions, and how they are encoded.
Table A7-15 Modified immediate values for Advanced SIMD instructions
op cmode Constant a <dt> b Notes
- 000x 00000000 00000000 00000000 abcdefgh 00000000 00000000 00000000 abcdefgh I32 c
001x 00000000 00000000 abcdefgh 00000000 00000000 00000000 abcdefgh 00000000 I32 c, d
010x 00000000 abcdefgh 00000000 00000000 00000000 abcdefgh 00000000 00000000 I32 c, d
011x abcdefgh 00000000 00000000 00000000 abcdefgh 00000000 00000000 00000000 I32 c, d
100x 00000000 abcdefgh 00000000 abcdefgh 00000000 abcdefgh 00000000 abcdefgh I16 c
101x abcdefgh 00000000 abcdefgh 00000000 abcdefgh 00000000 abcdefgh 00000000 I16 c, d
1100 00000000 00000000 abcdefgh 11111111 00000000 00000000 abcdefgh 11111111 I32 d, e
1101 00000000 abcdefgh 11111111 11111111 00000000 abcdefgh 11111111 11111111 I32 d, e
Table A7-15 Modified immediate values for Advanced SIMD instructions (continued)
op cmode Constant a <dt> b Notes
0 1110 abcdefgh abcdefgh abcdefgh abcdefgh abcdefgh abcdefgh abcdefgh abcdefgh I8 f
1111 aBbbbbbc defgh000 00000000 00000000 aBbbbbbc defgh000 00000000 00000000 F32 f, g
1 1110 aaaaaaaa bbbbbbbb cccccccc dddddddd eeeeeeee ffffffff gggggggg hhhhhhhh I64 f
1111 UNDEFINED - -
a. In this table, the immediate value is shown in binary form, to relate abcdefgh to the encoding diagram. In assembler
syntax, the constant is specified by a data type and a value of that type. That value is specified in the normal way (a
decimal number by default) and is replicated enough times to fill the 64-bit immediate. For example, a data type of I32
and a value of 10 specify the 64-bit constant 0x0000000A0000000A.
b. This specifies the data type used when the instruction is disassembled. On assembly, the data type must be matched in
the table if possible. Other data types are permitted as pseudo-instructions when a program is assembled, provided the
64-bit constant specified by the data type and value is available for the instruction. If a constant is available in more than
one way, the first entry in this table that can produce it is used. For example, VMOV.I64 D0, #0x8000000080000000 does
not specify a 64-bit constant that is available from the I64 line of the table, but does specify one that is available from
the fourth I32 line or the F32 line. It is assembled to the first of these, and therefore is disassembled as VMOV.I32 D0,
#0x80000000.
c. This constant is available for the VBIC, VMOV, VMVN, and VORR instructions.
d. UNPREDICTABLE if abcdefgh == 00000000.
e. This constant is available for the VMOV and VMVN instructions only.
f. This constant is available for the VMOV instruction only.
g. In this entry, B = NOT(b). The bit pattern represents the floating-point number (–1)S × 2exp × mantissa, where
S = UInt(a), exp = UInt(NOT(b):c:d)-3 and mantissa = (16+UInt(e:f:g:h))/16.
Advanced SIMD expand immediate pseudocode

// AdvSIMDExpandImm()
// ==================
bits(64) AdvSIMDExpandImm(bit op, bits(4) cmode, bits(8) imm8)
case cmode<3:1> of
when '000'
testimm8 = FALSE; imm64 = Replicate(Zeros(24):imm8, 2);
when '001'
testimm8 = TRUE; imm64 = Replicate(Zeros(16):imm8:Zeros(8), 2);
when '010'
testimm8 = TRUE; imm64 = Replicate(Zeros(8):imm8:Zeros(16), 2);
when '011'
testimm8 = TRUE; imm64 = Replicate(imm8:Zeros(24), 2);
when '100'
testimm8 = FALSE; imm64 = Replicate(Zeros(8):imm8, 4);
when '101'
testimm8 = TRUE; imm64 = Replicate(imm8:Zeros(8), 4);
when '110'
testimm8 = TRUE;
if cmode<0> == '0' then
imm64 = Replicate(Zeros(16):imm8:Ones(8), 2);
else
imm64 = Replicate(Zeros(8):imm8:Ones(16), 2);
when '111'
testimm8 = FALSE;
if cmode<0> == '0' && op == '0' then
imm64 = Replicate(imm8, 8);
if cmode<0> == '0' && op == '1' then
imm8a = Replicate(imm8<7>, 8); imm8b = Replicate(imm8<6>, 8);
imm8c = Replicate(imm8<5>, 8); imm8d = Replicate(imm8<4>, 8);
imm8e = Replicate(imm8<3>, 8); imm8f = Replicate(imm8<2>, 8);
imm8g = Replicate(imm8<1>, 8); imm8h = Replicate(imm8<0>, 8);
imm64 = imm8a:imm8b:imm8c:imm8d:imm8e:imm8f:imm8g:imm8h;
if cmode<0> == '1' && op == '0' then
imm32 = imm8<7>:NOT(imm8<6>):Replicate(imm8<6>,5):imm8<5:0>:Zeros(19);
imm64 = Replicate(imm32, 2);
if cmode<0> == '1' && op == '1' then
UNDEFINED;
if testimm8 && imm8 == '00000000' then

UNPREDICTABLE;
return imm64;

The Thumb encoding of Floating-point (VFP) data processing instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 T 1 1 1 0 opc1 opc2 1 0 1 opc3 0 opc4
The ARM encoding of Floating-point (VFP) data processing instructions is:

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 1 0 opc1 opc2 1 0 1 opc3 0 opc4
If T == 1 in the Thumb encoding or cond == 0b1111 in the ARM encoding, the instruction is UNDEFINED.
Otherwise:
• Table A7-16 shows the encodings for three-register Floating-point data-processing instructions. Other
encodings in this space are UNDEFINED.
• Table A7-17 applies only if Table A7-16 indicates that it does. It shows the encodings for Floating-point
data-processing instructions with two registers or a register and an immediate. Other encodings in this space
are UNDEFINED.
• Table A7-18 on page A7-271 shows the immediate constants available in the VMOV (immediate) instruction.
These instructions are CDP instructions for coprocessors 10 and 11.
Table A7-16 Three-register Floating-point data-processing instructions
opc1 opc3 Instruction See Variant
0x00 - Vector Multiply Accumulate or Subtract VMLA, VMLS (floating-point) on page A8-933 VFPv2
0x01 - Vector Negate Multiply Accumulate or Subtract VNMLA, VNMLS, VNMUL on page A8-971 VFPv2
0x10 x1
x0 Vector Multiply VMUL (floating-point) on page A8-961 VFPv2
0x11 x0 Vector Add VADD (floating-point) on page A8-831 VFPv2
x1 Vector Subtract VSUB (floating-point) on page A8-1087 VFPv2
1x00 x0 Vector Divide VDIV on page A8-883
1x01 - Vector Fused Negate Multiply Accumulate or VFNMA, VFNMS on page A8-895 VFPv4
Subtract
1x10 - Vector Fused Multiply Accumulate or Subtract VFMA, VFMS on page A8-893 VFPv4
1x11 - Other Floating-point data-processing instructions Table A7-17 -
Table A7-17 Other Floating-point data-processing instructions
- x0 Vector Move VMOV (immediate) on page A8-937 VFPv3
0000 01 Vector Move VMOV (register) on page A8-939 VFPv2
11 Vector Absolute VABS on page A8-825 VFPv2
0001 01 Vector Negate VNEG on page A8-969 VFPv2
11 Vector Square Root VSQRT on page A8-1059 VFPv2
Table A7-17 Other Floating-point data-processing instructions (continued)
001x x1 Vector Convert VCVTB, VCVTT on page A8-881 VFPv3HP a
010x x1 Vector Compare VCMP, VCMPE on page A8-865 VFPv2
0111 11 Vector Convert VCVT (between double-precision and single-precision) on page A8-877 VFPv2
1000 x1 Vector Convert VCVT, VCVTR (between floating-point and integer, Floating-point) on VFPv2
page A8-871
101x x1 Vector Convert VCVT (between floating-point and fixed-point, Floating-point) on VFPv3
page A8-875
110x x1 Vector Convert VCVT, VCVTR (between floating-point and integer, Floating-point) on VFPv2
page A8-871
111x x1 Vector Convert VCVT (between floating-point and fixed-point, Floating-point) on VFPv3
page A8-875
a. VFPv3 Half-precision Extension.
Table A7-18 Floating-point modified immediate constants
Data type opc2 opc4 Constant a
F32 abcd efgh aBbbbbbc defgh000 00000000 00000000
F64 abcd efgh aBbbbbbb bbcdefgh 00000000 00000000 00000000 00000000 00000000 00000000
a. In this column, B = NOT(b). The bit pattern represents the floating-point number (–1)S × 2exp × mantissa, where
S = UInt(a), exp = UInt(NOT(b):c:d)-3 and mantissa = (16+UInt(e:f:g:h))/16.
A7.5.1 Operation of modified immediate constants, Floating-point

The VFPExpandImm() pseudocode function describes the operation of an immediate constant in a floating-point
instruction.
// VFPExpandImm()
// ==============
bits(N) VFPExpandImm(bits(8) imm8, integer N)

if N == 32 then
E = 8;
else
E = 11;
F = N - E - 1;
sign = imm8<7>;
exp = NOT(imm8<6>):Replicate(imm8<6>,E-3):imm8<5:4>;
frac = imm8<3:0>:Zeros(F-4);
A7.6 Extension register load/store instructions
A7.6 Extension register load/store instructions

The Thumb encoding of Advanced SIMD and Floating-point (VFP) Extension register load and store instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 T 1 1 0 Opcode Rn 1 0 1
The ARM encoding of Advanced SIMD and Floating-point (VFP) Extension register load and store instructions is:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 0 Opcode Rn 1 0 1
Otherwise, the allocation of encodings in this space is shown in Table A7-19. Other encodings in this space are
UNDEFINED.
These instructions are LDC and STC instructions for coprocessors 10 and 11.
Table A7-19 Extension register load/store instructions
Opcode Rn Instruction See
0010x - - 64-bit transfers between ARM core and extension

registers on page A7-277
01x00 - Vector Store Multiple (Increment After, no writeback) VSTM on page A8-1081
01x10 - Vector Store Multiple (Increment After, writeback) VSTM on page A8-1081
1xx00 - Vector Store Register VSTR on page A8-1083
10x10 not 1101 Vector Store Multiple (Decrement Before, writeback) VSTM on page A8-1081
1101 Vector Push Registers VPUSH on page A8-993
01x01 - Vector Load Multiple (Increment After, no writeback) VLDM on page A8-923
01x11 not 1101 Vector Load Multiple (Increment After, writeback) VLDM on page A8-923
1101 Vector Pop Registers VPOP on page A8-991
1xx01 - Vector Load Register VLDR on page A8-925
10x11 - Vector Load Multiple (Decrement Before, writeback) VLDM on page A8-923
A7.7 Advanced SIMD element or structure load/store instructions

The Thumb encoding of Advanced SIMD element load and store instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 1 A L 0 B
The ARM encoding of Advanced SIMD element load and store instructions is:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 1 0 0 A L 0 B
The allocation of encodings in this space is shown in:

• Table A7-20 if L == 0. These are the encodings for store instructions.
• Table A7-21 on page A7-274 if L == 1. These are the encodings for load instructions.

The variable bits are in identical locations in the two encodings, after adjusting for the fact that the ARM encoding
is held in memory as a single word and the Thumb encoding is held as two consecutive halfwords.
The ARM instructions can only be executed unconditionally. The Thumb instructions can be executed conditionally
by using the IT instruction. For details see IT on page A8-391.
Table A7-20 Element and structure store instructions (L == 0)
A B Instruction See
0 0010 Vector Store VST1 (multiple single elements) on page A8-1065

011x
1010
0011 Vector Store VST2 (multiple 2-element structures) on page A8-1069

100x
010x Vector Store VST3 (multiple 3-element structures) on page A8-1073
000x Vector Store VST4 (multiple 4-element structures) on page A8-1077
1 0x00 Vector Store VST1 (single element from one lane) on page A8-1067
1000
0x01 Vector Store VST2 (single 2-element structure from one lane) on page A8-1071
1001
1010
1011
Table A7-21 Element and structure load instructions (L == 1)
A B Instruction See
0 0010 Vector Load VLD1 (multiple single elements) on page A8-899

011x
1010
0011 Vector Load VLD2 (multiple 2-element structures) on page A8-905

100x
010x Vector Load VLD3 (multiple 3-element structures) on page A8-911
000x Vector Load VLD4 (multiple 4-element structures) on page A8-917
1 0x00 Vector Load VLD1 (single element to one lane) on page A8-901
1000
1100 Vector Load VLD1 (single element to all lanes) on page A8-903
0x01 Vector Load VLD2 (single 2-element structure to one lane) on page A8-907
1001
1101 Vector Load VLD2 (single 2-element structure to all lanes) on page A8-909
1010
1011
A7.7.1 Advanced SIMD addressing mode

All the element and structure load/store instructions use this addressing mode. There is a choice of three formats:
[<Rn>{:<align>}] The address is contained in ARM core register Rn.

Rn is not updated by this instruction.
Encoded as Rm = 0b1111.
If Rn is encoded as 0b1111, the instruction is UNPREDICTABLE.
[<Rn>{:<align>}]! The address is contained in ARM core register Rn.

Rn is updated by this instruction: Rn = Rn + transfer_size
Encoded as Rm = 0b1101.
transfer_size is the number of bytes transferred by the instruction. This means that, after
the instruction is executed, Rn points to the address in memory immediately following the
last address loaded from or stored to.
This addressing mode can also be written as:
[<Rn>{:align}], #<transfer_size>
However, disassembly produces the [<Rn>{:align}]! form.
[<Rn>{:<align>}], <Rm>
The address is contained in ARM core register <Rn>.
Rn is updated by this instruction: Rn = Rn + Rm
Encoded as Rm = Rm. Rm must not be encoded as 0b1111 or 0b1101, the PC or the SP.
In all cases, <align> specifies an alignment. Details are given in the individual instruction descriptions.
Previous versions of the document used the @ character for alignment. So, for example, the first format in this section
was shown as [<Rn>{@<align>}]. Both @ and : are supported. However, to ensure portability of code to assemblers
that treat @ as a comment character, : is preferred.
A7.8 8, 16, and 32-bit transfer between ARM core and extension registers
A7.8 8, 16, and 32-bit transfer between ARM core and extension registers
The Thumb encoding of Advanced SIMD and Floating-point 8-bit, 16-bit, and 32-bit register data transfer
instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 T 1 1 1 0 A L 1 0 1 C B 1
The ARM encoding of Advanced SIMD and Floating-point 8-bit, 16-bit, and 32-bit register data transfer
instructions is:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 1 0 A L 1 0 1 C B 1
UNDEFINED.
These instructions are MRC and MCR instructions for coprocessors 10 and 11.
Table A7-22 8-bit, 16-bit and 32-bit data transfer instructions
L C A B Instruction See
0 0 000 - Vector Move VMOV (between ARM core register and single-precision register) on
page A8-945
111 - Move to Floating-point Special VMSR on page A8-957

register from ARM core register VMSR on page B9-2002, System level view
0 1 0xx - Vector Move VMOV (ARM core register to scalar) on page A8-941
1xx 0x Vector Duplicate VDUP (ARM core register) on page A8-887
1 0 000 - Vector Move VMOV (between ARM core register and single-precision register) on
page A8-945
111 - Move to ARM core register from VMRS on page A8-955

Floating-point Special register VMRS on page B9-2000, System level view
1 xxx - Vector Move VMOV (scalar to ARM core register) on page A8-943
A7.9 64-bit transfers between ARM core and extension registers

The Thumb encoding of Advanced SIMD and Floating-point 64-bit register data transfer instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 T 1 1 0 0 0 1 0 1 0 1 C op
The ARM encoding of Advanced SIMD and Floating-point 64-bit register data transfer instructions is:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 0 0 0 1 0 1 0 1 C op
UNDEFINED.
These instructions are MRRC and MCRR instructions for coprocessors 10 and 11.
Table A7-23 64-bit data transfer instructions
C op Instruction
0 00x1 VMOV (between two ARM core registers and two single-precision registers) on page A8-947
1 00x1 VMOV (between two ARM core registers and a doubleword extension register) on page A8-949
Chapter A8
Instruction Descriptions
This chapter describes each instruction. It contains the following sections:

• Format of instruction descriptions on page A8-280
• Standard assembler syntax fields on page A8-285
• Conditional execution on page A8-286
• Shifts applied to a register on page A8-289
• Memory accesses on page A8-292
• Encoding of lists of ARM core registers on page A8-293
• Additional pseudocode support for instruction descriptions on page A8-294
• Alphabetical list of instructions on page A8-298.
Note
The Floating-point Extension was previously described as the VFP Extension, and:
• Different versions of this extension, and the instructions they introduce, are identified using the abbreviation
VFP, for example VFPv3.
• The deprecated vector features of the Floating-point Extension are identified as VFP vectors.
A8 Instruction Descriptions
A8.1 Format of instruction descriptions

The instruction descriptions in Alphabetical list of instructions on page A8-298 normally use the following format:
• instruction section title
• introduction to the instruction
• instruction encoding(s) with architecture information
• assembler syntax
• pseudocode describing how the instruction operates
• exception information
• notes (where applicable).
Each of these items is described in more detail in the following subsections.
A few instruction descriptions describe alternative mnemonics for other instructions and use an abbreviated and
modified version of this format.
A8.1.1 Instruction section title

The instruction section title gives the base mnemonic for the instructions described in the section. When one
mnemonic has multiple forms described in separate instruction sections, this is followed by a short description of
the form in parentheses. The most common use of this is to distinguish between forms of an instruction in which
one of the operands is an immediate value and forms in which it is a register.
Another use of parenthesized text is to indicate the former mnemonic in some cases where a mnemonic has been
replaced entirely by another mnemonic in the new assembler syntax.
A8.1.2 Introduction to the instruction

The instruction section title is followed by text that briefly describes the main features of the instruction. This
description is not necessarily complete and is not definitive. If there is any conflict between it and the more detailed
information that follows, the latter takes priority.
A8.1.3 Instruction encodings

This is a list of one or more instruction encodings. Each instruction encoding is labelled as:
• T1, T2, T3 … for the first, second, third and any additional Thumb encodings
• A1, A2, A3 … for the first, second, third and any additional ARM encodings
• E1, E2, E3 … for the first, second, third and any additional ThumbEE encodings that are not also Thumb
encodings.
Where Thumb and ARM encodings are very closely related, the two encodings are described together, for example
as encoding T1/A1.
Each instruction encoding description consists of:
• Information about which architecture variants include the particular encoding of the instruction. This is
presented in one of two ways:
— For instruction encodings that are in the main instruction set architecture, as a list of the architecture
variants that include the encoding. See Architecture versions, profiles, and variants on page A1-30 for
a summary of these variants.
— For instruction encodings that are in the architecture extensions, as a list of the architecture extensions
that include the encoding. See Architecture extensions on page A1-32 for a summary of the
architecture extensions and the architecture variants that they can extend.
In architecture variant lists:
— ARMv7 means ARMv7-A and ARMv7-R profiles. The architecture variant information in this manual
does not cover the ARMv7-M profile.
— * is used as a wildcard. For example, ARMv5T* means ARMv5T, ARMv5TE, and ARMv5TEJ.
• An assembly syntax that ensures that the assembler selects the encoding in preference to any other encoding.
In some cases, multiple syntaxes are given. The correct one to use is sometimes indicated by annotations to
the syntax, such as Inside IT block and Outside IT block. In other cases, the correct one to use can be
determined by looking at the assembler syntax description and using it to determine which syntax
corresponds to the instruction being disassembled.
There is usually more than one syntax that ensures re-assembly to any particular encoding, and the exact set
of syntaxes that do so usually depends on the register numbers, immediate constants and other operands to
the instruction. For example, when assembling to the Thumb instruction set, the syntax AND R0, R0, R8
ensures selection of a 32-bit encoding but AND R0, R0, R1 selects a 16-bit encoding.
The assembly syntax documented for the encoding is chosen to be the simplest one that ensures selection of
that encoding for all operand combinations supported by that encoding. This often means that it includes
elements that are only necessary for a small subset of operand combinations. For example, the assembler
syntax documented for the 32-bit Thumb AND (register) encoding includes the .W qualifier to ensure that the
32-bit encoding is selected even for the small proportion of operand combinations for which the 16-bit
encoding is also available.
The assembly syntax given for an encoding is therefore a suitable one for a disassembler to disassemble that
encoding to. However, disassemblers might wish to use simpler syntaxes when they are suitable for the
operand combination, in order to produce more readable disassembled code.
• An encoding diagram, or a Thumb encoding diagram followed by an ARM encoding diagram when they are
being described together. This is half-width for 16-bit Thumb encodings and full-width for 32-bit Thumb and
ARM encodings. The 32-bit ARM encoding diagrams number the bits from 31 to 0, while the 32-bit Thumb
encoding diagrams number the bits from 15 to 0 for each halfword, to distinguish them from ARM encodings
and to act as a reminder that a 32-bit Thumb instruction consists of two consecutive halfwords rather than a
word.
In particular, if instructions are stored using the standard little-endian instruction endianness, the encoding
diagram for an ARM instruction at address A shows the bytes at addresses A+3, A+2, A+1, A from left to
right, but the encoding diagram for a 32-bit Thumb instruction shows them in the order A+1, A for the first
halfword, followed by A+3, A+2 for the second halfword.
• Encoding-specific pseudocode. This is pseudocode that translates the encoding-specific instruction fields
into inputs to the encoding-independent pseudocode in the later Operation subsection, and that picks out any
special cases in the encoding. For a detailed description of the pseudocode used and of the relationship
between the encoding diagram, the encoding-specific pseudocode and the encoding-independent
pseudocode, see Appendix D16 Pseudocode Definition.
A8.1.4 Assembler syntax

The Assembly syntax subsection describes the standard UAL syntax for the instruction.
Each syntax description consists of the following elements:
• One or more syntax prototype lines written in a typewriter font, using the conventions described in
Assembler syntax prototype line conventions on page A8-282. Each prototype line documents the mnemonic
and (where appropriate) operand parts of a full line of assembler code. When there is more than one such line,
each prototype line is annotated to indicate required results of the encoding-specific pseudocode.
For each instruction encoding belonging to a target instruction set, an assembler can use this information to
determine whether it can use that encoding to encode the instruction requested by the UAL source. If multiple
encodings can encode the instruction then:
— If both a 16-bit encoding and a 32-bit encoding can encode the instruction, the architecture prefers the
16-bit encoding. This means the assembler must use the 16-bit encoding rather than the 32-bit
encoding.
Software can use the .W and .N qualifiers to specify the required encoding width, see Standard
assembler syntax fields on page A8-285.
— If multiple encodings of the same length can encode the instruction, the Assembler syntax subsection
says which encoding is preferred, and how software can, instead, select the other encodings.
Each encoding also documents UAL syntax that selects it in preference to any other encoding.
If no encodings of the target instruction set can encode the instruction requested by the UAL source, normally
the assembler generates an error saying that the instruction is not available in that instruction set.
Note
Often, an instruction is available in one instruction set but not in another. The Assembler syntax subsection
identifies many of these cases. For example, the ARM instructions with bits<31:28> == 0b1111 described in
Unconditional instructions on page A5-214 cannot have a condition code, but the equivalent Thumb
instructions often can, and this usually appears in the Assembler syntax subsection as a statement that the
ARM instruction cannot be conditional.
However, some such cases are too complex to describe in the available space, so the definitive test of whether
an instruction is available in a given instruction set is whether there is an available encoding for it in that
instruction set.
• The line where: followed by descriptions of all of the variable or optional fields of the prototype syntax line.
Some syntax fields are standardized across all or most instructions. Standard assembler syntax fields on
page A8-285 describes these fields.
By default, syntax fields that specify registers, such as <Rd>, <Rn>, or <Rt>, can be any of R0-R12 or LR in
Thumb instructions, and any of R0-R12, SP or LR in ARM instructions. These require that the
encoding-specific pseudocode set the corresponding integer variable (such as d, n, or t) to the corresponding
register number, using 0-12 for R0-R12, 13 for SP, or 14 for LR:
— Normally, software can do this by setting the corresponding field in the instruction, typically named
Rd, Rn, Rt, to the binary encoding of that number.
— In the case of 16-bit Thumb encodings, the field is normally of length 3, and so the encoding is only
available when the assembler syntax specifies one of R0-R7. Such encodings often use a register field
name like Rdn. This indicates that the encoding is only available if <Rd> and <Rn> specify the same
register, and that the register number of that register is encoded in the field if they do.
The description of a syntax field that specifies a register sometimes extends or restricts the permitted range
of registers or documents other differences from the default rules for such fields. Examples of extensions are
permitting the use of the SP in a Thumb instruction, or permitting the use of the PC, identified using register
number 15.
• Where appropriate, text that briefly describes changes from the pre-UAL ARM assembler syntax. Where
present, this usually consists of an alternative pre-UAL form of the assembler mnemonic. The pre-UAL
ARM assembler syntax does not conflict with UAL. ARM recommends that it is supported, as an optional
extension to UAL, so that pre-UAL ARM assembler source files can be assembled.
Note
The pre-UAL Thumb assembler syntax is incompatible with UAL and is not documented in the instruction sections.
For details see Appendix D8 Legacy Instruction Mnemonics.
Assembler syntax prototype line conventions

The following conventions are used in assembler syntax prototype lines and their subfields:
< > Any item bracketed by < and > is a short description of a type of value to be supplied by the user in
that position. A longer description of the item is normally supplied by subsequent text. Such items
often correspond to a similarly named field in an encoding diagram for an instruction. When the
correspondence only requires the binary encoding of an integer value or register number to be
substituted into the instruction encoding, it is not described explicitly. For example, if the assembler
syntax for an ARM instruction contains an item <Rn> and the instruction encoding diagram contains
a 4-bit field named Rn, the number of the register specified in the assembler syntax is encoded in
binary in the instruction field.
If the correspondence between the assembler syntax item and the instruction encoding is more
complex than simple binary encoding of an integer or register number, the item description indicates
how it is encoded. This is often done by specifying a required output from the encoding-specific
pseudocode, such as add = TRUE. The assembler must only use encodings that produce that output.
{ } Any item bracketed by { and } is optional. A description of the item and of how its presence or
absence is encoded in the instruction is normally supplied by subsequent text.
Many instructions have an optional destination register. Unless otherwise stated, if such a
destination register is omitted, it is the same as the immediately following source register in the
instruction syntax.
# In the assembler syntax, numeric constants are normally preceded by a #. Some UAL instruction
syntax descriptions explicitly show this # as optional. Any UAL assembler:
• must treat the # as optional where an instruction syntax description shows it as optional
• can treat the # either as mandatory or as optional where an instruction syntax description does
not show it as optional.
Note
ARM recommends that UAL assemblers treat all uses of # shown in this manual as optional.
spaces Single spaces are used for clarity, to separate items. When a space is obligatory in the assembler
syntax, two or more consecutive spaces are used.
+/- This indicates an optional + or - sign. If neither is coded, + is assumed.
All other characters must be encoded precisely as they appear in the assembler syntax. Apart from { and }, the
special characters described above do not appear in the basic forms of assembler instructions documented in this
manual. The { and } characters need to be encoded in a few places as part of a variable item. When this happens,
the long description of the variable item indicates how they must be used.
A8.1.5 Pseudocode describing how the instruction operates

The Operation subsection contains encoding-independent pseudocode that describes the main operation of the
instruction. For a detailed description of the pseudocode used and of the relationship between the encoding diagram,
the encoding-specific pseudocode and the encoding-independent pseudocode, see Appendix D16 Pseudocode
Definition.
A8.1.6 Exception information

The Exceptions subsection contains a list of the exceptional conditions that can be caused by execution of the
instruction.
Processor exceptions are listed as follows:
• Resets and interrupts (both IRQs and FIQs) are not listed. They can occur before or after the execution of any
instruction, and in some cases during the execution of an instruction, but they are not in general caused by
the instruction concerned.
• Prefetch Abort exceptions are normally caused by a memory abort when an instruction is fetched, followed
by an attempt to execute that instruction. This can happen for any instruction, but is caused by the aborted
attempt to fetch the instruction rather than by the instruction itself, and so is not listed. A special case is the
BKPT instruction, that is defined as causing a Prefetch Abort exception in some circumstances.
• Data Abort exceptions are listed for all instructions that perform data memory accesses.
• Undefined Instruction exceptions are listed when they are part of the effects of a defined instruction. For
example, all coprocessor instructions are defined to produce the Undefined Instruction exception if not
accepted by their coprocessor. Undefined Instruction exceptions caused by the execution of an undefined
instruction are not listed, even when the undefined instruction is a special case of one or more of the
encodings of the instruction. Such special cases are instead indicated in the encoding-specific pseudocode for
the encoding.
• Supervisor Call and Secure Monitor Call exceptions are listed for the SVC and SMC instructions respectively.
Supervisor Call exceptions and the SVC instruction were previously called Software Interrupt exceptions and
the SWI instruction. Secure Monitor Call exceptions and the SMC instruction were previously called Secure
Monitor interrupts and the SMI instruction.
Floating-point exceptions are listed for instructions that can produce them. Floating-point exceptions on
page A2-69 describes these exceptions. They do not normally result in processor exceptions.
A8.1.7 Notes
Where appropriate, other notes about the instruction appear under additional subheadings.
Note
Information that was documented in notes in previous versions of the ARM Architecture Reference Manual and its
supplements has often been moved elsewhere. For example, operand restrictions on the values of fields in an
instruction encoding are now normally documented in the encoding-specific pseudocode for that encoding.
A8.2 Standard assembler syntax fields
A8.2 Standard assembler syntax fields

The following assembler syntax fields are standard across all or most instructions:
<c> Is an optional field. It specifies the condition under which the instruction is executed. See
Conditional execution on page A8-286 for the range of available conditions and their encoding. If
<c> is omitted, it defaults to always (AL).
<q> Specifies optional assembler qualifiers on the instruction. The following qualifiers are defined:
.N Meaning narrow, specifies that the assembler must select a 16-bit encoding for the
instruction. If this is not possible, an assembler error is produced.
.W Meaning wide, specifies that the assembler must select a 32-bit encoding for the
instruction. If this is not possible, an assembler error is produced.
If neither .W nor .N is specified, the assembler can select either 16-bit or 32-bit encodings. If both
are available, it must select a 16-bit encoding. In a few cases, more than one encoding of the same
length can be available for an instruction. The rules for selecting between such encodings are
instruction-specific and are part of the instruction description.
Note
When assembling to the ARM instruction set, the .N qualifier produces an assembler error and
the .W qualifier has no effect.
A8.3 Conditional execution

Most ARM instructions, and most Thumb instructions from ARMv6T2 onwards, can be executed conditionally,
based on the values of the APSR condition flags. Before ARMv6T2, the only conditional Thumb instruction was
the 16-bit conditional branch instruction. Table A8-1 lists the available conditions.
Table A8-1 Condition codes
Mnemonic
cond Meaning (integer) Meaning (floating-point) a Condition flags
extension
0000 EQ Equal Equal Z == 1
0001 NE Not equal Not equal, or unordered Z == 0
0010 CS b Carry set Greater than, equal, or unordered C == 1
0011 CC c Carry clear Less than C == 0
0100 MI Minus, negative Less than N == 1
0101 PL Plus, positive or zero Greater than, equal, or unordered N == 0
0110 VS Overflow Unordered V == 1
0111 VC No overflow Not unordered V == 0
1000 HI Unsigned higher Greater than, or unordered C == 1 and Z == 0
1001 LS Unsigned lower or same Less than or equal C == 0 or Z == 1
1010 GE Signed greater than or equal Greater than or equal N == V
1011 LT Signed less than Less than, or unordered N != V
1100 GT Signed greater than Greater than Z == 0 and N == V
1101 LE Signed less than or equal Less than, equal, or unordered Z == 1 or N != V
1110 None (AL) d Always (unconditional) Always (unconditional) Any
a. Unordered means at least one NaN operand.

b. HS (unsigned higher or same) is a synonym for CS.
c. LO (unsigned lower) is a synonym for CC.
d. AL is an optional mnemonic extension for always, except in IT instructions. For details see IT on page A8-391.
In Thumb instructions, the condition, if it is not AL, is normally encoded in a preceding IT instruction. For more
information see Conditional instructions on page A4-160 and IT on page A8-391. Some conditional branch
instructions do not require a preceding IT instruction, because they include a condition code in their encoding.
In ARM instructions, bits[31:28] of the instruction contain the condition code, or contain 0b1111 for some ARM
instructions that can only be executed unconditionally.
ARM deprecates the conditional execution of any instruction encoding provided by the Advanced SIMD Extension
that is not also provided by the Floating-point (VFP) extension, and strongly recommends that:
• For ARM instructions, any such Advanced SIMD instruction that can be conditionally executed is executed
with the <c> field omitted or set to AL.
Note
This applies only to VDUP, see VDUP (ARM core register) on page A8-887. The other instructions do not
permit conditional execution in ARM state.
• For Thumb instructions, such Advanced SIMD instructions are never included in an IT block. This means
they must be specified with the <c> field omitted or set to AL.
This deprecation does not apply to Advanced SIMD instruction encodings that are also available as Floating-point
instruction encodings. That is, it does not apply to the Advanced SIMD encodings of the instructions described in
the following sections:
• VLDM on page A8-923.
• VLDR on page A8-925.
• VMOV (ARM core register to scalar) on page A8-941.
• VMOV (between two ARM core registers and a doubleword extension register) on page A8-949.
• VMRS on page A8-955.
• VMSR on page A8-957.
• VPOP on page A8-991.
• VPUSH on page A8-993.
• VSTM on page A8-1081.
• VSTR on page A8-1083.
See also Conditional execution of undefined instructions on page B1-1208.
A8.3.1 Pseudocode details of conditional execution

The CurrentCond() pseudocode function has prototype:
bits(4) CurrentCond()
This function returns a 4-bit condition specifier as follows:
• For ARM instructions, it returns bits[31:28] of the instruction.
• For the T1 and T3 encodings of the Branch instruction (see B on page A8-332), it returns the 4-bit cond field
of the encoding.
• For all other Thumb and ThumbEE instructions:

— if ITSTATE.IT<3:0> != '0000' it returns ITSTATE.IT<7:4>
— if ITSTATE.IT<7:0> == '00000000' it returns '1110'
— otherwise, execution of the instruction is UNPREDICTABLE.
For more information, see IT block state register, ITSTATE on page A2-51.
The ConditionPassed() function uses this condition specifier and the APSR condition flags to determine whether
the instruction must be executed:
// ConditionPassed()
// =================
boolean ConditionPassed()
cond = CurrentCond();
// Evaluate base condition.

case cond<3:1> of
when ‘000’ result = (APSR.Z == ‘1’); // EQ or NE
when ‘001’ result = (APSR.C == ‘1’); // CS or CC
when ‘010’ result = (APSR.N == ‘1’); // MI or PL
when ‘011’ result = (APSR.V == ‘1’); // VS or VC
when ‘100’ result = (APSR.C == ‘1’) && (APSR.Z == ‘0’); // HI or LS
when ‘101’ result = (APSR.N == APSR.V); // GE or LT
when ‘110’ result = (APSR.N == APSR.V) && (APSR.Z == ‘0’); // GT or LE
when ‘111’ result = TRUE; // AL
// Condition flag values in the set ‘111x’ indicate the instruction is always executed.
// Otherwise, invert condition if necessary.
if cond<0> == ‘1’ && cond != ‘1111’ then
result = !result;
return result;
Undefined Instruction exception on page B1-1205 describes the handling of conditional instructions that are
UNDEFINED or UNPREDICTABLE. The pseudocode in the manual, as a sequential description of the instructions, has
limitations in this respect. For more information, see Limitations of the instruction pseudocode on page D16-2630.
A8.4 Shifts applied to a register

ARM register offset load/store word and unsigned byte instructions can apply a wide range of different constant
shifts to the offset register. Both Thumb and ARM data-processing instructions can apply the same range of different
constant shifts to the second operand register. For details see Constant shifts.
ARM data-processing instructions can apply a register-controlled shift to the second operand register.
A8.4.1 Constant shifts

These are the same in Thumb and ARM instructions, except that the input bits come from different positions.
<shift> is an optional shift to be applied to <Rm>. It can be any one of:
(omitted) No shift.
LSL #<n> Logical shift left <n> bits. 1 <= <n> <= 31.
LSR #<n> Logical shift right <n> bits. 1 <= <n> <= 32.
ASR #<n> Arithmetic shift right <n> bits. 1 <= <n> <= 32.
ROR #<n> Rotate right <n> bits. 1 <= <n> <= 31.
RRX Rotate right one bit, with extend. Bit[0] is written to shifter_carry_out, bits[31:1] are shifted right
one bit, and the Carry flag is shifted into bit[31].
Note
Assemblers can permit the use of some or all of ASR #0, LSL #0, LSR #0, and ROR #0 to specify that no shift is to be
performed. This is not standard UAL, and the encoding selected for Thumb instructions might vary between UAL
assemblers if it is used. To ensure disassembled code assembles to the original instructions, disassemblers must omit
the shift specifier when the instruction specifies no shift.
Similarly, assemblers can permit the use of #0 in the immediate forms of ASR, LSL, LSR, and ROR instructions to specify
that no shift is to be performed, that is, that a MOV (register) instruction is wanted. Again, this is not standard UAL,
and the encoding selected for Thumb instructions might vary between UAL assemblers if it is used. To ensure
disassembled code assembles to the original instructions, disassemblers must use the MOV (register) syntax when the
instruction specifies no shift.
Encoding
The assembler encodes <shift> into two type bits and five immediate bits, as follows:
(omitted) type = 0b00, immediate = 0.
LSL #<n> type = 0b00, immediate = <n>.
LSR #<n> type = 0b01.

If <n> < 32, immediate = <n>.
If <n> == 32, immediate = 0.
ASR #<n> type = 0b10.

If <n> < 32, immediate = <n>.
If <n> == 32, immediate = 0.
ROR #<n> type = 0b11, immediate = <n>.
RRX type = 0b11, immediate = 0.
A8.4.2 Register controlled shifts

These are only available in ARM instructions.
<type> is the type of shift to apply to the value read from <Rm>. It must be one of:
ASR Arithmetic shift right, encoded as type = 0b10.
LSL Logical shift left, encoded as type = 0b00.
LSR Logical shift right, encoded as type = 0b01.
ROR Rotate right, encoded as type = 0b11.
The bottom byte of <Rs> contains the shift amount.
A8.4.3 Pseudocode details of instruction-specified shifts and rotates

enumeration SRType {SRType_LSL, SRType_LSR, SRType_ASR, SRType_ROR, SRType_RRX};
// DecodeImmShift()
// ================
(SRType, integer) DecodeImmShift(bits(2) type, bits(5) imm5)
case type of
when ‘00’
shift_t = SRType_LSL; shift_n = UInt(imm5);
when ‘01’
shift_t = SRType_LSR; shift_n = if imm5 == ‘00000’ then 32 else UInt(imm5);
when ‘10’
shift_t = SRType_ASR; shift_n = if imm5 == ‘00000’ then 32 else UInt(imm5);
when ‘11’
if imm5 == ‘00000’ then
shift_t = SRType_RRX; shift_n = 1;
else
shift_t = SRType_ROR; shift_n = UInt(imm5);
return (shift_t, shift_n);
// DecodeRegShift()
// ================
SRType DecodeRegShift(bits(2) type)

case type of
when ‘00’ shift_t = SRType_LSL;
when ‘01’ shift_t = SRType_LSR;
when ‘10’ shift_t = SRType_ASR;
when ‘11’ shift_t = SRType_ROR;
return shift_t;
// Shift()
// =======
bits(N) Shift(bits(N) value, SRType type, integer amount, bit carry_in)

(result, -) = Shift_C(value, type, amount, carry_in);
return result;
// Shift_C()
// =========
(bits(N), bit) Shift_C(bits(N) value, SRType type, integer amount, bit carry_in)
assert !(type == SRType_RRX && amount != 1);
if amount == 0 then
(result, carry_out) = (value, carry_in);
else
case type of
when SRType_LSL
(result, carry_out) = LSL_C(value, amount);
when SRType_LSR
(result, carry_out) = LSR_C(value, amount);
when SRType_ASR
(result, carry_out) = ASR_C(value, amount);
when SRType_ROR
(result, carry_out) = ROR_C(value, amount);
when SRType_RRX
(result, carry_out) = RRX_C(value, carry_in);
A8.5 Memory accesses
A8.5 Memory accesses

Commonly, the following addressing modes are permitted for memory access instructions:
Offset addressing
The offset value is applied to an address obtained from the base register. The result is used as the
address for the memory access. The value of the base register is unchanged.
The assembly language syntax for this mode is:
[<Rn>, <offset>]
Pre-indexed addressing
The offset value is applied to an address obtained from the base register. The result is used as the
address for the memory access, and written back into the base register.
[<Rn>, <offset>]!
Post-indexed addressing
The address obtained from the base register is used, unchanged, as the address for the memory
access. The offset value is applied to the address, and written back into the base register
[<Rn>], <offset>
In each case, <Rn> is the base register. <offset> can be:

• an immediate constant, such as <imm8> or <imm12>
• an index register, <Rm>
• a shifted index register, such as <Rm>, LSL #<shift>.
For information about unaligned access, endianness, and exclusive access, see:
• Alignment support on page A3-106
• Endian support on page A3-108
• Synchronization and semaphores on page A3-112.
A8.6 Encoding of lists of ARM core registers
A8.6 Encoding of lists of ARM core registers

A number of instructions operate on lists of ARM core registers. For these instructions, the assembler syntax
includes a <registers> field, that provides a list of the registers to be operated on, with list entries separated by
commas.
The registers list is encoded in the instruction encoding. Most often, this is done using an 8-bit, 13-bit, or 16-bit
register_list field. This section gives more information about these and other possible register list encodings.
In a register_list field, each bit corresponds to a single register, and if the <registers> field of the assembler
instruction includes Rt then register_list<t> is set to 1, otherwise it is set to 0.
The full rules for the encoding of lists of ARM core registers are:
• Except for the cases listed here, 16-bit Thumb encodings use an 8-bit register list, and can access only
registers R0-R7.
The exceptions to this rule are:
— The T1 encoding of POP uses an 8-bit register list, and an additional bit, P, that corresponds to the PC.
This means it can access any of R0-R7 and the PC.
— The T1 encoding of PUSH uses an 8-bit register list, and an additional bit, M, that corresponds to the LR.
This means it can access any of R0-R7 and the LR.
• 32-bit Thumb encodings of load operations use a 13-bit register list, and two additional bits, M, corresponding
to the LR, and P, corresponding to the PC. This means these instructions can access any of R0-R12 and the
LR and PC.
• 32-bit Thumb encodings of store operations use a 13-bit register list, and one additional bit, M, corresponding
to the LR. This means these instructions can access any of R0-R12 and the LR.
• Except for the case listed here, ARM encodings use a 16-bit register list. This means these instructions can
access any of R0-R12 and the SP, LR, and PC.
The exception to this rule is:
— The system instructions LDM (exception return) and LDM (User registers) use a 15-bit register list. This
means these instructions can access any of R0-R12 and the SP and LR.
• The T3 and A2 encodings of POP, and the T3 and A2 encodings of PUSH, access a single register from the set
of registers {R0-R12, LR, PC} and encode the register number in the Rt field.
Note
POP is a load operation, and PUSH is a store operation.
In every case, the encoding-specific pseudocode converts the register list into a 32-bit variable, registers, with a
bit corresponding to each of the registers R0-R12, SP, LR, and PC.
Note
Some Floating-point and Advanced SIMD instructions operate on lists of Advanced SIMD and Floating-point
extension registers. The assembler syntax of these instructions includes a <list> field that specifies the registers to
be operated on, and the description of the instruction in Alphabetical list of instructions on page A8-298 defines the
use and encoding of this field.
A8.7 Additional pseudocode support for instruction descriptions

Earlier sections of this chapter include pseudocode that describes features of the execution of ARM and Thumb
instructions, see:
• Pseudocode details of conditional execution on page A8-287
• Pseudocode details of instruction-specified shifts and rotates on page A8-290
The following subsection gives additional pseudocode support functions for some of the instructions described in
Alphabetical list of instructions on page A8-298:
A8.7.1 Pseudocode details of coprocessor operations

The Coproc_Accepted() pseudocode function determines whether a coprocessor instruction is accepted for
execution.
// Coproc_Accepted()
// =================
// Determines whether the coprocessor instruction is accepted.
boolean Coproc_Accepted(integer cp_num, bits(32) instr)
// Not called for CP10 and CP11 coprocessors

assert !(cp_num IN {10,11});
if !(cp_num IN {14,15}) then

// Check against NSACR/CPACR/HCPTR
if HaveSecurityExt() then
// Check Non-Secure Access Control Register for permission to use cp_num.
if !IsSecure() && NSACR<cp_num> == ‘0’ then UNDEFINED;
// Check Coprocessor Access Control Register for permission to use cp_num.

if !HaveVirtExt() || !CurrentModeIsHyp() then
case CPACR<2*cp_num+1:2*cp_num> of
when ‘00’ UNDEFINED;
when ‘01’ if !CurrentModeIsNotUser() then UNDEFINED;
// else CPACR permits access
when ‘10’ UNPREDICTABLE;
when ‘11’ // CPACR permits access
if HaveSecurityExt() && HaveVirtExt() && !IsSecure() && HCPTR<cp_num> == ‘1’ then

HSRString = Zeros(25);
HSRString<5> = ‘0’;
HSRString<3:0> = cp_num<3:0>;
WriteHSR(‘000111’, HSRString);
if !CurrentModeIsHyp() then
TakeHypTrapException();
else
UNDEFINED;
return CPxInstrDecode(instr);
elsif cp_num == 14 then

// CP14 space
// Unpack the basic classes based on Opc1
if instr<27:24> == ‘1110’ && instr<4> == ‘1’ && instr<31:28> != ‘1111’ then
// MCR/MRC
opc1 = UInt(instr<23:21>);
two_reg = FALSE;
if instr<15:12> == ‘1111’ &&
!(instr<23:16> == ‘00010000’ && instr<7:0> == ‘00010001’) then
// every case using APSR except the DBGBSCRint
UNPREDICTABLE;
elsif instr<27:20> == ‘11000101’ && instr<31:28> != ‘1111’ then
// MRRC
opc1 = UInt(instr<7:4>);
if opc1 != 0 then UNDEFINED;
two_reg = TRUE;
elsif instr<27:25> == ‘110’ && instr<31:28> != ‘1111’ && instr<22> == ‘0’ then
// LDC/STC
opc1 = 0; // only use of LDC/STC is for Debug
if UInt(instr<15:12>) != 5 then UNDEFINED;
else
UNDEFINED;
case opc1 of
// Does not consider possible traps of Debug and Trace registers from
// Non-secure modes to Hyp mode here.
when 0 return CP14DebugInstrDecode(instr);
when 1 return CP14TraceInstrDecode(instr);
when 6
// ThumbEE registers - fully decoded here
if two_reg then UNDEFINED;
if instr<7:5> != ‘000’ || instr<3:1> != ‘000’ ||
instr<15:12> == ‘1111’ then
UNPREDICTABLE;
else
if instr<0> == ‘0’ then
if !CurrentModeIsNotUser() then UNDEFINED;
if instr<1> == ‘1’ then
if !CurrentModeIsNotUser() && TEECR.XED == ‘1’ then UNDEFINED;
if HaveSecurityExt() && HaveVirtExt() && !IsSecure() &&

!CurrentModeIsHyp() && HSTR.TTEE == ‘1’ then
HSRString<19:17> = instr<7:5>;
HSRString<0> = instr<20>;
return TRUE;
when 7 return CP14JazelleInstrDecode(instr);

otherwise
UNDEFINED;
elsif cp_num == 15 then

// Only MCR/MCRR/MRRC/MRC are supported in CP15
if instr<27:24> == ‘1110’ && instr<4> == ‘1’ && instr<31:28> != ‘1111’ then
// MCR/MRC
CrNnum = UInt(instr<19:16>);
two_reg = FALSE;
if instr<15:12> == ‘1111’ then UNPREDICTABLE;
// don’t support use of the PC
elsif instr<27:21> == ‘1100010’ && instr<31:28> != ‘1111’ then
// MCRR/MRRC
CrNnum = UInt(instr<3:0>);
two_reg = TRUE;
else
UNDEFINED;
if CrNnum == 4 then UNPREDICTABLE;
// Check for coarse-grained Hyp traps
// Check against HSTR for PL1 accesses

if HaveSecurityExt() && HaveVirtExt() && !IsSecure() && !CurrentModeIsHyp() &&
CrNnum != 14 && HSTR<CrNnum> == ‘1’ then
if !CurrentModeIsNotUser() && InstrIsPL0Undefined(instr) then
IMPLEMENTATION_CHOICE to be UNDEFINED;
if two_reg then
else
// Check for TIDCP as a coarse-grain check for PL1 accesses

if HaveSecurityExt() && HaveVirtExt() && !IsSecure() && !CurrentModeIsHyp() &&
HCR.TIDCP == ‘1’ && !two_reg then
CrMnum = UInt(instr<3:0>);
if (CrNnum == 9 && CrMnum IN {0,1,2,5,6,7,8}) ||
(CrNnum == 10 && CrMnum IN {0,1,4,8}) ||
(CrNnum == 11 && CrMnum IN {0,1,2,3,4,5,6,7,8,15}) then
if !CurrentModeIsNotUser() && InstrIsPL0Undefined(instr) then
IMPLEMENTATION_CHOICE to be UNDEFINED;
return CP15InstrDecode(instr);
The Coproc_DoneLoading() pseudocode function determines, for an LDC instruction, whether enough words have been
loaded:
boolean Coproc_DoneLoading(integer cp_num, bits(32) instr)
The Coproc_DoneStoring() function determines for an STC instruction whether enough words have been stored:
boolean Coproc_DoneStoring(integer cp_num, bits(32) instr)
The Coproc_GetOneWord() function obtains the word for an MRC instruction from the coprocessor:
bits(32) Coproc_GetOneWord(integer cp_num, bits(32) instr)
The Coproc_GetTwoWords() function obtains the two words for an MRRC instruction from the coprocessor:
(bits(32), bits(32)) Coproc_GetTwoWords(integer cp_num, bits(32) instr)
Note
The relative significance of the two words returned is IMPLEMENTATION DEFINED, but all uses within this manual
present the two words in the order (most significant, least significant).
The Coproc_GetWordToStore() function obtains the next word to store for an STC instruction from the coprocessor:
bits(32) Coproc_GetWordToStore(integer cp_num, bits(32) instr)
The Coproc_InternalOperation() procedure instructs a coprocessor to perform the internal operation requested by a
CDP instruction:
Coproc_InternalOperation(integer cp_num, bits(32) instr)
The Coproc_SendLoadedWord() procedure sends a loaded word for an LDC instruction to the coprocessor:
Coproc_SendLoadedWord(bits(32) word, integer cp_num, bits(32) instr)
The Coproc_SendOneWord() procedure sends the word for an MCR instruction to the coprocessor:
Coproc_SendOneWord(bits(32) word, integer cp_num, bits(32) instr)
The Coproc_SendTwoWords() procedure sends the two words for an MCRR instruction to the coprocessor:
Coproc_SendTwoWords(bits(32) word2, bits(32) word1, integer cp_num, bits(32) instr)
Note
The relative significance of word2 and word1 is IMPLEMENTATION DEFINED, but all uses within this manual treat word2
as more significant than word1.
The CPxInstrDecode() pseudocode function decodes an accepted access to a coprocessor other than CP10, CP11,
CP14, or CP15:
boolean CPxInstrDecode(bits(32) instr)
The CP14DebugInstrDecode() pseudocode function decodes an accepted access to a CP14 debug register:
boolean CP14DebugInstrDecode(bits(32) instr)
The CP14JazelleInstrDecode() pseudocode function decodes an accepted access to a CP14 Jazelle register:
boolean CP14JazelleInstrDecode(bits(32) instr)
The CP14TraceInstrDecode() pseudocode function decodes an accepted access to a CP14 Trace register:
boolean CP14TraceInstrDecode(bits(32) instr)
The CP15InstrDecode() pseudocode function decodes an accepted access to a CP15 register:
boolean CP15InstrDecode(bits(32) instr)
A8.7.2 Calling the supervisor

The CallSupervisor() pseudocode function generates a Supervisor Call exception, after setting up the HSR if the
exception must be taken to Hyp mode. Valid execution of the SVC instruction calls this function.
// CallSupervisor()
// ================
//
// Calls the Supervisor, with appropriate trapping etc
CallSupervisor(bits(16) immediate)
if CurrentModeIsHyp() ||
(HaveVirtExt() && !IsSecure() && !CurrentModeIsNotUser() && HCR.TGE == ‘1’) then
// will be taken to Hyp mode so must set HSR
HSRString<15:0> = if CurrentCond() == ‘1110’ then immediate else bits(16) UNKNOWN;
// This will go to Hyp mode if necessary

TakeSVCException();
A8.8 Alphabetical list of instructions

This section lists every instruction. For details of the format used see Format of instruction descriptions on
page A8-280.
This section is formatted so that a full description of an instruction uses a double page.
A8.8.1 ADC (immediate)

Add with Carry (immediate) adds an immediate value and the Carry flag value to a register value, and writes the
result to the destination register. It can optionally update the condition flags based on the result.
Encoding T1 ARMv6T2, ARMv7

ADC{S}<c> <Rd>, <Rn>, #<const>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 i 0 1 0 1 0 S Rn 0 imm3 Rd imm8
d = UInt(Rd); n = UInt(Rn); setflags = (S == ‘1’); imm32 = ThumbExpandImm(i:imm3:imm8);

if d IN {13,15} || n IN {13,15} then UNPREDICTABLE;
Encoding A1 ARMv4*, ARMv5T*, ARMv6*, ARMv7

ADC{S}<c> <Rd>, <Rn>, #<const>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 0 1 0 1 S Rn Rd imm12
For the case when cond is 0b1111, see Unconditional instructions on page A5-214.
if Rd == ‘1111’ && S == ‘1’ then SEE SUBS PC, LR and related instructions;
d = UInt(Rd); n = UInt(Rn); setflags = (S == ‘1’); imm32 = ARMExpandImm(imm12);
Assembler syntax
ADC{S}{<c>}{<q>} {<Rd>,} <Rn>, #<const>
where:
S If S is present, the instruction updates the flags. Otherwise, the flags are not updated.
<c>, <q> See Standard assembler syntax fields on page A8-285.
<Rd> The destination register. If S is specified and <Rd> is the PC, see SUBS PC, LR (Thumb) on
page B9-1996 or SUBS PC, LR and related instructions (ARM) on page B9-1998.
In ARM instructions, if S is not specified and <Rd> is the PC, the instruction is a branch to the
address calculated by the operation. This is an interworking branch, see Pseudocode details of
operations on ARM core registers on page A2-46. ARM deprecates this use of PC.
Note
Before ARMv7, this was a simple branch.
<Rn> The first operand register. The PC can be used in ARM instructions. ARM deprecates this use of PC.
<const> The immediate value to be added to the value obtained from <Rn>. See Modified immediate constants
in Thumb instructions on page A6-230 or Modified immediate constants in ARM instructions on
page A5-197 for the range of values.
The pre-UAL syntax ADC<c>S is equivalent to ADCS<c>.
Operation
if ConditionPassed() then
EncodingSpecificOperations();
(result, carry, overflow) = AddWithCarry(R[n], imm32, APSR.C);
if d == 15 then // Can only occur for ARM encoding
ALUWritePC(result); // setflags is always FALSE here
else
R[d] = result;
if setflags then
APSR.N = result<31>;
APSR.Z = IsZeroBit(result);
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.2 ADC (register)

Add with Carry (register) adds a register value, the Carry flag value, and an optionally-shifted register value, and
writes the result to the destination register. It can optionally update the condition flags based on the result.
Encoding T1 ARMv4T, ARMv5T*, ARMv6*, ARMv7

ADCS <Rdn>, <Rm> Outside IT block.
ADC<c> <Rdn>, <Rm> Inside IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 0 0 0 1 0 1 Rm Rdn
d = UInt(Rdn); n = UInt(Rdn); m = UInt(Rm); setflags = !InITBlock();

(shift_t, shift_n) = (SRType_LSL, 0);

ADC{S}<c>.W <Rd>, <Rn>, <Rm>{, <shift>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 1 1 0 1 0 S Rn (0) imm3 Rd imm2 type Rm
d = UInt(Rd); n = UInt(Rn); m = UInt(Rm); setflags = (S == ‘1’);

(shift_t, shift_n) = DecodeImmShift(type, imm3:imm2);
if d IN {13,15} || n IN {13,15} || m IN {13,15} then UNPREDICTABLE;

ADC{S}<c> <Rd>, <Rn>, <Rm>{, <shift>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 0 1 0 1 S Rn Rd imm5 type 0 Rm
(shift_t, shift_n) = DecodeImmShift(type, imm5);
Assembler syntax
ADC{S}{<c>}{<q>} {<Rd>,} <Rn>, <Rm> {, <shift>}
where:
In ARM instructions, if S is not specified and <Rd> is the PC, the instruction is a branch to the address
calculated by the operation. This is an interworking branch, see Pseudocode details of operations
on ARM core registers on page A2-46. ARM deprecates this use of the PC.
Note
<Rn> The first operand register. The PC can be used in ARM instructions. ARM deprecates this use of the
PC.
<Rm> The optionally shifted second operand register. The PC can be used in ARM instructions. ARM
deprecates this use of the PC.
<shift> The shift to apply to the value read from <Rm>. If present, encoding T1 is not permitted. If absent, no
shift is applied and any encoding is permitted. Shifts applied to a register on page A8-289 describes
the shifts and how they are encoded.
In Thumb assembly:
• outside an IT block, if ADCS <Rd>, <Rn>, <Rd> has <Rd> and <Rn> both in the range R0-R7, it is assembled using
encoding T1 as though ADCS <Rd>, <Rn> had been written.
• inside an IT block, if ADC<c> <Rd>, <Rn>, <Rd> has <Rd> and <Rn> both in the range R0-R7, it is assembled
using encoding T1 as though ADC<c> <Rd>, <Rn> had been written.
To prevent either of these happening, use the .W qualifier.
Operation
shifted = Shift(R[m], shift_t, shift_n, APSR.C);
(result, carry, overflow) = AddWithCarry(R[n], shifted, APSR.C);
else
R[d] = result;
if setflags then
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.3 ADC (register-shifted register)

Add with Carry (register-shifted register) adds a register value, the Carry flag value, and a register-shifted register
value. It writes the result to the destination register, and can optionally update the condition flags based on the result.

ADC{S}<c> <Rd>, <Rn>, <Rm>, <type> <Rs>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 0 1 0 1 S Rn Rd Rs 0 type 1 Rm
d = UInt(Rd); n = UInt(Rn); m = UInt(Rm); s = UInt(Rs);

setflags = (S == ‘1’); shift_t = DecodeRegShift(type);
if d == 15 || n == 15 || m == 15 || s == 15 then UNPREDICTABLE;
Assembler syntax
ADC{S}{<c>}{<q>} {<Rd>,} <Rn>, <Rm>, <type> <Rs>
where:
<Rd> The destination register.
<Rn> The first operand register.
<Rm> The register that is shifted and used as the second operand.
<type> The type of shift to apply to the value read from <Rm>. It must be one of:
<Rs> The register whose bottom byte contains the amount to shift by.
Operation
shift_n = UInt(R[s]<7:0>);
(result, carry, overflow) = AddWithCarry(R[n], shifted, APSR.C);
R[d] = result;
if setflags then
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.4 ADD (immediate, Thumb)

This instruction adds an immediate value to a register value, and writes the result to the destination register. It can
optionally update the condition flags based on the result.

ADDS <Rd>, <Rn>, #<imm3> Outside IT block.
ADD<c> <Rd>, <Rn>, #<imm3> Inside IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 1 1 1 0 imm3 Rn Rd
d = UInt(Rd); n = UInt(Rn); setflags = !InITBlock(); imm32 = ZeroExtend(imm3, 32);

ADDS <Rdn>, #<imm8> Outside IT block.
ADD<c> <Rdn>, #<imm8> Inside IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 1 1 0 Rdn imm8
d = UInt(Rdn); n = UInt(Rdn); setflags = !InITBlock(); imm32 = ZeroExtend(imm8, 32);

ADD{S}<c>.W <Rd>, <Rn>, #<const>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 i 0 1 0 0 0 S Rn 0 imm3 Rd imm8
if Rd == ‘1111’ && S == ‘1’ then SEE CMN (immediate);

if Rn == ‘1101’ then SEE ADD (SP plus immediate);
if d == 13 || (d == 15 && S == ‘0’) || n == 15 then UNPREDICTABLE;

ADDW<c> <Rd>, <Rn>, #<imm12>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 i 1 0 0 0 0 0 Rn 0 imm3 Rd imm8
if Rn == ‘1111’ then SEE ADR;

d = UInt(Rd); n = UInt(Rn); setflags = FALSE; imm32 = ZeroExtend(i:imm3:imm8, 32);
if d IN {13,15} then UNPREDICTABLE;
Assembler syntax
ADD{S}{<c>}{<q>} {<Rd>,} <Rn>, #<const> All encodings permitted
ADDW{<c>}{<q>} {<Rd>,} <Rn>, #<const> Only encoding T4 permitted
where:
<Rn> The first operand register. If <Rn> is SP, see ADD (SP plus immediate) on page A8-314. If <Rn> is
PC, see ADR on page A8-320.
<const> The immediate value to be added to the value obtained from <Rn>. The range of values is 0-7 for
encoding T1, 0-255 for encoding T2 and 0-4095 for encoding T4. See Modified immediate constants
in Thumb instructions on page A6-230 for the range of values for encoding T3.
When multiple encodings of the same length are available for an instruction, encoding T3 is preferred to encoding
T4 (if encoding T4 is required, use the ADDW syntax). Encoding T1 is preferred to encoding T2 if <Rd> is specified
and encoding T2 is preferred to encoding T1 if <Rd> is omitted.
The pre-UAL syntax ADD<c>S is equivalent to ADDS<c>.
Operation
(result, carry, overflow) = AddWithCarry(R[n], imm32, ‘0’);
R[d] = result;
if setflags then
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.5 ADD (immediate, ARM)

This instruction adds an immediate value to a register value, and writes the result to the destination register. It can

ADD{S}<c> <Rd>, <Rn>, #<const>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 0 1 0 0 S Rn Rd imm12
if Rn == ‘1111’ && S == ‘0’ then SEE ADR;

Assembler syntax
ADD{S}{<c>}{<q>} {<Rd>,} <Rn>, #<const>
where:
<Rd> The destination register. If S is specified and <Rd> is the PC, see SUBS PC, LR and related
instructions (ARM) on page B9-1998.
If S is not specified and <Rd> is the PC, the instruction is a branch to the address calculated by the
operation. This is an interworking branch, see Pseudocode details of operations on ARM core
registers on page A2-46.
Note
<Rn> The first operand register. If the SP is specified for <Rn>, see ADD (SP plus immediate) on
page A8-314. If the PC is specified for <Rn>, see ADR on page A8-320.
in ARM instructions on page A5-197 for the range of values.
Operation
if d == 15 then
else
R[d] = result;
if setflags then
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.6 ADD (register, Thumb)

This instruction adds a register value and an optionally-shifted register value, and writes the result to the destination
register. It can optionally update the condition flags based on the result.

ADDS <Rd>, <Rn>, <Rm> Outside IT block.
ADD<c> <Rd>, <Rn>, <Rm> Inside IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 1 1 0 0 Rm Rn Rd
d = UInt(Rd); n = UInt(Rn); m = UInt(Rm); setflags = !InITBlock();

Encoding T2 ARMv6T2, ARMv7 if <Rdn> and <Rm> are both from R0-R7
ARMv4T, ARMv5T*, ARMv6*, ARMv7 otherwise
ADD<c> <Rdn>, <Rm> If <Rdn> is the PC, must be outside or last in IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 0 1 0 0 Rm Rdn
DN
if (DN:Rdn) == ‘1101’ || Rm == ‘1101’ then SEE ADD (SP plus register);

d = UInt(DN:Rdn); n = d; m = UInt(Rm); setflags = FALSE; (shift_t, shift_n) = (SRType_LSL, 0);
if n == 15 && m == 15 then UNPREDICTABLE;
if d == 15 && InITBlock() && !LastInITBlock() then UNPREDICTABLE;

ADD{S}<c>.W <Rd>, <Rn>, <Rm>{, <shift>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if Rd == ‘1111’ && S == ‘1’ then SEE CMN (register);

if Rn == ‘1101’ then SEE ADD (SP plus register);
if d == 13 || (d == 15 && S == ‘0’) || n == 15 || m IN {13,15} then UNPREDICTABLE;
Assembler syntax
ADD{S}{<c>}{<q>} {<Rd>,} <Rn>, <Rm> {, <shift>}
where:
<Rd> The destination register. If S is specified and <Rd> is the PC, see CMN (register) on page A8-364. If
omitted, <Rd> is the same as <Rn> and encoding T2 is preferred to encoding T1 inside an IT block. If
<Rd> is present, encoding T1 is preferred to encoding T2.
If <Rd> is the PC and S is not specified, encoding T2 is used and the instruction is a branch to the
address calculated by the operation. This is a simple branch, see Pseudocode details of operations
<Rn> The first operand register. The PC can be used in encoding T2. If <Rn> is SP, see ADD (SP plus
register, Thumb) on page A8-316.
<Rm> The register that is optionally shifted and used as the second operand. The PC can be used in
encoding T2
<shift> The shift to apply to the value read from <Rm>. If present, only encoding T3 is permitted. If omitted,
no shift is applied and any encoding is permitted. Shifts applied to a register on page A8-289
describes the shifts and how they are encoded.
Inside an IT block, if ADD<c> <Rd>, <Rn>, <Rd> cannot be assembled using encoding T1, it is assembled using
encoding T2 as though ADD<c> <Rd>, <Rn> had been written. To prevent this happening, use the .W qualifier.
Operation
(result, carry, overflow) = AddWithCarry(R[n], shifted, ‘0’);
if d == 15 then
else
R[d] = result;
if setflags then
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.7 ADD (register, ARM)

This instruction adds a register value and an optionally-shifted register value, and writes the result to the destination
register. It can optionally update the condition flags based on the result.

ADD{S}<c> <Rd>, <Rn>, <Rm>{, <shift>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if Rn == ‘1101’ then SEE ADD (SP plus register);
Assembler syntax
ADD{S}{<c>}{<q>} {<Rd>,} <Rn>, <Rm> {, <shift>}
where:
instructions (ARM) on page B9-1998. If omitted, <Rd> is the same as <Rn>.
If <Rd> is the PC and S is not specified, the instruction is a branch to the address calculated by the
Note
<Rn> The first operand register. The PC can be used. If <Rn> is SP, see ADD (SP plus register, Thumb) on
page A8-316.
<Rm> The register that is optionally shifted and used as the second operand. The PC can be used.
<shift> The shift to apply to the value read from <Rm>. If present, only encoding T3 or A1 is permitted. If
omitted, no shift is applied and any encoding is permitted. Shifts applied to a register on
page A8-289 describes the shifts and how they are encoded.
Operation
if d == 15 then
else
R[d] = result;
if setflags then
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.8 ADD (register-shifted register)

Add (register-shifted register) adds a register value and a register-shifted register value. It writes the result to the
destination register, and can optionally update the condition flags based on the result.

ADD{S}<c> <Rd>, <Rn>, <Rm>, <type> <Rs>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Assembler syntax
ADD{S}{<c>}{<q>} {<Rd>,} <Rn>, <Rm>, <type> <Rs>
where:
Operation
R[d] = result;
if setflags then
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.9 ADD (SP plus immediate)

This instruction adds an immediate value to the SP value, and writes the result to the destination register.

ADD<c> <Rd>, SP, #<imm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 0 1 Rd imm8
d = UInt(Rd); setflags = FALSE; imm32 = ZeroExtend(imm8:’00’, 32);

ADD<c> SP, SP, #<imm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 1 0 0 0 0 0 imm7
d = 13; setflags = FALSE; imm32 = ZeroExtend(imm7:’00’, 32);

ADD{S}<c>.W <Rd>, SP, #<const>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 i 0 1 0 0 0 S 1 1 0 1 0 imm3 Rd imm8
if Rd == ‘1111’ && S == ‘1’ then SEE CMN (immediate);

d = UInt(Rd); setflags = (S == ‘1’); imm32 = ThumbExpandImm(i:imm3:imm8);
if d == 15 && S == ‘0’ then UNPREDICTABLE;

ADDW<c> <Rd>, SP, #<imm12>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 i 1 0 0 0 0 0 1 1 0 1 0 imm3 Rd imm8
d = UInt(Rd); setflags = FALSE; imm32 = ZeroExtend(i:imm3:imm8, 32);

if d == 15 then UNPREDICTABLE;

ADD{S}<c> <Rd>, SP, #<const>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 0 1 0 0 S 1 1 0 1 Rd imm12
d = UInt(Rd); setflags = (S == ‘1’); imm32 = ARMExpandImm(imm12);
Assembler syntax
ADD{S}{<c>}{<q>} {<Rd>,} SP, #<const> All encodings permitted
ADDW{<c>}{<q>} {<Rd>,} SP, #<const> Only encoding T4 is permitted
where:
page B9-1996 or SUBS PC, LR and related instructions (ARM) on page B9-1998. If omitted, <Rd>
is SP.
Note
<const> The immediate value to be added to the value obtained from SP. Values are multiples of 4 in the
range 0-1020 for encoding T1, multiples of 4 in the range 0-508 for encoding T2 and any value in
the range 0-4095 for encoding T4. See Modified immediate constants in Thumb instructions on
page A6-230 or Modified immediate constants in ARM instructions on page A5-197 for the range
of values for encodings T3 and A1.
When both 32-bit encodings are available for an instruction, encoding T3 is preferred to encoding
T4.
Note
If encoding T4 is required, use the ADDW syntax.
Operation
(result, carry, overflow) = AddWithCarry(SP, imm32, ‘0’);
else
R[d] = result;
if setflags then
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.10 ADD (SP plus register, Thumb)

This instruction adds an optionally-shifted register value to the SP value, and writes the result to the destination
register.

ADD<c> <Rdm>, SP, <Rdm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 0 1 0 0 1 1 0 1 Rdm
DM
d = UInt(DM:Rdm); m = UInt(DM:Rdm); setflags = FALSE;


ADD<c> SP, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 0 1 0 0 1 Rm 1 0 1
if Rm == ‘1101’ then SEE encoding T1;

d = 13; m = UInt(Rm); setflags = FALSE;

ADD{S}<c>.W <Rd>, SP, <Rm>{, <shift>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 1 1 0 0 0 S 1 1 0 1 (0) imm3 Rd imm2 type Rm
if Rd == ‘1111’ && S == ‘1’ then SEE CMN (register);

d = UInt(Rd); m = UInt(Rm); setflags = (S == ‘1’);
if d == 13 && (shift_t != SRType_LSL || shift_n > 3) then UNPREDICTABLE;
if (d == 15 && S == ‘0’) || m IN {13,15} then UNPREDICTABLE;
Assembler syntax
ADD{S}{<c>}{<q>} {<Rd>,} SP, <Rm>{, <shift>}
where:
<Rd> The destination register. If S is specified and <Rd> is the PC, see CMN (register) on page A8-364.
This register can be SP. If omitted, <Rd> is SP. This register can be the PC, but if it is, encoding T3
is not permitted. ARM deprecates using the PC.
If <Rd> is the PC and S is not specified, encoding T1 is used and the instruction is a branch to the
address calculated by the operation. This is a simple branch, see Pseudocode details of operations
<Rm> The register that is optionally shifted and used as the second operand. This register can be the PC,
but if it is, encoding T3 is not permitted. ARM deprecates using the PC. This register can be the SP,
but:
• ARM deprecates using the SP
• only encoding T1 is available and so the instruction can only be ADD SP, SP, SP.
<shift> The shift to apply to the value read from <Rm>. If omitted, no shift is applied and any encoding is
permitted. If present, only encoding T3 is permitted. Shifts applied to a register on page A8-289
If <Rd> is SP or omitted, <shift> is only permitted to be omitted, LSL #1, LSL #2, or LSL #3.
Operation
(result, carry, overflow) = AddWithCarry(SP, shifted, ‘0’);
if d == 15 then
else
R[d] = result;
if setflags then
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.11 ADD (SP plus register, ARM)

This instruction adds an optionally-shifted register value to the SP value, and writes the result to the destination
register.

ADD{S}<c> <Rd>, SP, <Rm>{, <shift>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 0 1 0 0 S 1 1 0 1 Rd imm5 type 0 Rm
Assembler syntax
ADD{S}{<c>}{<q>} {<Rd>,} SP, <Rm>{, <shift>}
where:
instructions (ARM) on page B9-1998. This register can be SP. If omitted, <Rd> is SP. This register
can be the PC, but ARM deprecates using the PC.
registers on page A2-46. ARM deprecates this use of the PC.
Note
<Rm> The register that is optionally shifted and used as the second operand. This register can be the PC,
but ARM deprecates using the PC. This register can be the SP, but ARM deprecates using the SP.
<shift> The shift to apply to the value read from <Rm>. If omitted, no shift is applied and any encoding is
permitted. Shifts applied to a register on page A8-289 describes the shifts and how they are
encoded.
Operation
(result, carry, overflow) = AddWithCarry(SP, shifted, ‘0’);
if d == 15 then
else
R[d] = result;
if setflags then
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.12 ADR
This instruction adds an immediate value to the PC value to form a PC-relative address, and writes the result to the
destination register.

ADR<c> <Rd>, <label>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 0 0 Rd imm8
d = UInt(Rd); imm32 = ZeroExtend(imm8:’00’, 32); add = TRUE;

ADR<c>.W <Rd>, <label> <label> before current instruction
SUB <Rd>, PC, #0 Special case for subtraction of zero
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 i 1 0 1 0 1 0 1 1 1 1 0 imm3 Rd imm8
d = UInt(Rd); imm32 = ZeroExtend(i:imm3:imm8, 32); add = FALSE;


ADR<c>.W <Rd>, <label> <label> after current instruction
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 i 1 0 0 0 0 0 1 1 1 1 0 imm3 Rd imm8
d = UInt(Rd); imm32 = ZeroExtend(i:imm3:imm8, 32); add = TRUE;


ADR<c> <Rd>, <label> <label> after current instruction
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 0 1 0 0 0 1 1 1 1 Rd imm12
d = UInt(Rd); imm32 = ARMExpandImm(imm12); add = TRUE;

ADR<c> <Rd>, <label> <label> before current instruction
SUB <Rd>, PC, #0 Special case for subtraction of zero
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 0 0 1 0 0 1 1 1 1 Rd imm12
d = UInt(Rd); imm32 = ARMExpandImm(imm12); add = FALSE;
Assembler syntax
ADR{<c>}{<q>} <Rd>, <label> Normal syntax
ADD{<c>}{<q>} <Rd>, PC, #<const> Alternative for encodings T1, T3, A1
SUB{<c>}{<q>} <Rd>, PC, #<const> Alternative for encoding T2, A2
where:
<Rd> The destination register. In ARM instructions, if <Rd> is the PC, the instruction is a branch to the
address calculated by the operation. This is an interworking branch, see Pseudocode details of
operations on ARM core registers on page A2-46.
Note
<label> The label of an instruction or literal data item whose address is to be loaded into <Rd>. The assembler
calculates the required value of the offset from the Align(PC, 4) value of the ADR instruction to this
label.
If the offset is zero or positive, encodings T1, T3, and A1 are permitted, with imm32 equal to the
offset.
If the offset is negative, encodings T2 and A2 are permitted, with imm32 equal to the size of the offset.
That is, the use of encoding T2 or A2 indicates that the required offset is minus the value of imm32.
Permitted values of the size of the offset are:
Encoding T1 Multiples of 4 in the range 0 to 1020.
Encodings T2, T3 Any value in the range 0 to 4095.
Encodings A1, A2 Any of the constants described in Modified immediate constants in ARM
instructions on page A5-197.
The alternative syntax permits the addition or subtraction of the offset and the immediate offset to be specified
separately, including permitting a subtraction of 0 that cannot be specified using the normal syntax. For more
information, see Use of labels in UAL instruction syntax on page A4-160.
Operation
result = if add then (Align(PC,4) + imm32) else (Align(PC,4) - imm32);
if d == 15 then // Can only occur for ARM encodings
ALUWritePC(result);
else
R[d] = result;
Exceptions
None.
A8.8.13 AND (immediate)

This instruction performs a bitwise AND of a register value and an immediate value, and writes the result to the

AND{S}<c> <Rd>, <Rn>, #<const>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 i 0 0 0 0 0 S Rn 0 imm3 Rd imm8
if Rd == ‘1111’ && S == ‘1’ then SEE TST (immediate);

d = UInt(Rd); n = UInt(Rn); setflags = (S == ‘1’);
(imm32, carry) = ThumbExpandImm_C(i:imm3:imm8, APSR.C);
if d == 13 || (d == 15 && S == ‘0’) || n IN {13,15} then UNPREDICTABLE;

AND{S}<c> <Rd>, <Rn>, #<const>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 0 0 0 0 S Rn Rd imm12
(imm32, carry) = ARMExpandImm_C(imm12, APSR.C);
Assembler syntax
AND{S}{<c>}{<q>} {<Rd>,} <Rn>, #<const>
where:
Note
PC.
<const> The immediate value to be ANDed with the value obtained from <Rn>. See Modified immediate
constants in Thumb instructions on page A6-230 or Modified immediate constants in ARM
instructions on page A5-197 for the range of values.
The pre-UAL syntax AND<c>S is equivalent to ANDS<c>.
Operation
result = R[n] AND imm32;
else
R[d] = result;
if setflags then
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.14 AND (register)

This instruction performs a bitwise AND of a register value and an optionally-shifted register value, and writes the
result to the destination register. It can optionally update the condition flags based on the result.

ANDS <Rdn>, <Rm> Outside IT block.
AND<c> <Rdn>, <Rm> Inside IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 0 0 0 0 0 0 Rm Rdn


AND{S}<c>.W <Rd>, <Rn>, <Rm>{, <shift>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if Rd == ‘1111’ && S == ‘1’ then SEE TST (register);

if d == 13 || (d == 15 && S == ‘0’) || n IN {13,15} || m IN {13,15} then UNPREDICTABLE;

AND{S}<c> <Rd>, <Rn>, <Rm>{, <shift>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Assembler syntax
AND{S}{<c>}{<q>} {<Rd>,} <Rn>, <Rm> {, <shift>}
where:
Note
PC.
<Rm> The register that is optionally shifted and used as the second operand. The PC can be used in ARM
instructions. ARM deprecates this use of the PC.
shift is applied and all encodings are permitted. Shifts applied to a register on page A8-289
In Thumb assembly:
• outside an IT block, if ANDS <Rd>, <Rn>, <Rd> has <Rd> and <Rn> both in the range R0-R7, it is assembled using
encoding T1 as though ANDS <Rd>, <Rn> had been written
• inside an IT block, if AND<c> <Rd>, <Rn>, <Rd> has <Rd> and <Rn> both in the range R0-R7, it is assembled
using encoding T1 as though AND<c> <Rd>, <Rn> had been written.
Operation
(shifted, carry) = Shift_C(R[m], shift_t, shift_n, APSR.C);
result = R[n] AND shifted;
else
R[d] = result;
if setflags then
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.15 AND (register-shifted register)

This instruction performs a bitwise AND of a register value and a register-shifted register value. It writes the result
to the destination register, and can optionally update the condition flags based on the result.

AND{S}<c> <Rd>, <Rn>, <Rm>, <type> <Rs>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Assembler syntax
AND{S}{<c>}{<q>} {<Rd>,} <Rn>, <Rm>, <type> <Rs>
where:
Operation
R[d] = result;
if setflags then
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.16 ASR (immediate)

Arithmetic Shift Right (immediate) shifts a register value right by an immediate number of bits, shifting in copies
of its sign bit, and writes the result to the destination register. It can optionally update the condition flags based on
the result.

ASRS <Rd>, <Rm>, #<imm> Outside IT block.
ASR<c> <Rd>, <Rm>, #<imm> Inside IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 1 0 imm5 Rm Rd
d = UInt(Rd); m = UInt(Rm); setflags = !InITBlock();

(-, shift_n) = DecodeImmShift(‘10’, imm5);

ASR{S}<c>.W <Rd>, <Rm>, #<imm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 1 0 0 1 0 S 1 1 1 1 (0) imm3 Rd imm2 1 0 Rm

(-, shift_n) = DecodeImmShift(‘10’, imm3:imm2);
if d IN {13,15} || m IN {13,15} then UNPREDICTABLE;

ASR{S}<c> <Rd>, <Rm>, #<imm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 1 0 1 S (0) (0) (0) (0) Rd imm5 1 0 0 Rm
Assembler syntax
ASR{S}{<c>}{<q>} {<Rd>,} <Rm>, #<imm>
where:

Note
<Rm> The first operand register. The PC can be used in ARM instructions. ARM deprecates this use of the
PC.
<imm> The shift amount, in the range 1 to 32. See Shifts applied to a register on page A8-289.
Operation
(result, carry) = Shift_C(R[m], SRType_ASR, shift_n, APSR.C);
else
R[d] = result;
if setflags then
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.17 ASR (register)

Arithmetic Shift Right (register) shifts a register value right by a variable number of bits, shifting in copies of its
sign bit, and writes the result to the destination register. The variable number of bits is read from the bottom byte of
a register. It can optionally update the condition flags based on the result.

ASRS <Rdn>, <Rm> Outside IT block.
ASR<c> <Rdn>, <Rm> Inside IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 0 0 0 1 0 0 Rm Rdn

ASR{S}<c>.W <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 0 1 0 S Rn 1 1 1 1 Rd 0 0 0 0 Rm


ASR{S}<c> <Rd>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 1 0 1 S (0) (0) (0) (0) Rd Rm 0 1 0 1 Rn

if d == 15 || n == 15 || m == 15 then UNPREDICTABLE;
Assembler syntax
ASR{S}{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
<Rm> The register whose bottom byte contains the amount to shift by.
Operation
shift_n = UInt(R[m]<7:0>);
(result, carry) = Shift_C(R[n], SRType_ASR, shift_n, APSR.C);
R[d] = result;
if setflags then
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.18 B
Branch causes a branch to a target address.

B<c> <label> Not permitted in IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 0 1 cond imm8
if cond == ‘1110’ then SEE UDF;

if cond == ‘1111’ then SEE SVC;
imm32 = SignExtend(imm8:’0’, 32);
if InITBlock() then UNPREDICTABLE;

B<c> <label> Outside or last in IT block
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 0 imm11

if InITBlock() && !LastInITBlock() then UNPREDICTABLE;

B<c>.W <label> Not permitted in IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 S cond imm6 1 0 J1 0 J2 imm11
if cond<3:1> == ‘111’ then SEE “Related encodings”;

imm32 = SignExtend(S:J2:J1:imm6:imm11:’0’, 32);

B<c>.W <label> Outside or last in IT block
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 S imm10 1 0 J1 1 J2 imm11
I1 = NOT(J1 EOR S); I2 = NOT(J2 EOR S); imm32 = SignExtend(S:I1:I2:imm10:imm11:’0’, 32);


B<c> <label>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 0 1 0 imm24
Related encodings See Branches and miscellaneous control on page A6-233.
Assembler syntax
B{<c>}{<q>} <label>
where:
Note
Encodings T1 and T3 are conditional in their own right, and do not require an IT instruction to make
them conditional.
For encodings T1 and T3, <c> must not be AL or omitted. The 4-bit encoding of the condition is
placed in the instruction and not in a preceding IT instruction, and the instruction must not be in an
IT block. As a result, encodings T1 and T2 are never both available to the assembler, nor are
encodings T3 and T4.
<label> The label of the instruction that is to be branched to. The assembler calculates the required value of
the offset from the PC value of the B instruction to this label, then selects an encoding that sets imm32
to that offset.
Permitted offsets are:
Encoding T1 Even numbers in the range –256 to 254
Encoding A1 Multiples of 4 in the range –33554432 to 33554428.
Operation
BranchWritePC(PC + imm32);
Exceptions
None.
A8.8.19 BFC
Bit Field Clear clears any number of adjacent bits at any position in a register, without affecting the other bits in the
register.

BFC<c> <Rd>, #<lsb>, #<width>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 (0) 1 1 0 1 1 0 1 1 1 1 0 imm3 Rd imm2 (0) msb
d = UInt(Rd); msbit = UInt(msb); lsbit = UInt(imm3:imm2);

Encoding A1 ARMv6T2, ARMv7

BFC<c> <Rd>, #<lsb>, #<width>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 1 1 1 0 msb Rd lsb 0 0 1 1 1 1 1
d = UInt(Rd); msbit = UInt(msb); lsbit = UInt(lsb);

Assembler syntax
BFC{<c>}{<q>} <Rd>, #<lsb>, #<width>
where:
<lsb> The least significant bit that is to be cleared, in the range 0 to 31. This determines the required value
of lsbit.
<width> The number of bits to be cleared, in the range 1 to 32-<lsb>. The required value of msbit is
<lsb>+<width>-1.
Operation
if msbit >= lsbit then
R[d]<msbit:lsbit> = Replicate(‘0’, msbit-lsbit+1);
// Other bits of R[d] are unchanged
else
UNPREDICTABLE;
Exceptions
None.
A8.8.20 BFI
Bit Field Insert copies any number of low order bits from a register into the same number of adjacent bits at any
position in the destination register.

BFI<c> <Rd>, <Rn>, #<lsb>, #<width>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 (0) 1 1 0 1 1 0 Rn 0 imm3 Rd imm2 (0) msb
if Rn == ‘1111’ then SEE BFC;

d = UInt(Rd); n = UInt(Rn); msbit = UInt(msb); lsbit = UInt(imm3:imm2);
if d IN {13,15} || n == 13 then UNPREDICTABLE;

BFI<c> <Rd>, <Rn>, #<lsb>, #<width>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 1 1 1 0 msb Rd lsb 0 0 1 Rn
if Rn == ‘1111’ then SEE BFC;

d = UInt(Rd); n = UInt(Rn); msbit = UInt(msb); lsbit = UInt(lsb);
Assembler syntax
BFI{<c>}{<q>} <Rd>, <Rn>, #<lsb>, #<width>
where:
<Rn> The source register.
<lsb> The least significant destination bit, in the range 0 to 31. This determines the required value of lsbit.
<width> The number of bits to be copied, in the range 1 to 32-<lsb>. The required value of msbit is
<lsb>+<width>-1.
Operation
if msbit >= lsbit then
R[d]<msbit:lsbit> = R[n]<(msbit-lsbit):0>;
// Other bits of R[d] are unchanged
else
UNPREDICTABLE;
Exceptions
None.
A8.8.21 BIC (immediate)

Bitwise Bit Clear (immediate) performs a bitwise AND of a register value and the complement of an immediate
value, and writes the result to the destination register. It can optionally update the condition flags based on the result.

BIC{S}<c> <Rd>, <Rn>, #<const>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 i 0 0 0 0 1 S Rn 0 imm3 Rd imm8


BIC{S}<c> <Rd>, <Rn>, #<const>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 1 1 1 0 S Rn Rd imm12
Assembler syntax
BIC{S}{<c>}{<q>} {<Rd>,} <Rn>, #<const>
where:
Note
<Rn> The register that contains the operand. The PC can be used in ARM instructions. ARM deprecates
this use of the PC.
<const> The immediate value to be bitwise inverted and ANDed with the value obtained from <Rn>. See
Modified immediate constants in Thumb instructions on page A6-230 or Modified immediate
constants in ARM instructions on page A5-197 for the range of values.
The pre-UAL syntax BIC<c>S is equivalent to BICS<c>.
Operation
result = R[n] AND NOT(imm32);
else
R[d] = result;
if setflags then
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.22 BIC (register)

Bitwise Bit Clear (register) performs a bitwise AND of a register value and the complement of an optionally-shifted
register value, and writes the result to the destination register. It can optionally update the condition flags based on
the result.

BICS <Rdn>, <Rm> Outside IT block.
BIC<c> <Rdn>, <Rm> Inside IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 0 0 1 1 1 0 Rm Rdn


BIC{S}<c>.W <Rd>, <Rn>, <Rm>{, <shift>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0


BIC{S}<c> <Rd>, <Rn>, <Rm>{, <shift>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Assembler syntax
BIC{S}{<c>}{<q>} {<Rd>,} <Rn>, <Rm> {, <shift>}
where:
Note
PC.
instructions. ARM deprecates this use of the PC.
Operation
result = R[n] AND NOT(shifted);
else
R[d] = result;
if setflags then
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.23 BIC (register-shifted register)

Bitwise Bit Clear (register-shifted register) performs a bitwise AND of a register value and the complement of a
register-shifted register value. It writes the result to the destination register, and can optionally update the condition
flags based on the result.

BIC{S}<c> <Rd>, <Rn>, <Rm>, <type> <Rs>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Assembler syntax
BIC{S}{<c>}{<q>} {<Rd>,} <Rn>, <Rm>, <type> <Rs>
where:
Operation
result = R[n] AND NOT(shifted);
R[d] = result;
if setflags then
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.24 BKPT
Breakpoint causes a software breakpoint to occur.
Breakpoint is always unconditional, even when inside an IT block.
Encoding T1 ARMv5T*, ARMv6*, ARMv7

BKPT #<imm8>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 1 1 1 1 0 imm8
imm32 = ZeroExtend(imm8, 32);

// imm32 is for assembly/disassembly only and is ignored by hardware.
Encoding A1 ARMv5T*, ARMv6*, ARMv7

BKPT #<imm16>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 0 0 1 0 imm12 0 1 1 1 imm4
imm32 = ZeroExtend(imm12:imm4, 32);

// imm32 is for assembly/disassembly only and is ignored by hardware.
if cond != ‘1110’ then UNPREDICTABLE; // BKPT must be encoded with AL condition
Assembler syntax
BKPT{<q>} {#}<imm>
where:
<q> See Standard assembler syntax fields on page A8-285. A BKPT instruction must be unconditional.
<imm> Specifies a value that is stored in the instruction, in the range 0-255 for a Thumb instruction or
0-65535 for an ARM instruction. This value is ignored by the processor, but can be used by a
debugger to store more information about the breakpoint.
Operation
BKPTInstrDebugEvent();
Exceptions
Prefetch Abort.
A8.8.25 BL, BLX (immediate)

Branch with Link calls a subroutine at a PC-relative address.
Branch with Link and Exchange Instruction Sets (immediate) calls a subroutine at a PC-relative address, and
changes instruction set from ARM to Thumb, or from Thumb to ARM.
Encoding T1 ARMv4T, ARMv5T*, ARMv6*, ARMv7 if J1 == J2 == 1

ARMv6T2, ARMv7 otherwise
BL<c> <label> Outside or last in IT block
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 S imm10 1 1 J1 1 J2 imm11
I1 = NOT(J1 EOR S); I2 = NOT(J2 EOR S); imm32 = SignExtend(S:I1:I2:imm10:imm11:’0’, 32);

targetInstrSet = CurrentInstrSet();
Encoding T2 ARMv5T*, ARMv6*, ARMv7 if J1 == J2 == 1

ARMv6T2, ARMv7 otherwise
BLX<c> <label> Outside or last in IT block
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 S imm10H 1 1 J1 0 J2 imm10L H
if CurrentInstrSet() == InstrSet_ThumbEE || H == ‘1’ then UNDEFINED;

I1 = NOT(J1 EOR S); I2 = NOT(J2 EOR S); imm32 = SignExtend(S:I1:I2:imm10H:imm10L:’00’, 32);
targetInstrSet = InstrSet_ARM;

BL<c> <label>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 0 1 1 imm24
For the case when cond is 0b1111, see the A2 encoding.
imm32 = SignExtend(imm24:’00’, 32); targetInstrSet = InstrSet_ARM;

BLX <label>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 H imm24
imm32 = SignExtend(imm24:H:’0’, 32); targetInstrSet = InstrSet_Thumb;
Assembler syntax
BL{X}{<c>}{<q>} <label>
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM BLX (immediate) instruction must
be unconditional.
X If present, specifies a change of instruction set (from ARM to Thumb or from Thumb to ARM). If
X is omitted, the processor remains in the same state. For ThumbEE instructions, specifying X is
not permitted.
<label> The label of the instruction that is to be branched to.

BL uses encoding T1 or A1. The assembler calculates the required value of the offset from the PC
value of the BL instruction to this label, then selects an encoding with imm32 set to that offset.
BLX uses encoding T2 or A2. The assembler calculates the required value of the offset from the
Align(PC, 4) value of the BLX instruction to this label, then selects an encoding with imm32 set to that
offset.
Permitted offsets are:
Encoding T1 Even numbers in the range –16777216 to 16777214.
Encoding T2 Multiples of 4 in the range –16777216 to 16777212.
Encoding A1 Multiples of 4 in the range –33554432 to 33554428.
Encoding A2 Even numbers in the range –33554432 to 33554430.
Operation
LR = PC - 4;
else
LR = PC<31:1> : ‘1’;
if targetInstrSet == InstrSet_ARM then
targetAddress = Align(PC,4) + imm32;
else
targetAddress = PC + imm32;
SelectInstrSet(targetInstrSet);
BranchWritePC(targetAddress);
Exceptions
None.
Branch range before ARMv6T2

Before ARMv6T2, J1 and J2 in encodings T1 and T2 were both 1, resulting in a smaller branch range. The
instructions could be executed as two separate 16-bit instructions, as described in BL and BLX (immediate)
instructions, before ARMv6T2 on page D12-2490.
A8.8.26 BLX (register)

Branch with Link and Exchange (register) calls a subroutine at an address and instruction set specified by a register.
Encoding T1 ARMv5T*, ARMv6*, ARMv7

BLX<c> <Rm> Outside or last in IT block
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 0 1 1 1 1 Rm (0) (0) (0)
m = UInt(Rm);
if m == 15 then UNPREDICTABLE;

BLX<c> <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 0 0 1 0 (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) 0 0 1 1 Rm
m = UInt(Rm);
Assembler syntax
BLX{<c>}{<q>} <Rm>
where:
<Rm> The register that contains the branch target address and instruction set selection bit. This register can
be the SP in both ARM and Thumb instructions, but ARM deprecates this use of the SP.
Operation
target = R[m];
next_instr_addr = PC - 4;
LR = next_instr_addr;
else
LR = next_instr_addr<31:1> : ‘1’;
BXWritePC(target);
Exceptions
None.
A8.8.27 BX
Branch and Exchange causes a branch to an address and instruction set specified by a register.

BX<c> <Rm> Outside or last in IT block
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 0 1 1 1 0 Rm (0) (0) (0)
m = UInt(Rm);
Encoding A1 ARMv4T, ARMv5T*, ARMv6*, ARMv7

BX<c> <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 0 0 1 0 (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) 0 0 0 1 Rm
m = UInt(Rm);
Assembler syntax
BX{<c>}{<q>} <Rm>
where:
<Rm> The register that contains the branch target address and instruction set selection bit. The PC can be
used. This register can be the SP in both ARM and Thumb instructions, but ARM deprecates this
use of the SP.
Note
If <Rm> is the PC in a Thumb instruction at a non word-aligned address, it results in UNPREDICTABLE
behavior because the address passed to the BXWritePC() pseudocode function has bits<1:0> = '10'.
Operation
BXWritePC(R[m]);
Exceptions
None.
A8.8.28 BXJ
Branch and Exchange Jazelle attempts to change to Jazelle state. If the attempt fails, it branches to an address and
instruction set specified by a register as though it were a BX instruction.
In an implementation that includes the Virtualization Extensions, if HSTR.TJDBX is set to 1, execution of a BXJ
instruction in a Non-secure mode other than Hyp mode generates a Hyp Trap exception. For more information see
Trapping accesses to Jazelle functionality on page B1-1254.

BXJ<c> <Rm> Outside or last in IT block
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 1 0 0 Rm 1 0 (0) 0 (1) (1) (1) (1) (0) (0) (0) (0) (0) (0) (0) (0)
m = UInt(Rm);
if m IN {13,15} then UNPREDICTABLE;
Encoding A1 ARMv5TEJ, ARMv6*, ARMv7

BXJ<c> <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 0 0 1 0 (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) 0 0 1 0 Rm
m = UInt(Rm);
Assembler syntax
BXJ{<c>}{<q>} <Rm>
where:
<Rm> The register that specifies the branch target address and instruction set selection bit to be used if the
attempt to switch to Jazelle state fails.
Operation
if HaveVirtExt() && !IsSecure() && !CurrentModeIsHyp() && HSTR.TJDBX == ‘1’ then
HSRString<3:0> = m;
elsif JMCR.JE == ‘0’ || CurrentInstrSet() == InstrSet_ThumbEE then
BXWritePC(R[m]);
else
if JazelleAcceptsExecution() then
SwitchToJazelleExecution();
else
SUBARCHITECTURE_DEFINED handler call;
Exceptions
Hyp Trap.
A8.8.29 CBNZ, CBZ

Compare and Branch on Nonzero and Compare and Branch on Zero compare the value in a register with zero, and
conditionally branch forward a constant value. They do not affect the condition flags.

CB{N}Z <Rn>, <label> Not permitted in IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 1 op 0 i 1 imm5 Rn
n = UInt(Rn); imm32 = ZeroExtend(i:imm5:’0’, 32); nonzero = (op == ‘1’);

Assembler syntax
CB{N}Z{<q>} <Rn>, <label>
where:
N If specified, causes the branch to occur when the contents of <Rn> are nonzero (encoded as op = 1).
If omitted, causes the branch to occur when the contents of <Rn> are zero (encoded as op = 0).
<q> See Standard assembler syntax fields on page A8-285. A CBZ or CBNZ instruction must be
unconditional.
<Rn> The operand register.
<label> The label of the instruction that is to be branched to. The assembler calculates the required value of
the offset from the PC value of the CBZ or CBNZ instruction to this label, then selects an encoding that
sets imm32 to that offset. Permitted offsets are even numbers in the range 0 to 126.
Operation
if nonzero != IsZero(R[n]) then
BranchWritePC(PC + imm32);
Exceptions
None.
A8.8.30 CDP, CDP2

Coprocessor Data Processing tells a coprocessor to perform an operation that is independent of ARM core registers
and memory. If no coprocessor can execute the instruction, an Undefined Instruction exception is generated.
This is a generic coprocessor instruction. Some of the fields have no functionality defined by the architecture and
are free for use by the coprocessor instruction set designer. These are the opc1, opc2, CRd, CRn, and CRm fields.
However, coprocessors CP8-CP15 are reserved for use by ARM, and this manual defines the valid CDP and CDP2
instructions when coproc is in the range p8-p15. For more information see Coprocessor support on page A2-93 and
General behavior of system control registers on page B5-1768.
Encoding T1/A1 ARMv6T2, ARMv7 for encoding T1

ARMv4*, ARMv5T*, ARMv6*, ARMv7 for encoding A1
CDP<c> <coproc>, <opc1>, <CRd>, <CRn>, <CRm>, <opc2>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 0 opc1 CRn CRd coproc opc2 0 CRm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 1 0 opc1 CRn CRd coproc opc2 0 CRm
For the case when cond is 0b1111, see the T2 and A2 encoding.
if coproc IN “101x” then SEE “Floating-point instructions”;

cp = UInt(coproc);

ARMv5T*, ARMv6*, ARMv7 for encoding A2
CDP2<c> <coproc>, <opc1>, <CRd>, <CRn>, <CRm>, <opc2>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if coproc IN “101x” then UNDEFINED;

cp = UInt(coproc);
Floating-point instructions See Floating-point data-processing instructions on page A7-270.
Assembler syntax
CDP{2}{<c>}{<q>} <coproc>, {#}<opc1>, <CRd>, <CRn>, <CRm> {, {#}<opc2>}
where:
2 If specified, selects encoding T2/A2. If omitted, selects encoding T1/A1.
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM CDP2 instruction must be
unconditional.
<coproc> The name of the coprocessor, and causes the corresponding coprocessor number to be placed in the
cp_num field of the instruction. The generic coprocessor names are p0-p15.
<opc1> Is a coprocessor-specific opcode, in the range 0 to 15.
<CRd> The destination coprocessor register for the instruction.
<CRn> The coprocessor register that contains the first operand.
<CRm> The coprocessor register that contains the second operand.
<opc2> Is a coprocessor-specific opcode in the range 0 to 7. If it is omitted, <opc2> is 0.
Operation
if !Coproc_Accepted(cp, ThisInstr()) then
GenerateCoprocessorException();
else
Coproc_InternalOperation(cp, ThisInstr());
Exceptions
Undefined Instruction.
Uses of these instructions by specific coprocessors might generate other exceptions.
A8.8.31 CHKA
CHKA is a ThumbEE instruction, see CHKA on page A9-1124.
A8.8.32 CLREX
Clear-Exclusive clears the local record of the executing processor that an address has had a request for an exclusive
access.
Encoding T1 ARMv7
CLREX<c>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 0 1 1 (1) (1) (1) (1) 1 0 (0) 0 (1) (1) (1) (1) 0 0 1 0 (1) (1) (1) (1)
// No additional decoding required
Encoding A1 ARMv6K, ARMv7

CLREX
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 1 0 1 0 1 1 1 (1) (1) (1) (1) (1) (1) (1) (1) (0) (0) (0) (0) 0 0 0 1 (1) (1) (1) (1)
Assembler syntax
CLREX{<c>}{<q>}
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM CLREX instruction must be
unconditional.
Operation
ClearExclusiveLocal(ProcessorID());
Exceptions
None.
A8.8.33 CLZ
Count Leading Zeros returns the number of binary zero bits before the first binary one bit in a value.

CLZ<c> <Rd>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 1 1 Rm 1 1 1 1 Rd 1 0 0 0 Rm
if !Consistent(Rm) then UNPREDICTABLE;

d = UInt(Rd); m = UInt(Rm);

CLZ<c> <Rd>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 0 1 1 0 (1) (1) (1) (1) Rd (1) (1) (1) (1) 0 0 0 1 Rm
if d == 15 || m == 15 then UNPREDICTABLE;
Assembler syntax
CLZ{<c>}{<q>} <Rd>, <Rm>
where:
<Rm> The register that contains the operand. Its number must be encoded twice in encoding T1.
Operation
result = CountLeadingZeroBits(R[m]);
R[d] = result<31:0>;
Exceptions
None.
A8.8.34 CMN (immediate)

Compare Negative (immediate) adds a register value and an immediate value. It updates the condition flags based
on the result, and discards the result.

CMN<c> <Rn>, #<const>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 i 0 1 0 0 0 1 Rn 0 imm3 1 1 1 1 imm8
n = UInt(Rn); imm32 = ThumbExpandImm(i:imm3:imm8);

if n == 15 then UNPREDICTABLE;

CMN<c> <Rn>, #<const>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 1 0 1 1 1 Rn (0) (0) (0) (0) imm12
n = UInt(Rn); imm32 = ARMExpandImm(imm12);
Assembler syntax
CMN{<c>}{<q>} <Rn>, #<const>
where:
<Rn> The register that contains the operand. SP can be used in Thumb and ARM instructions. The PC can
be used in ARM instructions, but ARM deprecates this use of the PC.
in Thumb instructions on page A6-230 or Modified immediate constants in ARM instructions on
page A5-197 for the range of values.
Operation
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.35 CMN (register)

Compare Negative (register) adds a register value and an optionally-shifted register value. It updates the condition
flags based on the result, and discards the result.

CMN<c> <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 0 0 1 0 1 1 Rm Rn
n = UInt(Rn); m = UInt(Rm);

CMN<c>.W <Rn>, <Rm>{, <shift>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 1 1 0 0 0 1 Rn (0) imm3 1 1 1 1 imm2 type Rm
if n == 15 || m IN {13,15} then UNPREDICTABLE;

CMN<c> <Rn>, <Rm>{, <shift>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 0 1 1 1 Rn (0) (0) (0) (0) imm5 type 0 Rm
Assembler syntax
CMN{<c>}{<q>} <Rn>, <Rm> {, <shift>}
where:
<Rn> The first operand register. SP can be used in Thumb instructions (encoding T2) and in ARM
instructions. The PC can be used in ARM instructions, but ARM deprecates this use of the PC.
instructions, but ARM deprecates this use of the PC.
Operation
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.36 CMN (register-shifted register)

Compare Negative (register-shifted register) adds a register value and a register-shifted register value. It updates the
condition flags based on the result, and discards the result.

CMN<c> <Rn>, <Rm>, <type> <Rs>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 0 1 1 1 Rn (0) (0) (0) (0) Rs 0 type 1 Rm
n = UInt(Rn); m = UInt(Rm); s = UInt(Rs);

shift_t = DecodeRegShift(type);
if n == 15 || m == 15 || s == 15 then UNPREDICTABLE;
Assembler syntax
CMN{<c>}{<q>} <Rn>, <Rm>, <type> <Rs>
where:
Operation
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.37 CMP (immediate)

Compare (immediate) subtracts an immediate value from a register value. It updates the condition flags based on
the result, and discards the result.

CMP<c> <Rn>, #<imm8>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 1 0 1 Rn imm8
n = UInt(Rn); imm32 = ZeroExtend(imm8, 32);

CMP<c>.W <Rn>, #<const>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 i 0 1 1 0 1 1 Rn 0 imm3 1 1 1 1 imm8
n = UInt(Rn); imm32 = ThumbExpandImm(i:imm3:imm8);


CMP<c> <Rn>, #<const>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 1 0 1 0 1 Rn (0) (0) (0) (0) imm12
n = UInt(Rn); imm32 = ARMExpandImm(imm12);
Assembler syntax
CMP{<c>}{<q>} <Rn>, #<const>
where:
<Rn> The first operand register. SP can be used in Thumb instructions (encoding T2) and in ARM
instructions. The PC can be used in ARM instructions, but ARM deprecates this use of the PC.
<const> The immediate value to be compared with the value obtained from <Rn>. The range of values is
0-255 for encoding T1. See Modified immediate constants in Thumb instructions on page A6-230
or Modified immediate constants in ARM instructions on page A5-197 for the range of values for
encoding T2 and A1.
Operation
(result, carry, overflow) = AddWithCarry(R[n], NOT(imm32), ‘1’);
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.38 CMP (register)

Compare (register) subtracts an optionally-shifted register value from a register value. It updates the condition flags
based on the result, and discards the result.

CMP<c> <Rn>, <Rm> <Rn> and <Rm> both from R0-R7
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 0 0 1 0 1 0 Rm Rn

CMP<c> <Rn>, <Rm> <Rn> and <Rm> not both from R0-R7
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 0 1 0 1 N Rm Rn
n = UInt(N:Rn); m = UInt(Rm);
if n < 8 && m < 8 then UNPREDICTABLE;
if n == 15 || m == 15 then UNPREDICTABLE;

CMP<c>.W <Rn>, <Rm> {, <shift>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 1 1 1 0 1 1 Rn (0) imm3 1 1 1 1 imm2 type Rm

CMP<c> <Rn>, <Rm>{, <shift>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Assembler syntax
CMP{<c>}{<q>} <Rn>, <Rm> {, <shift>}
where:
<Rn> The first operand register. The SP can be used. The PC can be used in ARM instructions, but ARM
instructions, but ARM deprecates this use of the PC. The SP can be used in both ARM and Thumb
instructions, but:
• ARM deprecates the use of SP
• when assembling for the Thumb instruction set, only encoding T2 is available.
<shift> The shift to apply to the value read from <Rm>. If present, encodings T1 and T2 are not permitted. If
absent, no shift is applied and all encodings are permitted. Shifts applied to a register on
page A8-289 describes the shifts and how they are encoded.
Operation
(result, carry, overflow) = AddWithCarry(R[n], NOT(shifted), ‘1’);
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.39 CMP (register-shifted register)

Compare (register-shifted register) subtracts a register-shifted register value from a register value. It updates the

CMP<c> <Rn>, <Rm>, <type> <Rs>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 0 1 0 1 Rn (0) (0) (0) (0) Rs 0 type 1 Rm

Assembler syntax
CMP{<c>}{<q>} <Rn>, <Rm>, <type> <Rs>
where:
Operation
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.40 CPS
Change Processor State is a system instruction, see CPS (Thumb) on page B9-1964 and CPS (ARM) on
page B9-1966.
A8.8.41 CPY
Copy is a pre-UAL synonym for MOV (register).
Assembler syntax
CPY <Rd>, <Rn>
This is equivalent to:

MOV <Rd>, <Rn>
Exceptions
None.
A8.8.42 CSDB
Consumption of Speculative Data Barrier is a memory barrier that controls speculative execution and data value
prediction.
No instruction other than branch instructions and instructions that write to the PC appearing in program order after
the CSDB can be speculatively executed using the results of any:
• Data value predictions of any instructions.
• APSR.{N, Z, C, V} predictions of any instructions other than conditional branch instructions and conditional
instructions that write to the PC appearing in program order before the CSDB that have not been
architecturally resolved.
Note
For purposes of the definition of CSDB, APSR.{N, Z, C, V} is not considered a data value. This definition permits:
• Control flow speculation before and after the CSDB.
• Speculative execution of conditional data processing instructions after the CSDB, unless they use the results
of data value or APSR.{N, Z, C, V} predictions of instructions appearing in program order before the CSDB
that have not been architecturally resolved.

CSDB{<c>}.W
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 0 1 0 (1) (1) (1) (1) 1 0 (0) 0 (0) 0 0 0 0 0 0 1 0 1 0 0

CSDB{<c>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 1 0 0 1 0 0 0 0 0 (1) (1) (1) (1) (0) (0) (0) (0) 0 0 0 1 0 1 0 0
if cond != ‘1110’ then UNPREDICTABLE;
Assembler syntax
CSDB{<c>}{<q>}
where:
Operation
ConsumptionOfSpeculativeDataBarrier();
Exceptions
None.
A8.8.43 DBG
Debug Hint provides a hint to debug and related systems. See their documentation for what use (if any) they make
of this instruction.
Encoding T1 ARMv7 (executes as NOP in ARMv6T2)

DBG<c> #<option>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 0 1 0 (1) (1) (1) (1) 1 0 (0) 0 (0) 0 0 0 1 1 1 1 option
// Any decoding of ‘option’ is specified by the debug system
Encoding A1 ARMv7 (executes as NOP in ARMv6Kand ARMv6T2)

DBG<c> #<option>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 1 0 0 1 0 0 0 0 0 (1) (1) (1) (1) (0) (0) (0) (0) 1 1 1 1 option
// Any decoding of ‘option’ is specified by the debug system
Assembler syntax
DBG{<c>}{<q>} #<option>
where:
<option> Provides extra information about the hint, and is in the range 0 to 15.
Operation
Hint_Debug(option);
Exceptions
None.
A8.8.44 DMB
Data Memory Barrier is a memory barrier that ensures the ordering of observations of memory accesses, see Data
Memory Barrier (DMB) on page A3-149.
Encoding T1 ARMv7
DMB<c> <option>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 0 1 1 (1) (1) (1) (1) 1 0 (0) 0 (1) (1) (1) (1) 0 1 0 1 option
Encoding A1 ARMv7
DMB <option>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 1 0 1 0 1 1 1 (1) (1) (1) (1) (1) (1) (1) (1) (0) (0) (0) (0) 0 1 0 1 option
Assembler syntax
DMB{<c>}{<q>} {<option>}
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM DMB instruction must be
unconditional.
<option> Specifies an optional limitation on the DMB operation. Values are:

SY Full system is the required shareability domain, reads and writes are the required access
types. Can be omitted.
This option is referred to as the full system DMB. Encoded as option = 0b1111.
ST Full system is the required shareability domain, writes are the required access type. SYST
is a synonym for ST. Encoded as option = 0b1110.
ISH Inner Shareable is the required shareability domain, reads and writes are the required
access types. Encoded as option = 0b1011.
ISHST Inner Shareable is the required shareability domain, writes are the required access type.
Encoded as option = 0b1010.
NSH Non-shareable is the required shareability domain, reads and writes are the required
NSHST Non-shareable is the required shareability domain, writes are the required access type.
OSH Outer Shareable is the required shareability domain, reads and writes are the required
OSHST Outer Shareable is the required shareability domain, writes are the required access type.
All other encodings of option are reserved. It is IMPLEMENTATION DEFINED whether options other
than SY are implemented. All unsupported and reserved options must execute as a full system DMB
operation, but software must not rely on this behavior.
Note
The instruction supports the following alternative <option> values, but ARM recommends that
software does not use these alternative values:
• SH as an alias for ISH
• SHST as an alias for ISHST

• UN as an alias for NSH
• UNST is an alias for NSHST.
Operation
case option of
when ‘0010’ domain = MBReqDomain_OuterShareable; types = MBReqTypes_Writes;
when ‘0011’ domain = MBReqDomain_OuterShareable; types = MBReqTypes_All;
when ‘0110’ domain = MBReqDomain_Nonshareable; types = MBReqTypes_Writes;
when ‘0111’ domain = MBReqDomain_Nonshareable; types = MBReqTypes_All;
when ‘1010’ domain = MBReqDomain_InnerShareable; types = MBReqTypes_Writes;
when ‘1011’ domain = MBReqDomain_InnerShareable; types = MBReqTypes_All;
when ‘1110’ domain = MBReqDomain_FullSystem; types = MBReqTypes_Writes;
otherwise domain = MBReqDomain_FullSystem; types = MBReqTypes_All;
if HaveVirtExt() && !IsSecure() && !CurrentModeIsHyp() then
if HCR.BSU == ‘11’ then
domain = MBReqDomain_FullSystem;
if HCR.BSU == ‘10’ && domain != MBReqDomain_FullSystem then
domain = MBReqDomain_OuterShareable;
if HCR.BSU == ‘01’ && domain == MBReqDomain_Nonshareable then
domain = MBReqDomain_InnerShareable;
DataMemoryBarrier(domain, types);
Exceptions
None.
A8.8.45 DSB
Data Synchronization Barrier is a memory barrier that ensures the completion of memory accesses, see Data
Synchronization Barrier (DSB) on page A3-150.
Encoding T1 ARMv7
DSB<c> <option>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 0 1 1 (1) (1) (1) (1) 1 0 (0) 0 (1) (1) (1) (1) 0 1 0 0 option
Encoding A1 ARMv7
DSB <option>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 1 0 1 0 1 1 1 (1) (1) (1) (1) (1) (1) (1) (1) (0) (0) (0) (0) 0 1 0 0 option
Assembler syntax
DSB{<c>}{<q>} {<option>}
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM DSB instruction must be
unconditional.
<option> Specifies an optional limitation on the DSB operation. Values are:

SY Full system is the required shareability domain, reads and writes are the required access
types. Can be omitted.
This option is referred to as the full system DSB. Encoded as option = 0b1111.
ST Full system is the required shareability domain, writes are the required access type. SYST
is a synonym for ST. Encoded as option = 0b1110.
ISH Inner Shareable is the required shareability domain, reads and writes are the required
ISHST Inner Shareable is the required shareability domain, writes are the required access type.
NSH Non-shareable is the required shareability domain, reads and writes are the required
NSHST Non-shareable is the required shareability domain, writes are the required access type.
OSH Outer Shareable is the required shareability domain, reads and writes are the required
OSHST Outer Shareable is the required shareability domain, writes are the required access type.
All other encodings of option are reserved. It is IMPLEMENTATION DEFINED whether options other
than SY are implemented. All unsupported and reserved options must execute as a full system DSB
operation, but software must not rely on this behavior.
Note
The instruction supports the following alternative <option> values, but ARM recommends that
software does not use these alternative values:
• SH as an alias for ISH
• SHST as an alias for ISHST

• UN as an alias for NSH
• UNST is an alias for NSHST.
Operation
case option of
when ‘0010’ domain = MBReqDomain_OuterShareable; types = MBReqTypes_Writes;
when ‘0011’ domain = MBReqDomain_OuterShareable; types = MBReqTypes_All;
when ‘0110’ domain = MBReqDomain_Nonshareable; types = MBReqTypes_Writes;
when ‘0111’ domain = MBReqDomain_Nonshareable; types = MBReqTypes_All;
when ‘1010’ domain = MBReqDomain_InnerShareable; types = MBReqTypes_Writes;
when ‘1011’ domain = MBReqDomain_InnerShareable; types = MBReqTypes_All;
when ‘1110’ domain = MBReqDomain_FullSystem; types = MBReqTypes_Writes;
otherwise domain = MBReqDomain_FullSystem; types = MBReqTypes_All;

if HCR.BSU == ‘11’ then
domain = MBReqDomain_FullSystem;
if HCR.BSU == ‘10’ && domain != MBReqDomain_FullSystem then
domain = MBReqDomain_OuterShareable;
if HCR.BSU == ‘01’ && domain == MBReqDomain_Nonshareable then
domain = MBReqDomain_InnerShareable;
DataSynchronizationBarrier(domain, types);
Exceptions
None.
A8.8.46 ENTERX
ENTERX causes a change from Thumb state to ThumbEE state, or has no effect in ThumbEE state. For details see
ENTERX, LEAVEX on page A9-1116.
A8.8.47 EOR (immediate)

Bitwise Exclusive OR (immediate) performs a bitwise Exclusive OR of a register value and an immediate value,
and writes the result to the destination register. It can optionally update the condition flags based on the result.

EOR{S}<c> <Rd>, <Rn>, #<const>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 i 0 0 1 0 0 S Rn 0 imm3 Rd imm8
if Rd == ‘1111’ && S == ‘1’ then SEE TEQ (immediate);

if d == 13 || (d == 15 && S == ‘0’) || n IN {13,15} then UNPREDICTABLE;

EOR{S}<c> <Rd>, <Rn>, #<const>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 0 0 0 1 S Rn Rd imm12
Assembler syntax
EOR{S}{<c>}{<q>} {<Rd>,} <Rn>, #<const>
where:
Note
<Rn> The register that contains the operand. The PC can be used in ARM instructions, but ARM
<const> The immediate value to be exclusive ORed with the value obtained from <Rn>. See Modified
immediate constants in Thumb instructions on page A6-230 or Modified immediate constants in
ARM instructions on page A5-197 for the range of values.
The pre-UAL syntax EOR<c>S is equivalent to EORS<c>.
Operation
result = R[n] EOR imm32;
else
R[d] = result;
if setflags then
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.48 EOR (register)

Bitwise Exclusive OR (register) performs a bitwise Exclusive OR of a register value and an optionally-shifted
the result.

EORS <Rdn>, <Rm> Outside IT block.
EOR<c> <Rdn>, <Rm> Inside IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 0 0 0 0 0 1 Rm Rdn


EOR{S}<c>.W <Rd>, <Rn>, <Rm>{, <shift>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if Rd == ‘1111’ && S == ‘1’ then SEE TEQ (register);

if d == 13 || (d == 15 && S == ‘0’) || n IN {13,15} || m IN {13,15} then UNPREDICTABLE;

EOR{S}<c> <Rd>, <Rn>, <Rm>{, <shift>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Assembler syntax
EOR{S}{<c>}{<q>} {<Rd>,} <Rn>, <Rm> {, <shift>}
where:
Note
<Rn> The first operand register. The PC can be used in ARM instructions, but ARM deprecates this use
of the PC.
shift is applied and all encodings are permitted.Shifts applied to a register on page A8-289 describes
the shifts and how they are encoded.
In Thumb assembly:
• outside an IT block, if EORS <Rd>, <Rn>, <Rd> has <Rd> and <Rn> both in the range R0-R7, it is assembled using
encoding T1 as though EORS <Rd>, <Rn> had been written
• inside an IT block, if EOR<c> <Rd>, <Rn>, <Rd> has <Rd> and <Rn> both in the range R0-R7, it is assembled
using encoding T1 as though EOR<c> <Rd>, <Rn> had been written.
Operation
result = R[n] EOR shifted;
else
R[d] = result;
if setflags then
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.49 EOR (register-shifted register)

Bitwise Exclusive OR (register-shifted register) performs a bitwise Exclusive OR of a register value and a
register-shifted register value. It writes the result to the destination register, and can optionally update the condition

EOR{S}<c> <Rd>, <Rn>, <Rm>, <type> <Rs>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Assembler syntax
EOR{S}{<c>}{<q>} {<Rd>,} <Rn>, <Rm>, <type> <Rs>
where:
Operation
R[d] = result;
if setflags then
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.50 ERET
Exception Return is a system instruction, see ERET on page B9-1968.
A8.8.51 F*, former Floating-point instruction mnemonics

Before the introduction of UAL, the Floating-point (VFP) instructions had mnemonics starting with F. In UAL, most
of these mnemonics are renamed to start with V. Other UAL mnemonic changes on page D8-2457 lists all of the
Floating-point instruction mnemonic changes. UAL does not define new mnemonics for the FLDMX and FSTMX
instructions, see FLDMX, FSTMX.
FLDMX, FSTMX
Encodings T1/A1 of the VLDM, VPOP, VPUSH, and VSTM instructions contain an imm8 field that is set to twice the number
of doubleword registers to be transferred. ARM deprecates use of these encodings with an odd value in imm8, and
there is no UAL syntax for them.
The pre-UAL mnemonics FLDMX and FSTMX result in the same instructions as FLDMD (VLDM.64 or VPOP.64) and FSTMD
(VSTM.64 or VPUSH.64) respectively, except that imm8 is equal to twice the number of doubleword registers plus one:
• from ARMv6, ARM deprecates use of FLDMX and FSTMX, except for disassembly purposes, and for reassembly
of disassembled code
• if an FLDMX or FSTMX instruction accesses any register in the range D16-D32, the instruction is UNPREDICTABLE.
A8.8.52 HB, HBL, HBLP, HBP

These are ThumbEE instructions, see HB, HBL on page A9-1125, HBLP on page A9-1126, and HBP on
page A9-1127.
A8.8.53 HVC
Hypervisor Call is a system instruction, see HVC on page B9-1970.
A8.8.54 ISB
Instruction Synchronization Barrier flushes the pipeline in the processor, so that all instructions following the ISB
are fetched from cache or memory, after the instruction has been completed. It ensures that the effects of context
changing operations executed before the ISB instruction are visible to the instructions fetched after the ISB. Context
changing operations include changing the Address Space Identifier (ASID), TLB maintenance operations, branch
predictor maintenance operations, and all changes to the CP15 registers. In addition, any branches that appear in
program order after the ISB instruction are written into the branch prediction logic with the context that is visible
after the ISB instruction. This is needed to ensure correct execution of the instruction stream.
Encoding T1 ARMv7
ISB<c> <option>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 0 1 1 (1) (1) (1) (1) 1 0 (0) 0 (1) (1) (1) (1) 0 1 1 0 option
Encoding A1 ARMv7
ISB <option>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 1 0 1 0 1 1 1 (1) (1) (1) (1) (1) (1) (1) (1) (0) (0) (0) (0) 0 1 1 0 option
Assembler syntax
ISB{<c>}{<q>} {<option>}
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM ISB instruction must be
unconditional.
<option> Specifies an optional limitation on the ISB operation. Values are:

SY Full system ISB operation, encoded as option = 0b1111. Can be omitted.
All other encodings of option are reserved. The corresponding instructions execute as full system
ISB operations, but must not be relied upon by software.
Operation
InstructionSynchronizationBarrier();
Exceptions
None.
A8.8.55 IT
If-Then makes up to four following instructions (the IT block) conditional. The conditions for the instructions in the
IT block are the same as, or the inverse of, the condition the IT instruction specifies for the first instruction in the
block.
The IT instruction itself does not affect the condition flags, but the execution of the instructions in the IT block can
change the condition flags.
16-bit instructions in the IT block, other than CMP, CMN and TST, do not set the condition flags. An IT instruction with
the AL condition can be used to get this changed behavior without conditional execution.
The architecture permits exception return to an instruction in the IT block only if the restoration of the CPSR
restores ITSTATE to a state consistent with the conditions specified by the IT instruction. Any other exception return
to an instruction in an IT block is UNPREDICTABLE. Any branch to a target instruction in an IT block is not permitted,
and if such a branch is made it is UNPREDICTABLE what condition is used when executing that target instruction and
any subsequent instruction in the IT block.
See also Conditional instructions on page A4-160 and Conditional execution on page A8-286.

IT{<x>{<y>{<z>}}} <firstcond> Not permitted in IT block
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 1 1 1 1 1 firstcond mask
if mask == ‘0000’ then SEE “Related encodings”;

if firstcond == ‘1111’ || (firstcond == ‘1110’ && BitCount(mask) != 1) then UNPREDICTABLE;
Related encodings See If-Then, and hints on page A6-227.
Assembler syntax
IT{<x>{<y>{<z>}}}{<q>} <firstcond>
where:
<x> The condition for the second instruction in the IT block.
<y> The condition for the third instruction in the IT block.
<z> The condition for the fourth instruction in the IT block.
<q> See Standard assembler syntax fields on page A8-285. An IT instruction must be unconditional.
<firstcond> The condition for the first instruction in the IT block. See Table A8-1 on page A8-286 for the range
of conditions available, and the encodings.
Each of <x>, <y>, and <z> can be either:
T Then. The condition for the instruction is <firstcond>.
E Else. The condition for the instruction is the inverse of <firstcond>. The condition code is the same
as <firstcond>, except that the least significant bit is inverted. E must not be specified if <firstcond>
is AL.
Table A8-2 on page A8-392 shows how the values of <x>, <y>, and <z> determine the value of the mask field.
Table A8-2 Determination of mask field
<x> <y> <z> mask[3] mask[2] mask[1] mask[0]
Omitted Omitted Omitted 1 0 0 0
T Omitted Omitted firstcond[0] 1 0 0
E Omitted Omitted NOT firstcond[0] 1 0 0
T T Omitted firstcond[0] firstcond[0] 1 0
E T Omitted NOT firstcond[0] firstcond[0] 1 0
T E Omitted firstcond[0] NOT firstcond[0] 1 0
E E Omitted NOT firstcond[0] NOT firstcond[0] 1 0
T T T firstcond[0] firstcond[0] firstcond[0] 1
E T T NOT firstcond[0] firstcond[0] firstcond[0] 1
T E T firstcond[0] NOT firstcond[0] firstcond[0] 1
E E T NOT firstcond[0] NOT firstcond[0] firstcond[0] 1
T T E firstcond[0] firstcond[0] NOT firstcond[0] 1
E T E NOT firstcond[0] firstcond[0] NOT firstcond[0] 1
T E E firstcond[0] NOT firstcond[0] NOT firstcond[0] 1
E E E NOT firstcond[0] NOT firstcond[0] NOT firstcond[0] 1
The conditions specified in an IT instruction must match those specified in the syntax of the instructions in its IT
block. When assembling to ARM code, assemblers check IT instruction syntax for validity but do not generate
assembled instructions for them. See Conditional instructions on page A4-160.
Operation
ITSTATE.IT<7:0> = firstcond:mask;
Exceptions
None.
A8.8.56 LDC, LDC2 (immediate)

Load Coprocessor loads memory data from a sequence of consecutive memory addresses to a coprocessor. If no
coprocessor can execute the instruction, an Undefined Instruction exception is generated.
are free for use by the coprocessor instruction set designer. These are the D bit, the CRd field, and in the Unindexed
addressing mode only, the imm8 field. However, coprocessors CP8-CP15 are reserved for use by ARM, and this
manual defines the valid LDC and LDC2 instructions when coproc is in the range p8-p15. For more information see
Coprocessor support on page A2-93.
In an implementation that includes the Virtualization Extensions, the permitted LDC access to a system control
register can be trapped to Hyp mode, meaning that an attempt to execute an LDC instruction in a Non-secure mode
other than Hyp mode, that would be permitted in the absence of the Hyp trap controls, generates a Hyp Trap
exception. For more information, see Trapping general CP14 accesses to debug registers on page B1-1258.
For more information about these instructions, see General behavior of system control registers on page B3-1442
or General behavior of system control registers on page B5-1768.
Note
For simplicity, the LDC pseudocode does not show this possible trap to Hyp mode.

LDC{L}<c> <coproc>, <CRd>, [<Rn>, #+/-<imm>]{!}
LDC{L}<c> <coproc>, <CRd>, [<Rn>], #+/-<imm>
LDC{L}<c> <coproc>, <CRd>, [<Rn>], <option>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 0 P U D W 1 Rn CRd coproc imm8
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 0 P U D W 1 Rn CRd coproc imm8
if Rn == ‘1111’ then SEE LDC (literal);

if P == ‘0’ && U == ‘0’ && D == ‘0’ && W == ‘0’ then UNDEFINED;
if P == ‘0’ && U == ‘0’ && D == ‘1’ && W == ‘0’ then SEE MRRC, MRRC2;
if coproc IN “101x” then SEE “Advanced SIMD and Floating-point”;
n = UInt(Rn); cp = UInt(coproc);
imm32 = ZeroExtend(imm8:’00’, 32); index = (P == ‘1’); add = (U == ‘1’); wback = (W == ‘1’);
LDC2{L}<c> <coproc>, <CRd>, [<Rn>, #+/-<imm>]{!}
LDC2{L}<c> <coproc>, <CRd>, [<Rn>], #+/-<imm>
LDC2{L}<c> <coproc>, <CRd>, [<Rn>], <option>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if Rn == ‘1111’ then SEE LDC (literal);

Advanced SIMD and Floating-point See Extension register load/store instructions on page A7-272
Assembler syntax
LDC{2}{L}{<c>}{<q>} <coproc>, <CRd>, [<Rn>{, #+/-<imm>}] Offset. P = 1, W = 0.
LDC{2}{L}{<c>}{<q>} <coproc>, <CRd>, [<Rn>, #+/-<imm>]! Pre-indexed. P = 1, W = 1.
LDC{2}{L}{<c>}{<q>} <coproc>, <CRd>, [<Rn>], #+/-<imm> Post-indexed. P = 0, W = 1.
LDC{2}{L}{<c>}{<q>} <coproc>, <CRd>, [<Rn>], <option> Unindexed. P = 0, W = 0, U = 1.
where:
L If specified, selects the D == 1 form of the encoding. If omitted, selects the D == 0 form.
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM LDC2 instruction must be
unconditional.
<coproc> The name of the coprocessor. The generic coprocessor names are p0-p15.
<CRd> The coprocessor destination register.
<Rn> The base register. The SP can be used. For PC use see LDC, LDC2 (literal) on page A8-395.
+/- Is + or omitted if the immediate offset is to be added to the base register value (add == TRUE, encoded
as U ==1), or – if it is to be subtracted (add == FALSE, encoded as U==0). #0 and #-0 generate
different instructions.
<imm> The immediate offset used for forming the address. Values are multiples of 4 in the range 0-1020.
For the offset addressing syntax, <imm> can be omitted, meaning an offset of +0.
<option> A coprocessor option. An integer in the range 0-255 enclosed in { }. Encoded in imm8.
The pre-UAL syntax LDC<c>L is equivalent to LDCL<c>.
Operation
else
NullCheckIfThumbEE(n);
offset_addr = if add then (R[n] + imm32) else (R[n] - imm32);
address = if index then offset_addr else R[n];
repeat
Coproc_SendLoadedWord(MemA[address,4], cp, ThisInstr());
address = address + 4;
until Coproc_DoneLoading(cp, ThisInstr());
if wback then R[n] = offset_addr;
Exceptions
Undefined Instruction, Data Abort, Hyp Trap.
A8.8.57 LDC, LDC2 (literal)

Load Coprocessor loads memory data from a sequence of consecutive memory addresses to a coprocessor. If no
manual defines the valid LDC and LDC2 instructions when coproc is in the range p8-p15. For more information see
Coprocessor support on page A2-93 and General behavior of system control registers on page B5-1768.
In an implementation that includes the Virtualization Extensions, the permitted LDC access to a system control
register can be trapped to Hyp mode, meaning that an attempt to execute an LDC instruction in a Non-secure mode
Note
For simplicity, the LDC pseudocode does not show this possible trap to Hyp mode.

LDC{L}<c> <coproc>, <CRd>, <label>
LDC{L}<c> <coproc>, <CRd>, [PC, #-0] Special case
LDC{L}<c> <coproc>, <CRd>, [PC], <option>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 0 P U D W 1 1 1 1 1 CRd coproc imm8
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 0 P U D W 1 1 1 1 1 CRd coproc imm8
For the case when cond is 0b1111, see the T2/A2 encoding.

index = (P == ‘1’); add = (U == ‘1’); cp = UInt(coproc); imm32 = ZeroExtend(imm8:’00’, 32);
if W == ‘1’ || (P == ‘0’ && CurrentInstrSet() != InstrSet_ARM) then UNPREDICTABLE;

LDC2{L}<c> <coproc>, <CRd>, <label>
LDC2{L}<c> <coproc>, <CRd>, [PC, #-0] Special case
LDC2{L}<c> <coproc>, <CRd>, [PC], <option>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

index = (P == ‘1’); add = (U == ‘1’); cp = UInt(coproc); imm32 = ZeroExtend(imm8:’00’, 32);
if W == ‘1’ || (P == ‘0’ && CurrentInstrSet() != InstrSet_ARM) then UNPREDICTABLE;
Assembler syntax
LDC{2}{L}{<c>}{<q>} <coproc>, <CRd>, <label> Normal form with P = 1, W = 0
LDC{2}{L}{<c>}{<q>} <coproc>, <CRd>, [PC, #+/-<imm>] Alternative form with P = 1, W = 0
LDC{2}{L}{<c>}{<q>} <coproc>, <CRd>, [PC], <option> Unindexed form with P = 0, U = 1, W = 0,
encoding A1/A2 only
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM LDC2 instruction must be
unconditional.
<CRd> The coprocessor destination register.
<label> The label of the literal data item that is to be loaded into <Rt>. The assembler calculates the required
value of the offset from the Align(PC, 4) value of the instruction to this label. Permitted values of
the offset are multiples of 4 in the range -1020 to 1020.
If the offset is zero or positive, imm32 is equal to the offset and add == TRUE (encoded as U == 1).
If the offset is negative, imm32 is equal to minus the offset and add == FALSE (encoded as U == 0).
The unindexed form is permitted for the ARM instruction set only. In it, <option> is a coprocessor option, written
as an integer 0-255 enclosed in { } and encoded in imm8.
The pre-UAL syntax LDC<c>L is equivalent to LDCL<c>.
Operation
else
NullCheckIfThumbEE(15);
offset_addr = if add then (Align(PC,4) + imm32) else (Align(PC,4) - imm32);
address = if index then offset_addr else Align(PC,4);
repeat
Coproc_SendLoadedWord(MemA[address,4], cp, ThisInstr());
until Coproc_DoneLoading(cp, ThisInstr());
Exceptions
A8.8.58 LDM/LDMIA/LDMFD (Thumb)

Load Multiple Increment After (Load Multiple Full Descending) loads multiple registers from consecutive memory
locations using an address from a base register. The consecutive memory locations start at this address, and the
address just above the highest of those locations can optionally be written back to the base register. The registers
loaded can include the PC, causing a branch to a loaded address. Related system instructions are LDM (User
registers) on page B9-1974 and LDM (exception return) on page B9-1972.
Encoding T1 ARMv4T, ARMv5T*, ARMv6*, ARMv7 (not in ThumbEE)

LDM<c> <Rn>!, <registers> <Rn> not included in <registers>
LDM<c> <Rn>, <registers> <Rn> included in <registers>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 0 0 1 Rn register_list
if CurrentInstrSet() == InstrSet_ThumbEE then SEE “ThumbEE instructions”;

n = UInt(Rn); registers = ‘00000000’:register_list; wback = (registers<n> == ‘0’);
if BitCount(registers) < 1 then UNPREDICTABLE;

LDM<c>.W <Rn>{!}, <registers>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 0 0 1 0 W 1 Rn P M (0) register_list
if W == ‘1’ && Rn == ‘1101’ then SEE POP (Thumb);

n = UInt(Rn); registers = P:M:’0’:register_list; wback = (W == ‘1’);
if n == 15 || BitCount(registers) < 2 || (P == ‘1’ && M == ‘1’) then UNPREDICTABLE;
if registers<15> == ‘1’ && InITBlock() && !LastInITBlock() then UNPREDICTABLE;
if wback && registers<n> == ‘1’ then UNPREDICTABLE;
ThumbEE instructions See 16-bit ThumbEE instructions on page A9-1115.
Assembler syntax
LDM{<c>}{<q>} <Rn>{!}, <registers>
where:
<Rn> The base register. SP can be used. If it is the SP and ! is specified, the instruction is treated as
described in POP (Thumb) on page A8-535.
! Causes the instruction to write a modified value back to <Rn>. Encoded as W = 1. If ! is omitted, the
instruction does not change <Rn> in this way. Encoded as W = 0.
<registers> Is a list of one or more registers to be loaded, separated by commas and surrounded by { and }. The
lowest-numbered register is loaded from the lowest memory address, through to the
highest-numbered register from the highest memory address. See also Encoding of lists of ARM core
Encoding T2 does not support a list containing only one register. If an LDMIA instruction with just
one register <Rt> in the list is assembled to Thumb and encoding T1 is not available, it is assembled
to the equivalent LDR{<c>}{<q>} <Rt>, [<Rn>]{, #4} instruction.
The SP cannot be in the list.
The PC can be in the list. If it is, the instruction branches to the address loaded to the PC. In
ARMv5T and above, this is an interworking branch, see Pseudocode details of operations on ARM
core registers on page A2-46. If the PC is in the list:
• the LR must not be in the list
• the instruction must be either outside any IT block, or the last instruction in an IT block.
If ! is specified, <registers> cannot include the base register.
LDMIA and LDMFD are pseudo-instructions for LDM. LDMFD refers to its use for popping data from Full Descending stacks.
The pre-UAL syntaxes LDM<c>IA and LDM<c>FD are equivalent to LDM<c>.
Operation
EncodingSpecificOperations(); NullCheckIfThumbEE(n);
address = R[n];
for i = 0 to 14
if registers<i> == ‘1’ then
R[i] = MemA[address,4]; address = address + 4;
if registers<15> == ‘1’ then
LoadWritePC(MemA[address,4]);
if wback && registers<n> == ‘0’ then R[n] = R[n] + 4*BitCount(registers);
if wback && registers<n> == ‘1’ then R[n] = bits(32) UNKNOWN;
Exceptions
Data Abort.
A8.8.59 LDM/LDMIA/LDMFD (ARM)

Load Multiple Increment After (Load Multiple Full Descending) loads multiple registers from consecutive memory
address just above the highest of those locations can optionally be written back to the base register. The registers
loaded can include the PC, causing a branch to a loaded address. Related system instructions are LDM (User
registers) on page B9-1974 and LDM (exception return) on page B9-1972.

LDM<c> <Rn>{!}, <registers>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 0 0 0 1 0 W 1 Rn register_list
if W == ‘1’ && Rn == ‘1101’ && BitCount(register_list) > 1 then SEE POP (ARM);
n = UInt(Rn); registers = register_list; wback = (W == ‘1’);
if n == 15 || BitCount(registers) < 1 then UNPREDICTABLE;
if wback && registers<n> == ‘1’ && ArchVersion() >= 7 then UNPREDICTABLE;
Assembler syntax
LDM{<c>}{<q>} <Rn>{!}, <registers>
where:
<Rn> The base register. SP can be used. If the SP is used, ! is specified, and there is more than one register
in the <registers> list, the instruction is treated as described in POP (ARM) on page A8-537.
! Causes the instruction to write a modified value back to <Rn>. Encoded as W = 1. If ! is omitted, the
instruction does not change <Rn> in this way. Encoded as W = 0.
The SP can be in the list. However, ARM deprecates using these instructions with SP in the list.
core registers on page A2-46.
ARM deprecates using these instructions with both the LR and the PC in the list.
Instructions with the base register in the list and ! specified are only available before ARMv7, and
ARM deprecates the use of such instructions. The value of the base register after such an instruction
is UNKNOWN.
LDMIA and LDMFD are pseudo-instructions for LDM. LDMFD refers to its use for popping data from Full Descending stacks.
The pre-UAL syntaxes LDM<c>IA and LDM<c>FD are equivalent to LDM<c>.
Operation
address = R[n];
for i = 0 to 14
Exceptions
Data Abort.
A8.8.60 LDMDA/LDMFA
Load Multiple Decrement After (Load Multiple Full Ascending) loads multiple registers from consecutive memory
locations using an address from a base register. The consecutive memory locations end at this address, and the
address just below the lowest of those locations can optionally be written back to the base register. The registers
loaded can include the PC, causing a branch to a loaded address.
Related system instructions are LDM (User registers) on page B9-1974 and LDM (exception return) on
page B9-1972.

LDMDA<c> <Rn>{!}, <registers>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Assembler syntax
LDMDA{<c>}{<q>} <Rn>{!}, <registers>
where:
<Rn> The base register. SP can be used.
! Causes the instruction to write a modified value back to <Rn>. Encoded as W = 1.

If ! is omitted, the instruction does not change <Rn> in this way. Encoded as W = 0.
The SP can be in the list. However, instructions that include the SP in the list are deprecated.
The PC can be in the list. If it is, the instruction branches to the address (data) loaded to the PC. In
ARMv5T and above, this branch is an interworking branch, see Pseudocode details of operations
ARM deprecates including both LR and PC in the list.
is UNKNOWN.
LDMFA is a pseudo-instruction for LDMDA, referring to its use for popping data from Full Ascending stacks.
The pre-UAL syntaxes LDM<c>DA and LDM<c>FA are equivalent to LDMDA<c>.
Operation
address = R[n] - 4*BitCount(registers) + 4;
for i = 0 to 14
if wback && registers<n> == ‘0’ then R[n] = R[n] - 4*BitCount(registers);
Exceptions
Data Abort.
A8.8.61 LDMDB/LDMEA
Load Multiple Decrement Before (Load Multiple Empty Ascending) loads multiple registers from consecutive
memory locations using an address from a base register. The consecutive memory locations end just below this
address, and the address of the lowest of those locations can optionally be written back to the base register. The
registers loaded can include the PC, causing a branch to a loaded address.
page B9-1972.

LDMDB<c> <Rn>{!}, <registers>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 0 1 0 0 W 1 Rn P M (0) register_list
n = UInt(Rn); registers = P:M:’0’:register_list; wback = (W == ‘1’);

if n == 15 || BitCount(registers) < 2 || (P == ‘1’ && M == ‘1’) then UNPREDICTABLE;

LDMDB<c> <Rn>{!}, <registers>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Assembler syntax
LDMDB{<c>}{<q>} <Rn>{!}, <registers>
where:
<Rn> The base register. The SP can be used.

Encoding T1 does not support a list containing only one register. If an LDMDB instruction with just
one register <Rt> in the list is assembled to Thumb, it is assembled to the equivalent LDR{<c>}{<q>}
<Rt>, [<Rn>, #-4]{!} instruction.
The SP can be in the list in ARM instructions, but not in Thumb instructions. However, ARM
instructions that include the SP in the list are deprecated.
core registers on page A2-46. In Thumb instructions, if the PC is in the list:
For the ARM instruction set, ARM deprecates including both LR and PC in the list.
Instructions with the base register in the list and ! specified are only available in the ARM
instruction set before ARMv7, and ARM deprecates the use of such instructions. The value of the
base register after such an instruction is UNKNOWN.
LDMEA is a pseudo-instruction for LDMDB, referring to its use for popping data from Empty Ascending stacks.
The pre-UAL syntaxes LDM<c>DB and LDM<c>EA are equivalent to LDMDB<c>.
Operation
address = R[n] - 4*BitCount(registers);
for i = 0 to 14
if wback && registers<n> == ‘0’ then R[n] = R[n] - 4*BitCount(registers);
Exceptions
Data Abort.
A8.8.62 LDMIB/LDMED
Load Multiple Increment Before (Load Multiple Empty Descending) loads multiple registers from consecutive
memory locations using an address from a base register. The consecutive memory locations start just above this
address, and the address of the last of those locations can optionally be written back to the base register. The registers
loaded can include the PC, causing a branch to a loaded address.
page B9-1972.

LDMIB<c> <Rn>{!}, <registers>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Assembler syntax
LDMIB{<c>}{<q>} <Rn>{!}, <registers>
where:

The SP can be in the list. However, instructions that include the SP in the list are deprecated.
The PC can be in the list. If it is, the instruction branches to the address (data) loaded to the PC. In
ARMv5T and above, this branch is an interworking branch, see Pseudocode details of operations
ARM deprecates including both LR and PC in the list.
is UNKNOWN.
LDMED is a pseudo-instruction for LDMIB, referring to its use for popping data from Empty Descending stacks.
The pre-UAL syntaxes LDM<c>IB and LDM<c>ED are equivalent to LDMIB<c>.
Operation
address = R[n] + 4;
for i = 0 to 14
Exceptions
Data Abort.
A8.8.63 LDR (immediate, Thumb)

Load Register (immediate) calculates an address from a base register value and an immediate offset, loads a word
from memory, and writes it to a register. It can use offset, post-indexed, or pre-indexed addressing. For information
about memory accesses see Memory accesses on page A8-292.

LDR<c> <Rt>, [<Rn>{, #<imm>}]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 1 0 1 imm5 Rn Rt
t = UInt(Rt); n = UInt(Rn); imm32 = ZeroExtend(imm5:’00’, 32);

index = TRUE; add = TRUE; wback = FALSE;

LDR<c> <Rt>, [SP{, #<imm>}]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 0 1 1 Rt imm8
t = UInt(Rt); n = 13; imm32 = ZeroExtend(imm8:’00’, 32);


LDR<c>.W <Rt>, [<Rn>{, #<imm12>}]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 1 1 0 1 Rn Rt imm12
if Rn == ‘1111’ then SEE LDR (literal);

t = UInt(Rt); n = UInt(Rn); imm32 = ZeroExtend(imm12, 32); index = TRUE; add = TRUE;
wback = FALSE; if t == 15 && InITBlock() && !LastInITBlock() then UNPREDICTABLE;

LDR<c> <Rt>, [<Rn>, #-<imm8>]
LDR<c> <Rt>, [<Rn>], #+/-<imm8>
LDR<c> <Rt>, [<Rn>, #+/-<imm8>]!
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 0 1 0 1 Rn Rt 1 P U W imm8

if P == ‘1’ && U == ‘1’ && W == ‘0’ then SEE LDRT;
if Rn == ‘1101’ && P == ‘0’ && U == ‘1’ && W == ‘1’ && imm8 == ‘00000100’ then SEE POP;
if P == ‘0’ && W == ‘0’ then UNDEFINED;
t = UInt(Rt); n = UInt(Rn);
imm32 = ZeroExtend(imm8, 32); index = (P == ‘1’); add = (U == ‘1’); wback = (W == ‘1’);
if (wback && n == t) || (t == 15 && InITBlock() && !LastInITBlock()) then UNPREDICTABLE;
Assembler syntax
LDR{<c>}{<q>} <Rt>, [<Rn> {, #+/-<imm>}] Offset: index==TRUE, wback==FALSE
LDR{<c>}{<q>} <Rt>, [<Rn>, #+/-<imm>]! Pre-indexed: index==TRUE, wback==TRUE
LDR{<c>}{<q>} <Rt>, [<Rn>], #+/-<imm> Post-indexed: index==FALSE, wback==TRUE
where:
<Rt> The destination register. The SP can be used. The PC can be used, provided the instruction is either
outside an IT block or the last instruction of an IT block. If the PC is used, the instruction branches
to the address (data) loaded to the PC. In ARMv5T and above, this branch is an interworking branch,
see Pseudocode details of operations on ARM core registers on page A2-46.
<Rn> The base register. The SP can be used. For PC use see LDR (literal) on page A8-411.
+/- + or omitted The immediate offset is to be added to the base register value (add == TRUE,
encoded as U == 1 in encoding T4).
– The immediate offset is to be subtracted from the base register value.
Encoding T4 must be used, with add == FALSE, encoded as U == 0.
#0 and #-0 generate different instructions.
<imm> The immediate offset used for forming the address. For the offset addressing syntax, <imm> can be
omitted, meaning an offset of 0. Values are:
Encoding T1 Multiples of 4 in the range 0-124.
Encoding T3 Any value in the range 0-4095.
Encoding T4 Any value in the range 0-255.
Operation
data = MemU[address,4];
if t == 15 then
if address<1:0> == ‘00’ then LoadWritePC(data); else UNPREDICTABLE;
elsif UnalignedSupport() || address<1:0> == ‘00’ then
R[t] = data;
else R[t] = bits(32) UNKNOWN; // Can only apply before ARMv7
Exceptions
Data Abort.
ThumbEE instruction
ThumbEE has additional LDR (immediate) encodings, see LDR (immediate) on page A9-1128.
A8.8.64 LDR (immediate, ARM)

Load Register (immediate) calculates an address from a base register value and an immediate offset, loads a word
from memory, and writes it to a register. It can use offset, post-indexed, or pre-indexed addressing. For information

LDR<c> <Rt>, [<Rn>{, #+/-<imm12>}]
LDR<c> <Rt>, [<Rn>], #+/-<imm12>
LDR<c> <Rt>, [<Rn>, #+/-<imm12>]!
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 0 P U 0 W 1 Rn Rt imm12

if P == ‘0’ && W == ‘1’ then SEE LDRT;
if Rn == ‘1101’ && P == ‘0’ && U == ‘1’ && W == ‘0’ && imm12 == ‘000000000100’ then SEE POP;
t = UInt(Rt); n = UInt(Rn); imm32 = ZeroExtend(imm12, 32);
index = (P == ‘1’); add = (U == ‘1’); wback = (P == ‘0’) || (W == ‘1’);
if wback && n == t then UNPREDICTABLE;
Assembler syntax
LDR{<c>}{<q>} <Rt>, [<Rn> {, #+/-<imm>}] Offset: index==TRUE, wback==FALSE
LDR{<c>}{<q>} <Rt>, [<Rn>, #+/-<imm>]! Pre-indexed: index==TRUE, wback==TRUE
LDR{<c>}{<q>} <Rt>, [<Rn>], #+/-<imm> Post-indexed: index==FALSE, wback==TRUE
where:
<Rt> The destination register. The SP or the PC can be used. If the PC is used, the instruction branches
<Rn> The base register. The SP can be used. For PC use see LDR (literal) on page A8-411.
as U ==1), or – if it is to be subtracted (add == FALSE, encoded as U ==0). #0 and #-0 generate
omitted, meaning an offset of 0. Any value in the range 0-4095 is permitted.
Operation
if t == 15 then
R[t] = data;
else // Can only apply before ARMv7
R[t] = ROR(data, 8*UInt(address<1:0>));
Exceptions
Data Abort.
A8.8.65 LDR (literal)

Load Register (literal) calculates an address from the PC value and an immediate offset, loads a word from memory,
and writes it to a register. For information about memory accesses see Memory accesses on page A8-292.

LDR<c> <Rt>, <label>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 1 Rt imm8
t = UInt(Rt); imm32 = ZeroExtend(imm8:’00’, 32); add = TRUE;

LDR<c>.W <Rt>, <label>
LDR<c>.W <Rt>, [PC, #-0] Special case
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 U 1 0 1 1 1 1 1 Rt imm12
t = UInt(Rt); imm32 = ZeroExtend(imm12, 32); add = (U == ‘1’);

if t == 15 && InITBlock() && !LastInITBlock() then UNPREDICTABLE;

LDR<c> <Rt>, <label>
LDR<c> <Rt>, [PC, #-0] Special case
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 0 P U 0 W 1 1 1 1 1 Rt imm12

if P == W then UNPREDICTABLE;
Assembler syntax
LDR{<c>}{<q>} <Rt>, <label> Normal form
LDR{<c>}{<q>} <Rt>, [PC, #+/-<imm>] Alternative form
where:
the offset are:
Encoding T1 Multiples of four in the range 0 to 1020.
Encoding T2 or A1 Any value in the range -4095 to 4095.
If the offset is zero or positive, imm32 is equal to the offset and add == TRUE, encoded as U == 1 in
encoding T2.
If the offset is negative, imm32 is equal to minus the offset and add == FALSE, encoded as U == 0.
Negative offset is not available in encoding T1.
Note
In examples in this manual, the syntax =<value> is used for the label of a memory word whose
contents are constant and equal to <value>. The actual syntax for such a label is
assembler-dependent.
Operation
EncodingSpecificOperations(); NullCheckIfThumbEE(15);
base = Align(PC,4);
address = if add then (base + imm32) else (base - imm32);
if t == 15 then
R[t] = data;
else
R[t] = bits(32) UNKNOWN;
Exceptions
Data Abort.
A8.8.66 LDR (register, Thumb)

Load Register (register) calculates an address from a base register value and an offset register value, loads a word
from memory, and writes it to a register. The offset register value can optionally be shifted. For information about
memory accesses, see Memory accesses on page A8-292.
The Thumb form of LDR (register) does not support register writeback.

LDR<c> <Rt>, [<Rn>, <Rm>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 1 1 0 0 Rm Rn Rt
if CurrentInstrSet() == InstrSet_ThumbEE then SEE “Modified operation in ThumbEE”;

t = UInt(Rt); n = UInt(Rn); m = UInt(Rm);

LDR<c>.W <Rt>, [<Rn>, <Rm>{, LSL #<imm2>}]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 0 1 0 1 Rn Rt 0 0 0 0 0 0 imm2 Rm

(shift_t, shift_n) = (SRType_LSL, UInt(imm2));
if t == 15 && InITBlock() && !LastInITBlock() then UNPREDICTABLE;
Modified operation in ThumbEE See LDR (register) on page A9-1118
Assembler syntax
LDR{<c>}{<q>} <Rt>, [<Rn>, {+}<Rm>{, <shift>}] Offset addressing
where:
<Rn> The base register. The SP can be used. In the Thumb instruction set, the PC cannot be used with this
form of the LDR instruction.
+ In Thumb instructions, the optionally shifted value of <Rm> is added to the base register value.
Thumb instructions cannot subtract <Rm> from the base register value.
<Rm> The offset that is optionally shifted and applied to the value of <Rn> to form the address.
shift is applied and all encodings are permitted. For encoding T2, <shift> can only be omitted,
encoded as imm2 = 0b00, or LSL #<imm> with <imm> = 1, 2, or 3, and <imm> encoded in imm2.
Operation
offset = Shift(R[m], shift_t, shift_n, APSR.C);
offset_addr = (R[n] + offset);
address = offset_addr;
if t == 15 then
if address<1:0> == ‘00’ then
LoadWritePC(data);
else
UNPREDICTABLE;
R[t] = data;
Exceptions
Data Abort.
A8.8.67 LDR (register, ARM)

from memory, and writes it to a register. The offset register value can optionally be shifted. For information about
memory accesses, see Memory accesses on page A8-292.

LDR<c> <Rt>, [<Rn>,+/-<Rm>{, <shift>}]{!}
LDR<c> <Rt>, [<Rn>],+/-<Rm>{, <shift>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 P U 0 W 1 Rn Rt imm5 type 0 Rm

if wback && (n == 15 || n == t) then UNPREDICTABLE;
if ArchVersion() < 6 && wback && m == n then UNPREDICTABLE;
Assembler syntax
LDR{<c>}{<q>} <Rt>, [<Rn>, {+/-}<Rm>{, <shift>}] Offset: index==TRUE, wback==FALSE
LDR{<c>}{<q>} <Rt>, [<Rn>, {+/-}<Rm>{, <shift>}]! Pre-indexed: index==TRUE, wback==TRUE
LDR{<c>}{<q>} <Rt>, [<Rn>], {+/-}<Rm>{, <shift>} Post-indexed: index==FALSE, wback==TRUE
where:
<Rt> The destination register. The SP can be used. The PC can be used. If the PC is used, the instruction
branches to the address (data) loaded to the PC. In ARMv5T and above, this branch is an
interworking branch, see Pseudocode details of operations on ARM core registers on page A2-46.
<Rn> The base register. The SP can be used. The PC can be used for offset addressing only.
+/- If + or omitted, the optionally shifted value of <Rm> is added to the base register value (add == TRUE
encoded as U == 1).
If –, the optionally shifted value of <Rm> is subtracted from the base register value (add == FALSE
encoded as U == 0).
<Rm> The offset that is optionally shifted and applied to the value of <Rn> to form the address.
<shift> The shift to apply to the value read from <Rm>. If absent, no shift is applied. Otherwise, see Shifts
applied to a register on page A8-289.
Operation
offset_addr = if add then (R[n] + offset) else (R[n] - offset);
if t == 15 then
LoadWritePC(data);
else
UNPREDICTABLE;
R[t] = data;
Exceptions
Data Abort.
A8.8.68 LDRB (immediate, Thumb)

Load Register Byte (immediate) calculates an address from a base register value and an immediate offset, loads a
byte from memory, zero-extends it to form a 32-bit word, and writes it to a register. It can use offset, post-indexed,
or pre-indexed addressing. For information about memory accesses see Memory accesses on page A8-292.

LDRB<c> <Rt>, [<Rn>{, #<imm5>}]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 1 1 1 imm5 Rn Rt


LDRB<c>.W <Rt>, [<Rn>{, #<imm12>}]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 1 0 0 1 Rn Rt imm12
if Rt == ‘1111’ then SEE PLD;

if Rn == ‘1111’ then SEE LDRB (literal);
if t == 13 then UNPREDICTABLE;

LDRB<c> <Rt>, [<Rn>, #-<imm8>]
LDRB<c> <Rt>, [<Rn>], #+/-<imm8>
LDRB<c> <Rt>, [<Rn>, #+/-<imm8>]!
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 0 0 0 1 Rn Rt 1 P U W imm8
if Rt == ‘1111’ && P == ‘1’ && U == ‘0’ && W == ‘0’ then SEE PLD, PLDW (immediate);
if P == ‘1’ && U == ‘1’ && W == ‘0’ then SEE LDRBT;
index = (P == ‘1’); add = (U == ‘1’); wback = (W == ‘1’);
if t == 13 || (t == 15 && W == ‘1’) || (wback && n == t) then UNPREDICTABLE;
Assembler syntax
LDRB{<c>}{<q>} <Rt>, [<Rn> {, #+/-<imm>}] Offset: index==TRUE, wback==FALSE
LDRB{<c>}{<q>} <Rt>, [<Rn>, #+/-<imm>]! Pre-indexed: index==TRUE, wback==TRUE
LDRB{<c>}{<q>} <Rt>, [<Rn>], #+/-<imm> Post-indexed: index==FALSE, wback==TRUE
where:
<Rt> The destination register.
<Rn> The base register. The SP can be used. For PC use see LDRB (literal) on page A8-421.
as U == 1), or – if it is to be subtracted (add == FALSE, encoded as U == 0). #0 and #-0 generate
Encoding T1 any value in the range 0-31
Encoding T3 any value in the range 0-255.
The pre-UAL syntax LDR<c>B is equivalent to LDRB<c>.
Operation
R[t] = ZeroExtend(MemU[address,1], 32);
Exceptions
Data Abort.
A8.8.69 LDRB (immediate, ARM)

Load Register Byte (immediate) calculates an address from a base register value and an immediate offset, loads a
byte from memory, zero-extends it to form a 32-bit word, and writes it to a register. It can use offset, post-indexed,
or pre-indexed addressing. For information about memory accesses see Memory accesses on page A8-292.

LDRB<c> <Rt>, [<Rn>{, #+/-<imm12>}]
LDRB<c> <Rt>, [<Rn>], #+/-<imm12>
LDRB<c> <Rt>, [<Rn>, #+/-<imm12>]!
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

if P == ‘0’ && W == ‘1’ then SEE LDRBT;
if t == 15 || (wback && n == t) then UNPREDICTABLE;
Assembler syntax
LDRB{<c>}{<q>} <Rt>, [<Rn> {, #+/-<imm>}] Offset: index==TRUE, wback==FALSE
LDRB{<c>}{<q>} <Rt>, [<Rn>, #+/-<imm>]! Pre-indexed: index==TRUE, wback==TRUE
LDRB{<c>}{<q>} <Rt>, [<Rn>], #+/-<imm> Post-indexed: index==FALSE, wback==TRUE
where:
<Rn> The base register. The SP can be used. For PC use see LDRB (literal) on page A8-421.
Operation
Exceptions
Data Abort.
A8.8.70 LDRB (literal)

Load Register Byte (literal) calculates an address from the PC value and an immediate offset, loads a byte from
memory, zero-extends it to form a 32-bit word, and writes it to a register. For information about memory accesses
see Memory accesses on page A8-292.

LDRB<c> <Rt>, <label>
LDRB<c> <Rt>, [PC, #-0] Special case
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 U 0 0 1 1 1 1 1 Rt imm12


LDRB<c> <Rt>, <label>
LDRB<c> <Rt>, [PC, #-0] Special case
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 0 P U 1 W 1 1 1 1 1 Rt imm12

Assembler syntax
LDRB{<c>}{<q>} <Rt>, <label> Normal form
LDRB{<c>}{<q>} <Rt>, [PC, #+/-<imm>] Alternative form
where:
the offset are -4095 to 4095.
If the offset is zero or positive, imm32 is equal to the offset and add == TRUE, encoded as U == 1.
Operation
base = Align(PC,4);
Exceptions
Data Abort.
A8.8.71 LDRB (register)

Load Register Byte (register) calculates an address from a base register value and an offset register value, loads a
byte from memory, zero-extends it to form a 32-bit word, and writes it to a register. The offset register value can
optionally be shifted. For information about memory accesses see Memory accesses on page A8-292.

LDRB<c> <Rt>, [<Rn>, <Rm>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 1 1 1 0 Rm Rn Rt


LDRB<c>.W <Rt>, [<Rn>, <Rm>{, LSL #<imm2>}]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 0 0 0 1 Rn Rt 0 0 0 0 0 0 imm2 Rm

if t == 13 || m IN {13,15} then UNPREDICTABLE;

LDRB<c> <Rt>, [<Rn>,+/-<Rm>{, <shift>}]{!}
LDRB<c> <Rt>, [<Rn>],+/-<Rm>{, <shift>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

if t == 15 || m == 15 then UNPREDICTABLE;
Assembler syntax
LDRB{<c>}{<q>} <Rt>, [<Rn>, +/-<Rm>{, <shift>}] Offset: index==TRUE, wback==FALSE
LDRB{<c>}{<q>} <Rt>, [<Rn>, +/-<Rm>{, <shift>}]! Pre-indexed: index==TRUE, wback==TRUE
LDRB{<c>}{<q>} <Rt>, [<Rn>], +/-<Rm>{, <shift>} Post-indexed: index==FALSE, wback==TRUE
where:
<Rn> The base register. The SP can be used. In the ARM instruction set the PC can be used, for the offset
addressing form of the instruction only. In the Thumb instruction set, the PC cannot be used with
any of these forms of the LDRB instruction.
+/- Is + or omitted if the optionally shifted value of <Rm> is to be added to the base register value
(add == TRUE, encoded as U == 1 in encoding A1), or – if it is to be subtracted (permitted in ARM
instructions only, add == FALSE, encoded as U == 0).
<Rm> Contains the offset that is optionally shifted and applied to the value of <Rn> to form the address.
encoded as imm2 = 0b00, or LSL #<imm> with <imm> = 1, 2, or 3, and <imm> encoded in imm2. For
encoding A1, see Shifts applied to a register on page A8-289.
Operation
R[t] = ZeroExtend(MemU[address,1],32);
Exceptions
Data Abort.
A8.8.72 LDRBT
Load Register Byte Unprivileged loads a byte from memory, zero-extends it to form a 32-bit word, and writes it to
a register. For information about memory accesses see Memory accesses on page A8-292.
The memory access is restricted as if the processor were running in User mode. This makes no difference if the
processor is actually running in User mode.
LDRBT is UNPREDICTABLE in Hyp mode.
The Thumb instruction uses an offset addressing mode, that calculates the address used for the memory access from
a base register value and an immediate offset, and leaves the base register unchanged.
The ARM instruction uses a post-indexed addressing mode, that uses a base register value as the address for the
memory access, and calculates a new address from a base register value and an offset and writes it back to the base
register. The offset can be an immediate value or an optionally-shifted register value.

LDRBT<c> <Rt>, [<Rn>, #<imm8>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 0 0 0 1 Rn Rt 1 1 1 0 imm8

t = UInt(Rt); n = UInt(Rn); postindex = FALSE; add = TRUE;
register_form = FALSE; imm32 = ZeroExtend(imm8, 32);
if t IN {13,15} then UNPREDICTABLE;

LDRBT<c> <Rt>, [<Rn>], #+/-<imm12>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 0 0 U 1 1 1 Rn Rt imm12
t = UInt(Rt); n = UInt(Rn); postindex = TRUE; add = (U == ‘1’);

if t == 15 || n == 15 || n == t then UNPREDICTABLE;

LDRBT<c> <Rt>, [<Rn>],+/-<Rm>{, <shift>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 U 1 1 1 Rn Rt imm5 type 0 Rm
t = UInt(Rt); n = UInt(Rn); m = UInt(Rm); postindex = TRUE; add = (U == ‘1’);

register_form = TRUE; (shift_t, shift_n) = DecodeImmShift(type, imm5);
if t == 15 || n == 15 || n == t || m == 15 then UNPREDICTABLE;
if ArchVersion() < 6 && m == n then UNPREDICTABLE;
Assembler syntax
LDRBT{<c>}{<q>} <Rt>, [<Rn> {, #<imm>}] Offset: Thumb only
LDRBT{<c>}{<q>} <Rt>, [<Rn>] {, #+/-<imm>} Post-indexed: ARM only
LDRBT{<c>}{<q>} <Rt>, [<Rn>], +/-<Rm> {, <shift>} Post-indexed: ARM only
where:
+/- Is + or omitted if <imm> or the optionally shifted value of <Rm> is to be added to the base register value
(add == TRUE, encoded as U == 1 in encodings A1 and A2), or – if it is to be subtracted (permitted
in ARM instructions only, add == FALSE, encoded as U == 0).
<imm> The immediate offset applied to the value of <Rn>. Values are 0-255 for encoding T1, and 0-4095 for
encoding A1. <imm> can be omitted, meaning an offset of 0.
<shift> The shift to apply to the value read from <Rm>. If omitted, no shift is applied. Shifts applied to a
register on page A8-289 describes the shifts and how they are encoded.
The pre-UAL syntax LDR<c>BT is equivalent to LDRBT<c>.
Operation
if CurrentModeIsHyp() then UNPREDICTABLE; // Hyp mode
offset = if register_form then Shift(R[m], shift_t, shift_n, APSR.C) else imm32;
address = if postindex then R[n] else offset_addr;
R[t] = ZeroExtend(MemU_unpriv[address,1],32);
if postindex then R[n] = offset_addr;
Exceptions
Data Abort.
A8.8.73 LDRD (immediate)

Load Register Dual (immediate) calculates an address from a base register value and an immediate offset, loads two
words from memory, and writes them to two registers. It can use offset, post-indexed, or pre-indexed addressing.
For information about memory accesses see Memory accesses on page A8-292.

LDRD<c> <Rt>, <Rt2>, [<Rn>{, #+/-<imm>}]
LDRD<c> <Rt>, <Rt2>, [<Rn>], #+/-<imm>
LDRD<c> <Rt>, <Rt2>, [<Rn>, #+/-<imm>]!
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 0 P U 1 W 1 Rn Rt Rt2 imm8
if P == ‘0’ && W == ‘0’ then SEE “Related encodings”;

if Rn == ‘1111’ then SEE LDRD (literal);
t = UInt(Rt); t2 = UInt(Rt2); n = UInt(Rn); imm32 = ZeroExtend(imm8:’00’, 32);
if wback && (n == t || n == t2) then UNPREDICTABLE;
if t IN {13,15} || t2 IN {13,15} || t == t2 then UNPREDICTABLE;
Encoding A1 ARMv5TE*, ARMv6*, ARMv7

LDRD<c> <Rt>, <Rt2>, [<Rn>{, #+/-<imm8>}]
LDRD<c> <Rt>, <Rt2>, [<Rn>], #+/-<imm8>
LDRD<c> <Rt>, <Rt2>, [<Rn>, #+/-<imm8>]!
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 P U 1 W 0 Rn Rt imm4H 1 1 0 1 imm4L
if Rn == ‘1111’ then SEE LDRD (literal);

if Rt<0> == ‘1’ then UNPREDICTABLE;
t = UInt(Rt); t2 = t+1; n = UInt(Rn); imm32 = ZeroExtend(imm4H:imm4L, 32);
if P == ‘0’ && W == ‘1’ then UNPREDICTABLE;
if t2 == 15 then UNPREDICTABLE;
Related encodings See Load/store dual, load/store exclusive, table branch on page A6-236.
Assembler syntax
LDRD{<c>}{<q>} <Rt>, <Rt2>, [<Rn> {, #+/-<imm>}] Offset: index==TRUE, wback==FALSE
LDRD{<c>}{<q>} <Rt>, <Rt2>, [<Rn>, #+/-<imm>]! Pre-indexed: index==TRUE, wback==TRUE
LDRD{<c>}{<q>} <Rt>, <Rt2>, [<Rn>], #+/-<imm> Post-indexed: index==FALSE, wback==TRUE
where:
<Rt> The first destination register. For an ARM instruction, <Rt> must be even-numbered and not R14.
<Rt2> The second destination register. For an ARM instruction, <Rt2> must be <R(t+1)>.
<Rn> The base register. The SP can be used. For PC use see LDRD (literal) on page A8-429.
Encoding A1 Any value in the range 0-255.
The pre-UAL syntax LDR<c>D is equivalent to LDRD<c>.
Operation
if HaveLPAE() && address<2:0> == ‘000’ then
data = MemA[address,8];
if BigEndian() then
R[t] = data<63:32>;
R[t2] = data<31:0>;
else
R[t] = data<31:0>;
R[t2] = data<63:32>;
else
R[t] = MemA[address,4];
R[t2] = MemA[address+4,4];
Exceptions
Data Abort.
A8.8.74 LDRD (literal)

Load Register Dual (literal) calculates an address from the PC value and an immediate offset, loads two words from
memory, and writes them to two registers. For information about memory accesses see Memory accesses on
page A8-292.

LDRD<c> <Rt>, <Rt2>, <label>
LDRD<c> <Rt>, <Rt2>, [PC, #-0] Special case
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 0 P U 1 W 1 1 1 1 1 Rt Rt2 imm8

t = UInt(Rt); t2 = UInt(Rt2);
imm32 = ZeroExtend(imm8:’00’, 32); add = (U == ‘1’);
if t IN {13,15} || t2 IN {13,15} || t == t2 then UNPREDICTABLE;
if W == ‘1’ then UNPREDICTABLE;

LDRD<c> <Rt>, <Rt2>, <label>
LDRD<c> <Rt>, <Rt2>, [PC, #-0] Special case
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 (1) U 1 (0) 0 1 1 1 1 Rt imm4H 1 1 0 1 imm4L

t = UInt(Rt); t2 = t+1; imm32 = ZeroExtend(imm4H:imm4L, 32); add = (U == ‘1’);
Assembler syntax
LDRD{<c>}{<q>} <Rt>, <Rt2>, <label> Normal form
LDRD{<c>}{<q>} <Rt>, <Rt2>, [PC, #+/-<imm>] Alternative form
where:
the offset are:
Encoding T1 Multiples of 4 in the range -1020 to 1020.
Encoding A1 Any value in the range -255 to 255.
If the offset is zero or positive, imm32 is equal to the offset and add == TRUE, encoded as U == 1.
Operation
address = if add then (Align(PC,4) + imm32) else (Align(PC,4) - imm32);
if BigEndian() then
R[t] = data<63:32>;
R[t2] = data<31:0>;
else
R[t] = data<31:0>;
R[t2] = data<63:32>;
else
Exceptions
Data Abort.
A8.8.75 LDRD (register)

Load Register Dual (register) calculates an address from a base register value and a register offset, loads two words
from memory, and writes them to two registers. It can use offset, post-indexed, or pre-indexed addressing. For
information about memory accesses see Memory accesses on page A8-292.

LDRD<c> <Rt>, <Rt2>, [<Rn>,+/-<Rm>]{!}
LDRD<c> <Rt>, <Rt2>, [<Rn>],+/-<Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 P U 0 W 0 Rn Rt (0) (0) (0) (0) 1 1 0 1 Rm

t = UInt(Rt); t2 = t+1; n = UInt(Rn); m = UInt(Rm);
if t2 == 15 || m == 15 || m == t || m == t2 then UNPREDICTABLE;
if wback && (n == 15 || n == t || n == t2) then UNPREDICTABLE;
Assembler syntax
LDRD{<c>}{<q>} <Rt>, <Rt2>, [<Rn>, +/-<Rm>] Offset: index==TRUE, wback==FALSE
LDRD{<c>}{<q>} <Rt>, <Rt2>, [<Rn>, +/-<Rm>]! Pre-indexed: index==TRUE, wback==TRUE
LDRD{<c>}{<q>} <Rt>, <Rt2>, [<Rn>], +/-<Rm> Post-indexed: index==FALSE, wback==TRUE
where:
<Rt> The first destination register. This register must be even-numbered and not R14.
<Rt2> The second destination register. This register must be <R(t+1)>.
<Rn> The base register. The SP can be used. The PC can be used, for offset addressing only.
+/- Is + or omitted if the value of <Rm> is to be added to the base register value (add == TRUE, encoded as
U == 1), or – if it is to be subtracted (add == FALSE, encoded as U == 0).
<Rm> Contains the offset that is applied to the value of <Rn> to form the address.
Operation
offset_addr = if add then (R[n] + R[m]) else (R[n] - R[m]);
if BigEndian() then
R[t] = data<63:32>;
R[t2] = data<31:0>;
else
R[t] = data<31:0>;
R[t2] = data<63:32>;
else
Exceptions
Data Abort.
A8.8.76 LDREX
Load Register Exclusive calculates an address from a base register value and an immediate offset, loads a word from
memory, writes it to a register and:
• if the address has the Shared Memory attribute, marks the physical address as exclusive access for the
executing processor in a global monitor
• causes the executing processor to indicate an active exclusive access in the local monitor.
For more information about support for shared memory see Synchronization and semaphores on page A3-112. For

LDREX<c> <Rt>, [<Rn>{, #<imm>}]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 0 0 0 1 0 1 Rn Rt (1) (1) (1) (1) imm8

if t IN {13,15} || n == 15 then UNPREDICTABLE;
Encoding A1 ARMv6*, ARMv7

LDREX<c> <Rt>, [<Rn>]
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 1 0 0 1 Rn Rt (1) (1) (1) (1) 1 0 0 1 (1) (1) (1) (1)
t = UInt(Rt); n = UInt(Rn); imm32 = Zeros(32); // Zero offset

if t == 15 || n == 15 then UNPREDICTABLE;
Assembler syntax
LDREX{<c>}{<q>} <Rt>, [<Rn> {, #<imm>}]
where:
<imm> The immediate offset added to the value of <Rn> to form the address. <imm> can be omitted, meaning
an offset of 0. Values are:
Encoding T1 multiples of 4 in the range 0-1020
Encoding A1 omitted or 0.
Operation
address = R[n] + imm32;
SetExclusiveMonitors(address,4);
Exceptions
Data Abort.
A8.8.77 LDREXB
Load Register Exclusive Byte derives an address from a base register value, loads a byte from memory, zero-extends
it to form a 32-bit word, writes it to a register and:
Encoding T1 ARMv7
LDREXB<c> <Rt>, [<Rn>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 0 0 1 1 0 1 Rn Rt (1) (1) (1) (1) 0 1 0 0 (1) (1) (1) (1)

LDREXB<c> <Rt>, [<Rn>]
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 1 1 0 1 Rn Rt (1) (1) (1) (1) 1 0 0 1 (1) (1) (1) (1)
Assembler syntax
LDREXB{<c>}{<q>} <Rt>, [<Rn>]
where:
Operation
address = R[n];
R[t] = ZeroExtend(MemA[address,1], 32);
Exceptions
Data Abort.
A8.8.78 LDREXD
Load Register Exclusive Doubleword derives an address from a base register value, loads a 64-bit doubleword from
memory, writes it to two registers and:
Encoding T1 ARMv7
LDREXD<c> <Rt>, <Rt2>, [<Rn>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 0 0 1 1 0 1 Rn Rt Rt2 0 1 1 1 (1) (1) (1) (1)
t = UInt(Rt); t2 = UInt(Rt2); n = UInt(Rn);

if t IN {13,15} || t2 IN {13,15} || t == t2 || n == 15 then UNPREDICTABLE;

LDREXD<c> <Rt>, <Rt2>, [<Rn>]
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 1 0 1 1 Rn Rt (1) (1) (1) (1) 1 0 0 1 (1) (1) (1) (1)
t = UInt(Rt); t2 = t+1; n = UInt(Rn);

if Rt<0> == ‘1’ || Rt == ‘1110’ || n == 15 then UNPREDICTABLE;
Assembler syntax
LDREXD{<c>}{<q>} <Rt>, <Rt2>, [<Rn>]
where:
Operation
address = R[n];
// LDREXD requires doubleword-aligned address
if address<2:0> != ‘000’ then AlignmentFault(address, FALSE)
// See the description of Single-copy atomicity for details of whether
// the two loads are 64-bit single-copy atomic.
Exceptions
Data Abort.
A8.8.79 LDREXH
Load Register Exclusive Halfword derives an address from a base register value, loads a halfword from memory,
zero-extends it to form a 32-bit word, writes it to a register and:
Encoding T1 ARMv7
LDREXH<c> <Rt>, [<Rn>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 0 0 1 1 0 1 Rn Rt (1) (1) (1) (1) 0 1 0 1 (1) (1) (1) (1)

LDREXH<c> <Rt>, [<Rn>]
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 1 1 1 1 Rn Rt (1) (1) (1) (1) 1 0 0 1 (1) (1) (1) (1)
Assembler syntax
LDREXH{<c>}{<q>} <Rt>, [<Rn>]
where:
Operation
address = R[n];
R[t] = ZeroExtend(MemA[address,2], 32);
Exceptions
Data Abort.
A8.8.80 LDRH (immediate, Thumb)

Load Register Halfword (immediate) calculates an address from a base register value and an immediate offset, loads
a halfword from memory, zero-extends it to form a 32-bit word, and writes it to a register. It can use offset,
post-indexed, or pre-indexed addressing. For information about memory accesses see Memory accesses on
page A8-292.

LDRH<c> <Rt>, [<Rn>{, #<imm>}]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 0 0 1 imm5 Rn Rt


LDRH<c>.W <Rt>, [<Rn>{, #<imm12>}]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 1 0 1 1 Rn Rt imm12
if Rt == ‘1111’ then SEE PLD (immediate);

if Rn == ‘1111’ then SEE LDRH (literal);

LDRH<c> <Rt>, [<Rn>, #-<imm8>]
LDRH<c> <Rt>, [<Rn>], #+/-<imm8>
LDRH<c> <Rt>, [<Rn>, #+/-<imm8>]!
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 0 0 1 1 Rn Rt 1 P U W imm8

if Rt == ‘1111’ && P == ‘1’ && U == ‘0’ && W == ‘0’ then SEE PLD, PLDW (immediate);
if P == ‘1’ && U == ‘1’ && W == ‘0’ then SEE LDRHT;
Assembler syntax
LDRH{<c>}{<q>} <Rt>, [<Rn> {, #+/-<imm>}] Offset: index==TRUE, wback==FALSE
LDRH{<c>}{<q>} <Rt>, [<Rn>, #+/-<imm>]! Pre-indexed: index==TRUE, wback==TRUE
LDRH{<c>}{<q>} <Rt>, [<Rn>], #+/-<imm> Post-indexed: index==FALSE, wback==TRUE
where:
<Rn> The base register. The SP can be used. For PC use see LDRH (literal) on page A8-445.
+/- Is + or omitted to indicate that the immediate offset is added to the base register value (add == TRUE),
or – to indicate that the offset is to be subtracted (add == FALSE). Different instructions are generated
for #0 and #-0.
The pre-UAL syntax LDR<c>H is equivalent to LDRH<c>.
Operation
if UnalignedSupport() || address<0> == ‘0’ then
R[t] = ZeroExtend(data, 32);
Exceptions
Data Abort.
A8.8.81 LDRH (immediate, ARM)

Load Register Halfword (immediate) calculates an address from a base register value and an immediate offset, loads
a halfword from memory, zero-extends it to form a 32-bit word, and writes it to a register. It can use offset,
page A8-292.

LDRH<c> <Rt>, [<Rn>{, #+/-<imm8>}]
LDRH<c> <Rt>, [<Rn>], #+/-<imm8>
LDRH<c> <Rt>, [<Rn>, #+/-<imm8>]!
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

if P == ‘0’ && W == ‘1’ then SEE LDRHT;
t = UInt(Rt); n = UInt(Rn); imm32 = ZeroExtend(imm4H:imm4L, 32);
Assembler syntax
LDRH{<c>}{<q>} <Rt>, [<Rn> {, #+/-<imm>}] Offset: index==TRUE, wback==FALSE
LDRH{<c>}{<q>} <Rt>, [<Rn>, #+/-<imm>]! Pre-indexed: index==TRUE, wback==TRUE
LDRH{<c>}{<q>} <Rt>, [<Rn>], #+/-<imm> Post-indexed: index==FALSE, wback==TRUE
where:
<Rn> The base register. The SP can be used. For PC use see LDRH (literal) on page A8-445.
for #0 and #-0.
Operation
Exceptions
Data Abort.
A8.8.82 LDRH (literal)

Load Register Halfword (literal) calculates an address from the PC value and an immediate offset, loads a halfword
from memory, zero-extends it to form a 32-bit word, and writes it to a register. For information about memory
accesses see Memory accesses on page A8-292.

LDRH<c> <Rt>, <label>
LDRH<c> <Rt>, [PC, #-0] Special case
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 U 0 1 1 1 1 1 1 Rt imm12
if Rt == ‘1111’ then SEE PLD (literal);


LDRH<c> <Rt>, <label>
LDRH<c> <Rt>, [PC, #-0] Special case
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 P U 1 W 1 1 1 1 1 Rt imm4H 1 0 1 1 imm4L
if P == ‘0’ && W == ‘1’ then SEE LDHRT;

t = UInt(Rt); imm32 = ZeroExtend(imm4H:imm4L, 32); add = (U == ‘1’);
Assembler syntax
LDRH{<c>}{<q>} <Rt>, <label> Normal form
LDRH{<c>}{<q>} <Rt>, [PC, #+/-<imm>] Alternative form
where:
the offset are:
Encoding T1 any value in the range -4095 to 4095
Encoding A1 any value in the range -255 to 255.
If the offset is zero or positive, imm32 is equal to the offset and add == TRUE.
If the offset is negative, imm32 is equal to minus the offset and add == FALSE.
Operation
base = Align(PC,4);
Exceptions
Data Abort.
A8.8.83 LDRH (register)

Load Register Halfword (register) calculates an address from a base register value and an offset register value, loads
a halfword from memory, zero-extends it to form a 32-bit word, and writes it to a register. The offset register value
can be shifted left by 0, 1, 2, or 3 bits. For information about memory accesses see Memory accesses on
page A8-292.

LDRH<c> <Rt>, [<Rn>, <Rm>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 1 1 0 1 Rm Rn Rt


LDRH<c>.W <Rt>, [<Rn>, <Rm>{, LSL #<imm2>}]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 0 0 1 1 Rn Rt 0 0 0 0 0 0 imm2 Rm

if Rt == ‘1111’ then SEE PLDW (register);

LDRH<c> <Rt>, [<Rn>,+/-<Rm>]{!}
LDRH<c> <Rt>, [<Rn>],+/-<Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 P U 0 W 1 Rn Rt (0) (0) (0) (0) 1 0 1 1 Rm
if P == ‘0’ && W == ‘1’ then SEE LDRHT;

Modified operation in ThumbEE See LDRH (register) on page A9-1119
Assembler syntax
LDRH{<c>}{<q>} <Rt>, [<Rn>, <Rm>{, LSL #<imm>}] Offset: index==TRUE, wback==FALSE
LDRH{<c>}{<q>} <Rt>, [<Rn>, +/-<Rm>] Offset: index==TRUE, wback==FALSE
LDRH{<c>}{<q>} <Rt>, [<Rn>, +/-<Rm>]! Pre-indexed: index==TRUE, wback==TRUE
LDRH{<c>}{<q>} <Rt>, [<Rn>], +/-<Rm> Post-indexed: index==FALSE, wback==TRUE
where:
<Rn> The base register. The SP can be used. In the ARM instruction set the PC can be used, for offset
addressing forms of the instruction only. In the Thumb instruction set, the PC cannot be used for any
of these forms of the LDRH instruction.
(add == TRUE), or – if it is to be subtracted (permitted in ARM instructions only, add == FALSE).
<Rm> Contains the offset that is optionally left shifted and added to the value of <Rn> to form the address.
<imm> If present, the size of the left shift to apply to the value from <Rm>, in the range 1-3. Only encoding
T2 is permitted, and <imm> is encoded in imm2.
If absent, no shift is specified and all encodings are permitted. In encoding T2, imm2 is encoded as
0b00.
Operation
Exceptions
Data Abort.
A8.8.84 LDRHT
Load Register Halfword Unprivileged loads a halfword from memory, zero-extends it to form a 32-bit word, and
writes it to a register. For information about memory accesses see Memory accesses on page A8-292.
LDRHT is UNPREDICTABLE in Hyp mode.
register. The offset can be an immediate value or a register value.

LDRHT<c> <Rt>, [<Rn>, #<imm8>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 0 0 1 1 Rn Rt 1 1 1 0 imm8


LDRHT<c> <Rt>, [<Rn>] {, #+/-<imm8>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 0 U 1 1 1 Rn Rt imm4H 1 0 1 1 imm4L

register_form = FALSE; imm32 = ZeroExtend(imm4H:imm4L, 32);

LDRHT<c> <Rt>, [<Rn>], +/-<Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 0 U 0 1 1 Rn Rt (0) (0) (0) (0) 1 0 1 1 Rm

register_form = TRUE;
Assembler syntax
LDRHT{<c>}{<q>} <Rt>, [<Rn> {, #<imm>}] Offset: Thumb only
LDRHT{<c>}{<q>} <Rt>, [<Rn>] {, #+/-<imm>} Post-indexed: ARM only
LDRHT{<c>}{<q>} <Rt>, [<Rn>], +/-<Rm> Post-indexed: ARM only
where:
+/- Is + or omitted if <imm> or the optionally shifted value of <Rm> is to be added to the base register
value.Encoded as add = TRUE.
Is – if <imm> or the optionally shifted value of <Rm> is to be subtracted from the base register value.
This is permitted in ARM instructions only, and is encoded as add = FALSE.
<imm> The immediate offset applied to the value of <Rn>. Any value in the range 0-255 is permitted. <imm>
can be omitted, meaning an offset of 0.
Operation
offset = if register_form then R[m] else imm32;
data = MemU_unpriv[address,2];
Exceptions
Data Abort.
A8.8.85 LDRSB (immediate)

Load Register Signed Byte (immediate) calculates an address from a base register value and an immediate offset,
loads a byte from memory, sign-extends it to form a 32-bit word, and writes it to a register. It can use offset,
page A8-292.

LDRSB<c> <Rt>, [<Rn>, #<imm12>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 1 1 0 0 1 Rn Rt imm12
if Rt == ‘1111’ then SEE PLI;

if Rn == ‘1111’ then SEE LDRSB (literal);

LDRSB<c> <Rt>, [<Rn>, #-<imm8>]
LDRSB<c> <Rt>, [<Rn>], #+/-<imm8>
LDRSB<c> <Rt>, [<Rn>, #+/-<imm8>]!
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 1 0 0 0 1 Rn Rt 1 P U W imm8
if Rt == ‘1111’ && P == ‘1’ && U == ‘0’ && W == ‘0’ then SEE PLI;
if P == ‘1’ && U == ‘1’ && W == ‘0’ then SEE LDRSBT;

LDRSB<c> <Rt>, [<Rn>{, #+/-<imm8>}]
LDRSB<c> <Rt>, [<Rn>], #+/-<imm8>
LDRSB<c> <Rt>, [<Rn>, #+/-<imm8>]!
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

if P == ‘0’ && W == ‘1’ then SEE LDRSBT;
Assembler syntax
LDRSB{<c>}{<q>} <Rt>, [<Rn> {, #+/-<imm>}] Offset: index==TRUE, wback==FALSE
LDRSB{<c>}{<q>} <Rt>, [<Rn>, #+/-<imm>]! Pre-indexed: index==TRUE, wback==TRUE
LDRSB{<c>}{<q>} <Rt>, [<Rn>], #+/-<imm> Post-indexed: index==FALSE, wback==TRUE
where:
<Rn> The base register. The SP can be used. For PC use see LDRSB (literal) on page A8-453.
for #0 and #-0.
Encoding T2 or A1 any value in the range0-255.
The pre-UAL syntax LDR<c>SB is equivalent to LDRSB<c>.
Operation
R[t] = SignExtend(MemU[address,1], 32);
Exceptions
Data Abort.
A8.8.86 LDRSB (literal)

Load Register Signed Byte (literal) calculates an address from the PC value and an immediate offset, loads a byte
from memory, sign-extends it to form a 32-bit word, and writes it to a register. For information about memory

LDRSB<c> <Rt>, <label>
LDRSB<c> <Rt>, [PC, #-0] Special case
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 1 U 0 0 1 1 1 1 1 Rt imm12


LDRSB<c> <Rt>, <label>
LDRSB<c> <Rt>, [PC, #-0] Special case
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Assembler syntax
LDRSB{<c>}{<q>} <Rt>, <label> Normal form
LDRSB{<c>}{<q>} <Rt>, [PC, #+/-<imm>] Alternative form
where:
the offset are:
Operation
base = Align(PC,4);
Exceptions
Data Abort.
A8.8.87 LDRSB (register)

Load Register Signed Byte (register) calculates an address from a base register value and an offset register value,
loads a byte from memory, sign-extends it to form a 32-bit word, and writes it to a register. The offset register value
can be shifted left by 0, 1, 2, or 3 bits. For information about memory accesses see Memory accesses on
page A8-292.

LDRSB<c> <Rt>, [<Rn>, <Rm>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 1 0 1 1 Rm Rn Rt


LDRSB<c>.W <Rt>, [<Rn>, <Rm>{, LSL #<imm2>}]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 1 0 0 0 1 Rn Rt 0 0 0 0 0 0 imm2 Rm


LDRSB<c> <Rt>, [<Rn>,+/-<Rm>]{!}
LDRSB<c> <Rt>, [<Rn>],+/-<Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 P U 0 W 1 Rn Rt (0) (0) (0) (0) 1 1 0 1 Rm

Assembler syntax
LDRSB{<c>}{<q>} <Rt>, [<Rn>, <Rm>{, LSL #<imm>}] Offset: index==TRUE, wback==FALSE
LDRSB{<c>}{<q>} <Rt>, [<Rn>, +/-<Rm>] Offset: index==TRUE, wback==FALSE
LDRSB{<c>}{<q>} <Rt>, [<Rn>, +/-<Rm>]! Pre-indexed: index==TRUE, wback==TRUE
LDRSB{<c>}{<q>} <Rt>, [<Rn>], +/-<Rm> Post-indexed: index==FALSE, wback==TRUE
where:
of these forms of the LDRSB instruction.
0b00.
Operation
Exceptions
Data Abort.
A8.8.88 LDRSBT
Load Register Signed Byte Unprivileged loads a byte from memory, sign-extends it to form a 32-bit word, and
writes it to a register. For information about memory accesses see Memory accesses on page A8-292.
LDRSBT is UNPREDICTABLE in Hyp mode.

LDRSBT<c> <Rt>, [<Rn>, #<imm8>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 1 0 0 0 1 Rn Rt 1 1 1 0 imm8


LDRSBT<c> <Rt>, [<Rn>] {, #+/-<imm8>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0


LDRSBT<c> <Rt>, [<Rn>], +/-<Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 0 U 0 1 1 Rn Rt (0) (0) (0) (0) 1 1 0 1 Rm

Assembler syntax
LDRSBT{<c>}{<q>} <Rt>, [<Rn> {, #<imm>}] Offset: Thumb only
LDRSBT{<c>}{<q>} <Rt>, [<Rn>] {, #+/-<imm>} Post-indexed: ARM only
LDRSBT{<c>}{<q>} <Rt>, [<Rn>], +/-<Rm> Post-indexed: ARM only
where:
Operation
R[t] = SignExtend(MemU_unpriv[address,1], 32);
Exceptions
Data Abort.
A8.8.89 LDRSH (immediate)

Load Register Signed Halfword (immediate) calculates an address from a base register value and an immediate
offset, loads a halfword from memory, sign-extends it to form a 32-bit word, and writes it to a register. It can use
offset, post-indexed, or pre-indexed addressing. For information about memory accesses see Memory accesses on
page A8-292.

LDRSH<c> <Rt>, [<Rn>, #<imm12>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 1 1 0 1 1 Rn Rt imm12
if Rn == ‘1111’ then SEE LDRSH (literal);

if Rt == ‘1111’ then SEE “Related instructions”;

LDRSH<c> <Rt>, [<Rn>, #-<imm8>]
LDRSH<c> <Rt>, [<Rn>], #+/-<imm8>
LDRSH<c> <Rt>, [<Rn>, #+/-<imm8>]!
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 1 0 0 1 1 Rn Rt 1 P U W imm8

if Rt == ‘1111’ && P == ‘1’ && U == ‘0’ && W == ‘0’ then SEE “Related instructions”;
if P == ‘1’ && U == ‘1’ && W == ‘0’ then SEE LDRSHT;

LDRSH<c> <Rt>, [<Rn>{, #+/-<imm8>}]
LDRSH<c> <Rt>, [<Rn>], #+/-<imm8>
LDRSH<c> <Rt>, [<Rn>, #+/-<imm8>]!
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

if P == ‘0’ && W == ‘1’ then SEE LDRSHT;
Related instructions See Load halfword, memory hints on page A6-238
Assembler syntax
LDRSH{<c>}{<q>} <Rt>, [<Rn> {, #+/-<imm>}] Offset: index==TRUE, wback==FALSE
LDRSH{<c>}{<q>} <Rt>, [<Rn>, #+/-<imm>]! Pre-indexed: index==TRUE, wback==TRUE
LDRSH{<c>}{<q>} <Rt>, [<Rn>], #+/-<imm> Post-indexed: index==FALSE, wback==TRUE
where:
<Rn> The base register. The SP can be used. For PC use see LDRSH (literal) on page A8-461.
for #0 and #-0.
<imm> The immediate offset used for forming the address, Values are 0-4095 for encoding T1, and 0-255
for encoding T2 or A1. For the offset syntax, <imm> can be omitted, meaning an offset of 0.
The pre-UAL syntax LDR<c>SH is equivalent to LDRSH<c>.
Operation
R[t] = SignExtend(data, 32);
Exceptions
Data Abort.
A8.8.90 LDRSH (literal)

Load Register Signed Halfword (literal) calculates an address from the PC value and an immediate offset, loads a
halfword from memory, sign-extends it to form a 32-bit word, and writes it to a register. For information about
memory accesses see Memory accesses on page A8-292.

LDRSH<c> <Rt>, <label>
LDRSH<c> <Rt>, [PC, #-0] Special case
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 1 U 0 1 1 1 1 1 1 Rt imm12


LDRSH<c> <Rt>, <label>
LDRSH<c> <Rt>, [PC, #-0] Special case
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Assembler syntax
LDRSH{<c>}{<q>} <Rt>, <label> Normal form
LDRSH{<c>}{<q>} <Rt>, [PC, #+/-<imm>] Alternative form
where:
the offset are:
Operation
base = Align(PC,4);
Exceptions
Data Abort.
A8.8.91 LDRSH (register)

Load Register Signed Halfword (register) calculates an address from a base register value and an offset register
value, loads a halfword from memory, sign-extends it to form a 32-bit word, and writes it to a register. The offset
register value can be shifted left by 0, 1, 2, or 3 bits. For information about memory accesses see Memory accesses
on page A8-292.

LDRSH<c> <Rt>, [<Rn>, <Rm>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 1 1 1 1 Rm Rn Rt


LDRSH<c>.W <Rt>, [<Rn>, <Rm>{, LSL #<imm2>}]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 1 0 0 1 1 Rn Rt 0 0 0 0 0 0 imm2 Rm


LDRSH<c> <Rt>, [<Rn>,+/-<Rm>]{!}
LDRSH<c> <Rt>, [<Rn>],+/-<Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 P U 0 W 1 Rn Rt (0) (0) (0) (0) 1 1 1 1 Rm


Modified operation in ThumbEE See LDRSH (register) on page A9-1120
Assembler syntax
LDRSH{<c>}{<q>} <Rt>, [<Rn>, <Rm>{, LSL #<imm>}] Offset: index==TRUE, wback==FALSE
LDRSH{<c>}{<q>} <Rt>, [<Rn>, +/-<Rm>] Offset: index==TRUE, wback==FALSE
LDRSH{<c>}{<q>} <Rt>, [<Rn>, +/-<Rm>]! Pre-indexed: index==TRUE, wback==TRUE
LDRSH{<c>}{<q>} <Rt>, [<Rn>], +/-<Rm> Post-indexed: index==FALSE, wback==TRUE
where:
of these forms of the LDRSH instruction.
0b00.
Operation
Exceptions
Data Abort.
A8.8.92 LDRSHT
Load Register Signed Halfword Unprivileged loads a halfword from memory, sign-extends it to form a 32-bit word,
and writes it to a register. For information about memory accesses see Memory accesses on page A8-292.
LDRSHT is UNPREDICTABLE in Hyp mode.

LDRSHT<c> <Rt>, [<Rn>, #<imm8>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 1 0 0 1 1 Rn Rt 1 1 1 0 imm8


LDRSHT<c> <Rt>, [<Rn>] {, #+/-<imm8>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0


LDRSHT<c> <Rt>, [<Rn>], +/-<Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 0 U 0 1 1 Rn Rt (0) (0) (0) (0) 1 1 1 1 Rm

Assembler syntax
LDRSHT{<c>}{<q>} <Rt>, [<Rn> {, #<imm>}] Offset: Thumb only
LDRSHT{<c>}{<q>} <Rt>, [<Rn>] {, #+/-<imm>} Post-indexed: ARM only
LDRSHT{<c>}{<q>} <Rt>, [<Rn>], +/-<Rm> Post-indexed: ARM only
where:
Operation
Exceptions
Data Abort.
A8.8.93 LDRT
Load Register Unprivileged loads a word from memory, and writes it to a register. For information about memory
LDRT is UNPREDICTABLE in Hyp mode.

LDRT<c> <Rt>, [<Rn>, #<imm8>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 0 1 0 1 Rn Rt 1 1 1 0 imm8


LDRT<c> <Rt>, [<Rn>] {, #+/-<imm12>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 0 0 U 0 1 1 Rn Rt imm12


LDRT<c> <Rt>, [<Rn>],+/-<Rm>{, <shift>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Assembler syntax
LDRT{<c>}{<q>} <Rt>, [<Rn> {, #<imm>}] Offset: Thumb only
LDRT{<c>}{<q>} <Rt>, [<Rn>] {, #+/-<imm>} Post-indexed: ARM only
LDRT{<c>}{<q>} <Rt>, [<Rn>], +/-<Rm> {, <shift>} Post-indexed: ARM only
where:
The pre-UAL syntax LDR<c>T is equivalent to LDRT<c>.
Operation
if UnalignedSupport() || address<1:0> == ‘00’ then
R[t] = data;
else
Exceptions
Data Abort.
A8.8.94 LEAVEX
LEAVEX causes a change from ThumbEE to Thumb state, or has no effect in Thumb state. For details see ENTERX,
LEAVEX on page A9-1116.
A8.8.95 LSL (immediate)

Logical Shift Left (immediate) shifts a register value left by an immediate number of bits, shifting in zeros, and

LSLS <Rd>, <Rm>, #<imm5> Outside IT block.
LSL<c> <Rd>, <Rm>, #<imm5> Inside IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 0 imm5 Rm Rd
if imm5 == ‘00000’ then SEE MOV (register);


LSL{S}<c>.W <Rd>, <Rm>, #<imm5>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 1 0 0 1 0 S 1 1 1 1 (0) imm3 Rd imm2 0 0 Rm
if (imm3:imm2) == ‘00000’ then SEE MOV (register);


LSL{S}<c> <Rd>, <Rm>, #<imm5>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 1 0 1 S (0) (0) (0) (0) Rd imm5 0 0 0 Rm
if imm5 == ‘00000’ then SEE MOV (register);
Assembler syntax
LSL{S}{<c>}{<q>} {<Rd>,} <Rm>, #<imm5>
where:

Note
<Rm> The first operand register. The PC can be used in ARM instructions, but ARM deprecates this use
of the PC.
<imm5> The shift amount, in the range 1 to 31. See Shifts applied to a register on page A8-289.
Operation
(result, carry) = Shift_C(R[m], SRType_LSL, shift_n, APSR.C);
else
R[d] = result;
if setflags then
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.96 LSL (register)

Logical Shift Left (register) shifts a register value left by a variable number of bits, shifting in zeros, and writes the
result to the destination register. The variable number of bits is read from the bottom byte of a register. It can

LSLS <Rdn>, <Rm> Outside IT block.
LSL<c> <Rdn>, <Rm> Inside IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 0 0 0 0 1 0 Rm Rdn

LSL{S}<c>.W <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 0 0 0 S Rn 1 1 1 1 Rd 0 0 0 0 Rm


LSL{S}<c> <Rd>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 1 0 1 S (0) (0) (0) (0) Rd Rm 0 0 0 1 Rn

Assembler syntax
LSL{S}{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
Operation
(result, carry) = Shift_C(R[n], SRType_LSL, shift_n, APSR.C);
R[d] = result;
if setflags then
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.97 LSR (immediate)

Logical Shift Right (immediate) shifts a register value right by an immediate number of bits, shifting in zeros, and

LSRS <Rd>, <Rm>, #<imm> Outside IT block.
LSR<c> <Rd>, <Rm>, #<imm> Inside IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 1 imm5 Rm Rd


LSR{S}<c>.W <Rd>, <Rm>, #<imm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 1 0 0 1 0 S 1 1 1 1 (0) imm3 Rd imm2 0 1 Rm


LSR{S}<c> <Rd>, <Rm>, #<imm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 1 0 1 S (0) (0) (0) (0) Rd imm5 0 1 0 Rm
Assembler syntax
LSR{S}{<c>}{<q>} {<Rd>,} <Rm>, #<imm>
where:

Note
of the PC.
Operation
(result, carry) = Shift_C(R[m], SRType_LSR, shift_n, APSR.C);
else
R[d] = result;
if setflags then
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.98 LSR (register)

Logical Shift Right (register) shifts a register value right by a variable number of bits, shifting in zeros, and writes
the result to the destination register. The variable number of bits is read from the bottom byte of a register. It can

LSRS <Rdn>, <Rm> Outside IT block.
LSR<c> <Rdn>, <Rm> Inside IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 0 0 0 0 1 1 Rm Rdn

LSR{S}<c>.W <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 0 0 1 S Rn 1 1 1 1 Rd 0 0 0 0 Rm


LSR{S}<c> <Rd>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 1 0 1 S (0) (0) (0) (0) Rd Rm 0 0 1 1 Rn

Assembler syntax
LSR{S}{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
Operation
(result, carry) = Shift_C(R[n], SRType_LSR, shift_n, APSR.C);
R[d] = result;
if setflags then
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.99 MCR, MCR2

Move to Coprocessor from ARM core register passes the value of an ARM core register to a coprocessor. If no
are free for use by the coprocessor instruction set designer. These are the opc1, opc2, CRn, and CRm fields. However,
coprocessors CP8-CP15 are reserved for use by ARM, and this manual defines the valid MCR and MCR2 instructions
when coproc is in the range p8-p15. For more information see Coprocessor support on page A2-93 and General
behavior of system control registers on page B5-1768.
In an implementation that includes the Virtualization Extensions, MCR accesses to system control registers can be
trapped to Hyp mode, meaning that an attempt to execute an MCR instruction in a Non-secure mode other than Hyp
mode, that would be permitted in the absence of the Hyp trap controls, generates a Hyp Trap exception. For more
information, see Traps to the hypervisor on page B1-1246.
Note
Because of the range of possible traps to Hyp mode, the MCR pseudocode does not show these possible traps.

MCR<c> <coproc>, <opc1>, <Rt>, <CRn>, <CRm>{, <opc2>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 0 opc1 0 CRn Rt coproc opc2 1 CRm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 1 0 opc1 0 CRn Rt coproc opc2 1 CRm
For the case when cond is 0b1111, see T2/A2 encoding.

t = UInt(Rt); cp = UInt(coproc);
if t == 15 || (t == 13 && (CurrentInstrSet() != InstrSet_ARM)) then UNPREDICTABLE;

MCR2<c> <coproc>, <opc1>, <Rt>, <CRn>, <CRm>{, <opc2>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

if t == 15 || (t == 13 && (CurrentInstrSet() != InstrSet_ARM)) then UNPREDICTABLE;
Advanced SIMD and See 8, 16, and 32-bit transfer between ARM core and extension registers on
Floating-point page A7-276
Assembler syntax
MCR{2}{<c>}{<q>} <coproc>, {#}<opc1>, <Rt>, <CRn>, <CRm>{, {#}<opc2>}
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM MCR2 instruction must be
unconditional.
<opc1> Is a coprocessor-specific opcode in the range 0 to 7.
<Rt> Is the ARM core register whose value is transferred to the coprocessor.
<CRn> Is the destination coprocessor register.
<CRm> Is an additional destination coprocessor register.
<opc2> Is a coprocessor-specific opcode in the range 0-7. If omitted, <opc2> is assumed to be 0.
Operation
else
Coproc_SendOneWord(R[t], cp, ThisInstr());
Exceptions
Undefined Instruction, Hyp Trap.
A8.8.100 MCRR, MCRR2

Move to Coprocessor from two ARM core registers passes the values of two ARM core registers to a coprocessor.
If no coprocessor can execute the instruction, an Undefined Instruction exception is generated.
are free for use by the coprocessor instruction set designer. These are the opc1 and CRm fields. However, coprocessors
CP8-CP15 are reserved for use by ARM, and this manual defines the valid MCRR and MCRR2 instructions when coproc
is in the range p8-p15. For more information see Coprocessor support on page A2-93 and General behavior of
In an implementation that includes the Virtualization Extensions, MCRR accesses to system control registers can be
trapped to Hyp mode, meaning that an attempt to execute an MCRR instruction in a Non-secure mode other than Hyp
Note
Because of the range of possible traps to Hyp mode, the MCRR pseudocode does not show these possible traps.

ARMv5TE*, ARMv6*, ARMv7 for encoding A1
MCRR<c> <coproc>, <opc1>, <Rt>, <Rt2>, <CRm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 0 0 0 1 0 0 Rt2 Rt coproc opc1 CRm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 0 0 0 1 0 0 Rt2 Rt coproc opc1 CRm
For the case when cond is 0b1111, see T2/A2 encoding.

t = UInt(Rt); t2 = UInt(Rt2); cp = UInt(coproc);
if t == 15 || t2 == 15 then UNPREDICTABLE;
if (t == 13 || t2 == 13) && (CurrentInstrSet() != InstrSet_ARM) then UNPREDICTABLE;

ARMv6*, ARMv7 for encoding A2
MCRR2<c> <coproc>, <opc1>, <Rt>, <Rt2>, <CRm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Advanced SIMD and See 64-bit transfers between ARM core and extension registers on page A7-277
Floating-point
Assembler syntax
MCRR{2}{<c>}{<q>} <coproc>, {#}<opc1>, <Rt>, <Rt2>, <CRm>
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM MCRR2 instruction must be
unconditional.
<coproc> The name of the coprocessor.

The generic coprocessor names are p0-p15.
<Rt> Is the first ARM core register whose value is transferred to the coprocessor.
<Rt2> Is the second ARM core register whose value is transferred to the coprocessor.
<CRm> Is the destination coprocessor register.
Note
For the architected uses of the MCRR instructions, as described in this manual, Rt2 transfers bits[63:32] of the
selected coprocessor register, and Rt transfers bits[31:0]. For IMPLEMENTATION DEFINED uses of the instructions the
relative significance of Rt2 and Rt is IMPLEMENTATION DEFINED.
Operation
else
Coproc_SendTwoWords(R[t2], R[t], cp, ThisInstr());
Exceptions
A8.8.101 MLA
Multiply Accumulate multiplies two register values, and adds a third register value. The least significant 32 bits of
the result are written to the destination register. These 32 bits do not depend on whether the source register values
are considered to be signed values or unsigned values.
In an ARM instruction, the condition flags can optionally be updated based on the result. Use of this option
adversely affects performance on many processor implementations.

MLA<c> <Rd>, <Rn>, <Rm>, <Ra>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 0 0 0 0 Rn Ra Rd 0 0 0 0 Rm
if Ra == ‘1111’ then SEE MUL;

d = UInt(Rd); n = UInt(Rn); m = UInt(Rm); a = UInt(Ra); setflags = FALSE;
if d IN {13,15} || n IN {13,15} || m IN {13,15} || a == 13 then UNPREDICTABLE;

MLA{S}<c> <Rd>, <Rn>, <Rm>, <Ra>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 0 0 0 1 S Rd Ra Rm 1 0 0 1 Rn
d = UInt(Rd); n = UInt(Rn); m = UInt(Rm); a = UInt(Ra); setflags = (S == ‘1’);

if d == 15 || n == 15 || m == 15 || a == 15 then UNPREDICTABLE;
if ArchVersion() < 6 && d == n then UNPREDICTABLE;
Assembler syntax
MLA{S}{<c>}{<q>} <Rd>, <Rn>, <Rm>, <Ra>
where:
S can be specified only for the ARM instruction set.
<Rm> The second operand register.
<Ra> The register containing the accumulate value.
The pre-UAL syntax MLA<c>S is equivalent to MLAS<c>.
Operation
operand1 = SInt(R[n]); // operand1 = UInt(R[n]) produces the same final results
operand2 = SInt(R[m]); // operand2 = UInt(R[m]) produces the same final results
addend = SInt(R[a]); // addend = UInt(R[a]) produces the same final results
result = operand1 * operand2 + addend;
if setflags then
APSR.Z = IsZeroBit(result<31:0>);
if ArchVersion() == 4 then
APSR.C = bit UNKNOWN;
// else APSR.C unchanged
// APSR.V always unchanged
Exceptions
None.
A8.8.102 MLS
Multiply and Subtract multiplies two register values, and subtracts the product from a third register value. The least
significant 32 bits of the result are written to the destination register. These 32 bits do not depend on whether the
source register values are considered to be signed values or unsigned values.

MLS<c> <Rd>, <Rn>, <Rm>, <Ra>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 0 0 0 0 Rn Ra Rd 0 0 0 1 Rm
d = UInt(Rd); n = UInt(Rn); m = UInt(Rm); a = UInt(Ra);

if d IN {13,15} || n IN {13,15} || m IN {13,15} || a IN {13,15} then UNPREDICTABLE;

MLS<c> <Rd>, <Rn>, <Rm>, <Ra>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 0 0 1 1 0 Rd Ra Rm 1 0 0 1 Rn

Assembler syntax
MLS{<c>}{<q>} <Rd>, <Rn>, <Rm>, <Ra>
where:
<Ra> The register containing the accumulate value.
Operation
addend = SInt(R[a]); // addend = UInt(R[a]) produces the same final results
result = addend - operand1 * operand2;
Exceptions
None.
A8.8.103 MOV (immediate)

Move (immediate) writes an immediate value to the destination register. It can optionally update the condition flags
based on the value.

MOVS <Rd>, #<imm8> Outside IT block.
MOV<c> <Rd>, #<imm8> Inside IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 1 0 0 Rd imm8
d = UInt(Rd); setflags = !InITBlock(); imm32 = ZeroExtend(imm8, 32); carry = APSR.C;

MOV{S}<c>.W <Rd>, #<const>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 i 0 0 0 1 0 S 1 1 1 1 0 imm3 Rd imm8
d = UInt(Rd); setflags = (S == ‘1’); (imm32, carry) = ThumbExpandImm_C(i:imm3:imm8, APSR.C);


MOVW<c> <Rd>, #<imm16>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 i 1 0 0 1 0 0 imm4 0 imm3 Rd imm8
d = UInt(Rd); setflags = FALSE; imm32 = ZeroExtend(imm4:i:imm3:imm8, 32);


MOV{S}<c> <Rd>, #<const>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 1 1 0 1 S (0) (0) (0) (0) Rd imm12
d = UInt(Rd); setflags = (S == ‘1’); (imm32, carry) = ARMExpandImm_C(imm12, APSR.C);

MOVW<c> <Rd>, #<imm16>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 1 0 0 0 0 imm4 Rd imm12
d = UInt(Rd); setflags = FALSE; imm32 = ZeroExtend(imm4:imm12, 32);

Assembler syntax
MOV{S}{<c>}{<q>} <Rd>, #<const> All encodings permitted
MOVW{<c>}{<q>} <Rd>, #<const> Only encoding T3 or A2 permitted
where:
In ARM instructions, if S is not specified and <Rd> is the PC, encoding A2 is not permitted, and for
encoding A1 the instruction is a branch to the address calculated by the operation. This is an
interworking branch, see Pseudocode details of operations on ARM core registers on page A2-46.
ARM deprecates this use of the PC.
Note
<const> The immediate value to be placed in <Rd>. The range of values is 0-255 for encoding T1 and 0-65535
for encoding T3 or A2. See Modified immediate constants in Thumb instructions on page A6-230
or Modified immediate constants in ARM instructions on page A5-197 for the range of values for
encoding T2 or A1.
When both 32-bit encodings are available for an instruction, encoding T2 or A1 is preferred to
encoding T3 or A2 (if encoding T3 or A2 is required, use the MOVW syntax).
The pre-UAL syntax MOV<c>S is equivalent to MOVS<c>.
Operation
result = imm32;
if d == 15 then // Can only occur for encoding A1
else
R[d] = result;
if setflags then
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.104 MOV (register, Thumb)

Move (register) copies a value from a register to the destination register. It can optionally update the condition flags
based on the value.
Encoding T1 ARMv6*, ARMv7 if <Rd> and <Rm> both from R0-R7

ARMv4T, ARMv5T*, ARMv6*, ARMv7 otherwise
MOV<c> <Rd>, <Rm> If <Rd> is the PC, must be outside or last in IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 0 1 1 0 D Rm Rd
d = UInt(D:Rd); m = UInt(Rm); setflags = FALSE;


MOVS <Rd>, <Rm> Not permitted in IT block
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 0 0 0 0 0 0 Rm Rd
d = UInt(Rd); m = UInt(Rm); setflags = TRUE;


MOV{S}<c>.W <Rd>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 1 0 0 1 0 S 1 1 1 1 (0) 0 0 0 Rd 0 0 0 0 Rm

if setflags && (d IN {13,15} || m IN {13,15}) then UNPREDICTABLE;
if !setflags && (d == 15 || m == 15 || (d == 13 && m == 13)) then UNPREDICTABLE;
Assembler syntax
MOV{S}{<c>}{<q>} <Rd>, <Rm>
where:
<Rd> The destination register. This register can be the SP or PC. S must not be specified if <Rd> is the SP.
If <Rd> is the PC and S is not specified:
• The instruction causes a branch to the address moved to the PC. This is a simple branch, see
Pseudocode details of operations on ARM core registers on page A2-46.
• The instruction must either be outside an IT block or the last instruction of an IT block.
<Rm> The source register. This register can be the SP or PC. S must not be specified if <Rm> is the SP or PC.
Encoding T3 is not permitted if:

• <Rd> or <Rm> is the PC
• both <Rd> and <Rm> are the SP.
Note
• ARM deprecates the use of the following MOV (register) instructions:
— ones in which <Rd> is the SP or PC and <Rm> is also the SP or PC
— ones in which S is specified and <Rm> is the SP, or <Rm> is the PC.
• See also Changing between Thumb state and ARM state on page A4-158 about the use of the MOV PC, LR
instruction.
Operation
result = R[m];
if d == 15 then
else
R[d] = result;
if setflags then
// APSR.C unchanged
// APSR.V unchanged
Exceptions
None.
A8.8.105 MOV (register, ARM)

Move (register) copies a value from a register to the destination register. It can optionally update the condition flags
based on the value.

MOV{S}<c> <Rd>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 1 0 1 S (0) (0) (0) (0) Rd 0 0 0 0 0 0 0 0 Rm
Assembler syntax
MOV{S}{<c>}{<q>} <Rd>, <Rm>
where:
instructions (ARM) on page B9-1998. This register can be the SP or PC.
If <Rd> is the PC and S is not specified, the instruction causes a branch to the address moved to the
PC. This is an interworking branch, see Pseudocode details of operations on ARM core registers on
page A2-46.
Note
<Rm> The source register. This register can be the SP or PC.
Note
• ARM deprecates the use of the following MOV (register) instructions:
— ones in which <Rd> is the SP or PC and <Rm> is also the SP or PC
— ones in which S is specified and <Rd> is the SP, <Rm> is the SP, or <Rm> is the PC.
• See also Changing between Thumb state and ARM state on page A4-158 about the use of the MOV PC, LR
instruction.
Operation
result = R[m];
if d == 15 then
else
R[d] = result;
if setflags then
// APSR.C unchanged
// APSR.V unchanged
Exceptions
None.
A8.8.106 MOV (shifted register)

For the special case of MOVS where <Rd> is the PC, see SUBS PC, LR (Thumb) on page B9-1996 and SUBS PC, LR
and related instructions (ARM) on page B9-1998. Otherwise, MOV (shifted register) is a pseudo-instruction for ASR,
LSL, LSR, ROR, and RRX. For more information see the following sections:
• ASR (immediate) on page A8-328
• ASR (register) on page A8-330
• LSL (immediate) on page A8-469
• LSL (register) on page A8-471
• LSR (immediate) on page A8-473
• LSR (register) on page A8-475
• ROR (immediate) on page A8-569
• ROR (register) on page A8-571
• RRX on page A8-573.
Assembler syntax
Table A8-3 shows the equivalences between MOV (shifted register) and other instructions.
Table A8-3 MOV (shifted register) equivalences
MOV instruction Canonical form
MOV{S} <Rd>, <Rm>, ASR #<n> ASR{S} <Rd>, <Rm>, #<n>
MOV{S} <Rd>, <Rm>, LSL #<n> LSL{S} <Rd>, <Rm>, #<n>
MOV{S} <Rd>, <Rm>, LSR #<n> LSR{S} <Rd>, <Rm>, #<n>
MOV{S} <Rd>, <Rm>, ROR #<n> ROR{S} <Rd>, <Rm>, #<n>
MOV{S} <Rd>, <Rm>, ASR <Rs> ASR{S} <Rd>, <Rm>, <Rs>
MOV{S} <Rd>, <Rm>, LSL <Rs> LSL{S} <Rd>, <Rm>, <Rs>
MOV{S} <Rd>, <Rm>, LSR <Rs> LSR{S} <Rd>, <Rm>, <Rs>
MOV{S} <Rd>, <Rm>, ROR <Rs> ROR{S} <Rd>, <Rm>, <Rs>
MOV{S} <Rd>, <Rm>, RRX RRX{S} <Rd>, <Rm>
Disassembly produces the canonical form of the instruction.
Exceptions
None.
A8.8.107 MOVT
Move Top writes an immediate value to the top halfword of the destination register. It does not affect the contents
of the bottom halfword.

MOVT<c> <Rd>, #<imm16>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 i 1 0 1 1 0 0 imm4 0 imm3 Rd imm8
d = UInt(Rd); imm16 = imm4:i:imm3:imm8;


MOVT<c> <Rd>, #<imm16>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 1 0 1 0 0 imm4 Rd imm12
d = UInt(Rd); imm16 = imm4:imm12;

Assembler syntax
MOVT{<c>}{<q>} <Rd>, #<imm16>
where:
<imm16> The immediate value to be written to <Rd>. It must be in the range 0-65535.
Operation
R[d]<31:16> = imm16;
// R[d]<15:0> unchanged
Exceptions
None.
A8.8.108 MRC, MRC2

Move to ARM core register from Coprocessor causes a coprocessor to transfer a value to an ARM core register or
to the condition flags. If no coprocessor can execute the instruction, an Undefined Instruction exception is
generated.
are free for use by the coprocessor instruction set designer. These are the opc1, opc2, CRn, and CRm fields. However,
coprocessors CP8-CP15 are reserved for use by ARM, and this manual defines the valid MRC and MRC2 instructions
when coproc is in the range p8-p15. For more information see Coprocessor support on page A2-93 and General
behavior of system control registers on page B5-1768.
In an implementation that includes the Virtualization Extensions, MRC accesses to system control registers can be
trapped to Hyp mode, meaning that an attempt to execute an MRC instruction in a Non-secure mode other than Hyp
Note
Because of the range of possible traps to Hyp mode, the MRC pseudocode does not show these possible traps.

MRC<c> <coproc>, <opc1>, <Rt>, <CRn>, <CRm>{, <opc2>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 1 0 opc1 1 CRn Rt coproc opc2 1 CRm

if t == 13 && (CurrentInstrSet() != InstrSet_ARM) then UNPREDICTABLE;

MRC2<c> <coproc>, <opc1>, <Rt>, <CRn>, <CRm>{, <opc2>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

if t == 13 && (CurrentInstrSet() != InstrSet_ARM) then UNPREDICTABLE;
Advanced SIMD and See 8, 16, and 32-bit transfer between ARM core and extension registers on
Floating-point page A7-276
Assembler syntax
MRC{2}{<c>}{<q>} <coproc>, {#}<opc1>, <Rt>, <CRn>, <CRm>{, {#}<opc2>}
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM MRC2 instruction must be
unconditional.
<Rt> Is the destination ARM core register. This register can be R0-R14 or, in some cases, APSR_nzcv.
The APSR_nzcv form writes bits[31:28] of the transferred value to the N, Z, C, and V condition
flags and is specified by setting the Rt field of the encoding to 0b1111. Some coprocessors do not
support that form of the instruction. For permitted uses with CP14 and CP15, see:
• Additional rules for MCR and MRC accesses to CP14 and CP15 registers on page B3-1444
for a VMSA implementation.
for a PMSA implementation.
In pre-UAL assembler syntax, PC was written instead of APSR_nzcv to select this form.
<CRn> Is the coprocessor register that contains the first operand.
<CRm> Is an additional source or destination coprocessor register.
<opc2> Is a coprocessor-specific opcode in the range 0 to 7. If omitted, <opc2> is assumed to be 0.
Operation
else
value = Coproc_GetOneWord(cp, ThisInstr());
if t != 15 then
R[t] = value;
else
// Note: not all coprocessors support assignment to the APSR
APSR.N = value<31>;
APSR.Z = value<30>;
APSR.C = value<29>;
APSR.V = value<28>;
// value<27:0> are not used.
Exceptions
A8.8.109 MRRC, MRRC2

Move to two ARM core registers from Coprocessor causes a coprocessor to transfer values to two ARM core
registers. If no coprocessor can execute the instruction, an Undefined Instruction exception is generated.
are free for use by the coprocessor instruction set designer. These are the opc1 and CRm fields. However, coprocessors
CP8-CP15 are reserved for use by ARM, and this manual defines the valid MRRC and MRRC2 instructions when coproc
is in the range p8-p15. For more information see Coprocessor support on page A2-93 and General behavior of
In an implementation that includes the Virtualization Extensions, MRRC accesses to system control registers can be
trapped to Hyp mode, meaning that an attempt to execute an MRRC instruction in a Non-secure mode other than Hyp
Note
Because of the range of possible traps to Hyp mode, the MRRC pseudocode does not show these possible traps.

ARMv5TE*, ARMv6*, ARMv7 for encoding A1
MRRC<c> <coproc>, <opc>, <Rt>, <Rt2>, <CRm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 0 0 0 1 0 1 Rt2 Rt coproc opc1 CRm
For the case when cond is 0b1111.see the T2/A2 encoding.

if t == 15 || t2 == 15 || t == t2 then UNPREDICTABLE;

ARMv6*, ARMv7 for encoding A2
MRRC2<c> <coproc>, <opc>, <Rt>, <Rt2>, <CRm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

if t == 15 || t2 == 15 || t == t2 then UNPREDICTABLE;
Advanced SIMD and See 64-bit transfers between ARM core and extension registers on page A7-277
Floating-point
Assembler syntax
MRRC{2}{<c>}{<q>} <coproc>, {#}<opc1>, <Rt>, <Rt2>, <CRm>
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM MRRC2 instruction must be
unconditional.
<Rt> Is the first destination ARM core register.
<Rt2> Is the second destination ARM core register.
<CRm> Is the coprocessor register that supplies the data to be transferred.
Note
For the architected uses of the MRRC instructions, as described in this manual, Rt2 transfers bits[63:32] of the
selected coprocessor register, and Rt transfers bits[31:0]. For IMPLEMENTATION DEFINED uses of the instructions the
relative significance of Rt2 and Rt is IMPLEMENTATION DEFINED.
Operation
else
(R[t2], R[t]) = Coproc_GetTwoWords(cp, ThisInstr());
Exceptions
A8.8.110 MRS
Move to Register from Special register moves the value from the APSR into an ARM core register.
For details of system level use of this instruction, see MRS on page B9-1976.

MRS<c> <Rd>, <spec_reg>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 1 1 0 (1) (1) (1) (1) 1 0 (0) 0 Rd (0) (0) 0 (0) (0) (0) (0) (0)
d = UInt(Rd);

MRS<c> <Rd>, <spec_reg>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 0 0 0 0 (1) (1) (1) (1) Rd (0) (0) 0 (0) 0 0 0 0 (0) (0) (0) (0)
d = UInt(Rd);
Assembler syntax
MRS{<c>}{<q>} <Rd>, <spec_reg>
where:
<spec_reg> Is one of:

• APSR
• CPSR.
When the MRS instruction is executed in User mode, CPSR is treated as a synonym of APSR.
ARM recommends that application level software uses the APSR form. For more information, see The
Application Program Status Register (APSR) on page A2-49.
Operation
R[d] = APSR;
Exceptions
None.
A8.8.111 MRS (Banked register)

Move to Register from Banked or Special register is a system instruction, see MRS (Banked register) on
page B9-1978.
A8.8.112 MSR (immediate)

Move immediate value to Special register moves selected bits of an immediate value to the corresponding bits in
the APSR.
For details of system level use of this instruction, see MSR (immediate) on page B9-1982.

MSR<c> <spec_reg>, #<const>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 1 0 0 1 0 mask 0 0 (1) (1) (1) (1) imm12
if mask == ‘00’ then SEE “Related encodings”;

imm32 = ARMExpandImm(imm12); write_nzcvq = (mask<1> == ‘1’); write_g = (mask<0> == ‘1’);
Related encodings See MSR (immediate), and hints on page A5-204.
Assembler syntax
MSR{<c>}{<q>} <spec_reg>, #<imm>
where:

• APSR_<bits>
• CPSR_<fields>.
ARM recommends that application level software uses the APSR forms. For more
information, see The Application Program Status Register (APSR) on page A2-49.
<imm> Is the immediate value to be transferred to <spec_reg>. See Modified immediate constants in
<bits> Is one of nzcvq, g, or nzcvqg.

In the A and R profiles:
• APSR_nzcvq is the same as CPSR_f
• APSR_g is the same as CPSR_s
• APSR_nzcvqg is the same as CPSR_fs.
<fields> Is a sequence of one or more of the following: s, f.
Operation
if write_nzcvq then
APSR.N = imm32<31>;
APSR.Z = imm32<30>;
APSR.C = imm32<29>;
APSR.V = imm32<28>;
APSR.Q = imm32<27>;
if write_g then
APSR.GE = imm32<19:16>;
Exceptions
None.
Usage
For details of the APSR see The Application Program Status Register (APSR) on page A2-49. Because of the
Do-Not-Modify nature of its reserved bits, the immediate form of MSR is normally only useful at the Application
level for writing to APSR_nzcvq (CPSR_f).
For the A and R profiles, MSR (immediate) on page B9-1982 describes additional functionality that is available
using the reserved bits. This includes some deprecated functionality that is also available to unprivileged software
and therefore can be used at the Application level.
A8.8.113 MSR (register)

Move to Special register from ARM core register moves selected bits of an ARM core register to the APSR.
For details of system level use of this instruction, see MSR (register) on page B9-1984.

MSR<c> <spec_reg>, <Rn>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 0 0 0 Rn 1 0 (0) 0 mask 0 0 (0) (0) 0 (0) (0) (0) (0) (0)
n = UInt(Rn); write_nzcvq = (mask<1> == ‘1’); write_g = (mask<0> == ‘1’);

if mask == ‘00’ then UNPREDICTABLE;
if n IN {13,15} then UNPREDICTABLE;

MSR<c> <spec_reg>, <Rn>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 0 0 1 0 mask 0 0 (1) (1) (1) (1) (0) (0) 0 (0) 0 0 0 0 Rn
n = UInt(Rn); write_nzcvq = (mask<1> == ‘1’); write_g = (mask<0> == ‘1’);

if mask == ‘00’ then UNPREDICTABLE;
Assembler syntax
MSR{<c>}{<q>} <spec_reg>, <Rn>
where:
• APSR_<bits>
• CPSR_<fields>.
ARM recommends that application level software uses the APSR form. For more information, see The
<Rn> Is the ARM core register to be transferred to <spec_reg>.
<bits> Is one of nzcvq, g, or nzcvqg.
In the A and R profiles:
• APSR_nzcvq is the same as CPSR_f
• APSR_g is the same as CPSR_s
• APSR_nzcvqg is the same as CPSR_fs.
<fields> Is a sequence of one or more of the following: s, f.
Operation
if write_nzcvq then
APSR.N = R[n]<31>;
APSR.Z = R[n]<30>;
APSR.C = R[n]<29>;
APSR.V = R[n]<28>;
APSR.Q = R[n]<27>;
if write_g then
APSR.GE = R[n]<19:16>;
Exceptions
None.
Usage
For details of the APSR see The Application Program Status Register (APSR) on page A2-49. Because of the
Do-Not-Modify nature of its reserved bits, a read-modify-write sequence is normally needed when the MSR
instruction is being used at Application level and its destination is not APSR_nzcvq (CPSR_f).
For the A and R profiles, MSR (register) on page B9-1984 describes additional functionality that is available using
the reserved bits. This includes some deprecated functionality that is also available to unprivileged software and
therefore can be used at the Application level.
A8.8.114 MSR (Banked register)

Move to Banked or Special register from ARM core register is a system instruction, see MSR (Banked register) on
page B9-1980.
A8.8.115 MUL
Multiply multiplies two register values. The least significant 32 bits of the result are written to the destination
register. These 32 bits do not depend on whether the source register values are considered to be signed values or
unsigned values.
Optionally, it can update the condition flags based on the result. In the Thumb instruction set, this option is limited
to only a few forms of the instruction. Use of this option adversely affects performance on many processor
implementations.

MULS <Rdm>, <Rn>, <Rdm> Outside IT block.
MUL<c> <Rdm>, <Rn>, <Rdm> Inside IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 0 0 1 1 0 1 Rn Rdm
d = UInt(Rdm); n = UInt(Rn); m = UInt(Rdm); setflags = !InITBlock();


MUL<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 0 0 0 0 Rn 1 1 1 1 Rd 0 0 0 0 Rm
d = UInt(Rd); n = UInt(Rn); m = UInt(Rm); setflags = FALSE;


MUL{S}<c> <Rd>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 0 0 0 0 S Rd (0) (0) (0) (0) Rm 1 0 0 1 Rn

Assembler syntax
MUL{S}{<c>}{<q>} <Rd>, <Rn>{, <Rm>}
where:
In the Thumb instruction set, S can be specified only if both <Rn> and <Rm> are R0-R7 and the
instruction is outside an IT block.
<Rm> The second operand register. If omitted, <Rd> is used.
Note
Issues A and B of this document showed the MUL syntax as MUL{S}{<c>}{<q>} {<Rd>, }<Rn>, <Rm>. The <Rm> register
is now made optional because omitting <Rd> can generate UNPREDICTABLE instructions in some cases. Some
assembler versions might not support this revised specification.
The pre-UAL syntax MUL<c>S is equivalent to MULS<c>.
Operation
result = operand1 * operand2;
if setflags then
// else APSR.C unchanged
// APSR.V always unchanged
Exceptions
None.
A8.8.116 MVN (immediate)

Bitwise NOT (immediate) writes the bitwise inverse of an immediate value to the destination register. It can
optionally update the condition flags based on the value.

MVN{S}<c> <Rd>, #<const>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 i 0 0 0 1 1 S 1 1 1 1 0 imm3 Rd imm8
d = UInt(Rd); setflags = (S == ‘1’);


MVN{S}<c> <Rd>, #<const>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 1 1 1 1 S (0) (0) (0) (0) Rd imm12
d = UInt(Rd); setflags = (S == ‘1’);
Assembler syntax
MVN{S}{<c>}{<q>} <Rd>, #<const>
where:
Note
<const> The immediate value to be bitwise inverted. See Modified immediate constants in Thumb
instructions on page A6-230 or Modified immediate constants in ARM instructions on page A5-197
for the range of values.
The pre-UAL syntax MVN<c>S is equivalent to MVNS<c>.
Operation
result = NOT(imm32);
else
R[d] = result;
if setflags then
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.117 MVN (register)

Bitwise NOT (register) writes the bitwise inverse of a register value to the destination register. It can optionally
update the condition flags based on the result.

MVNS <Rd>, <Rm> Outside IT block.
MVN<c> <Rd>, <Rm> Inside IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 0 0 1 1 1 1 Rm Rd


MVN{S}<c>.W <Rd>, <Rm>{, <shift>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0


MVN{S}<c> <Rd>, <Rm>{, <shift>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 1 1 1 S (0) (0) (0) (0) Rd imm5 type 0 Rm
Assembler syntax
MVN{S}{<c>}{<q>} <Rd>, <Rm> {, <shift>}
where:
Note
<Rm> The register that is optionally shifted and used as the source register. The PC can be used in ARM
Operation
result = NOT(shifted);
else
R[d] = result;
if setflags then
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.118 MVN (register-shifted register)

Bitwise NOT (register-shifted register) writes the bitwise inverse of a register-shifted register value to the
destination register. It can optionally update the condition flags based on the result.

MVN{S}<c> <Rd>, <Rm>, <type> <Rs>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 1 1 1 S (0) (0) (0) (0) Rd Rs 0 type 1 Rm
d = UInt(Rd); m = UInt(Rm); s = UInt(Rs);

if d == 15 || m == 15 || s == 15 then UNPREDICTABLE;
Assembler syntax
MVN{S}{<c>}{<q>} <Rd>, <Rm>, <type> <Rs>
where:
<Rm> The register that is shifted and used as the operand.
Operation
result = NOT(shifted);
R[d] = result;
if setflags then
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.119 NEG
Negate is a pre-UAL synonym for RSB (immediate) with an immediate value of 0. For details see RSB (immediate)
on page A8-575.
Assembler syntax
NEG{<c>}{<q>} <Rd>, <Rm>
This is equivalent to:
RSBS{<c>}{<q>} <Rd>, <Rm>, #0
Exceptions
None.
A8.8.120 NOP
No Operation does nothing. This instruction can be used for instruction alignment purposes.
See Pre-UAL pseudo-instruction NOP on page D8-2460 for details of NOP before the introduction of UAL and the
ARMv6K and ARMv6T2 architecture variants.
Note
The timing effects of including a NOP instruction in a program are not guaranteed. It can increase execution time,
leave it unchanged, or even reduce it. Therefore, NOP instructions are not suitable for timing loops.

NOP<c>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 1 1 1 1 1 0 0 0 0 0 0 0 0

NOP<c>.W
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 0 1 0 (1) (1) (1) (1) 1 0 (0) 0 (0) 0 0 0 0 0 0 0 0 0 0 0
Encoding A1 ARMv6K, ARMv6T2, ARMv7

NOP<c>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 1 0 0 1 0 0 0 0 0 (1) (1) (1) (1) (0) (0) (0) (0) 0 0 0 0 0 0 0 0
Assembler syntax
NOP{<c>}{<q>}
where:
{<c>}{<q>} See Standard assembler syntax fields on page A8-285.
Operation
// Do nothing
Exceptions
None.
A8.8.121 ORN (immediate)

Bitwise OR NOT (immediate) performs a bitwise (inclusive) OR of a register value and the complement of an
immediate value, and writes the result to the destination register. It can optionally update the condition flags based
on the result.

ORN{S}<c> <Rd>, <Rn>, #<const>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 i 0 0 0 1 1 S Rn 0 imm3 Rd imm8
if Rn == ‘1111’ then SEE MVN (immediate);

Assembler syntax
ORN{S}{<c>}{<q>} {<Rd>,} <Rn>, #<const>
where:
<Rn> The register that contains the operand.
<const> The immediate value to be bitwise inverted and ORed with the value obtained from <Rn>. See
Modified immediate constants in Thumb instructions on page A6-230 for the range of values.
Operation
result = R[n] OR NOT(imm32);
R[d] = result;
if setflags then
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.122 ORN (register)

Bitwise OR NOT (register) performs a bitwise (inclusive) OR of a register value and the complement of an
optionally-shifted register value, and writes the result to the destination register. It can optionally update the
condition flags based on the result.

ORN{S}<c> <Rd>, <Rn>, <Rm>{, <shift>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if Rn == ‘1111’ then SEE MVN (register);

if d IN {13,15} || n == 13 || m IN {13,15} then UNPREDICTABLE;
Assembler syntax
ORN{S}{<c>}{<q>} {<Rd>,} <Rn>, <Rm> {, <shift>}
where:
<Rm> The register that is optionally shifted and used as the second operand.
Operation
result = R[n] OR NOT(shifted);
R[d] = result;
if setflags then
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.123 ORR (immediate)

Bitwise OR (immediate) performs a bitwise (inclusive) OR of a register value and an immediate value, and writes
the result to the destination register. It can optionally update the condition flags based on the result.

ORR{S}<c> <Rd>, <Rn>, #<const>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 i 0 0 0 1 0 S Rn 0 imm3 Rd imm8
if Rn == ‘1111’ then SEE MOV (immediate);


ORR{S}<c> <Rd>, <Rn>, #<const>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 1 1 0 0 S Rn Rd imm12
Assembler syntax
ORR{S}{<c>}{<q>} {<Rd>,} <Rn>, #<const>
where:
Note
<Rn> The register that contains the operand. The PC can be used in ARM instructions, but ARM
<const> The immediate value to be bitwise ORed with the value obtained from <Rn>. See Modified
The pre-UAL syntax ORR<c>S is equivalent to ORRS<c>.
Operation
result = R[n] OR imm32;
else
R[d] = result;
if setflags then
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.124 ORR (register)

Bitwise OR (register) performs a bitwise (inclusive) OR of a register value and an optionally-shifted register value,
and writes the result to the destination register. It can optionally update the condition flags based on the result.

ORRS <Rdn>, <Rm> Outside IT block.
ORR<c> <Rdn>, <Rm> Inside IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 0 0 1 1 0 0 Rm Rdn


ORR{S}<c>.W <Rd>, <Rn>, <Rm>{, <shift>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if Rn == ‘1111’ then SEE “Related encodings”;


ORR{S}<c> <Rd>, <Rn>, <Rm>{, <shift>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Related encodings See Move register and immediate shifts on page A6-241.
Assembler syntax
ORR{S}{<c>}{<q>} {<Rd>,} <Rn>, <Rm> {, <shift>}
where:
Note
of the PC.
In Thumb assembly:
• outside an IT block, if ORRS <Rd>, <Rn>, <Rd> is written with <Rd> and <Rn> both in the range R0-R7, it is
assembled using encoding T1 as though ORRS <Rd>, <Rn> had been written
• inside an IT block, if ORR<c> <Rd>, <Rn>, <Rd> is written with <Rd> and <Rn> both in the range R0-R7, it is
assembled using encoding T1 as though ORR<c> <Rd>, <Rn> had been written.
Operation
result = R[n] OR shifted;
else
R[d] = result;
if setflags then
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.125 ORR (register-shifted register)

Bitwise OR (register-shifted register) performs a bitwise (inclusive) OR of a register value and a register-shifted
the result.

ORR{S}<c> <Rd>, <Rn>, <Rm>, <type> <Rs>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Assembler syntax
ORR{S}{<c>}{<q>} {<Rd>,} <Rn>, <Rm>, <type> <Rs>
where:
Operation
result = R[n] OR shifted;
R[d] = result;
if setflags then
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.126 PKH
Pack Halfword combines one halfword of its first operand with the other halfword of its shifted second operand.

PKHBT<c> <Rd>, <Rn>, <Rm>{, LSL #<imm>}
PKHTB<c> <Rd>, <Rn>, <Rm>{, ASR #<imm>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 1 0 1 1 0 S Rn (0) imm3 Rd imm2 tb T Rm
if S == ‘1’ || T == ‘1’ then UNDEFINED;

d = UInt(Rd); n = UInt(Rn); m = UInt(Rm); tbform = (tb == ‘1’);
(shift_t, shift_n) = DecodeImmShift(tb:’0’, imm3:imm2);

PKHBT<c> <Rd>, <Rn>, <Rm>{, LSL #<imm>}
PKHTB<c> <Rd>, <Rn>, <Rm>{, ASR #<imm>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 1 0 0 0 Rn Rd imm5 tb 0 1 Rm
d = UInt(Rd); n = UInt(Rn); m = UInt(Rm); tbform = (tb == ‘1’);

(shift_t, shift_n) = DecodeImmShift(tb:’0’, imm5);
Assembler syntax
PKHBT{<c>}{<q>} {<Rd>,} <Rn>, <Rm> {, LSL #<imm>} tbform == FALSE
PKHTB{<c>}{<q>} {<Rd>,} <Rn>, <Rm> {, ASR #<imm>} tbform == TRUE
where:
<Rm> The register that is optionally shifted and used as the second operand.
<imm> The shift to apply to the value read from <Rm>, encoded in imm3:imm2 for encoding T1 and imm5
for encoding A1.
For PKHBT, it is one of:
omitted No shift, encoded as 0b00000.
1-31 Left shift by specified number of bits, encoded as a binary number.
For PKHTB, it is one of:
omitted Instruction is a pseudo-instruction and is assembled as though PKHBT{<c>}{<q>} <Rd>,
<Rm>, <Rn> had been written.
1-32 Arithmetic right shift by specified number of bits. A shift by 32 bits is encoded as
0b00000. Other shift amounts are encoded as binary numbers.
Note
An assembler can permit <imm> = 0 to mean the same thing as omitting the shift, but this is not
standard UAL and must not be used for disassembly.
Operation
operand2 = Shift(R[m], shift_t, shift_n, APSR.C); // APSR.C ignored
R[d]<15:0> = if tbform then operand2<15:0> else R[n]<15:0>;
R[d]<31:16> = if tbform then R[n]<31:16> else operand2<31:16>;
Exceptions
None.
A8.8.127 PLD, PLDW (immediate)

Preload Data signals the memory system that data memory accesses from a specified address are likely in the near
future. The memory system can respond by taking actions that are expected to speed up the memory accesses when
they do occur, such as pre-loading the cache line containing the specified address into the data cache.
On an architecture variant that includes both the PLD and PLDW instructions, the PLD instruction signals that the likely
memory access is a read, and the PLDW instruction signals that it is a write.
The effect of a PLD or PLDW instruction is IMPLEMENTATION DEFINED. For more information, see Preloading caches
on page A3-155 and Behavior of Preload Data (PLD, PLDW) and Preload Instruction (PLI) with caches on
page B2-1267.
Encoding T1 ARMv6T2, ARMv7 for PLD

ARMv7 with MP Extensions for PLDW
PLD{W}<c> [<Rn>, #<imm12>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 1 0 W 1 Rn 1 1 1 1 imm12
if Rn == ‘1111’ then SEE PLD (literal);

n = UInt(Rn); imm32 = ZeroExtend(imm12, 32); add = TRUE; is_pldw = (W == ‘1’);

PLD{W}<c> [<Rn>, #-<imm8>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 0 0 W 1 Rn 1 1 1 1 1 1 0 0 imm8

n = UInt(Rn); imm32 = ZeroExtend(imm8, 32); add = FALSE; is_pldw = (W == ‘1’);
Encoding A1 ARMv5TE*, ARMv6*, ARMv7 for PLD

PLD{W} [<Rn>, #+/-<imm12>]
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 1 0 1 U R 0 1 Rn (1) (1) (1) (1) imm12

n = UInt(Rn); imm32 = ZeroExtend(imm12, 32); add = (U == ‘1’); is_pldw = (R == ‘0’);
Assembler syntax
PLD{W}{<c>}{<q>} [<Rn> {, #+/-<imm>}]
where:
W If specified, selects PLDW, encoded as W = 1 in Thumb encodings and R = 0 in ARM encodings.

If omitted, selects PLD, encoded as W = 0 in Thumb encodings and R = 1 in ARM encodings.
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM PLD or PLDW instruction must be
unconditional.
<Rn> The base register. The SP can be used. For PC use in the PLD instruction, see PLD (literal) on
page A8-527.
for #0 and #-0.
<imm> The immediate offset used for forming the address. This offset can be omitted, meaning an offset of
0. Values are:
Encoding T1, A1 any value in the range 0-4095
Operation
address = if add then (R[n] + imm32) else (R[n] - imm32);
if is_pldw then
Hint_PreloadDataForWrite(address);
else
Hint_PreloadData(address);
Exceptions
None.
A8.8.128 PLD (literal)

The effect of a PLD instruction is IMPLEMENTATION DEFINED. For more information, see Preloading caches on
page A3-155 and Behavior of Preload Data (PLD, PLDW) and Preload Instruction (PLI) with caches on
page B2-1267.

PLD<c> <label>
PLD<c> [PC, #-0] Special case
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 U 0 (0) 1 1 1 1 1 1 1 1 1 imm12
imm32 = ZeroExtend(imm12, 32); add = (U == ‘1’);

PLD <label>
PLD [PC, #-0] Special case
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 1 0 1 U (1) 0 1 1 1 1 1 (1) (1) (1) (1) imm12
imm32 = ZeroExtend(imm12, 32); add = (U == ‘1’);
Assembler syntax
PLD{<c>}{<q>} <label> Normal form
PLD{<c>}{<q>} [PC, #+/-<imm>] Alternative form
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM PLD instruction must be
unconditional.
<label> The label of the literal data item that is likely to be accessed in the near future. The assembler
calculates the required value of the offset from the Align(PC, 4) value of the instruction to this label.
The offset must be in the range –4095 to 4095.
+/- Is + or omitted to indicate that the immediate offset is added to the Align(PC, 4) value (add == TRUE),
for #0 and #-0.
<imm> The immediate offset used for forming the address. Values are in the range 0-4095.
Operation
address = if add then (Align(PC,4) + imm32) else (Align(PC,4) - imm32);
Exceptions
None.
A8.8.129 PLD, PLDW (register)

On an architecture variant that includes both the PLD and PLDW instructions, the PLD instruction signals that the likely
memory access is a read, and the PLDW instruction signals that it is a write.
The effect of a PLD or PLDW instruction is IMPLEMENTATION DEFINED. For more information, see Preloading caches
on page A3-155 and Behavior of Preload Data (PLD, PLDW) and Preload Instruction (PLI) with caches on
page B2-1267.

PLD{W}<c> [<Rn>, <Rm>{, LSL #<imm2>}]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 0 0 W 1 Rn 1 1 1 1 0 0 0 0 0 0 imm2 Rm

n = UInt(Rn); m = UInt(Rm); add = TRUE; is_pldw = (W == ‘1’);
Encoding A1 ARMv5TE*, ARMv6*, ARMv7 for PLD

PLD{W} [<Rn>,+/-<Rm>{, <shift>}]
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 1 1 1 U R 0 1 Rn (1) (1) (1) (1) imm5 type 0 Rm
n = UInt(Rn); m = UInt(Rm); add = (U == ‘1’); is_pldw = (R == ‘0’);

if m == 15 || (n == 15 && is_pldw) then UNPREDICTABLE;
Assembler syntax
PLD{W}{<c>}{<q>} [<Rn>, +/-<Rm> {, <shift>}]
where:
W If specified, selects PLDW, encoded as W = 1 in Thumb encodings and R = 0 in ARM encodings.

If omitted, selects PLD, encoded as W = 0 in Thumb encodings and R = 1 in ARM encodings.
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM PLD or PLDW instruction must be
unconditional.
<Rn> Is the base register. The SP can be used. The PC can be used in ARM PLD instructions, but not in
Thumb PLD instructions or in any PLDW instructions.
<shift> The shift to apply to the value read from <Rm>. If absent, no shift is applied. For encoding T1, <shift>
can only be omitted, encoded as imm2 = 0b00, or LSL #<imm> with <imm> = 1, 2, or 3, with <imm>
encoded in imm2. For encoding A1, see Shifts applied to a register on page A8-289.
Operation
address = if add then (R[n] + offset) else (R[n] - offset);
if is_pldw then
Hint_PreloadDataForWrite(address);
else
Exceptions
None.
A8.8.130 PLI (immediate, literal)

Preload Instruction signals the memory system that instruction memory accesses from a specified address are likely
in the near future. The memory system can respond by taking actions that are expected to speed up the memory
accesses when they do occur, such as pre-loading the cache line containing the specified address into the instruction
cache.
The effect of a PLI instruction is IMPLEMENTATION DEFINED. For more information, see Preloading caches on
page B2-1267.
Encoding T1 ARMv7
PLI<c> [<Rn>, #<imm12>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 1 1 0 0 1 Rn 1 1 1 1 imm12
if Rn == ‘1111’ then SEE encoding T3;

n = UInt(Rn); imm32 = ZeroExtend(imm12, 32); add = TRUE;
Encoding T2 ARMv7
PLI<c> [<Rn>, #-<imm8>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 1 0 0 0 1 Rn 1 1 1 1 1 1 0 0 imm8
if Rn == ‘1111’ then SEE encoding T3;

n = UInt(Rn); imm32 = ZeroExtend(imm8, 32); add = FALSE;
Encoding T3 ARMv7
PLI<c> <label>
PLI<c> [PC, #-0] Special case
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 1 U 0 0 1 1 1 1 1 1 1 1 1 imm12
n = 15; imm32 = ZeroExtend(imm12, 32); add = (U == ‘1’);
Encoding A1 ARMv7
PLI [<Rn>, #+/-<imm12>]
PLI <label>
PLI [PC, #-0] Special case
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 1 0 0 U 1 0 1 Rn (1) (1) (1) (1) imm12
n = UInt(Rn); imm32 = ZeroExtend(imm12, 32); add = (U == ‘1’);
Assembler syntax
PLI{<c>}{<q>} [<Rn> {, #+/-<imm>}] Immediate form
PLI{<c>}{<q>} <label> Normal literal form
PLI{<c>}{<q>} [PC, #+/-<imm>] Alternative literal form
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM PLI instruction must be
unconditional.
<Rn> Is the base register. The SP can be used.
for #0 and #-0.
<imm> The immediate offset used for forming the address. For the immediate form of the syntax, <imm> can
be omitted, in which case the #0 form of the instruction is assembled. Values are:
Encoding T1, T3, A1 any value in the range 0 to 4095
Encoding T2 any value in the range 0 to 255.
<label> The label of the instruction that is likely to be accessed in the near future. The assembler calculates
the required value of the offset from the Align(PC, 4) value of the instruction to this label. The offset
must be in the range –4095 to 4095.
For the literal forms of the instruction, encoding T3 is used, or Rn is encoded as 0b1111 in encoding A1, to indicate
that the PC is the base register.
The alternative literal syntax permits the addition or subtraction of the offset and the immediate offset to be specified
Operation
base = if n == 15 then Align(PC,4) else R[n];
Hint_PreloadInstr(address);
Exceptions
None.
A8.8.131 PLI (register)

Preload Instruction signals the memory system that instruction memory accesses from a specified address are likely
in the near future. The memory system can respond by taking actions that are expected to speed up the memory
accesses when they do occur, such as pre-loading the cache line containing the specified address into the instruction
cache. For more information, see Behavior of Preload Data (PLD, PLDW) and Preload Instruction (PLI) with
caches on page B2-1267.
The effect of a PLI instruction is IMPLEMENTATION DEFINED. For more information, see Preloading caches on
page B2-1267.
Encoding T1 ARMv7
PLI<c> [<Rn>, <Rm>{, LSL #<imm2>}]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 1 0 0 0 1 Rn 1 1 1 1 0 0 0 0 0 0 imm2 Rm
if Rn == ‘1111’ then SEE PLI (immediate, literal);

n = UInt(Rn); m = UInt(Rm); add = TRUE;
Encoding A1 ARMv7
PLI [<Rn>,+/-<Rm>{, <shift>}]
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 1 1 0 U 1 0 1 Rn (1) (1) (1) (1) imm5 type 0 Rm
n = UInt(Rn); m = UInt(Rm); add = (U == ‘1’);

Assembler syntax
PLI{<c>}{<q>} [<Rn>, +/-<Rm> {, <shift>}]
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM PLI instruction must be
unconditional.
<Rn> Is the base register. The SP can be used.
<shift> The shift to apply to the value read from <Rm>. If absent, no shift is applied. For encoding T1, <shift>
can only be omitted, encoded as imm2 = 0b00, or LSL #<imm> with <imm> = 1, 2, or 3, with <imm>
encoded in imm2. For encoding A1, see Shifts applied to a register on page A8-289.
Operation
address = if add then (R[n] + offset) else (R[n] - offset);
Hint_PreloadInstr(address);
Exceptions
None.
A8.8.132 POP (Thumb)

Pop Multiple Registers loads multiple registers from the stack, loading from consecutive memory locations starting
at the address in SP, and updates SP to point just above the loaded data.

POP<c> <registers>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 1 1 1 0 P register_list
registers = P:’0000000’:register_list; UnalignedAllowed = FALSE;


POP<c>.W <registers> <registers> contains more than one register
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 0 0 1 0 1 1 1 1 0 1 P M (0) register_list
registers = P:M:’0’:register_list; UnalignedAllowed = FALSE;

if BitCount(registers) < 2 || (P == ‘1’ && M == ‘1’) then UNPREDICTABLE;

POP<c>.W <registers> <registers> contains one register, <Rt>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 0 1 0 1 1 1 0 1 Rt 1 0 1 1 0 0 0 0 0 1 0 0
t = UInt(Rt); registers = Zeros(16); registers<t> = ‘1’; UnalignedAllowed = TRUE;

if t == 13 || (t == 15 && InITBlock() && !LastInITBlock()) then UNPREDICTABLE;
Assembler syntax
POP{<c>}{<q>} <registers> Standard syntax
LDM{<c>}{<q>} SP!, <registers> Equivalent LDM syntax
where:
If the list contains more than one register, the instruction is assembled to encoding T1 or T2. If the
list contains exactly one register, the instruction is assembled to encoding T1 or T3.
core registers on page A2-46. If the PC is in the list:
Operation
address = SP;
for i = 0 to 14
R[i] = if UnalignedAllowed then MemU[address,4] else MemA[address,4];
if UnalignedAllowed then
LoadWritePC(MemU[address,4]);
else
UNPREDICTABLE;
else
if registers<13> == ‘0’ then SP = SP + 4*BitCount(registers);
if registers<13> == ‘1’ then SP = bits(32) UNKNOWN;
Exceptions
Data Abort.
A8.8.133 POP (ARM)

Pop Multiple Registers loads multiple registers from the stack, loading from consecutive memory locations starting
at the address in SP, and updates SP to point just above the loaded data.

POP<c> <registers> <registers> contains more than one register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 0 0 0 1 0 1 1 1 1 0 1 register_list
if BitCount(register_list) < 2 then SEE LDM / LDMIA / LDMFD;

registers = register_list; UnalignedAllowed = FALSE;
if registers<13> == ‘1’ && ArchVersion() >= 7 then UNPREDICTABLE;

POP<c> <registers> <registers> contains one register, <Rt>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 0 0 1 0 0 1 1 1 0 1 Rt 0 0 0 0 0 0 0 0 0 1 0 0

Assembler syntax
POP{<c>}{<q>} <registers> Standard syntax
LDM{<c>}{<q>} SP!, <registers> Equivalent LDM syntax
where:
If the list contains more than one register, the instruction is assembled to encoding A1. If the list
contains exactly one register, the instruction is assembled to encoding A2.
The SP can only be in the list before ARMv7. ARM deprecates any use of ARM instructions that
include the SP, and the value of the SP after such an instruction is UNKNOWN.
core registers on page A2-46.
ARM deprecates the use of this instruction with both the LR and the PC in the list.
Operation
address = SP;
for i = 0 to 14
R[i] = if UnalignedAllowed then MemU[address,4] else MemA[address,4];
LoadWritePC(MemU[address,4]);
else
UNPREDICTABLE;
else
if registers<13> == ‘0’ then SP = SP + 4*BitCount(registers);
if registers<13> == ‘1’ then SP = bits(32) UNKNOWN;
Exceptions
Data Abort.
A8.8.134 PUSH
Push Multiple Registers stores multiple registers to the stack, storing to consecutive memory locations ending just
below the address in SP, and updates SP to point to the start of the stored data.

PUSH<c> <registers>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 1 0 1 0 M register_list
registers = ‘0’:M:’000000’:register_list; UnalignedAllowed = FALSE;


PUSH<c>.W <registers> <registers> contains more than one register
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 0 1 0 0 1 0 1 1 0 1 (0) M (0) register_list
registers = ‘0’:M:’0’:register_list; UnalignedAllowed = FALSE;


PUSH<c>.W <registers> <registers> contains one register, <Rt>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 0 1 0 0 1 1 0 1 Rt 1 1 0 1 0 0 0 0 0 1 0 0


PUSH<c> <registers> <registers> contains more than one register
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 0 0 1 0 0 1 0 1 1 0 1 register_list
if BitCount(register_list) < 2 then SEE STMDB / STMFD;

registers = register_list; UnalignedAllowed = FALSE;

PUSH<c> <registers> <registers> contains one register, <Rt>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 0 1 0 0 1 0 1 1 0 1 Rt 0 0 0 0 0 0 0 0 0 1 0 0

Assembler syntax
PUSH{<c>}{<q>} <registers> Standard syntax
STMDB{<c>}{<q>} SP!, <registers> Equivalent STM syntax
where:
<registers> Is a list of one or more registers to be stored, separated by commas and surrounded by { and }. The
lowest-numbered register is stored to the lowest memory address, through to the highest-numbered
register to the highest memory address. See also Encoding of lists of ARM core registers on
page A8-293.
If the list contains more than one register, the instruction is assembled to encoding T1, T2, or A1. If
the list contains exactly one register, the instruction is assembled to encoding T1, T3, or A2.
The SP and PC can be in the list in ARM instructions, but not in Thumb instructions. However:
• ARM deprecates the use of ARM instructions that include the PC in the list
• if the SP is in the list, and it is not the lowest-numbered register in the list, the instruction
stores an UNKNOWN value for the SP.
Operation
address = SP - 4*BitCount(registers);
for i = 0 to 14
if i == 13 && i != LowestSetBit(registers) then // Only possible for encoding A1
MemA[address,4] = bits(32) UNKNOWN;
else
MemU[address,4] = R[i];
else
MemA[address,4] = R[i];
if registers<15> == ‘1’ then // Only possible for encoding A1 or A2
MemU[address,4] = PCStoreValue();
else
MemA[address,4] = PCStoreValue();
SP = SP - 4*BitCount(registers);
Exceptions
Data Abort.
A8.8.135 QADD
Saturating Add adds two register values, saturates the result to the 32-bit signed integer range –231 to (231 – 1), and
writes the result to the destination register. If saturation occurs, it sets the Q flag in the APSR.

QADD<c> <Rd>, <Rm>, <Rn>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 0 0 Rn 1 1 1 1 Rd 1 0 0 0 Rm
d = UInt(Rd); n = UInt(Rn); m = UInt(Rm);


QADD<c> <Rd>, <Rm>, <Rn>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 0 0 0 0 Rn Rd (0) (0) (0) (0) 0 1 0 1 Rm

Assembler syntax
QADD{<c>}{<q>} {<Rd>,} <Rm>, <Rn>
where:
<Rm> The first operand register.
<Rn> The second operand register.
Operation
(R[d], sat) = SignedSatQ(SInt(R[m]) + SInt(R[n]), 32);
if sat then
APSR.Q = ‘1’;
Exceptions
None.
A8.8.136 QADD16
Saturating Add 16 performs two 16-bit integer additions, saturates the results to the 16-bit signed integer range
–215 ≤ x ≤ 215 – 1, and writes the results to the destination register.

QADD16<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 0 1 Rn 1 1 1 1 Rd 0 0 0 1 Rm


31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 0 1 0 Rn Rd (1) (1) (1) (1) 0 0 0 1 Rm

Assembler syntax
QADD16{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
Operation
sum1 = SInt(R[n]<15:0>) + SInt(R[m]<15:0>);
R[d]<15:0> = SignedSat(sum1, 16);
Exceptions
None.
A8.8.137 QADD8
Saturating Add 8 performs four 8-bit integer additions, saturates the results to the 8-bit signed integer range

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 0 0 Rn 1 1 1 1 Rd 0 0 0 1 Rm


31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 0 1 0 Rn Rd (1) (1) (1) (1) 1 0 0 1 Rm

Assembler syntax
QADD8{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
Operation
Exceptions
None.
A8.8.138 QASX
Saturating Add and Subtract with Exchange exchanges the two halfwords of the second operand, performs one
16-bit integer addition and one 16-bit subtraction, saturates the results to the 16-bit signed integer range

QASX<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 1 0 Rn 1 1 1 1 Rd 0 0 0 1 Rm


QASX<c> <Rd>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 0 1 0 Rn Rd (1) (1) (1) (1) 0 0 1 1 Rm

Assembler syntax
QASX{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
The pre-UAL syntax QADDSUBX<c> is equivalent to QASX<c>.
Operation
diff = SInt(R[n]<15:0>) - SInt(R[m]<31:16>);
sum = SInt(R[n]<31:16>) + SInt(R[m]<15:0>);
R[d]<15:0> = SignedSat(diff, 16);
R[d]<31:16> = SignedSat(sum, 16);
Exceptions
None.
A8.8.139 QDADD
Saturating Double and Add adds a doubled register value to another register value, and writes the result to the
destination register. Both the doubling and the addition have their results saturated to the 32-bit signed integer range
–231 ≤ x ≤ 231 – 1. If saturation occurs in either operation, it sets the Q flag in the APSR.

QDADD<c> <Rd>, <Rm>, <Rn>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 0 0 Rn 1 1 1 1 Rd 1 0 0 1 Rm


QDADD<c> <Rd>, <Rm>, <Rn>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 0 1 0 0 Rn Rd (0) (0) (0) (0) 0 1 0 1 Rm

Assembler syntax
QDADD{<c>}{<q>} {<Rd>,} <Rm>, <Rn>
where:
Operation
(doubled, sat1) = SignedSatQ(2 * SInt(R[n]), 32);
(R[d], sat2) = SignedSatQ(SInt(R[m]) + SInt(doubled), 32);
if sat1 || sat2 then
APSR.Q = ‘1’;
Exceptions
None.
A8.8.140 QDSUB
Saturating Double and Subtract subtracts a doubled register value from another register value, and writes the result
to the destination register. Both the doubling and the subtraction have their results saturated to the 32-bit signed
integer range –231 ≤ x ≤ 231 – 1. If saturation occurs in either operation, it sets the Q flag in the APSR.

QDSUB<c> <Rd>, <Rm>, <Rn>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 0 0 Rn 1 1 1 1 Rd 1 0 1 1 Rm


QDSUB<c> <Rd>, <Rm>, <Rn>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 0 1 1 0 Rn Rd (0) (0) (0) (0) 0 1 0 1 Rm

Assembler syntax
QDSUB{<c>}{<q>} {<Rd>,} <Rm>, <Rn>
where:
Operation
(doubled, sat1) = SignedSatQ(2 * SInt(R[n]), 32);
(R[d], sat2) = SignedSatQ(SInt(R[m]) - SInt(doubled), 32);
APSR.Q = ‘1’;
Exceptions
None.
A8.8.141 QSAX
Saturating Subtract and Add with Exchange exchanges the two halfwords of the second operand, performs one
16-bit integer subtraction and one 16-bit addition, saturates the results to the 16-bit signed integer range

QSAX<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 1 1 0 Rn 1 1 1 1 Rd 0 0 0 1 Rm


QSAX<c> <Rd>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 0 1 0 Rn Rd (1) (1) (1) (1) 0 1 0 1 Rm

Assembler syntax
QSAX{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
The pre-UAL syntax QSUBADDX<c> is equivalent to QSAX<c>.
Operation
R[d]<15:0> = SignedSat(sum, 16);
R[d]<31:16> = SignedSat(diff, 16);
Exceptions
None.
A8.8.142 QSUB
Saturating Subtract subtracts one register value from another register value, saturates the result to the 32-bit signed
integer range –231 ≤ x ≤ 231 – 1, and writes the result to the destination register. If saturation occurs, it sets the Q
flag in the APSR.

QSUB<c> <Rd>, <Rm>, <Rn>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 0 0 Rn 1 1 1 1 Rd 1 0 1 0 Rm


QSUB<c> <Rd>, <Rm>, <Rn>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 0 0 1 0 Rn Rd (0) (0) (0) (0) 0 1 0 1 Rm

Assembler syntax
QSUB{<c>}{<q>} {<Rd>,} <Rm>, <Rn>
where:
Operation
(R[d], sat) = SignedSatQ(SInt(R[m]) - SInt(R[n]), 32);
if sat then
APSR.Q = ‘1’;
Exceptions
None.
A8.8.143 QSUB16
Saturating Subtract 16 performs two 16-bit integer subtractions, saturates the results to the 16-bit signed integer
range –215 ≤ x ≤ 215 – 1, and writes the results to the destination register.

QSUB16<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 1 0 1 Rn 1 1 1 1 Rd 0 0 0 1 Rm


31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 0 1 0 Rn Rd (1) (1) (1) (1) 0 1 1 1 Rm

Assembler syntax
QSUB16{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
Operation
diff1 = SInt(R[n]<15:0>) - SInt(R[m]<15:0>);
R[d]<15:0> = SignedSat(diff1, 16);
Exceptions
None.
A8.8.144 QSUB8
Saturating Subtract 8 performs four 8-bit integer subtractions, saturates the results to the 8-bit signed integer range

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 1 0 0 Rn 1 1 1 1 Rd 0 0 0 1 Rm


31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 0 1 0 Rn Rd (1) (1) (1) (1) 1 1 1 1 Rm

Assembler syntax
QSUB8{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
Operation
Exceptions
None.
A8.8.145 RBIT
Reverse Bits reverses the bit order in a 32-bit register.

RBIT<c> <Rd>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 0 1 Rm 1 1 1 1 Rd 1 0 1 0 Rm


RBIT<c> <Rd>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 1 1 1 1 (1) (1) (1) (1) Rd (1) (1) (1) (1) 0 0 1 1 Rm
Assembler syntax
RBIT{<c>}{<q>} <Rd>, <Rm>
where:
<Rm> The register that contains the operand. In encoding T1, its number must be encoded twice.
Operation
bits(32) result;
for i = 0 to 31
result<31-i> = R[m]<i>;
R[d] = result;
Exceptions
None.
A8.8.146 REV
Byte-Reverse Word reverses the byte order in a 32-bit register.
Encoding T1 ARMv6*, ARMv7

REV<c> <Rd>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 1 1 0 1 0 0 0 Rm Rd

REV<c>.W <Rd>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 0 1 Rm 1 1 1 1 Rd 1 0 0 0 Rm


REV<c> <Rd>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 1 0 1 1 (1) (1) (1) (1) Rd (1) (1) (1) (1) 0 0 1 1 Rm
Assembler syntax
REV{<c>}{<q>} <Rd>, <Rm>
where:
Operation
bits(32) result;
result<31:24> = R[m]<7:0>;
result<23:16> = R[m]<15:8>;
result<15:8> = R[m]<23:16>;
result<7:0> = R[m]<31:24>;
R[d] = result;
Exceptions
None.
A8.8.147 REV16
Byte-Reverse Packed Halfword reverses the byte order in each16-bit halfword of a 32-bit register.

REV16<c> <Rd>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 1 1 0 1 0 0 1 Rm Rd

REV16<c>.W <Rd>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 0 1 Rm 1 1 1 1 Rd 1 0 0 1 Rm


REV16<c> <Rd>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 1 0 1 1 (1) (1) (1) (1) Rd (1) (1) (1) (1) 1 0 1 1 Rm
Assembler syntax
REV16{<c>}{<q>} <Rd>, <Rm>
where:
Operation
bits(32) result;
result<31:24> = R[m]<23:16>;
result<23:16> = R[m]<31:24>;
result<15:8> = R[m]<7:0>;
result<7:0> = R[m]<15:8>;
R[d] = result;
Exceptions
None.
A8.8.148 REVSH
Byte-Reverse Signed Halfword reverses the byte order in the lower 16-bit halfword of a 32-bit register, and
sign-extends the result to 32 bits.

REVSH<c> <Rd>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 1 1 0 1 0 1 1 Rm Rd

REVSH<c>.W <Rd>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 0 1 Rm 1 1 1 1 Rd 1 0 1 1 Rm


REVSH<c> <Rd>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 1 1 1 1 (1) (1) (1) (1) Rd (1) (1) (1) (1) 1 0 1 1 Rm
Assembler syntax
REVSH{<c>}{<q>} <Rd>, <Rm>
where:
Operation
bits(32) result;
result<31:8> = SignExtend(R[m]<7:0>, 24);
result<7:0> = R[m]<15:8>;
R[d] = result;
Exceptions
None.
A8.8.149 RFE
Return From Exception is a system instruction. For details see RFE on page B9-1986.
A8.8.150 ROR (immediate)

Rotate Right (immediate) provides the value of the contents of a register rotated by a constant value. The bits that
are rotated off the right end are inserted into the vacated bit positions on the left. It can optionally update the

ROR{S}<c> <Rd>, <Rm>, #<imm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 1 0 0 1 0 S 1 1 1 1 (0) imm3 Rd imm2 1 1 Rm
if (imm3:imm2) == ‘00000’ then SEE RRX;


ROR{S}<c> <Rd>, <Rm>, #<imm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 1 0 1 S (0) (0) (0) (0) Rd imm5 1 1 0 Rm
if imm5 == ‘00000’ then SEE RRX;
Assembler syntax
ROR{S}{<c>}{<q>} {<Rd>,} <Rm>, #<imm>
where:

Note
of the PC.
Operation
(result, carry) = Shift_C(R[m], SRType_ROR, shift_n, APSR.C);
else
R[d] = result;
if setflags then
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.151 ROR (register)

Rotate Right (register) provides the value of the contents of a register rotated by a variable number of bits. The bits
that are rotated off the right end are inserted into the vacated bit positions on the left. The variable number of bits is
read from the bottom byte of a register. It can optionally update the condition flags based on the result.

RORS <Rdn>, <Rm> Outside IT block.
ROR<c> <Rdn>, <Rm> Inside IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 0 0 0 1 1 1 Rm Rdn

ROR{S}<c>.W <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 0 1 1 S Rn 1 1 1 1 Rd 0 0 0 0 Rm


ROR{S}<c> <Rd>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 1 0 1 S (0) (0) (0) (0) Rd Rm 0 1 1 1 Rn

Assembler syntax
ROR{S}{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
<Rm> The register whose bottom byte contains the amount to rotate by.
Operation
(result, carry) = Shift_C(R[n], SRType_ROR, shift_n, APSR.C);
R[d] = result;
if setflags then
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.152 RRX
Rotate Right with Extend provides the value of the contents of a register shifted right by one place, with the Carry
flag shifted into bit[31].
RRX can optionally update the condition flags based on the result. In that case, bit[0] is shifted into the Carry flag.

RRX{S}<c> <Rd>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 1 0 0 1 0 S 1 1 1 1 (0) 0 0 0 Rd 0 0 1 1 Rm


RRX{S}<c> <Rd>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 1 0 1 S (0) (0) (0) (0) Rd 0 0 0 0 0 1 1 0 Rm
Assembler syntax
RRX{S}{<c>}{<q>} {<Rd>,} <Rm>
where:

Note
<Rm> The register that contains the operand. The PC can be used in ARM instructions, but ARM
Operation
(result, carry) = Shift_C(R[m], SRType_RRX, 1, APSR.C);
else
R[d] = result;
if setflags then
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.153 RSB (immediate)

Reverse Subtract (immediate) subtracts a register value from an immediate value, and writes the result to the

RSBS <Rd>, <Rn>, #0 Outside IT block.
RSB<c> <Rd>, <Rn>, #0 Inside IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 0 0 1 0 0 1 Rn Rd
d = UInt(Rd); n = UInt(Rn); setflags = !InITBlock(); imm32 = Zeros(32); // immediate = #0

RSB{S}<c>.W <Rd>, <Rn>, #<const>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 i 0 1 1 1 0 S Rn 0 imm3 Rd imm8


RSB{S}<c> <Rd>, <Rn>, #<const>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 0 0 1 1 S Rn Rd imm12
Assembler syntax
RSB{S}{<c>}{<q>} {<Rd>,} <Rn>, #<const>
where:
Note
of the PC.
<const> The immediate value to be added to the value obtained from <Rn>. The only permitted value for
encoding T1 is 0. See Modified immediate constants in Thumb instructions on page A6-230 or
Modified immediate constants in ARM instructions on page A5-197 for the range of values for
encoding T2 or A1.
The pre-UAL syntax RSB<c>S is equivalent to RSBS<c>.
Operation
(result, carry, overflow) = AddWithCarry(NOT(R[n]), imm32, ‘1’);
else
R[d] = result;
if setflags then
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.154 RSB (register)

Reverse Subtract (register) subtracts a register value from an optionally-shifted register value, and writes the result
to the destination register. It can optionally update the condition flags based on the result.

RSB{S}<c> <Rd>, <Rn>, <Rm>{, <shift>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0


RSB{S}<c> <Rd>, <Rn>, <Rm>{, <shift>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Assembler syntax
RSB{S}{<c>}{<q>} {<Rd>,} <Rn>, <Rm> {, <shift>}
where:
Note
of the PC.
Operation
(result, carry, overflow) = AddWithCarry(NOT(R[n]), shifted, ‘1’);
else
R[d] = result;
if setflags then
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.155 RSB (register-shifted register)

Reverse Subtract (register-shifted register) subtracts a register value from a register-shifted register value, and

RSB{S}<c> <Rd>, <Rn>, <Rm>, <type> <Rs>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Assembler syntax
RSB{S}{<c>}{<q>} {<Rd>,} <Rn>, <Rm>, <type> <Rs>
where:
Operation
(result, carry, overflow) = AddWithCarry(NOT(R[n]), shifted, ‘1’);
R[d] = result;
if setflags then
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.156 RSC (immediate)

Reverse Subtract with Carry (immediate) subtracts a register value and the value of NOT (Carry flag) from an
immediate value, and writes the result to the destination register. It can optionally update the condition flags based
on the result.

RSC{S}<c> <Rd>, <Rn>, #<const>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 0 1 1 1 S Rn Rd imm12
Assembler syntax
RSC{S}{<c>}{<q>} {<Rd>,} <Rn>, #<const>
where:
<Rn> The first operand register. The PC can be used, but ARM deprecates this use of the PC.
<const> The immediate value that the value obtained from <Rn> is to be subtracted from. See Modified
immediate constants in ARM instructions on page A5-197 for the range of values.
The pre-UAL syntax RSC<c>S is equivalent to RSCS<c>.
Operation
(result, carry, overflow) = AddWithCarry(NOT(R[n]), imm32, APSR.C);
if d == 15 then
else
R[d] = result;
if setflags then
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.157 RSC (register)

Reverse Subtract with Carry (register) subtracts a register value and the value of NOT (Carry flag) from an
optionally-shifted register value, and writes the result to the destination register. It can optionally update the

RSC{S}<c> <Rd>, <Rn>, <Rm>{, <shift>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Assembler syntax
RSC{S}{<c>}{<q>} {<Rd>,} <Rn>, <Rm> {, <shift>}
where:
Note
<Rn> The first operand register. The PC can be used, but ARM deprecates this use of the PC.
<Rm> The register that is optionally shifted and used as the second operand. The PC can be used, but ARM
Operation
(result, carry, overflow) = AddWithCarry(NOT(R[n]), shifted, APSR.C);
if d == 15 then
else
R[d] = result;
if setflags then
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.158 RSC (register-shifted register)

Reverse Subtract (register-shifted register) subtracts a register value and the value of NOT (Carry flag) from a
register-shifted register value, and writes the result to the destination register. It can optionally update the condition

RSC{S}<c> <Rd>, <Rn>, <Rm>, <type> <Rs>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Assembler syntax
RSC{S}{<c>}{<q>} {<Rd>,} <Rn>, <Rm>, <type> <Rs>
where:
Operation
(result, carry, overflow) = AddWithCarry(NOT(R[n]), shifted, APSR.C);
R[d] = result;
if setflags then
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.159 SADD16
Signed Add 16 performs two 16-bit signed integer additions, and writes the results to the destination register. It sets
the APSR.GE bits according to the results of the additions.

SADD16<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 0 1 Rn 1 1 1 1 Rd 0 0 0 0 Rm


31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 0 0 1 Rn Rd (1) (1) (1) (1) 0 0 0 1 Rm

Assembler syntax
SADD16{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
Operation
R[d]<15:0> = sum1<15:0>;
R[d]<31:16> = sum2<15:0>;
APSR.GE<1:0> = if sum1 >= 0 then ‘11’ else ‘00’;
APSR.GE<3:2> = if sum2 >= 0 then ‘11’ else ‘00’;
Exceptions
None.
A8.8.160 SADD8
Signed Add 8 performs four 8-bit signed integer additions, and writes the results to the destination register. It sets
the APSR.GE bits according to the results of the additions.

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 0 0 Rn 1 1 1 1 Rd 0 0 0 0 Rm


31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 0 0 1 Rn Rd (1) (1) (1) (1) 1 0 0 1 Rm

Assembler syntax
SADD8{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
Operation
R[d]<7:0> = sum1<7:0>;
R[d]<15:8> = sum2<7:0>;
R[d]<23:16> = sum3<7:0>;
R[d]<31:24> = sum4<7:0>;
APSR.GE<0> = if sum1 >= 0 then ‘1’ else ‘0’;
Exceptions
None.
A8.8.161 SASX
Signed Add and Subtract with Exchange exchanges the two halfwords of the second operand, performs one 16-bit
integer addition and one 16-bit subtraction, and writes the results to the destination register. It sets the APSR.GE
bits according to the results.

SASX<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 1 0 Rn 1 1 1 1 Rd 0 0 0 0 Rm


SASX<c> <Rd>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 0 0 1 Rn Rd (1) (1) (1) (1) 0 0 1 1 Rm

Assembler syntax
SASX{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
The pre-UAL syntax SADDSUBX<c> is equivalent to SASX<c>.
Operation
R[d]<15:0> = diff<15:0>;
R[d]<31:16> = sum<15:0>;
APSR.GE<1:0> = if diff >= 0 then ‘11’ else ‘00’;
APSR.GE<3:2> = if sum >= 0 then ‘11’ else ‘00’;
Exceptions
None.
A8.8.162 SBC (immediate)

Subtract with Carry (immediate) subtracts an immediate value and the value of NOT (Carry flag) from a register
value, and writes the result to the destination register. It can optionally update the condition flags based on the result.

SBC{S}<c> <Rd>, <Rn>, #<const>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 i 0 1 0 1 1 S Rn 0 imm3 Rd imm8


SBC{S}<c> <Rd>, <Rn>, #<const>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 0 1 1 0 S Rn Rd imm12
Assembler syntax
SBC{S}{<c>}{<q>} {<Rd>,} <Rn>, #<const>
where:
Note
of the PC.
<const> The immediate value to be subtracted from the value obtained from <Rn>. See Modified immediate
The pre-UAL syntax SBC<c>S is equivalent to SBCS<c>.
Operation
(result, carry, overflow) = AddWithCarry(R[n], NOT(imm32), APSR.C);
else
R[d] = result;
if setflags then
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.163 SBC (register)

Subtract with Carry (register) subtracts an optionally-shifted register value and the value of NOT (Carry flag) from
a register value, and writes the result to the destination register. It can optionally update the condition flags based
on the result.

SBCS <Rdn>, <Rm> Outside IT block.
SBC<c> <Rdn>, <Rm> Inside IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 0 0 0 1 1 0 Rm Rdn


SBC{S}<c>.W <Rd>, <Rn>, <Rm>{, <shift>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0


SBC{S}<c> <Rd>, <Rn>, <Rm>{, <shift>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Assembler syntax
SBC{S}{<c>}{<q>} {<Rd>,} <Rn>, <Rm> {, <shift>}
where:
Note
of the PC.
Operation
(result, carry, overflow) = AddWithCarry(R[n], NOT(shifted), APSR.C);
else
R[d] = result;
if setflags then
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.164 SBC (register-shifted register)

Subtract with Carry (register-shifted register) subtracts a register-shifted register value and the value of NOT (Carry
flag) from a register value, and writes the result to the destination register. It can optionally update the condition

SBC{S}<c> <Rd>, <Rn>, <Rm>, <type> <Rs>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Assembler syntax
SBC{S}{<c>}{<q>} {<Rd>,} <Rn>, <Rm>, <type> <Rs>
where:
Operation
(result, carry, overflow) = AddWithCarry(R[n], NOT(shifted), APSR.C);
R[d] = result;
if setflags then
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.165 SBFX
Signed Bit Field Extract extracts any number of adjacent bits at any position from a register, sign-extends them to
32 bits, and writes the result to the destination register.

SBFX<c> <Rd>, <Rn>, #<lsb>, #<width>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 (0) 1 1 0 1 0 0 Rn 0 imm3 Rd imm2 (0) widthm1
d = UInt(Rd); n = UInt(Rn);
lsbit = UInt(imm3:imm2); widthminus1 = UInt(widthm1);

SBFX<c> <Rd>, <Rn>, #<lsb>, #<width>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 1 1 0 1 widthm1 Rd lsb 1 0 1 Rn
lsbit = UInt(lsb); widthminus1 = UInt(widthm1);
if d == 15 || n == 15 then UNPREDICTABLE;
Assembler syntax
SBFX{<c>}{<q>} <Rd>, <Rn>, #<lsb>, #<width>
where:
<lsb> is the bit number of the least significant bit in the field, in the range 0-31. This determines the
required value of lsbit.
<width> is the width of the field, in the range 1 to 32-<lsb>. The required value of widthminus1 is <width>-1.
Operation
msbit = lsbit + widthminus1;
if msbit <= 31 then
R[d] = SignExtend(R[n]<msbit:lsbit>, 32);
else
UNPREDICTABLE;
Exceptions
None.
A8.8.166 SDIV
Signed Divide divides a 32-bit signed integer register value by a 32-bit signed integer register value, and writes the
result to the destination register. The condition flags are not affected.
See ARMv7 implementation requirements and options for the divide instructions on page A4-170 for more
information about this instruction.
Encoding T1 ARMv7-R, ARMv7VE, otherwise OPTIONAL in ARMv7-A

SDIV<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 1 0 0 1 Rn (1) (1) (1) (1) Rd 1 1 1 1 Rm

Encoding A1 ARMv7VE, otherwise OPTIONAL in ARMv7-A and ARMv7-R

SDIV<c> <Rd>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 1 0 0 0 1 Rd (1) (1) (1) (1) Rm 0 0 0 1 Rn

Assembler syntax
SDIV{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
<Rn> The register that contains the dividend.
<Rm> The register that contains the divisor.
Operation
if SInt(R[m]) == 0 then
if IntegerZeroDivideTrappingEnabled() then
GenerateIntegerZeroDivide();
else
result = 0;
else
result = RoundTowardsZero(SInt(R[n]) / SInt(R[m]));
Exceptions
In ARMv7-R profile, Undefined Instruction, see Divide instructions on page A4-170.
In ARMv7-A profile, none.
Overflow
If the signed integer division 0x80000000 / 0xFFFFFFFF is performed, the pseudocode produces the intermediate
integer result +231, that overflows the 32-bit signed integer range. No indication of this overflow case is produced,
and the 32-bit result written to R[d] must be the bottom 32 bits of the binary representation of +231. So the result of
the division is 0x80000000.
A8.8.167 SEL
Select Bytes selects each byte of its result from either its first operand or its second operand, according to the values
of the GE flags.

SEL<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 1 0 Rn 1 1 1 1 Rd 1 0 0 0 Rm


SEL<c> <Rd>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 1 0 0 0 Rn Rd (1) (1) (1) (1) 1 0 1 1 Rm

Assembler syntax
SEL{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
Operation
R[d]<7:0> = if APSR.GE<0> == ‘1’ then R[n]<7:0> else R[m]<7:0>;
Exceptions
None.
A8.8.168 SETEND
Set Endianness writes a new value to ENDIANSTATE.

SETEND <endian_specifier> Not permitted in IT block
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 1 0 1 1 0 0 1 0 (1) E (0) (0) (0)
set_bigend = (E == ‘1’);

SETEND <endian_specifier> Cannot be conditional
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 0 1 0 0 0 0 (0) (0) (0) 1 (0) (0) (0) (0) (0) (0) E (0) 0 0 0 0 (0) (0) (0) (0)
set_bigend = (E == ‘1’);
Assembler syntax
SETEND{<q>} <endian_specifier>
where:
<q> See Standard assembler syntax fields on page A8-285. A SETEND instruction must be unconditional.
<endian_specifier>
Is one of:
BE Sets the E bit in the instruction. This sets ENDIANSTATE.
LE Clears the E bit in the instruction. This clears ENDIANSTATE.
Operation
ENDIANSTATE = if set_bigend then ‘1’ else ‘0’;
Exceptions
None.
A8.8.169 SEV
Send Event is a hint instruction. It causes an event to be signaled to all processors in the multiprocessor system. For
more information, see Wait For Event and Send Event on page B1-1199.

SEV<c>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 1 1 1 1 1 0 1 0 0 0 0 0 0

SEV<c>.W
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 0 1 0 (1) (1) (1) (1) 1 0 (0) 0 (0) 0 0 0 0 0 0 0 0 1 0 0
Encoding A1 ARMv6K, ARMv7 (executes as NOP in ARMv6T2)

SEV<c>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 1 0 0 1 0 0 0 0 0 (1) (1) (1) (1) (0) (0) (0) (0) 0 0 0 0 0 1 0 0
Assembler syntax
SEV{<c>}{<q>}
where:
Operation
SendEvent();
Exceptions
None.
A8.8.170 SHADD16
Signed Halving Add 16 performs two signed 16-bit integer additions, halves the results, and writes the results to the

SHADD16<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 0 1 Rn 1 1 1 1 Rd 0 0 1 0 Rm


31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 0 1 1 Rn Rd (1) (1) (1) (1) 0 0 0 1 Rm

Assembler syntax
SHADD16{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
Operation
R[d]<15:0> = sum1<16:1>;
R[d]<31:16> = sum2<16:1>;
Exceptions
None.
A8.8.171 SHADD8
Signed Halving Add 8 performs four signed 8-bit integer additions, halves the results, and writes the results to the

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 0 0 Rn 1 1 1 1 Rd 0 0 1 0 Rm


31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 0 1 1 Rn Rd (1) (1) (1) (1) 1 0 0 1 Rm

Assembler syntax
SHADD8{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
Operation
R[d]<7:0> = sum1<8:1>;
R[d]<15:8> = sum2<8:1>;
R[d]<23:16> = sum3<8:1>;
R[d]<31:24> = sum4<8:1>;
Exceptions
None.
A8.8.172 SHASX
Signed Halving Add and Subtract with Exchange exchanges the two halfwords of the second operand, performs one
signed 16-bit integer addition and one signed 16-bit subtraction, halves the results, and writes the results to the

SHASX<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 1 0 Rn 1 1 1 1 Rd 0 0 1 0 Rm


SHASX<c> <Rd>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 0 1 1 Rn Rd (1) (1) (1) (1) 0 0 1 1 Rm

Assembler syntax
SHASX{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
The pre-UAL syntax SHADDSUBX<c> is equivalent to SHASX<c>.
Operation
R[d]<15:0> = diff<16:1>;
R[d]<31:16> = sum<16:1>;
Exceptions
None.
A8.8.173 SHSAX
Signed Halving Subtract and Add with Exchange exchanges the two halfwords of the second operand, performs one
signed 16-bit integer subtraction and one signed 16-bit addition, halves the results, and writes the results to the

SHSAX<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 1 1 0 Rn 1 1 1 1 Rd 0 0 1 0 Rm


SHSAX<c> <Rd>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 0 1 1 Rn Rd (1) (1) (1) (1) 0 1 0 1 Rm

Assembler syntax
SHSAX{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
The pre-UAL syntax SHSUBADDX<c> is equivalent to SHSAX<c>.
Operation
R[d]<15:0> = sum<16:1>;
R[d]<31:16> = diff<16:1>;
Exceptions
None.
A8.8.174 SHSUB16
Signed Halving Subtract 16 performs two signed 16-bit integer subtractions, halves the results, and writes the results
to the destination register.

SHSUB16<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 1 0 1 Rn 1 1 1 1 Rd 0 0 1 0 Rm


31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 0 1 1 Rn Rd (1) (1) (1) (1) 0 1 1 1 Rm

Assembler syntax
SHSUB16{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
Operation
R[d]<15:0> = diff1<16:1>;
R[d]<31:16> = diff2<16:1>;
Exceptions
None.
A8.8.175 SHSUB8
Signed Halving Subtract 8 performs four signed 8-bit integer subtractions, halves the results, and writes the results

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 1 0 0 Rn 1 1 1 1 Rd 0 0 1 0 Rm


31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 0 1 1 Rn Rd (1) (1) (1) (1) 1 1 1 1 Rm

Assembler syntax
SHSUB8{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
Operation
R[d]<7:0> = diff1<8:1>;
R[d]<15:8> = diff2<8:1>;
R[d]<23:16> = diff3<8:1>;
R[d]<31:24> = diff4<8:1>;
Exceptions
None.
A8.8.176 SMC (previously SMI)

Secure Monitor Call is a system instruction. For details see SMC (previously SMI) on page B9-1988.
A8.8.177 SMLABB, SMLABT, SMLATB, SMLATT

Signed Multiply Accumulate (halfwords) performs a signed multiply accumulate operation. The multiply acts on
two signed 16-bit quantities, taken from either the bottom or the top half of their respective source registers. The
other halves of these source registers are ignored. The 32-bit product is added to a 32-bit accumulate value and the
result is written to the destination register.
If overflow occurs during the addition of the accumulate value, the instruction sets the Q flag in the APSR. It is not
possible for overflow to occur during the multiplication.

SMLA<x><y><c> <Rd>, <Rn>, <Rm>, <Ra>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 0 0 0 1 Rn Ra Rd 0 0 N M Rm
if Ra == ‘1111’ then SEE SMULBB, SMULBT, SMULTB, SMULTT;

n_high = (N == ‘1’); m_high = (M == ‘1’);

SMLA<x><y><c> <Rd>, <Rn>, <Rm>, <Ra>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 0 0 0 0 Rd Ra Rm 1 M N 0 Rn

n_high = (N == ‘1’); m_high = (M == ‘1’);
Assembler syntax
SMLA<x><y>{<c>}{<q>} <Rd>, <Rn>, <Rm>, <Ra>
where:
<x> Specifies which half of the source register <Rn> is used as the first multiply operand. If <x> is B, then
the bottom half (bits[15:0]) of <Rn> is used. If <x> is T, then the top half (bits[31:16]) of <Rn> is used.
<y> Specifies which half of the source register <Rm> is used as the second multiply operand. If <y> is B,
then the bottom half (bits[15:0]) of <Rm> is used. If <y> is T, then the top half (bits[31:16]) of <Rm> is
used.
<Rn> The source register whose bottom or top half (selected by <x>) is the first multiply operand.
<Rm> The source register whose bottom or top half (selected by <y>) is the second multiply operand.
<Ra> The register that contains the accumulate value.
Operation
operand1 = if n_high then R[n]<31:16> else R[n]<15:0>;
operand2 = if m_high then R[m]<31:16> else R[m]<15:0>;
result = SInt(operand1) * SInt(operand2) + SInt(R[a]);
if result != SInt(result<31:0>) then // Signed overflow
APSR.Q = ‘1’;
Exceptions
None.
A8.8.178 SMLAD
Signed Multiply Accumulate Dual performs two signed 16 × 16-bit multiplications. It adds the products to a 32-bit
accumulate operand.
Optionally, the instruction can exchange the halfwords of the second operand before performing the arithmetic. This
produces top × bottom and bottom × top multiplication.
This instruction sets the Q flag if the accumulate operation overflows. Overflow cannot occur during the
multiplications.

SMLAD{X}<c> <Rd>, <Rn>, <Rm>, <Ra>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 0 0 1 0 Rn Ra Rd 0 0 0 M Rm
if Ra == ‘1111’ then SEE SMUAD;

m_swap = (M == ‘1’);

SMLAD{X}<c> <Rd>, <Rn>, <Rm>, <Ra>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 1 0 0 0 0 Rd Ra Rm 0 0 M 1 Rn
if Ra == ‘1111’ then SEE SMUAD;

m_swap = (M == ‘1’);
Assembler syntax
SMLAD{X}{<c>}{<q>} <Rd>, <Rn>, <Rm>, <Ra>
where:
X If X is present (encoded as M = 1), the multiplications are bottom × top and top × bottom.
If the X is omitted (encoded as M = 0), the multiplications are bottom × bottom and top × top.
Operation
operand2 = if m_swap then ROR(R[m],16) else R[m];
product1 = SInt(R[n]<15:0>) * SInt(operand2<15:0>);
result = product1 + product2 + SInt(R[a]);
APSR.Q = ‘1’;
Exceptions
None.
A8.8.179 SMLAL
Signed Multiply Accumulate Long multiplies two signed 32-bit values to produce a 64-bit value, and accumulates
this with a 64-bit value.
In ARM instructions, the condition flags can optionally be updated based on the result. Use of this option adversely
affects performance on many processor implementations.

SMLAL<c> <RdLo>, <RdHi>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 1 1 0 0 Rn RdLo RdHi 0 0 0 0 Rm
dLo = UInt(RdLo); dHi = UInt(RdHi); n = UInt(Rn); m = UInt(Rm); setflags = FALSE;

if dLo IN {13,15} || dHi IN {13,15} || n IN {13,15} || m IN {13,15} then UNPREDICTABLE;
if dHi == dLo then UNPREDICTABLE;

SMLAL{S}<c> <RdLo>, <RdHi>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 0 1 1 1 S RdHi RdLo Rm 1 0 0 1 Rn
dLo = UInt(RdLo); dHi = UInt(RdHi); n = UInt(Rn); m = UInt(Rm); setflags = (S == ‘1’);

if dLo == 15 || dHi == 15 || n == 15 || m == 15 then UNPREDICTABLE;
if ArchVersion() < 6 && (dHi == n || dLo == n) then UNPREDICTABLE;
Assembler syntax
SMLAL{S}{<c>}{<q>} <RdLo>, <RdHi>, <Rn>, <Rm>
where:
<RdLo> Supplies the lower 32 bits of the accumulate value, and is the destination register for the lower 32
bits of the result.
<RdHi> Supplies the upper 32 bits of the accumulate value, and is the destination register for the upper 32
bits of the result.
The pre-UAL syntax SMLAL<c>S is equivalent to SMLALS<c>.
Operation
result = SInt(R[n]) * SInt(R[m]) + SInt(R[dHi]:R[dLo]);
R[dHi] = result<63:32>;
R[dLo] = result<31:0>;
if setflags then
APSR.V = bit UNKNOWN;
// else APSR.C, APSR.V unchanged
Exceptions
None.
A8.8.180 SMLALBB, SMLALBT, SMLALTB, SMLALTT

Signed Multiply Accumulate Long (halfwords) multiplies two signed 16-bit values to produce a 32-bit value, and
accumulates this with a 64-bit value. The multiply acts on two signed 16-bit quantities, taken from either the bottom
or the top half of their respective source registers. The other halves of these source registers are ignored. The 32-bit
product is sign-extended and accumulated with a 64-bit accumulate value.
Overflow is possible during this instruction, but only as a result of the 64-bit addition. This overflow is not detected
if it occurs. Instead, the result wraps around modulo 264.

SMLAL<x><y><c> <RdLo>, <RdHi>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 1 1 0 0 Rn RdLo RdHi 1 0 N M Rm
dLo = UInt(RdLo); dHi = UInt(RdHi); n = UInt(Rn); m = UInt(Rm);

n_high = (N == ‘1’); m_high = (M == ‘1’);

SMLAL<x><y><c> <RdLo>, <RdHi>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 0 1 0 0 RdHi RdLo Rm 1 M N 0 Rn

n_high = (N == ‘1’); m_high = (M == ‘1’);
Assembler syntax
SMLAL<x><y>{<c>}{<q>} <RdLo>, <RdHi>, <Rn>, <Rm>
where:
used.
bits of the result.
bits of the result.
Operation
result = SInt(operand1) * SInt(operand2) + SInt(R[dHi]:R[dLo]);
Exceptions
None.
A8.8.181 SMLALD
Signed Multiply Accumulate Long Dual performs two signed 16 × 16-bit multiplications. It adds the products to a
64-bit accumulate operand.

SMLALD{X}<c> <RdLo>, <RdHi>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 1 1 0 0 Rn RdLo RdHi 1 1 0 M Rm
dLo = UInt(RdLo); dHi = UInt(RdHi); n = UInt(Rn); m = UInt(Rm); m_swap = (M == ‘1’);


SMLALD{X}<c> <RdLo>, <RdHi>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 1 0 1 0 0 RdHi RdLo Rm 0 0 M 1 Rn

Assembler syntax
SMLALD{X}{<c>}{<q>} <RdLo>, <RdHi>, <Rn>, <Rm>
where:
X If X is present, the multiplications are bottom × top and top × bottom.

If the X is omitted, the multiplications are bottom × bottom and top × top.
bits of the result.
bits of the result.
Operation
result = product1 + product2 + SInt(R[dHi]:R[dLo]);
Exceptions
None.
A8.8.182 SMLAWB, SMLAWT

Signed Multiply Accumulate (word by halfword) performs a signed multiply accumulate operation. The multiply
acts on a signed 32-bit quantity and a signed 16-bit quantity. The signed 16-bit quantity is taken from either the
bottom or the top half of its source register. The other half of the second source register is ignored. The top 32 bits
of the 48-bit product are added to a 32-bit accumulate value and the result is written to the destination register. The
bottom 16 bits of the 48-bit product are ignored.
If overflow occurs during the addition of the accumulate value, the instruction sets the Q flag in the APSR. No
overflow can occur during the multiplication.

SMLAW<y><c> <Rd>, <Rn>, <Rm>, <Ra>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 0 0 1 1 Rn Ra Rd 0 0 0 M Rm
if Ra == ‘1111’ then SEE SMULWB, SMULWT;

d = UInt(Rd); n = UInt(Rn); m = UInt(Rm); a = UInt(Ra); m_high = (M == ‘1’);

SMLAW<y><c> <Rd>, <Rn>, <Rm>, <Ra>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 0 0 1 0 Rd Ra Rm 1 M 0 0 Rn
d = UInt(Rd); n = UInt(Rn); m = UInt(Rm); a = UInt(Ra); m_high = (M == ‘1’);

Assembler syntax
SMLAW<y>{<c>}{<q>} <Rd>, <Rn>, <Rm>, <Ra>
where:
used.
Operation
result = SInt(R[n]) * SInt(operand2) + (SInt(R[a]) << 16);
R[d] = result<47:16>;
if (result >> 16) != SInt(R[d]) then // Signed overflow
APSR.Q = ‘1’;
Exceptions
None.
A8.8.183 SMLSD
Signed Multiply Subtract Dual performs two signed 16 × 16-bit multiplications. It adds the difference of the
products to a 32-bit accumulate operand.
This instruction sets the Q flag if the accumulate operation overflows. Overflow cannot occur during the
multiplications or subtraction.

SMLSD{X}<c> <Rd>, <Rn>, <Rm>, <Ra>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 0 1 0 0 Rn Ra Rd 0 0 0 M Rm
if Ra == ‘1111’ then SEE SMUSD;

d = UInt(Rd); n = UInt(Rn); m = UInt(Rm); a = UInt(Ra); m_swap = (M == ‘1’);

SMLSD{X}<c> <Rd>, <Rn>, <Rm>, <Ra>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 1 0 0 0 0 Rd Ra Rm 0 1 M 1 Rn
if Ra == ‘1111’ then SEE SMUSD;

d = UInt(Rd); n = UInt(Rn); m = UInt(Rm); a = UInt(Ra); m_swap = (M == ‘1’);
Assembler syntax
SMLSD{X}{<c>}{<q>} <Rd>, <Rn>, <Rm>, <Ra>
where:

Operation
result = product1 - product2 + SInt(R[a]);
APSR.Q = ‘1’;
Exceptions
None.
A8.8.184 SMLSLD
Signed Multiply Subtract Long Dual performs two signed 16 × 16-bit multiplications. It adds the difference of the
products to a 64-bit accumulate operand.

SMLSLD{X}<c> <RdLo>, <RdHi>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 1 1 0 1 Rn RdLo RdHi 1 1 0 M Rm


SMLSLD{X}<c> <RdLo>, <RdHi>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 1 0 1 0 0 RdHi RdLo Rm 0 1 M 1 Rn

Assembler syntax
SMLSLD{X}{<c>}{<q>} <RdLo>, <RdHi>, <Rn>, <Rm>
where:

bits of the result.
bits of the result.
Operation
result = product1 - product2 + SInt(R[dHi]:R[dLo]);
Exceptions
None.
A8.8.185 SMMLA
Signed Most Significant Word Multiply Accumulate multiplies two signed 32-bit values, extracts the most
significant 32 bits of the result, and adds an accumulate value.
Optionally, the instruction can specify that the result is rounded instead of being truncated. In this case, the constant
0x80000000 is added to the product before the high word is extracted.

SMMLA{R}<c> <Rd>, <Rn>, <Rm>, <Ra>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 0 1 0 1 Rn Ra Rd 0 0 0 R Rm
if Ra == ‘1111’ then SEE SMMUL;

d = UInt(Rd); n = UInt(Rn); m = UInt(Rm); a = UInt(Ra); round = (R == ‘1’);

SMMLA{R}<c> <Rd>, <Rn>, <Rm>, <Ra>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 1 0 1 0 1 Rd Ra Rm 0 0 R 1 Rn
if Ra == ‘1111’ then SEE SMMUL;

Assembler syntax
SMMLA{R}{<c>}{<q>} <Rd>, <Rn>, <Rm>, <Ra>
where:
R If R is present, the multiplication is rounded.

If the R is omitted, the multiplication is truncated.
<Rn> The register that contains the first multiply operand.
<Rm> The register that contains the second multiply operand.
Operation
result = (SInt(R[a]) << 32) + SInt(R[n]) * SInt(R[m]);
if round then result = result + 0x80000000;
R[d] = result<63:32>;
Exceptions
None.
A8.8.186 SMMLS
Signed Most Significant Word Multiply Subtract multiplies two signed 32-bit values, subtracts the result from a
32-bit accumulate value that is shifted left by 32 bits, and extracts the most significant 32 bits of the result of that
subtraction.
Optionally, the instruction can specify that the result of the instruction is rounded instead of being truncated. In this
case, the constant 0x80000000 is added to the result of the subtraction before the high word is extracted.

SMMLS{R}<c> <Rd>, <Rn>, <Rm>, <Ra>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 0 1 1 0 Rn Ra Rd 0 0 0 R Rm

if d IN {13,15} || n IN {13,15} || m IN {13,15} || a IN {13,15} then UNPREDICTABLE;

SMMLS{R}<c> <Rd>, <Rn>, <Rm>, <Ra>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 1 0 1 0 1 Rd Ra Rm 1 1 R 1 Rn

Assembler syntax
SMMLS{R}{<c>}{<q>} <Rd>, <Rn>, <Rm>, <Ra>
where:

Operation
result = (SInt(R[a]) << 32) - SInt(R[n]) * SInt(R[m]);
R[d] = result<63:32>;
Exceptions
None.
A8.8.187 SMMUL
Signed Most Significant Word Multiply multiplies two signed 32-bit values, extracts the most significant 32 bits of
the result, and writes those bits to the destination register.
Optionally, the instruction can specify that the result is rounded instead of being truncated. In this case, the constant
0x80000000 is added to the product before the high word is extracted.

SMMUL{R}<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 0 1 0 1 Rn 1 1 1 1 Rd 0 0 0 R Rm
d = UInt(Rd); n = UInt(Rn); m = UInt(Rm); round = (R == ‘1’);


SMMUL{R}<c> <Rd>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 1 0 1 0 1 Rd 1 1 1 1 Rm 0 0 R 1 Rn
d = UInt(Rd); n = UInt(Rn); m = UInt(Rm); round = (R == ‘1’);

Assembler syntax
SMMUL{R}{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:

Operation
result = SInt(R[n]) * SInt(R[m]);
R[d] = result<63:32>;
Exceptions
None.
A8.8.188 SMUAD
Signed Dual Multiply Add performs two signed 16 × 16-bit multiplications. It adds the products together, and writes
the result to the destination register.
This instruction sets the Q flag if the addition overflows. The multiplications cannot overflow.

SMUAD{X}<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 0 0 1 0 Rn 1 1 1 1 Rd 0 0 0 M Rm
d = UInt(Rd); n = UInt(Rn); m = UInt(Rm); m_swap = (M == ‘1’);


SMUAD{X}<c> <Rd>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 1 0 0 0 0 Rd 1 1 1 1 Rm 0 0 M 1 Rn

Assembler syntax
SMUAD{X}{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:

Operation
result = product1 + product2;
APSR.Q = ‘1’;
Exceptions
None.
A8.8.189 SMULBB, SMULBT, SMULTB, SMULTT

Signed Multiply (halfwords) multiplies two signed 16-bit quantities, taken from either the bottom or the top half of
their respective source registers. The other halves of these source registers are ignored. The 32-bit product is written
to the destination register. No overflow is possible during this instruction.

SMUL<x><y><c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 0 0 0 1 Rn 1 1 1 1 Rd 0 0 N M Rm

n_high = (N == ‘1’); m_high = (M == ‘1’);

SMUL<x><y><c> <Rd>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 0 1 1 0 Rd (0) (0) (0) (0) Rm 1 M N 0 Rn

n_high = (N == ‘1’); m_high = (M == ‘1’);
Assembler syntax
SMUL<x><y>{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
used.
Operation
result = SInt(operand1) * SInt(operand2);
// Signed overflow cannot occur
Exceptions
None.
A8.8.190 SMULL
Signed Multiply Long multiplies two 32-bit signed values to produce a 64-bit result.

SMULL<c> <RdLo>, <RdHi>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 1 0 0 0 Rn RdLo RdHi 0 0 0 0 Rm


SMULL{S}<c> <RdLo>, <RdHi>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Assembler syntax
SMULL{S}{<c>}{<q>} <RdLo>, <RdHi>, <Rn>, <Rm>
where:
<RdLo> Stores the lower 32 bits of the result.
<RdHi> Stores the upper 32 bits of the result.
The pre-UAL syntax SMULL<c>S is equivalent to SMULLS<c>.
Operation
result = SInt(R[n]) * SInt(R[m]);
if setflags then
Exceptions
None.
A8.8.191 SMULWB, SMULWT

Signed Multiply (word by halfword) multiplies a signed 32-bit quantity and a signed 16-bit quantity. The signed
16-bit quantity is taken from either the bottom or the top half of its source register. The other half of the second
source register is ignored. The top 32 bits of the 48-bit product are written to the destination register. The bottom
16 bits of the 48-bit product are ignored. No overflow is possible during this instruction.

SMULW<y><c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 0 0 1 1 Rn 1 1 1 1 Rd 0 0 0 M Rm
d = UInt(Rd); n = UInt(Rn); m = UInt(Rm); m_high = (M == ‘1’);


SMULW<y><c> <Rd>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 0 0 1 0 Rd (0) (0) (0) (0) Rm 1 M 1 0 Rn
d = UInt(Rd); n = UInt(Rn); m = UInt(Rm); m_high = (M == ‘1’);

Assembler syntax
SMULW<y>{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
used.
Operation
product = SInt(R[n]) * SInt(operand2);
R[d] = product<47:16>;
Exceptions
None.
A8.8.192 SMUSD
Signed Multiply Subtract Dual performs two signed 16 × 16-bit multiplications. It subtracts one of the products from
the other, and writes the result to the destination register.
Overflow cannot occur.

SMUSD{X}<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 0 1 0 0 Rn 1 1 1 1 Rd 0 0 0 M Rm


SMUSD{X}<c> <Rd>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 1 0 0 0 0 Rd 1 1 1 1 Rm 0 1 M 1 Rn

Assembler syntax
SMUSD{X}{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:

Operation
result = product1 - product2;
Exceptions
None.
A8.8.193 SRS
Store Return State is a system instruction. For details see SRS (Thumb) on page B9-1990 and SRS (ARM) on
page B9-1992.
A8.8.194 SSAT
Signed Saturate saturates an optionally-shifted signed value to a selectable signed range.
The Q flag is set if the operation saturates.

SSAT<c> <Rd>, #<imm>, <Rn>{, <shift>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 (0) 1 1 0 0 sh 0 Rn 0 imm3 Rd imm2 (0) sat_imm
if sh == ‘1’ && (imm3:imm2) == ‘00000’ then SEE SSAT16;

d = UInt(Rd); n = UInt(Rn); saturate_to = UInt(sat_imm)+1;
(shift_t, shift_n) = DecodeImmShift(sh:’0’, imm3:imm2);

SSAT<c> <Rd>, #<imm>, <Rn>{, <shift>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 1 0 1 sat_imm Rd imm5 sh 0 1 Rn

(shift_t, shift_n) = DecodeImmShift(sh:’0’, imm5);
Assembler syntax
SSAT{<c>}{<q>} <Rd>, #<imm>, <Rn> {, <shift>}
where:
<imm> The bit position for saturation, in the range 1 to 32. The sat_imm field of the instruction encodes this
bit position, by taking the value (<imm>-1).
<Rn> The register that contains the value to be saturated.
<shift> The optional shift, encoded in the sh bit and the immsh field, where immsh is:
• imm3:imm2 for encoding T1
• imm5 for encoding A1.
<shift> must be one of:
omitted No shift. Encoded as sh = 0, immsh = 0b00000.
LSL #<n> Left shift by <n> bits, with <n> in the range 1-31.
Encoded as sh = 0, immsh = <n>.
ASR #<n> Arithmetic right shift by <n> bits, with <n> in the range 1-31.
ASR #32 Arithmetic right shift by 32 bits, permitted only for encoding A1.
Encoded as sh = 1, immsh = 0b00000.
Note
An assembler can permit ASR #0 or LSL #0 to mean the same thing as omitting the shift, but this is
not standard UAL and must not be used for disassembly.
Operation
operand = Shift(R[n], shift_t, shift_n, APSR.C); // APSR.C ignored
(result, sat) = SignedSatQ(SInt(operand), saturate_to);
R[d] = SignExtend(result, 32);
if sat then
APSR.Q = ‘1’;
Exceptions
None.
A8.8.195 SSAT16
Signed Saturate 16 saturates two signed 16-bit values to a selected signed range.

SSAT16<c> <Rd>, #<imm>, <Rn>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 (0) 1 1 0 0 1 0 Rn 0 0 0 0 Rd 0 0 (0) (0) sat_imm


SSAT16<c> <Rd>, #<imm>, <Rn>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 1 0 1 0 sat_imm Rd (1) (1) (1) (1) 0 0 1 1 Rn

Assembler syntax
SSAT16{<c>}{<q>} <Rd>, #<imm>, <Rn>
where:
<imm> The bit position for saturation, in the range 1 to 16. The sat_imm field of the instruction encodes this
bit position, by taking the value (<imm>-1).
<Rn> The register that contains the values to be saturated.
Operation
(result1, sat1) = SignedSatQ(SInt(R[n]<15:0>), saturate_to);
(result2, sat2) = SignedSatQ(SInt(R[n]<31:16>), saturate_to);
R[d]<15:0> = SignExtend(result1, 16);
R[d]<31:16> = SignExtend(result2, 16);
APSR.Q = ‘1’;
Exceptions
None.
A8.8.196 SSAX
Signed Subtract and Add with Exchange exchanges the two halfwords of the second operand, performs one 16-bit
integer subtraction and one 16-bit addition, and writes the results to the destination register. It sets the APSR.GE
bits according to the results.

SSAX<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 1 1 0 Rn 1 1 1 1 Rd 0 0 0 0 Rm


SSAX<c> <Rd>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 0 0 1 Rn Rd (1) (1) (1) (1) 0 1 0 1 Rm

Assembler syntax
SSAX{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
The pre-UAL syntax SSUBADDX<c> is equivalent to SSAX<c>.
Operation
R[d]<15:0> = sum<15:0>;
R[d]<31:16> = diff<15:0>;
APSR.GE<1:0> = if sum >= 0 then ‘11’ else ‘00’;
Exceptions
None.
A8.8.197 SSUB16
Signed Subtract 16 performs two 16-bit signed integer subtractions, and writes the results to the destination register.
It sets the APSR.GE bits according to the results of the subtractions.

SSUB16<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 1 0 1 Rn 1 1 1 1 Rd 0 0 0 0 Rm


31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 0 0 1 Rn Rd (1) (1) (1) (1) 0 1 1 1 Rm

Assembler syntax
SSUB16{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
Operation
R[d]<15:0> = diff1<15:0>;
R[d]<31:16> = diff2<15:0>;
APSR.GE<1:0> = if diff1 >= 0 then ‘11’ else ‘00’;
Exceptions
None.
A8.8.198 SSUB8
Signed Subtract 8 performs four 8-bit signed integer subtractions, and writes the results to the destination register.
It sets the APSR.GE bits according to the results of the subtractions.

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 1 0 0 Rn 1 1 1 1 Rd 0 0 0 0 Rm


31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 0 0 1 Rn Rd (1) (1) (1) (1) 1 1 1 1 Rm

Assembler syntax
SSUB8{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
Operation
R[d]<7:0> = diff1<7:0>;
R[d]<15:8> = diff2<7:0>;
R[d]<23:16> = diff3<7:0>;
R[d]<31:24> = diff4<7:0>;
APSR.GE<0> = if diff1 >= 0 then ‘1’ else ‘0’;
Exceptions
None.
A8.8.199 STC, STC2

Store Coprocessor stores data from a coprocessor to a sequence of consecutive memory addresses. If no coprocessor
can execute the instruction, an Undefined Instruction exception is generated.
manual defines the valid STC and STC2 instructions when coproc is in the range p8-p15. For more information see
Coprocessor support on page A2-93 and General behavior of system control registers on page B5-1768.
In an implementation that includes the Virtualization Extensions, the permitted STC access to a system control
register can be trapped to Hyp mode, meaning that an attempt to execute an STC instruction in a Non-secure mode
Note
For simplicity, the STC pseudocode does not show this possible trap to Hyp mode.

STC{L}<c> <coproc>, <CRd>, [<Rn>, #+/-<imm>]{!}
STC{L}<c> <coproc>, <CRd>, [<Rn>], #+/-<imm>
STC{L}<c> <coproc>, <CRd>, [<Rn>], <option>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 0 P U D W 0 Rn CRd coproc imm8

if P == ‘0’ && U == ‘0’ && D == ‘1’ && W == ‘0’ then SEE MCRR, MCRR2;
if n == 15 && (wback || CurrentInstrSet() != InstrSet_ARM) then UNPREDICTABLE;

STC2{L}<c> <coproc>, <CRd>, [<Rn>, #+/-<imm>]{!}
STC2{L}<c> <coproc>, <CRd>, [<Rn>], #+/-<imm>
STC2{L}<c> <coproc>, <CRd>, [<Rn>], <option>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

if P == ‘0’ && U == ‘0’ && D == ‘1’ && W == ‘0’ then SEE MCRR, MCRR2;
Assembler syntax
STC{2}{L}{<c>}{<q>} <coproc>, <CRd>, [<Rn>{, #+/-<imm>}] Offset. P = 1, W = 0.
STC{2}{L}{<c>}{<q>} <coproc>, <CRd>, [<Rn>, #+/-<imm>]! Pre-indexed. P = 1, W = 1.
STC{2}{L}{<c>}{<q>} <coproc>, <CRd>, [<Rn>], #+/-<imm> Post-indexed. P = 0, W = 1.
STC{2}{L}{<c>}{<q>} <coproc>, <CRd>, [<Rn>], <option> Unindexed. P = 0, W = 0, U = 1.
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM STC2 instruction must be
unconditional.
<CRd> The coprocessor source register.
<Rn> The base register. The SP can be used. In the ARM instruction set, for offset and unindexed
addressing only, the PC can be used. However, ARM deprecates use of the PC.
+/- Is + or omitted if the immediate offset is to be added to the base register value (add == TRUE), or – if
it is to be subtracted (add == FALSE). #0 and #-0 generate different instructions.
For the offset addressing syntax, <imm> can be omitted, meaning an offset of +0.
<option> A coprocessor option. An integer in the range 0-255 enclosed in { }. Encoded in imm8.
The pre-UAL syntax STC<c>L is equivalent to STCL<c>.
Operation
else
NullCheckIfThumbEE(n);
repeat
MemA[address,4] = Coproc_GetWordToStore(cp, ThisInstr());
until Coproc_DoneStoring(cp, ThisInstr());
Exceptions
A8.8.200 STM (STMIA, STMEA)

Store Multiple Increment After (Store Multiple Empty Ascending) stores multiple registers to consecutive memory
address just above the last of those locations can optionally be written back to the base register.
For details of related system instructions see STM (User registers) on page B9-1994.
Encoding T1 ARMv4T, ARMv5T*, ARMv6*, ARMv7 (not in ThumbEE)

STM<c> <Rn>!, <registers>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 0 0 0 Rn register_list
if CurrentInstrSet() == InstrSet_ThumbEE then SEE “ThumbEE instructions”;

n = UInt(Rn); registers = ‘00000000’:register_list; wback = TRUE;

STM<c>.W <Rn>{!}, <registers>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 0 0 1 0 W 0 Rn (0) M (0) register_list
n = UInt(Rn); registers = ‘0’:M:’0’:register_list; wback = (W == ‘1’);


STM<c> <Rn>{!}, <registers>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

ThumbEE instructions See 16-bit ThumbEE instructions on page A9-1115.
Assembler syntax
STM{<c>}{<q>} <Rn>{!}, <registers>
where:

page A8-293.
Encoding T2 does not support a list containing only one register. If an STM instruction with just one
register <Rt> in the list is assembled to Thumb and encoding T1 is not available, it is assembled to
the equivalent STR{<c>}{<q>} <Rt>, [<Rn>]{, #4} instruction.
The SP and PC can be in the list in ARM instructions, but not in Thumb instructions. However,
ARM deprecates the use of ARM instructions that include the SP or the PC in the list.
ARM deprecates the use of instructions with the base register in the list and ! specified. If the base
register is not the lowest-numbered register in the list, such an instruction stores an UNKNOWN value
for the base register.
An instruction with the base register in the list and ! specified cannot use encoding T2.
STMEA and STMIA are pseudo-instructions for STM. STMEA refers to its use for pushing data onto Empty Ascending
stacks.
The pre-UAL syntaxes STM<c>IA and STM<c>EA are equivalent to STM<c>.
Operation
address = R[n];
for i = 0 to 14
if i == n && wback && i != LowestSetBit(registers) then
MemA[address,4] = bits(32) UNKNOWN; // Only possible for encodings T1 and A1
else
if registers<15> == ‘1’ then // Only possible for encoding A1
if wback then R[n] = R[n] + 4*BitCount(registers);
Exceptions
Data Abort.
A8.8.201 STMDA (STMED)

Store Multiple Decrement After (Store Multiple Empty Descending) stores multiple registers to consecutive
memory locations using an address from a base register. The consecutive memory locations end at this address, and
the address just below the lowest of those locations can optionally be written back to the base register.

STMDA<c> <Rn>{!}, <registers>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Assembler syntax
STMDA{<c>}{<q>} <Rn>{!}, <registers>
where:

page A8-293.
The SP and PC can be in the list. However, ARM deprecates the use of instructions that include the
SP or the PC in the list.
STMED is s pseudo-instruction for STMDA, referring to its use for pushing data onto Empty Descending stacks.
The pre-UAL syntaxes STM<c>DA and STM<c>ED are equivalent to STMDA<c>.
Operation
address = R[n] - 4*BitCount(registers) + 4;
for i = 0 to 14
else
if wback then R[n] = R[n] - 4*BitCount(registers);
Exceptions
Data Abort.
A8.8.202 STMDB (STMFD)

Store Multiple Decrement Before (Store Multiple Full Descending) stores multiple registers to consecutive memory
locations using an address from a base register. The consecutive memory locations end just below this address, and
the address of the first of those locations can optionally be written back to the base register.

STMDB<c> <Rn>{!}, <registers>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 0 1 0 0 W 0 Rn (0) M (0) register_list
if W == ‘1’ && Rn == ‘1101’ then SEE PUSH;

n = UInt(Rn); registers = ‘0’:M:’0’:register_list; wback = (W == ‘1’);

STMDB<c> <Rn>{!}, <registers>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if W == ‘1’ && Rn == ‘1101’ && BitCount(register_list) >= 2 then SEE PUSH;

Assembler syntax
STMDB{<c>}{<q>} <Rn>{!}, <registers>
where:
<Rn> The base register. The SP can be used. If the SP is used, and ! is specified:
• for encoding T1, it is treated as described in PUSH on page A8-539
• for encoding A1, if there is more than one register in the <registers> list, it is treated as
described in PUSH on page A8-539.

page A8-293.
Encoding T1 does not support a list containing only one register. If an STMDB instruction with just
one register <Rt> in the list is assembled to Thumb, it is assembled to the equivalent STR{<c>}{<q>}
<Rt>, [<Rn>, #-4]{!} instruction.
The SP and PC can be in the list in ARM instructions, but not in Thumb instructions. However,
ARM deprecates the use of ARM instructions that include the SP or the PC in the list.
Instructions with the base register in the list and ! specified are only available in the ARM
instruction set, and ARM deprecates the use of such instructions. If the base register is not the
lowest-numbered register in the list, such an instruction stores an UNKNOWN value for the base
register.
STMFD is a pseudo-instruction for STMDB, referring to its use for pushing data onto Full Descending stacks.
The pre-UAL syntaxes STM<c>DB and STM<c>FD are equivalent to STMDB<c>.
Operation
address = R[n] - 4*BitCount(registers);
for i = 0 to 14
MemA[address,4] = bits(32) UNKNOWN; // Only possible for encoding A1
else
if registers<15> == ‘1’ then // Only possible for encoding A1
if wback then R[n] = R[n] - 4*BitCount(registers);
Exceptions
Data Abort.
A8.8.203 STMIB (STMFA)

Store Multiple Increment Before (Store Multiple Full Ascending) stores multiple registers to consecutive memory
locations using an address from a base register. The consecutive memory locations start just above this address, and
the address of the last of those locations can optionally be written back to the base register.

STMIB<c> <Rn>{!}, <registers>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Assembler syntax
STMIB{<c>}{<q>} <Rn>{!}, <registers>
where:

page A8-293.
The SP and PC can be in the list. However, ARM deprecates the use of instructions that include the
SP or the PC in the list.
STMFA is a pseudo-instruction for STMIB, referring to its use for pushing data onto Full Ascending stacks.
The pre-UAL syntax STM<c>IB and STM<c>FA are equivalent to STMIB<c>.
Operation
address = R[n] + 4;
for i = 0 to 14
else
if wback then R[n] = R[n] + 4*BitCount(registers);
Exceptions
Data Abort.
A8.8.204 STR (immediate, Thumb)

Store Register (immediate) calculates an address from a base register value and an immediate offset, and stores a
word from a register to memory. It can use offset, post-indexed, or pre-indexed addressing. For information about

STR<c> <Rt>, [<Rn>{, #<imm>}]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 1 0 0 imm5 Rn Rt


STR<c> <Rt>, [SP, #<imm>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 0 1 0 Rt imm8
t = UInt(Rt); n = 13; imm32 = ZeroExtend(imm8:’00’, 32);


STR<c>.W <Rt>, [<Rn>, #<imm12>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 1 1 0 0 Rn Rt imm12
if Rn == ‘1111’ then UNDEFINED;


STR<c> <Rt>, [<Rn>, #-<imm8>]
STR<c> <Rt>, [<Rn>], #+/-<imm8>
STR<c> <Rt>, [<Rn>, #+/-<imm8>]!
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 0 1 0 0 Rn Rt 1 P U W imm8
if P == ‘1’ && U == ‘1’ && W == ‘0’ then SEE STRT;

if Rn == ‘1101’ && P == ‘1’ && U == ‘0’ && W == ‘1’ && imm8 == ‘00000100’ then SEE PUSH;
if Rn == ‘1111’ || (P == ‘0’ && W == ‘0’) then UNDEFINED;
Assembler syntax
STR{<c>}{<q>} <Rt>, [<Rn> {, #+/-<imm>}] Offset: index==TRUE, wback==FALSE
STR{<c>}{<q>} <Rt>, [<Rn>, #+/-<imm>]! Pre-indexed: index==TRUE, wback==TRUE
STR{<c>}{<q>} <Rt>, [<Rn>], #+/-<imm> Post-indexed: index==FALSE, wback==TRUE
where:
<Rt> The source register. The SP can be used.
<imm> The immediate offset used for forming the address. Values are:
For the offset addressing syntax, <imm> can be omitted, meaning an offset of 0.
Operation
if UnalignedSupport() || address<1:0> == ‘00’ then
MemU[address,4] = R[t];
else // Can only occur before ARMv7
MemU[address,4] = bits(32) UNKNOWN;
Exceptions
Data Abort.
ThumbEE instruction
ThumbEE has an additional STR (immediate) encoding. For details see STR (immediate) on page A9-1130.
A8.8.205 STR (immediate, ARM)

Store Register (immediate) calculates an address from a base register value and an immediate offset, and stores a
word from a register to memory. It can use offset, post-indexed, or pre-indexed addressing. For information about

STR<c> <Rt>, [<Rn>{, #+/-<imm12>}]
STR<c> <Rt>, [<Rn>], #+/-<imm12>
STR<c> <Rt>, [<Rn>, #+/-<imm12>]!
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if P == ‘0’ && W == ‘1’ then SEE STRT;

if Rn == ‘1101’ && P == ‘1’ && U == ‘0’ && W == ‘1’ && imm12 == ‘000000000100’ then SEE PUSH;
Assembler syntax
STR{<c>}{<q>} <Rt>, [<Rn> {, #+/-<imm>}] Offset: index==TRUE, wback==FALSE
STR{<c>}{<q>} <Rt>, [<Rn>, #+/-<imm>]! Pre-indexed: index==TRUE, wback==TRUE
STR{<c>}{<q>} <Rt>, [<Rn>], #+/-<imm> Post-indexed: index==FALSE, wback==TRUE
where:
<Rt> The source register. The SP or the PC can be used. However, ARM deprecates use of the PC.
<Rn> The base register. The SP can be used. For offset addressing only, the PC can be used. However,
ARM deprecates use of the PC.
<imm> The immediate offset used for forming the address. Any value in the range 0-4095 is permitted. For
the offset addressing syntax, <imm> can be omitted, meaning an offset of 0.
Operation
MemU[address,4] = if t == 15 then PCStoreValue() else R[t];
Exceptions
Data Abort.
A8.8.206 STR (register)

Store Register (register) calculates an address from a base register value and an offset register value, stores a word
from a register to memory. The offset register value can optionally be shifted. For information about memory

STR<c> <Rt>, [<Rn>, <Rm>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 1 0 0 0 Rm Rn Rt


STR<c>.W <Rt>, [<Rn>, <Rm>{, LSL #<imm2>}]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 0 1 0 0 Rn Rt 0 0 0 0 0 0 imm2 Rm


STR<c> <Rt>, [<Rn>,+/-<Rm>{, <shift>}]{!}
STR<c> <Rt>, [<Rn>],+/-<Rm>{, <shift>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if P == ‘0’ && W == ‘1’ then SEE STRT;

Modified operation in ThumbEE See STR (register) on page A9-1121
Assembler syntax
STR{<c>}{<q>} <Rt>, [<Rn>, <Rm>{, <shift>}] Offset: index==TRUE, wback==FALSE
STR{<c>}{<q>} <Rt>, [<Rn>, <Rm>{, <shift>}]! Pre-indexed: index==TRUE, wback==TRUE
STR{<c>}{<q>} <Rt>, [<Rn>], <Rm>{, <shift>} Post-indexed: index==FALSE, wback==TRUE
where:
<Rt> The source register. The SP can be used. In the ARM instruction set, the PC can be used. However,
<Rn> The base register. The SP can be used. In the ARM instruction set, for offset addressing only, the
PC can be used. However, ARM deprecates use of the PC.
<Rm> Contains the offset that is optionally shifted and added to the value of <Rn> to form the address.
Operation
if t == 15 then // Only possible for encoding A1
data = PCStoreValue();
else
data = R[t];
if UnalignedSupport() || address<1:0> == ‘00’ || CurrentInstrSet() == InstrSet_ARM then
MemU[address,4] = data;
Exceptions
Data Abort.
A8.8.207 STRB (immediate, Thumb)

Store Register Byte (immediate) calculates an address from a base register value and an immediate offset, and stores
a byte from a register to memory. It can use offset, post-indexed, or pre-indexed addressing. For information about

STRB<c> <Rt>, [<Rn>, #<imm5>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 1 1 0 imm5 Rn Rt


STRB<c>.W <Rt>, [<Rn>, #<imm12>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 1 0 0 0 Rn Rt imm12


STRB<c> <Rt>, [<Rn>, #-<imm8>]
STRB<c> <Rt>, [<Rn>], #+/-<imm8>
STRB<c> <Rt>, [<Rn>, #+/-<imm8>]!
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 0 0 0 0 Rn Rt 1 P U W imm8
if P == ‘1’ && U == ‘1’ && W == ‘0’ then SEE STRBT;

if t IN {13,15} || (wback && n == t) then UNPREDICTABLE;
Assembler syntax
STRB{<c>}{<q>} <Rt>, [<Rn> {, #+/-<imm>}] Offset: index==TRUE, wback==FALSE
STRB{<c>}{<q>} <Rt>, [<Rn>, #+/-<imm>]! Pre-indexed: index==TRUE, wback==TRUE
STRB{<c>}{<q>} <Rt>, [<Rn>], #+/-<imm> Post-indexed: index==FALSE, wback==TRUE
where:
<Rt> The source register.
The pre-UAL syntax STR<c>B is equivalent to STRB<c>.
Operation
MemU[address,1] = R[t]<7:0>;
Exceptions
Data Abort.
A8.8.208 STRB (immediate, ARM)

Store Register Byte (immediate) calculates an address from a base register value and an immediate offset, and stores
a byte from a register to memory. It can use offset, post-indexed, or pre-indexed addressing. For information about

STRB<c> <Rt>, [<Rn>{, #+/-<imm12>}]
STRB<c> <Rt>, [<Rn>], #+/-<imm12>
STRB<c> <Rt>, [<Rn>, #+/-<imm12>]!
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if P == ‘0’ && W == ‘1’ then SEE STRBT;

Assembler syntax
STRB{<c>}{<q>} <Rt>, [<Rn> {, #+/-<imm>}] Offset: index==TRUE, wback==FALSE
STRB{<c>}{<q>} <Rt>, [<Rn>, #+/-<imm>]! Pre-indexed: index==TRUE, wback==TRUE
STRB{<c>}{<q>} <Rt>, [<Rn>], #+/-<imm> Post-indexed: index==FALSE, wback==TRUE
where:
<imm> The immediate offset used for forming the address. Values are 0-4095. For the offset addressing
syntax, <imm> can be omitted, meaning an offset of 0.
Operation
Exceptions
Data Abort.
A8.8.209 STRB (register)

Store Register Byte (register) calculates an address from a base register value and an offset register value, and stores
a byte from a register to memory. The offset register value can optionally be shifted. For information about memory

STRB<c> <Rt>, [<Rn>, <Rm>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 1 0 1 0 Rm Rn Rt


STRB<c>.W <Rt>, [<Rn>, <Rm>{, LSL #<imm2>}]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 0 0 0 0 Rn Rt 0 0 0 0 0 0 imm2 Rm

if t IN {13,15} || m IN {13,15} then UNPREDICTABLE;

STRB<c> <Rt>, [<Rn>,+/-<Rm>{, <shift>}]{!}
STRB<c> <Rt>, [<Rn>],+/-<Rm>{, <shift>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if P == ‘0’ && W == ‘1’ then SEE STRBT;

Assembler syntax
STRB{<c>}{<q>} <Rt>, [<Rn>, <Rm>{, <shift>}] Offset: index==TRUE, wback==FALSE
STRB{<c>}{<q>} <Rt>, [<Rn>, <Rm>{, <shift>}]! Pre-indexed: index==TRUE, wback==TRUE
STRB{<c>}{<q>} <Rt>, [<Rn>], <Rm>{, <shift>} Post-indexed: index==FALSE, wback==TRUE
where:
Operation
Exceptions
Data Abort.
A8.8.210 STRBT
Store Register Byte Unprivileged stores a byte from a register to memory. For information about memory accesses
see Memory accesses on page A8-292.
STRBT is UNPREDICTABLE in Hyp mode.

STRBT<c> <Rt>, [<Rn>, #<imm8>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 0 0 0 0 Rn Rt 1 1 1 0 imm8


STRBT<c> <Rt>, [<Rn>], #+/-<imm12>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 0 0 U 1 1 0 Rn Rt imm12


STRBT<c> <Rt>, [<Rn>],+/-<Rm>{, <shift>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Assembler syntax
STRBT{<c>}{<q>} <Rt>, [<Rn> {, #<imm>}] Offset: Thumb only
STRBT{<c>}{<q>} <Rt>, [<Rn>] {, #<imm>} Post-indexed: ARM only
STRBT{<c>}{<q>} <Rt>, [<Rn>], +/-<Rm> {, <shift>} Post-indexed: ARM only
where:
The pre-UAL syntax STR<c>BT is equivalent to STRBT<c>.
Operation
MemU_unpriv[address,1] = R[t]<7:0>;
Exceptions
Data Abort.
A8.8.211 STRD (immediate)

Store Register Dual (immediate) calculates an address from a base register value and an immediate offset, and stores
two words from two registers to memory. It can use offset, post-indexed, or pre-indexed addressing. For information

STRD<c> <Rt>, <Rt2>, [<Rn>{, #+/-<imm>}]
STRD<c> <Rt>, <Rt2>, [<Rn>], #+/-<imm>
STRD<c> <Rt>, <Rt2>, [<Rn>, #+/-<imm>]!
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 0 P U 1 W 0 Rn Rt Rt2 imm8

t = UInt(Rt); t2 = UInt(Rt2); n = UInt(Rn); imm32 = ZeroExtend(imm8:’00’, 32);
if n == 15 || t IN {13,15} || t2 IN {13,15} then UNPREDICTABLE;

STRD<c> <Rt>, <Rt2>, [<Rn>{, #+/-<imm8>}]
STRD<c> <Rt>, <Rt2>, [<Rn>], #+/-<imm8>
STRD<c> <Rt>, <Rt2>, [<Rn>, #+/-<imm8>]!
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

t = UInt(Rt); t2 = t+1; n = UInt(Rn); imm32 = ZeroExtend(imm4H:imm4L, 32);
Assembler syntax
STRD{<c>}{<q>} <Rt>, <Rt2>, [<Rn> {, #+/-<imm>}] Offset: index==TRUE, wback==FALSE
STRD{<c>}{<q>} <Rt>, <Rt2>, [<Rn>, #+/-<imm>]! Pre-indexed: index==TRUE, wback==TRUE
STRD{<c>}{<q>} <Rt>, <Rt2>, [<Rn>], #+/-<imm> Post-indexed: index==FALSE, wback==TRUE
where:
<Rt> The first source register. For an ARM instruction, <Rt> must be even-numbered and not R14.
<Rt2> The second source register. For an ARM instruction, <Rt2> must be <R(t+1)>.
<imm> The immediate offset used for forming the address. Values are multiples of 4 in the range 0-1020
for encoding T1, and any value in the range 0-255 for encoding A1. For the offset addressing syntax,
<imm> can be omitted, meaning an offset of 0.
The pre-UAL syntax STR<c>D is equivalent to STRD<c>.
Operation
bits(64) data;
if BigEndian() then
data<63:32> = R[t];
data<31:0> = R[t2];
else
data<31:0> = R[t];
data<63:32> = R[t2];
MemA[address,8] = data;
else
MemA[address,4] = R[t];
MemA[address+4,4] = R[t2];
Exceptions
Data Abort.
A8.8.212 STRD (register)

Store Register Dual (register) calculates an address from a base register value and a register offset, and stores two
words from two registers to memory. It can use offset, post-indexed, or pre-indexed addressing. For information

STRD<c> <Rt>, <Rt2>, [<Rn>,+/-<Rm>]{!}
STRD<c> <Rt>, <Rt2>, [<Rn>],+/-<Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 P U 0 W 0 Rn Rt (0) (0) (0) (0) 1 1 1 1 Rm

t = UInt(Rt); t2 = t+1; n = UInt(Rn); m = UInt(Rm);
if t2 == 15 || m == 15 then UNPREDICTABLE;
Assembler syntax
STRD{<c>}{<q>} <Rt>, <Rt2>, [<Rn>, +/-<Rm>] Offset: index==TRUE, wback==FALSE
STRD{<c>}{<q>} <Rt>, <Rt2>, [<Rn>, +/-<Rm>]! Pre-indexed: index==TRUE, wback==TRUE
STRD{<c>}{<q>} <Rt>, <Rt2>, [<Rn>], +/-<Rm> Post-indexed: index==FALSE, wback==TRUE
where:
<Rt> The first source register. This register must be even-numbered and not R14.
<Rt2> The second source register. This register must be <R(t+1)>.
it is to be subtracted (add == FALSE).
<Rm> Contains the offset that is added to the value of <Rn> to form the address.
The pre-UAL syntax STR<c>D is equivalent to STRD<c>.
Operation
offset_addr = if add then (R[n] + R[m]) else (R[n] - R[m]);
bits(64) data;
if BigEndian() then
data<63:32> = R[t];
data<31:0> = R[t2];
else
data<31:0> = R[t];
data<63:32> = R[t2];
MemA[address,8] = data;
else
MemA[address+4,4] = R[t2];
Exceptions
Data Abort.
A8.8.213 STREX
Store Register Exclusive calculates an address from a base register value and an immediate offset, stores a word
from a register to memory if the executing processor has exclusive access to the memory addressed, and returns a
status word that indicates whether this store was performed.

STREX<c> <Rd>, <Rt>, [<Rn>{, #<imm>}]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 0 0 0 1 0 0 Rn Rt Rd imm8
d = UInt(Rd); t = UInt(Rt); n = UInt(Rn); imm32 = ZeroExtend(imm8:’00’, 32);

if d IN {13,15} || t IN {13,15} || n == 15 then UNPREDICTABLE;
if d == n || d == t then UNPREDICTABLE;

STREX<c> <Rd>, <Rt>, [<Rn>]
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 1 0 0 0 Rn Rd (1) (1) (1) (1) 1 0 0 1 Rt
d = UInt(Rd); t = UInt(Rt); n = UInt(Rn); imm32 = Zeros(32); // Zero offset

if d == 15 || t == 15 || n == 15 then UNPREDICTABLE;
Assembler syntax
STREX{<c>}{<q>} <Rd>, <Rt>, [<Rn> {, #<imm>}]
where:
<Rd> The destination register for the returned status value. The value returned is:
0 if the operation updates memory
1 if the operation fails to update memory.
<imm> The immediate offset added to the value of <Rn> to form the address. Values are multiples of 4 in the
range 0-1020 for encoding T1, and 0 for encoding A1. <imm> can be omitted, meaning an offset of 0.
Operation
address = R[n] + imm32;
if ExclusiveMonitorsPass(address,4) then
R[d] = ZeroExtend(‘0’, 32);
else
Exceptions
Data Abort.
Aborts and alignment

If a synchronous Data Abort exception is generated by the execution of this instruction:
• memory is not updated
• <Rd> is not updated.
In ARMv7, a non word-aligned memory address causes an Alignment fault Data Abort exception to be generated,
subject to the following rules:
• If ExclusiveMonitorsPass() returns TRUE, the exception is generated.
• Otherwise, it is IMPLEMENTATION DEFINED whether the exception is generated.
If ExclusiveMonitorsPass() returns FALSE and the memory address, if accessed, would generate a synchronous Data
Abort exception, it is IMPLEMENTATION DEFINED whether the exception is generated.
Note
In ARMv6:
• If SCTLR.A and SCTLR.U are both 0, a non word-aligned memory address causes UNPREDICTABLE
behavior.
• Otherwise, the ARMv7 behavior applies.
A8.8.214 STREXB
Store Register Exclusive Byte derives an address from a base register value, stores a byte from a register to memory
if the executing processor has exclusive access to the memory addressed, and returns a status word that indicates
whether this store was performed.
Encoding T1 ARMv7
STREXB<c> <Rd>, <Rt>, [<Rn>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 0 0 1 1 0 0 Rn Rt (1) (1) (1) (1) 0 1 0 0 Rd
d = UInt(Rd); t = UInt(Rt); n = UInt(Rn);


STREXB<c> <Rd>, <Rt>, [<Rn>]
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 1 1 0 0 Rn Rd (1) (1) (1) (1) 1 0 0 1 Rt

Assembler syntax
STREXB{<c>}{<q>} <Rd>, <Rt>, [<Rn>]
where:
Operation
address = R[n];
MemA[address,1] = R[t]<7:0>;
else
Exceptions
Data Abort.
Aborts
A8.8.215 STREXD
Store Register Exclusive Doubleword derives an address from a base register value, stores a 64-bit doubleword from
two registers to memory if the executing processor has exclusive access to the memory addressed, and returns a
status word that indicates whether this store was performed.
Encoding T1 ARMv7
STREXD<c> <Rd>, <Rt>, <Rt2>, [<Rn>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 0 0 1 1 0 0 Rn Rt Rt2 0 1 1 1 Rd
d = UInt(Rd); t = UInt(Rt); t2 = UInt(Rt2); n = UInt(Rn);

if d IN {13,15} || t IN {13,15} || t2 IN {13,15} || n == 15 then UNPREDICTABLE;
if d == n || d == t || d == t2 then UNPREDICTABLE;

STREXD<c> <Rd>, <Rt>, <Rt2>, [<Rn>]
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 1 0 1 0 Rn Rd (1) (1) (1) (1) 1 0 0 1 Rt
d = UInt(Rd); t = UInt(Rt); t2 = t+1; n = UInt(Rn);

if d == 15 || Rt<0> == ‘1’ || Rt == ‘1110’ || n == 15 then UNPREDICTABLE;
if d == n || d == t || d == t2 then UNPREDICTABLE;
Assembler syntax
STREXD{<c>}{<q>} <Rd>, <Rt>, <Rt2>, [<Rn>]
where:
<Rd> must not be the same as <Rn>, <Rt>, or <Rt2>.
<Rt> The first source register. For an ARM instruction, <Rt> must be even-numbered and not R14.
<Rt2> The second source register. For an ARM instruction, <Rt2> must be <R(t+1)>.
Operation
address = R[n];
// For the alignment requirements see “Aborts and alignment”
// Create doubleword to store such that R[t] will be stored at address and R[t2] at address+4.
value = if BigEndian() then R[t]:R[t2] else R[t2]:R[t];
MemA[address,8] = value;
else
Exceptions
Data Abort.

In ARMv7, a non doubleword-aligned memory address causes an Alignment fault Data Abort exception to be
generated, subject to the following rules:
Note
In ARMv6K:
• If SCTLR.A and SCTLR.U are both 0, a non doubleword-aligned memory address causes UNPREDICTABLE
behavior.
A8.8.216 STREXH
Store Register Exclusive Halfword derives an address from a base register value, stores a halfword from a register
to memory if the executing processor has exclusive access to the memory addressed, and returns a status word that
indicates whether this store was performed.
Encoding T1 ARMv7
STREXH<c> <Rd>, <Rt>, [<Rn>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 0 0 1 1 0 0 Rn Rt (1) (1) (1) (1) 0 1 0 1 Rd


STREXH<c> <Rd>, <Rt>, [<Rn>]
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 1 1 1 0 Rn Rd (1) (1) (1) (1) 1 0 0 1 Rt

Assembler syntax
STREXH{<c>}{<q>} <Rd>, <Rt>, [<Rn>]
where:
Operation
address = R[n];
MemA[address,2] = R[t]<15:0>;
else
Exceptions
Data Abort.

In ARMv7, a non halfword-aligned memory address causes an Alignment fault Data Abort exception to be
generated, subject to the following rules:
Note
In ARMv6K:
• If SCTLR.A and SCTLR.U are both 0, a non halfword-aligned memory address causes UNPREDICTABLE
behavior.
A8.8.217 STRH (immediate, Thumb)

Store Register Halfword (immediate) calculates an address from a base register value and an immediate offset, and
stores a halfword from a register to memory. It can use offset, post-indexed, or pre-indexed addressing. For

STRH<c> <Rt>, [<Rn>{, #<imm>}]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 0 0 0 imm5 Rn Rt


STRH<c>.W <Rt>, [<Rn>{, #<imm12>}]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 1 0 1 0 Rn Rt imm12


STRH<c> <Rt>, [<Rn>, #-<imm8>]
STRH<c> <Rt>, [<Rn>], #+/-<imm8>
STRH<c> <Rt>, [<Rn>, #+/-<imm8>]!
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 0 0 1 0 Rn Rt 1 P U W imm8
if P == ‘1’ && U == ‘1’ && W == ‘0’ then SEE STRHT;

if t IN {13,15} || (wback && n == t) then UNPREDICTABLE;
Assembler syntax
STRH{<c>}{<q>} <Rt>, [<Rn> {, #+/-<imm>}] Offset: index==TRUE, wback==FALSE
STRH{<c>}{<q>} <Rt>, [<Rn>, #+/-<imm>]! Pre-indexed: index==TRUE, wback==TRUE
STRH{<c>}{<q>} <Rt>, [<Rn>], #+/-<imm> Post-indexed: index==FALSE, wback==TRUE
where:
The pre-UAL syntax STR<c>H is equivalent to STRH<c>.
Operation
Exceptions
Data Abort.
A8.8.218 STRH (immediate, ARM)

Store Register Halfword (immediate) calculates an address from a base register value and an immediate offset, and
stores a halfword from a register to memory. It can use offset, post-indexed, or pre-indexed addressing. For

STRH<c> <Rt>, [<Rn>{, #+/-<imm8>}]
STRH<c> <Rt>, [<Rn>], #+/-<imm8>
STRH<c> <Rt>, [<Rn>, #+/-<imm8>]!
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if P == ‘0’ && W == ‘1’ then SEE STRHT;

Assembler syntax
STRH{<c>}{<q>} <Rt>, [<Rn> {, #+/-<imm>}] Offset: index==TRUE, wback==FALSE
STRH{<c>}{<q>} <Rt>, [<Rn>, #+/-<imm>]! Pre-indexed: index==TRUE, wback==TRUE
STRH{<c>}{<q>} <Rt>, [<Rn>], #+/-<imm> Post-indexed: index==FALSE, wback==TRUE
where:
<imm> The immediate offset used for forming the address. Values are 0-255. For the offset addressing
syntax, <imm> can be omitted, meaning an offset of 0.
Operation
Exceptions
Data Abort.
A8.8.219 STRH (register)

Store Register Halfword (register) calculates an address from a base register value and an offset register value, and
stores a halfword from a register to memory. The offset register value can be shifted left by 0, 1, 2, or 3 bits. For

STRH<c> <Rt>, [<Rn>, <Rm>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 1 0 0 1 Rm Rn Rt


STRH<c>.W <Rt>, [<Rn>, <Rm>{, LSL #<imm2>}]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 0 0 1 0 Rn Rt 0 0 0 0 0 0 imm2 Rm

if t IN {13,15} || m IN {13,15} then UNPREDICTABLE;

STRH<c> <Rt>, [<Rn>,+/-<Rm>]{!}
STRH<c> <Rt>, [<Rn>],+/-<Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 P U 0 W 0 Rn Rt (0) (0) (0) (0) 1 0 1 1 Rm
if P == ‘0’ && W == ‘1’ then SEE STRHT;

Modified operation in ThumbEE See STRH (register) on page A9-1122
Assembler syntax
STRH{<c>}{<q>} <Rt>, [<Rn>, +/-<Rm>{, LSL #<imm>}] Offset: index==TRUE, wback==FALSE
STRH{<c>}{<q>} <Rt>, [<Rn>, +/-<Rm>]! Pre-indexed: index==TRUE, wback==TRUE
STRH{<c>}{<q>} <Rt>, [<Rn>], +/-<Rm> Post-indexed: index==FALSE, wback==TRUE
where:
0b00.
Operation
Exceptions
Data Abort.
A8.8.220 STRHT
Store Register Halfword Unprivileged stores a halfword from a register to memory. For information about memory
STRHT is UNPREDICTABLE in Hyp mode.

STRHT<c> <Rt>, [<Rn>, #<imm8>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 0 0 1 0 Rn Rt 1 1 1 0 imm8


STRHT<c> <Rt>, [<Rn>] {, #+/-<imm8>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0


STRHT<c> <Rt>, [<Rn>], +/-<Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 0 U 0 1 0 Rn Rt (0) (0) (0) (0) 1 0 1 1 Rm

Assembler syntax
STRHT{<c>}{<q>} <Rt>, [<Rn> {, #<imm>}] Offset: Thumb only
STRHT{<c>}{<q>} <Rt>, [<Rn>] {, #+/-<imm>} Post-indexed: ARM only
STRHT{<c>}{<q>} <Rt>, [<Rn>], +/-<Rm> Post-indexed: ARM only
where:
Operation
MemU_unpriv[address,2] = R[t]<15:0>;
MemU_unpriv[address,2] = bits(16) UNKNOWN;
Exceptions
Data Abort.
A8.8.221 STRT
Store Register Unprivileged stores a word from a register to memory. For information about memory accesses see
Memory accesses on page A8-292.
STRT is UNPREDICTABLE in Hyp mode.

STRT<c> <Rt>, [<Rn>, #<imm8>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 0 0 1 0 0 Rn Rt 1 1 1 0 imm8


STRT<c> <Rt>, [<Rn>] {, +/-<imm12>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 0 0 U 0 1 0 Rn Rt imm12

if n == 15 || n == t then UNPREDICTABLE;

STRT<c> <Rt>, [<Rn>],+/-<Rm>{, <shift>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

if n == 15 || n == t || m == 15 then UNPREDICTABLE;
Assembler syntax
STRT{<c>}{<q>} <Rt>, [<Rn> {, #<imm>}] Offset: Thumb only
STRT{<c>}{<q>} <Rt>, [<Rn>] {, #+/-<imm>} Post-indexed: ARM only
STRT{<c>}{<q>} <Rt>, [<Rn>], +/-<Rm> {, <shift>} Post-indexed: ARM only
where:
<Rt> The source register. In the ARM instruction set, the PC can be used. However, ARM deprecates use
of the PC.
The pre-UAL syntax STR<c>T is equivalent to STRT<c>.
Operation
if t == 15 then // Only possible for encodings A1 and A2
data = PCStoreValue();
else
data = R[t];
if UnalignedSupport() || address<1:0> == ‘00’ || CurrentInstrSet() == InstrSet_ARM then
MemU_unpriv[address,4] = data;
MemU_unpriv[address,4] = bits(32) UNKNOWN;
Exceptions
Data Abort.
A8.8.222 SUB (immediate, Thumb)

This instruction subtracts an immediate value from a register value, and writes the result to the destination register.
It can optionally update the condition flags based on the result.

SUBS <Rd>, <Rn>, #<imm3> Outside IT block.
SUB<c> <Rd>, <Rn>, #<imm3> Inside IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 1 1 1 1 imm3 Rn Rd
d = UInt(Rd); n = UInt(Rn); setflags = !InITBlock(); imm32 = ZeroExtend(imm3, 32);

SUBS <Rdn>, #<imm8> Outside IT block.
SUB<c> <Rdn>, #<imm8> Inside IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 1 1 1 Rdn imm8
d = UInt(Rdn); n = UInt(Rdn); setflags = !InITBlock(); imm32 = ZeroExtend(imm8, 32);

SUB{S}<c>.W <Rd>, <Rn>, #<const>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 i 0 1 1 0 1 S Rn 0 imm3 Rd imm8
if Rd == ‘1111’ && S == ‘1’ then SEE CMP (immediate);

if Rn == ‘1101’ then SEE SUB (SP minus immediate);
if d == 13 || (d == 15 && S == ‘0’) || n == 15 then UNPREDICTABLE;

SUBW<c> <Rd>, <Rn>, #<imm12>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 i 1 0 1 0 1 0 Rn 0 imm3 Rd imm8
if Rn == ‘1111’ then SEE ADR;

d = UInt(Rd); n = UInt(Rn); setflags = FALSE; imm32 = ZeroExtend(i:imm3:imm8, 32);
Assembler syntax
SUB{S}{<c>}{<q>} {<Rd>,} <Rn>, #<const> All encodings permitted
SUBW{<c>}{<q>} {<Rd>,} <Rn>, #<const> Only encoding T4 permitted
where:
page B9-1996.
<Rn> The first operand register. If the SP is specified for <Rn>, see SUB (SP minus immediate) on
<const> The immediate value to be subtracted from the value obtained from <Rn>. The range of values is 0-7
for encoding T1, 0-255 for encoding T2 and 0-4095 for encoding T4. See Modified immediate
constants in Thumb instructions on page A6-230 for the range of values for encoding T3.
When multiple encodings of the same length are available for an instruction, encoding T3 is
preferred to encoding T4. If encoding T4 is required, use the SUBW syntax. Encoding T1 is preferred
to encoding T2 if <Rd> is specified and encoding T2 is preferred to encoding T1 if <Rd> is omitted.
The pre-UAL syntax SUB<c>S is equivalent to SUBS<c>.
Operation
R[d] = result;
if setflags then
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.223 SUB (immediate, ARM)

This instruction subtracts an immediate value from a register value, and writes the result to the destination register.
It can optionally update the condition flags based on the result.

SUB{S}<c> <Rd>, <Rn>, #<const>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 0 0 1 0 S Rn Rd imm12
if Rn == ‘1111’ && S == ‘0’ then SEE ADR;

Assembler syntax
SUB{S}{<c>}{<q>} {<Rd>,} <Rn>, #<const>
where:
Note
<Rn> The first operand register. If the SP is specified for <Rn>, see SUB (SP minus immediate) on
<const> The immediate value to be subtracted from the value obtained from <Rn>. See Modified immediate
constants in ARM instructions on page A5-197 for the range of values.
Operation
if d == 15 then
else
R[d] = result;
if setflags then
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.224 SUB (register)

This instruction subtracts an optionally-shifted register value from a register value, and writes the result to the

SUBS <Rd>, <Rn>, <Rm> Outside IT block.
SUB<c> <Rd>, <Rn>, <Rm> Inside IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 1 1 0 1 Rm Rn Rd
d = UInt(Rd); n = UInt(Rn); m = UInt(Rm); setflags = !InITBlock();


SUB{S}<c>.W <Rd>, <Rn>, <Rm>{, <shift>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if Rd == ‘1111’ && S == ‘1’ then SEE CMP (register);

if Rn == ‘1101’ then SEE SUB (SP minus register);
if d == 13 || (d == 15 && S == ‘0’) || n == 15 || m IN {13,15} then UNPREDICTABLE;

SUB{S}<c> <Rd>, <Rn>, <Rm>{, <shift>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if Rn == ‘1101’ then SEE SUB (SP minus register);
Assembler syntax
SUB{S}{<c>}{<q>} {<Rd>,} <Rn>, <Rm> {, <shift>}
where:
Note
of the PC. If the SP is specified for <Rn>, see SUB (SP minus register) on page A8-719.
Operation
else
R[d] = result;
if setflags then
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.225 SUB (register-shifted register)

This instruction subtracts a register-shifted register value from a register value, and writes the result to the

SUB{S}<c> <Rd>, <Rn>, <Rm>, <type> <Rs>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Assembler syntax
SUB{S}{<c>}{<q>} {<Rd>,} <Rn>, <Rm>, <type> <Rs>
where:
Operation
R[d] = result;
if setflags then
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.226 SUB (SP minus immediate)

This instruction subtracts an immediate value from the SP value, and writes the result to the destination register.

SUB<c> SP, SP, #<imm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 1 0 0 0 0 1 imm7
d = 13; setflags = FALSE; imm32 = ZeroExtend(imm7:’00’, 32);

SUB{S}<c>.W <Rd>, SP, #<const>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 i 0 1 1 0 1 S 1 1 0 1 0 imm3 Rd imm8
if Rd == ‘1111’ && S == ‘1’ then SEE CMP (immediate);

d = UInt(Rd); setflags = (S == ‘1’); imm32 = ThumbExpandImm(i:imm3:imm8);
if d == 15 && S == ‘0’ then UNPREDICTABLE;

SUBW<c> <Rd>, SP, #<imm12>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 i 1 0 1 0 1 0 1 1 0 1 0 imm3 Rd imm8
d = UInt(Rd); setflags = FALSE; imm32 = ZeroExtend(i:imm3:imm8, 32);


SUB{S}<c> <Rd>, SP, #<const>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 0 0 1 0 S 1 1 0 1 Rd imm12
d = UInt(Rd); setflags = (S == ‘1’); imm32 = ARMExpandImm(imm12);
Assembler syntax
SUB{S}{<c>}{<q>} {<Rd>,} SP, #<const> All encodings permitted
SUBW{<c>}{<q>} {<Rd>,} SP, #<const> Only encoding T3 permitted
where:
is SP.
Note
<const> The immediate value to be subtracted from the value obtained from SP. Values are multiples of 4 in
the range 0-508 for encoding T1 and any value in the range 0-4095 for encoding T3. See Modified
ARM instructions on page A5-197 for the range of values for encodings T2 and A1.
When both 32-bit encodings are available for an instruction, encoding T2 is preferred to encoding
T3 (if encoding T3 is required, use the SUBW syntax).
Operation
(result, carry, overflow) = AddWithCarry(SP, NOT(imm32), ‘1’);
else
R[d] = result;
if setflags then
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.227 SUB (SP minus register)

This instruction subtracts an optionally-shifted register value from the SP value, and writes the result to the

SUB{S}<c> <Rd>, SP, <Rm>{, <shift>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if Rd == ‘1111’ && S == ‘1’ then SEE CMP (register);

if d == 13 && (shift_t != SRType_LSL || shift_n > 3) then UNPREDICTABLE;
if (d == 15 && S == ‘0’) || m IN {13,15} then UNPREDICTABLE;

SUB{S}<c> <Rd>, SP, <Rm>{, <shift>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 0 0 1 0 S 1 1 0 1 Rd imm5 type 0 Rm
Assembler syntax
SUB{S}{<c>}{<q>} {<Rd>,} SP, <Rm> {, <shift>}
where:
<c><q> See Standard assembler syntax fields on page A8-285.
is SP.
Note
In the Thumb instruction set, if <Rd> is SP or omitted, <shift> is only permitted to be omitted, LSL #1,
LSL #2, or LSL #3.
Operation
(result, carry, overflow) = AddWithCarry(SP, NOT(shifted), ‘1’);
else
R[d] = result;
if setflags then
APSR.C = carry;
APSR.V = overflow;
Exceptions
None.
A8.8.228 SUBS PC, LR and related instructions

These instructions are for system level use only. See SUBS PC, LR (Thumb) on page B9-1996 and SUBS PC, LR
and related instructions (ARM) on page B9-1998.
A8.8.229 SVC (previously SWI)

Supervisor Call, previously called Software Interrupt, causes a Supervisor Call exception. For more information,
see Supervisor Call (SVC) exception on page B1-1209.
Software can use this instruction as a call to an operating system to provide a service.
In the following cases, the Supervisor Call exception generated by the SVC instruction is taken to Hyp mode:
• If the SVC is executed in Hyp mode.
• If HCR.TGE is set to 1, and the SVC is executed in Non-secure User mode. For more information, see
Supervisor Call exception, when HCR.TGE is set to 1 on page B1-1191
In these cases, the HSR identifies that the exception entry was caused by a Supervisor Call exception, EC value 0x11,
see Use of the HSR on page B3-1421. The immediate field in the HSR:
• if the SVC is unconditional:
— for the Thumb instruction, is the zero-extended value of the imm8 field
— for the ARM instruction, is the least-significant 16 bits the imm24 field
• if the SVC is conditional, is UNKNOWN.

SVC<c> #<imm8>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 0 1 1 1 1 1 imm8

// imm32 is for assembly/disassembly. SVC handlers in some
// systems interpret imm8 in software, for example to determine the required service.

SVC<c> #<imm24>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 1 1 imm24

// imm32 is for assembly/disassembly. SVC handlers in some
// systems interpret imm24 in software, for example to determine the required service.
Assembler syntax
SVC{<c>}{<q>} {#}<imm>
where:
<imm> Specifies an immediate constant, 8-bit in Thumb instructions, or 24-bit in ARM instructions.
The pre-UAL syntax SWI<c> is equivalent to SVC<c>.
Operation
CallSupervisor(imm32<15:0>);
Exceptions
Supervisor Call.
A8.8.230 SWP, SWPB

SWP (Swap) swaps a word between registers and memory. SWP loads a word from the memory address given by the
value of register <Rn>. The value of register <Rt2> is then stored to the memory address given by the value of <Rn>,
and the original loaded value is written to register <Rt>. If the same register is specified for <Rt> and <Rt2>, this
instruction swaps the value of the register and the value at the memory address.
SWPB (Swap Byte) swaps a byte between registers and memory. SWPB loads a byte from the memory address given by
the value of register <Rn>. The value of the least significant byte of register <Rt2> is stored to the memory address
given by <Rn>, the original loaded value is zero-extended to a 32-bit word, and the word is written to register <Rt>.
If the same register is specified for <Rt> and <Rt2>, this instruction swaps the value of the least significant byte of
the register and the byte value at the memory address, and clears the most significant three bytes of the register.
For both instructions, the memory system ensures that no other memory access can occur to the memory location
between the load access and the store access.
Note
• The SWP and SWPB instructions rely on the properties of the system beyond the processor to ensure that no
stores from other observers can occur between the load access and the store access, and this might not be
implemented for all regions of memory on some system implementations. In all cases, SWP and SWPB do ensure
that no stores from the processor that executed the SWP or SWPB instruction can occur between the load access
and the store access of the SWP or SWPB.
• ARM deprecates the use of SWP and SWPB, and strongly recommends that new software uses:
— LDREX/STREX in preference to SWP
— LDREXB/STREXB in preference to SWPB.
• If the translation table entries that relate to a memory location accessed by the SWP or SWPB instruction change,
or are seen to change by the executing processor as a result of TLB eviction, this might mean that the
translation table attributes, permissions or addresses for the load are different to those for the store. In this
case, the architecture makes no guarantee that no memory access occur to these memory locations between
the load and store.
The Virtualization Extensions make the SWP and SWPB instructions OPTIONAL and deprecated:
• If an implementation does not include the SWP and SWPB instructions, the ID_ISAR0.Swap_instrs and
ID_ISAR4.SWP_frac fields are zero, see About the Instruction Set Attribute registers on page B7-1940.
• In an implementation that includes SWP and SWPB, both instructions are UNDEFINED in Hyp mode.
Encoding A1 ARMv4*, ARMv5T*, deprecated in ARMv6* and ARMv7, OPTIONAL in ARMv7VE

SWP{B}<c> <Rt>, <Rt2>, [<Rn>]
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 0 B 0 0 Rn Rt (0) (0) (0) (0) 1 0 0 1 Rt2
t = UInt(Rt); t2 = UInt(Rt2); n = UInt(Rn); size = if B == ‘1’ then 1 else 4;

if t == 15 || t2 == 15 || n == 15 || n == t || n == t2 then UNPREDICTABLE;
Assembler syntax
SWP{B}{<c>}{<q>} <Rt>, <Rt2>, [<Rn>]
where:
B If B is present, the instruction operates on a byte. Otherwise, it operates on a word.
<Rt2> Contains the value that is stored to memory.
<Rn> Contains the memory address to load from.
The pre-UAL syntax SWP<c>B is equivalent to SWPB<c>.
Operation
if CurrentModeIsHyp() then UNDEFINED;
// The MemA[] accesses in the next two statements are locked together, that is, the memory
// system must ensure that no other access to the same location can occur between them.
data = ZeroExtend(MemA[R[n], size],32);
MemA[R[n], size] = R[t2]<8*size-1:0>;
if size == 1 then // SWPB
R[t] = data;
else // SWP
// Rotation in the following will always be by zero in ARMv7, due to alignment checks,
// but can be nonzero in legacy configurations.
R[t] = ROR(data, 8*UInt(R[n]<1:0>));
Exceptions
Data Abort.
A8.8.231 SXTAB
Signed Extend and Add Byte extracts an 8-bit value from a register, sign-extends it to 32 bits, adds the result to the
value in another register, and writes the final result to the destination register. The instruction can specify a rotation
by 0, 8, 16, or 24 bits before extracting the 8-bit value.

SXTAB<c> <Rd>, <Rn>, <Rm>{, <rotation>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 0 1 0 0 Rn 1 1 1 1 Rd 1 (0) rotate Rm
if Rn == ‘1111’ then SEE SXTB;

d = UInt(Rd); n = UInt(Rn); m = UInt(Rm); rotation = UInt(rotate:’000’);

SXTAB<c> <Rd>, <Rn>, <Rm>{, <rotation>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 1 0 1 0 Rn Rd rotate (0) (0) 0 1 1 1 Rm
if Rn == ‘1111’ then SEE SXTB;

Assembler syntax
SXTAB{<c>}{<q>} {<Rd>,} <Rn>, <Rm> {, <rotation>}
where:
<rotation> This can be any one of:

omitted encoded as rotate = 0b00
ROR #8 encoded as rotate = 0b01
ROR #24 encoded as rotate = 0b11.
Note
An assembler can permit ROR #0 to mean the same thing as omitting the rotation, possibly with
restrictions on the permitted encodings, but this is not standard UAL and must not be used for
disassembly.
Operation
rotated = ROR(R[m], rotation);
R[d] = R[n] + SignExtend(rotated<7:0>, 32);
Exceptions
None.
A8.8.232 SXTAB16
Signed Extend and Add Byte 16 extracts two 8-bit values from a register, sign-extends them to 16 bits each, adds
the results to two 16-bit values from another register, and writes the final results to the destination register. The
instruction can specify a rotation by 0, 8, 16, or 24 bits before extracting the 8-bit values.

SXTAB16<c> <Rd>, <Rn>, <Rm>{, <rotation>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 0 0 1 0 Rn 1 1 1 1 Rd 1 (0) rotate Rm
if Rn == ‘1111’ then SEE SXTB16;


SXTAB16<c> <Rd>, <Rn>, <Rm>{, <rotation>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if Rn == ‘1111’ then SEE SXTB16;

Assembler syntax
SXTAB16{<c>}{<q>} {<Rd>,} <Rn>, <Rm> {, <rotation>}
where:

Note
disassembly.
Operation
R[d]<15:0> = R[n]<15:0> + SignExtend(rotated<7:0>, 16);
R[d]<31:16> = R[n]<31:16> + SignExtend(rotated<23:16>, 16);
Exceptions
None.
A8.8.233 SXTAH
Signed Extend and Add Halfword extracts a 16-bit value from a register, sign-extends it to 32 bits, adds the result
to a value from another register, and writes the final result to the destination register. The instruction can specify a
rotation by 0, 8, 16, or 24 bits before extracting the 16-bit value.

SXTAH<c> <Rd>, <Rn>, <Rm>{, <rotation>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 0 0 0 0 Rn 1 1 1 1 Rd 1 (0) rotate Rm
if Rn == ‘1111’ then SEE SXTH;


SXTAH<c> <Rd>, <Rn>, <Rm>{, <rotation>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if Rn == ‘1111’ then SEE SXTH;

Assembler syntax
SXTAH{<c>}{<q>} {<Rd>,} <Rn>, <Rm> {, <rotation>}
where:

Note
disassembly.
Operation
R[d] = R[n] + SignExtend(rotated<15:0>, 32);
Exceptions
None.
A8.8.234 SXTB
Signed Extend Byte extracts an 8-bit value from a register, sign-extends it to 32 bits, and writes the result to the
destination register. The instruction can specify a rotation by 0, 8, 16, or 24 bits before extracting the 8-bit value.

SXTB<c> <Rd>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 1 0 0 1 0 0 1 Rm Rd
d = UInt(Rd); m = UInt(Rm); rotation = 0;

SXTB<c>.W <Rd>, <Rm>{, <rotation>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 0 1 0 0 1 1 1 1 1 1 1 1 Rd 1 (0) rotate Rm
d = UInt(Rd); m = UInt(Rm); rotation = UInt(rotate:’000’);


SXTB<c> <Rd>, <Rm>{, <rotation>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 1 0 1 0 1 1 1 1 Rd rotate (0) (0) 0 1 1 1 Rm

Assembler syntax
SXTB{<c>}{<q>} {<Rd>,} <Rm> {, <rotation>}
where:
<Rm> The register that contains the operand.

omitted any encoding, encoded as rotate = 0b00 in encoding T2 or A1
ROR #8 encoding T2 or A1, encoded as rotate = 0b01
ROR #24 encoding T2 or A1, encoded as rotate = 0b11.
Note
disassembly.
Operation
R[d] = SignExtend(rotated<7:0>, 32);
Exceptions
None.
A8.8.235 SXTB16
Signed Extend Byte 16 extracts two 8-bit values from a register, sign-extends them to 16 bits each, and writes the
results to the destination register. The instruction can specify a rotation by 0, 8, 16, or 24 bits before extracting the
8-bit values.

SXTB16<c> <Rd>, <Rm>{, <rotation>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 0 0 1 0 1 1 1 1 1 1 1 1 Rd 1 (0) rotate Rm


SXTB16<c> <Rd>, <Rm>{, <rotation>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 1 0 0 0 1 1 1 1 Rd rotate (0) (0) 0 1 1 1 Rm

Assembler syntax
SXTB16{<c>}{<q>} {<Rd>,} <Rm> {, <rotation>}
where:

Note
disassembly.
Operation
R[d]<15:0> = SignExtend(rotated<7:0>, 16);
R[d]<31:16> = SignExtend(rotated<23:16>, 16);
Exceptions
None.
A8.8.236 SXTH
Signed Extend Halfword extracts a 16-bit value from a register, sign-extends it to 32 bits, and writes the result to
the destination register. The instruction can specify a rotation by 0, 8, 16, or 24 bits before extracting the 16-bit
value.

SXTH<c> <Rd>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 1 0 0 1 0 0 0 Rm Rd

SXTH<c>.W <Rd>, <Rm>{, <rotation>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 0 0 0 0 1 1 1 1 1 1 1 1 Rd 1 (0) rotate Rm


SXTH<c> <Rd>, <Rm>{, <rotation>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 1 0 1 1 1 1 1 1 Rd rotate (0) (0) 0 1 1 1 Rm

Assembler syntax
SXTH{<c>}{<q>} {<Rd>,} <Rm> {, <rotation>}
where:

Note
disassembly.
Operation
R[d] = SignExtend(rotated<15:0>, 32);
Exceptions
None.
A8.8.237 TBB, TBH

Table Branch Byte causes a PC-relative forward branch using a table of single byte offsets. A base register provides
a pointer to the table, and a second register supplies an index into the table. The branch length is twice the value of
the byte returned from the table.
Table Branch Halfword causes a PC-relative forward branch using a table of single halfword offsets. A base register
provides a pointer to the table, and a second register supplies an index into the table. The branch length is twice the
value of the halfword returned from the table.

TBB<c> [<Rn>, <Rm>] Outside or last in IT block
TBH<c> [<Rn>, <Rm>, LSL #1] Outside or last in IT block
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 0 0 1 1 0 1 Rn (1) (1) (1) (1) (0) (0) (0) (0) 0 0 0 H Rm
n = UInt(Rn); m = UInt(Rm); is_tbh = (H == ‘1’);

Assembler syntax
TBB{<c>}{<q>} [<Rn>, <Rm>]
TBH{<c>}{<q>} [<Rn>, <Rm>, LSL #1]
where:
<Rn> The base register. This contains the address of the table of branch lengths. The PC can be used. If it
is, the table immediately follows this instruction.
<Rm> The index register.

For TBB, this contains an integer pointing to a single byte in the table. The offset in the table is the
value of the index.
For TBH, this contains an integer pointing to a halfword in the table. The offset in the table is twice
the value of the index.
Operation
if is_tbh then
halfwords = UInt(MemU[R[n]+LSL(R[m],1), 2]);
else
halfwords = UInt(MemU[R[n]+R[m], 1]);
BranchWritePC(PC + 2*halfwords);
Exceptions
Data Abort.
A8.8.238 TEQ (immediate)

Test Equivalence (immediate) performs a bitwise exclusive OR operation on a register value and an immediate
value. It updates the condition flags based on the result, and discards the result.

TEQ<c> <Rn>, #<const>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 i 0 0 1 0 0 1 Rn 0 imm3 1 1 1 1 imm8
n = UInt(Rn);

TEQ<c> <Rn>, #<const>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 1 0 0 1 1 Rn (0) (0) (0) (0) imm12
n = UInt(Rn);
Assembler syntax
TEQ{<c>}{<q>} <Rn>, #<const>
where:
<Rn> The operand register. The PC can be used in ARM instructions, but ARM deprecates this use of the
PC.
<const> The immediate value to be tested against the value obtained from <Rn>. See Modified immediate
Operation
result = R[n] EOR imm32;
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.239 TEQ (register)

Test Equivalence (register) performs a bitwise exclusive OR operation on a register value and an optionally-shifted
register value. It updates the condition flags based on the result, and discards the result.

TEQ<c> <Rn>, <Rm>{, <shift>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 1 0 1 0 0 1 Rn (0) imm3 1 1 1 1 imm2 type Rm
if n IN {13,15} || m IN {13,15} then UNPREDICTABLE;

TEQ<c> <Rn>, <Rm>{, <shift>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Assembler syntax
TEQ{<c>}{<q>} <Rn>, <Rm> {, <shift>}
where:
of the PC.
Operation
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.240 TEQ (register-shifted register)

Test Equivalence (register-shifted register) performs a bitwise exclusive OR operation on a register value and a
register-shifted register value. It updates the condition flags based on the result, and discards the result.

TEQ<c> <Rn>, <Rm>, <type> <Rs>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 0 0 1 1 Rn (0) (0) (0) (0) Rs 0 type 1 Rm

Assembler syntax
TEQ{<c>}{<q>} <Rn>, <Rm>, <type> <Rs>
where:
Operation
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.241 TST (immediate)

Test (immediate) performs a bitwise AND operation on a register value and an immediate value. It updates the

TST<c> <Rn>, #<const>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 i 0 0 0 0 0 1 Rn 0 imm3 1 1 1 1 imm8
n = UInt(Rn);

TST<c> <Rn>, #<const>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 1 0 0 0 1 Rn (0) (0) (0) (0) imm12
n = UInt(Rn);
Assembler syntax
TST{<c>}{<q>} <Rn>, #<const>
where:
<Rn> The operand register. The PC can be used in ARM instructions, but ARM deprecates this use of the
PC.
<const> The immediate value to be tested against the value obtained from <Rn>. See Modified immediate
Operation
result = R[n] AND imm32;
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.242 TST (register)

Test (register) performs a bitwise AND operation on a register value and an optionally-shifted register value. It
updates the condition flags based on the result, and discards the result.

TST<c> <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 0 0 0 1 0 0 0 Rm Rn

TST<c>.W <Rn>, <Rm>{, <shift>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 0 1 0 0 0 0 1 Rn (0) imm3 1 1 1 1 imm2 type Rm
if n IN {13,15} || m IN {13,15} then UNPREDICTABLE;

TST<c> <Rn>, <Rm>{, <shift>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Assembler syntax
TST{<c>}{<q>} <Rn>, <Rm> {, <shift>}
where:
of the PC.
Operation
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.243 TST (register-shifted register)

Test (register-shifted register) performs a bitwise AND operation on a register value and a register-shifted register
value. It updates the condition flags based on the result, and discards the result.

TST<c> <Rn>, <Rm>, <type> <Rs>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 1 0 0 0 1 Rn (0) (0) (0) (0) Rs 0 type 1 Rm

Assembler syntax
TST{<c>}{<q>} <Rn>, <Rm>, <type> <Rs>
where:
Operation
APSR.C = carry;
// APSR.V unchanged
Exceptions
None.
A8.8.244 UADD16
Unsigned Add 16 performs two 16-bit unsigned integer additions, and writes the results to the destination register.
It sets the APSR.GE bits according to the results of the additions.

UADD16<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 0 1 Rn 1 1 1 1 Rd 0 1 0 0 Rm


31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 1 0 1 Rn Rd (1) (1) (1) (1) 0 0 0 1 Rm

Assembler syntax
UADD16{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
Operation
sum1 = UInt(R[n]<15:0>) + UInt(R[m]<15:0>);
R[d]<15:0> = sum1<15:0>;
R[d]<31:16> = sum2<15:0>;
APSR.GE<1:0> = if sum1 >= 0x10000 then ‘11’ else ‘00’;
APSR.GE<3:2> = if sum2 >= 0x10000 then ‘11’ else ‘00’;
Exceptions
None.
A8.8.245 UADD8
Unsigned Add 8 performs four unsigned 8-bit integer additions, and writes the results to the destination register. It
sets the APSR.GE bits according to the results of the additions.

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 0 0 Rn 1 1 1 1 Rd 0 1 0 0 Rm


31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 1 0 1 Rn Rd (1) (1) (1) (1) 1 0 0 1 Rm

Assembler syntax
UADD8{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
Operation
R[d]<7:0> = sum1<7:0>;
R[d]<15:8> = sum2<7:0>;
R[d]<23:16> = sum3<7:0>;
R[d]<31:24> = sum4<7:0>;
APSR.GE<0> = if sum1 >= 0x100 then ‘1’ else ‘0’;
Exceptions
None.
A8.8.246 UASX
Unsigned Add and Subtract with Exchange exchanges the two halfwords of the second operand, performs one
unsigned 16-bit integer addition and one unsigned 16-bit subtraction, and writes the results to the destination
register. It sets the APSR.GE bits according to the results.

UASX<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 1 0 Rn 1 1 1 1 Rd 0 1 0 0 Rm


UASX<c> <Rd>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 1 0 1 Rn Rd (1) (1) (1) (1) 0 0 1 1 Rm

Assembler syntax
UASX{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
The pre-UAL syntax UADDSUBX<c> is equivalent to UASX<c>.
Operation
diff = UInt(R[n]<15:0>) - UInt(R[m]<31:16>);
sum = UInt(R[n]<31:16>) + UInt(R[m]<15:0>);
R[d]<15:0> = diff<15:0>;
R[d]<31:16> = sum<15:0>;
APSR.GE<3:2> = if sum >= 0x10000 then ‘11’ else ‘00’;
Exceptions
None.
A8.8.247 UBFX
Unsigned Bit Field Extract extracts any number of adjacent bits at any position from a register, zero-extends them
to 32 bits, and writes the result to the destination register.

UBFX<c> <Rd>, <Rn>, #<lsb>, #<width>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 (0) 1 1 1 1 0 0 Rn 0 imm3 Rd imm2 (0) widthm1
lsbit = UInt(imm3:imm2); widthminus1 = UInt(widthm1);

UBFX<c> <Rd>, <Rn>, #<lsb>, #<width>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 1 1 1 1 widthm1 Rd lsb 1 0 1 Rn
lsbit = UInt(lsb); widthminus1 = UInt(widthm1);
Assembler syntax
UBFX{<c>}{<q>} <Rd>, <Rn>, #<lsb>, #<width>
where:
<lsb> is the bit number of the least significant bit in the field, in the range 0-31. This determines the
required value of lsbit.
<width> is the width of the field, in the range 1 to 32-<lsb>. The required value of widthminus1 is <width>-1.
Operation
msbit = lsbit + widthminus1;
if msbit <= 31 then
R[d] = ZeroExtend(R[n]<msbit:lsbit>, 32);
else
UNPREDICTABLE;
Exceptions
None.
A8.8.248 UDF
Permanently Undefined generates an Undefined Instruction exception.
The encodings for UDF used in this section are defined as permanently UNDEFINED in the versions of the architecture
specified in this section. Issue C.a of this manual first defines an assembler mnemonic for these encodings.
However:
• with the Thumb instruction set, ARM deprecates using the UDF instruction in an IT block
• in the ARM instruction set, UDF is not conditional.
Encoding T1 ARMv4T, ARMv5T*, ARMv6, ARMv7

UDF<c> #<imm8>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 0 1 1 1 1 0 imm8

// imm32 is for assembly and disassembly only, and is ignored by hardware.

UDF<c>.W #<imm16>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 1 1 1 1 1 1 1 imm4 1 0 1 0 imm12

Encoding A1 ARMv4T, ARMv5T*, ARMv6, ARMv7

UDF<c> #<imm16>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 0 1 1 1 1 1 1 1 imm12 1 1 1 1 imm4

Assembler syntax
UDF{<c>}{<q>} {#}<imm>
where:

In the ARM instruction set, <c> must be AL or omitted.
In the Thumb instruction set, ARM deprecates using any <c> value other than AL.
<imm> Specifies an immediate constant, that is 8-bit in encoding T1, and 16-bit in encodings T2 and A1.
The processor ignores the value of this constant.
Operation
UNDEFINED;
Exceptions
Undefined Instruction.
A8.8.249 UDIV
Unsigned Divide divides a 32-bit unsigned integer register value by a 32-bit unsigned integer register value, and
writes the result to the destination register. The condition flags are not affected.
See ARMv7 implementation requirements and options for the divide instructions on page A4-170 for more
information about this instruction.
Encoding T1 ARMv7-R, ARMv7VE, otherwise OPTIONAL in ARMv7-A

UDIV<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 1 0 1 1 Rn (1) (1) (1) (1) Rd 1 1 1 1 Rm

Encoding A1 ARMv7VE, otherwise OPTIONAL in ARMv7-A and ARMv7-R

UDIV<c> <Rd>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 1 0 0 1 1 Rd (1) (1) (1) (1) Rm 0 0 0 1 Rn

Assembler syntax
UDIV{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
<Rn> The register that contains the dividend.
<Rm> The register that contains the divisor.
Operation
if UInt(R[m]) == 0 then
if IntegerZeroDivideTrappingEnabled() then
GenerateIntegerZeroDivide();
else
result = 0;
else
result = RoundTowardsZero(UInt(R[n]) / UInt(R[m]));
Exceptions
In ARMv7-R profile, Undefined Instruction, see Divide instructions on page A4-170.
In ARMv7-A profile, none.
A8.8.250 UHADD16
Unsigned Halving Add 16 performs two unsigned 16-bit integer additions, halves the results, and writes the results

UHADD16<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 0 1 Rn 1 1 1 1 Rd 0 1 1 0 Rm


31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 1 1 1 Rn Rd (1) (1) (1) (1) 0 0 0 1 Rm

Assembler syntax
UHADD16{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
Operation
R[d]<15:0> = sum1<16:1>;
R[d]<31:16> = sum2<16:1>;
Exceptions
None.
A8.8.251 UHADD8
Unsigned Halving Add 8 performs four unsigned 8-bit integer additions, halves the results, and writes the results to
the destination register.

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 0 0 Rn 1 1 1 1 Rd 0 1 1 0 Rm


31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 1 1 1 Rn Rd (1) (1) (1) (1) 1 0 0 1 Rm

Assembler syntax
UHADD8{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
Operation
R[d]<7:0> = sum1<8:1>;
R[d]<15:8> = sum2<8:1>;
R[d]<23:16> = sum3<8:1>;
R[d]<31:24> = sum4<8:1>;
Exceptions
None.
A8.8.252 UHASX
Unsigned Halving Add and Subtract with Exchange exchanges the two halfwords of the second operand, performs
one unsigned 16-bit integer addition and one unsigned 16-bit subtraction, halves the results, and writes the results

UHASX<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 1 0 Rn 1 1 1 1 Rd 0 1 1 0 Rm


UHASX<c> <Rd>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 1 1 1 Rn Rd (1) (1) (1) (1) 0 0 1 1 Rm

Assembler syntax
UHASX{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
The pre-UAL syntax UHADDSUBX<c> is equivalent to UHASX<c>.
Operation
R[d]<15:0> = diff<16:1>;
R[d]<31:16> = sum<16:1>;
Exceptions
None.
A8.8.253 UHSAX
Unsigned Halving Subtract and Add with Exchange exchanges the two halfwords of the second operand, performs
one unsigned 16-bit integer subtraction and one unsigned 16-bit addition, halves the results, and writes the results

UHSAX<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 1 1 0 Rn 1 1 1 1 Rd 0 1 1 0 Rm


UHSAX<c> <Rd>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 1 1 1 Rn Rd (1) (1) (1) (1) 0 1 0 1 Rm

Assembler syntax
UHSAX{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
The pre-UAL syntax UHSUBADDX<c> is equivalent to UHSAX<c>.
Operation
R[d]<15:0> = sum<16:1>;
R[d]<31:16> = diff<16:1>;
Exceptions
None.
A8.8.254 UHSUB16
Unsigned Halving Subtract 16 performs two unsigned 16-bit integer subtractions, halves the results, and writes the
results to the destination register.

UHSUB16<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 1 0 1 Rn 1 1 1 1 Rd 0 1 1 0 Rm


31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 1 1 1 Rn Rd (1) (1) (1) (1) 0 1 1 1 Rm

Assembler syntax
UHSUB16{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
Operation
diff1 = UInt(R[n]<15:0>) - UInt(R[m]<15:0>);
R[d]<15:0> = diff1<16:1>;
R[d]<31:16> = diff2<16:1>;
Exceptions
None.
A8.8.255 UHSUB8
Unsigned Halving Subtract 8 performs four unsigned 8-bit integer subtractions, halves the results, and writes the
results to the destination register.

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 1 0 0 Rn 1 1 1 1 Rd 0 1 1 0 Rm


31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 1 1 1 Rn Rd (1) (1) (1) (1) 1 1 1 1 Rm

Assembler syntax
UHSUB8{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
Operation
R[d]<7:0> = diff1<8:1>;
R[d]<15:8> = diff2<8:1>;
R[d]<23:16> = diff3<8:1>;
R[d]<31:24> = diff4<8:1>;
Exceptions
None.
A8.8.256 UMAAL
Unsigned Multiply Accumulate Accumulate Long multiplies two unsigned 32-bit values to produce a 64-bit value,
adds two unsigned 32-bit values, and writes the 64-bit result to two registers.

UMAAL<c> <RdLo>, <RdHi>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 1 1 1 0 Rn RdLo RdHi 0 1 1 0 Rm


UMAAL<c> <RdLo>, <RdHi>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 0 0 0 1 0 0 RdHi RdLo Rm 1 0 0 1 Rn

Assembler syntax
UMAAL{<c>}{<q>} <RdLo>, <RdHi>, <Rn>, <Rm>
where:
<RdLo> Supplies one of the 32-bit values to be added, and is the destination register for the lower 32 bits of
the result.
<RdHi> Supplies the other of the 32-bit values to be added, and is the destination register for the upper
32 bits of the result.
Operation
result = UInt(R[n]) * UInt(R[m]) + UInt(R[dHi]) + UInt(R[dLo]);
Exceptions
None.
A8.8.257 UMLAL
Unsigned Multiply Accumulate Long multiplies two unsigned 32-bit values to produce a 64-bit value, and
accumulates this with a 64-bit value.

UMLAL<c> <RdLo>, <RdHi>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 1 1 1 0 Rn RdLo RdHi 0 0 0 0 Rm


UMLAL{S}<c> <RdLo>, <RdHi>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Assembler syntax
UMLAL{S}{<c>}{<q>} <RdLo>, <RdHi>, <Rn>, <Rm>
where:
bits of the result.
bits of the result.
The pre-UAL syntax UMLAL<c>S is equivalent to UMLALS<c>.
Operation
result = UInt(R[n]) * UInt(R[m]) + UInt(R[dHi]:R[dLo]);
if setflags then
Exceptions
None.
A8.8.258 UMULL
Unsigned Multiply Long multiplies two 32-bit unsigned values to produce a 64-bit result.

UMULL<c> <RdLo>, <RdHi>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 1 0 1 0 Rn RdLo RdHi 0 0 0 0 Rm


UMULL{S}<c> <RdLo>, <RdHi>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Assembler syntax
UMULL{S}{<c>}{<q>} <RdLo>, <RdHi>, <Rn>, <Rm>
where:
<RdLo> Stores the lower 32 bits of the result.
<RdHi> Stores the upper 32 bits of the result.
The pre-UAL syntax UMULL<c>S is equivalent to UMULLS<c>.
Operation
result = UInt(R[n]) * UInt(R[m]);
if setflags then
Exceptions
None.
A8.8.259 UQADD16
Unsigned Saturating Add 16 performs two unsigned 16-bit integer additions, saturates the results to the 16-bit
unsigned integer range 0 ≤ x ≤ 216 – 1, and writes the results to the destination register.

UQADD16<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 0 1 Rn 1 1 1 1 Rd 0 1 0 1 Rm


31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 1 1 0 Rn Rd (1) (1) (1) (1) 0 0 0 1 Rm

Assembler syntax
UQADD16{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
Operation
R[d]<15:0> = UnsignedSat(sum1, 16);
Exceptions
None.
A8.8.260 UQADD8
Unsigned Saturating Add 8 performs four unsigned 8-bit integer additions, saturates the results to the 8-bit unsigned
integer range 0 ≤ x ≤ 28 – 1, and writes the results to the destination register.

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 0 0 Rn 1 1 1 1 Rd 0 1 0 1 Rm


31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 1 1 0 Rn Rd (1) (1) (1) (1) 1 0 0 1 Rm

Assembler syntax
UQADD8{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
Operation
Exceptions
None.
A8.8.261 UQASX
Unsigned Saturating Add and Subtract with Exchange exchanges the two halfwords of the second operand,
performs one unsigned 16-bit integer addition and one unsigned 16-bit subtraction, saturates the results to the 16-bit

UQASX<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 0 1 0 Rn 1 1 1 1 Rd 0 1 0 1 Rm


UQASX<c> <Rd>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 1 1 0 Rn Rd (1) (1) (1) (1) 0 0 1 1 Rm

Assembler syntax
UQASX{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
The pre-UAL syntax UQADDSUBX<c> is equivalent to UQASX<c>.
Operation
R[d]<15:0> = UnsignedSat(diff, 16);
R[d]<31:16> = UnsignedSat(sum, 16);
Exceptions
None.
A8.8.262 UQSAX
Unsigned Saturating Subtract and Add with Exchange exchanges the two halfwords of the second operand,
performs one unsigned 16-bit integer subtraction and one unsigned 16-bit addition, saturates the results to the 16-bit

UQSAX<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 1 1 0 Rn 1 1 1 1 Rd 0 1 0 1 Rm


UQSAX<c> <Rd>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 1 1 0 Rn Rd (1) (1) (1) (1) 0 1 0 1 Rm

Assembler syntax
UQSAX{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
The pre-UAL syntax UQSUBADDX<c> is equivalent to UQSAX<c>.
Operation
R[d]<15:0> = UnsignedSat(sum, 16);
R[d]<31:16> = UnsignedSat(diff, 16);
Exceptions
None.
A8.8.263 UQSUB16
Unsigned Saturating Subtract 16 performs two unsigned 16-bit integer subtractions, saturates the results to the
16-bit unsigned integer range 0 ≤ x ≤ 216 – 1, and writes the results to the destination register.

UQSUB16<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 1 0 1 Rn 1 1 1 1 Rd 0 1 0 1 Rm


31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 1 1 0 Rn Rd (1) (1) (1) (1) 0 1 1 1 Rm

Assembler syntax
UQSUB16{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
Operation
R[d]<15:0> = UnsignedSat(diff1, 16);
Exceptions
None.
A8.8.264 UQSUB8
Unsigned Saturating Subtract 8 performs four unsigned 8-bit integer subtractions, saturates the results to the 8-bit

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 1 0 0 Rn 1 1 1 1 Rd 0 1 0 1 Rm


31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 1 1 0 Rn Rd (1) (1) (1) (1) 1 1 1 1 Rm

Assembler syntax
UQSUB8{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
Operation
Exceptions
None.
A8.8.265 USAD8
Unsigned Sum of Absolute Differences performs four unsigned 8-bit subtractions, and adds the absolute values of
the differences together.

USAD8<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 0 1 1 1 Rn 1 1 1 1 Rd 0 0 0 0 Rm


USAD8<c> <Rd>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 1 1 0 0 0 Rd 1 1 1 1 Rm 0 0 0 1 Rn

Assembler syntax
USAD8{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
Operation
absdiff1 = Abs(UInt(R[n]<7:0>) - UInt(R[m]<7:0>));
result = absdiff1 + absdiff2 + absdiff3 + absdiff4;
Exceptions
None.
A8.8.266 USADA8
Unsigned Sum of Absolute Differences and Accumulate performs four unsigned 8-bit subtractions, and adds the
absolute values of the differences to a 32-bit accumulate operand.

USADA8<c> <Rd>, <Rn>, <Rm>, <Ra>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 1 0 1 1 1 Rn Ra Rd 0 0 0 0 Rm
if Ra == ‘1111’ then SEE USAD8;


USADA8<c> <Rd>, <Rn>, <Rm>, <Ra>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 1 1 0 0 0 Rd Ra Rm 0 0 0 1 Rn
if Ra == ‘1111’ then SEE USAD8;

Assembler syntax
USADA8{<c>}{<q>} <Rd>, <Rn>, <Rm>, <Ra>
where:
<Ra> The register that contains the accumulation value.
Operation
result = UInt(R[a]) + absdiff1 + absdiff2 + absdiff3 + absdiff4;
Exceptions
None.
A8.8.267 USAT
Unsigned Saturate saturates an optionally-shifted signed value to a selected unsigned range.

USAT<c> <Rd>, #<imm5>, <Rn>{, <shift>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 (0) 1 1 1 0 sh 0 Rn 0 imm3 Rd imm2 (0) sat_imm
if sh == ‘1’ && (imm3:imm2) == ‘00000’ then SEE USAT16;

d = UInt(Rd); n = UInt(Rn); saturate_to = UInt(sat_imm);
(shift_t, shift_n) = DecodeImmShift(sh:’0’, imm3:imm2);

USAT<c> <Rd>, #<imm5>, <Rn>{, <shift>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 1 1 1 sat_imm Rd imm5 sh 0 1 Rn

(shift_t, shift_n) = DecodeImmShift(sh:’0’, imm5);
Assembler syntax
USAT{<c>}{<q>} <Rd>, #<imm>, <Rn> {, <shift>}
where:
<imm> The bit position for saturation, in the range 0 to 31. This is encoded directly in the sat_imm field of
the instruction, meaning sat_imm takes the value of <imm>.
<Rn> The register that contains the value to be saturated.
<shift> The optional shift, encoded in the sh bit and the immsh field, where immsh is:
• imm3:imm2 for encoding T1
• imm5 for encoding A1.
<shift> must be one of:
omitted No shift. Encoded as sh = 0, immsh = 0b00000.
LSL #<n> Left shift by <n> bits, with <n> in the range 1-31.
ASR #<n> Arithmetic right shift by <n> bits, with <n> in the range 1-31.
ASR #32 Arithmetic right shift by 32 bits, permitted only for encoding A1.
Encoded as sh = 1, immsh = 0b00000.
Note
An assembler can permit ASR #0 or LSL #0 to mean the same thing as omitting the shift, but this is
not standard UAL and must not be used for disassembly.
Operation
operand = Shift(R[n], shift_t, shift_n, APSR.C); // APSR.C ignored
(result, sat) = UnsignedSatQ(SInt(operand), saturate_to);
R[d] = ZeroExtend(result, 32);
if sat then
APSR.Q = ‘1’;
Exceptions
None.
A8.8.268 USAT16
Unsigned Saturate 16 saturates two signed 16-bit values to a selected unsigned range.

USAT16<c> <Rd>, #<imm4>, <Rn>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 (0) 1 1 1 0 1 0 Rn 0 0 0 0 Rd 0 0 (0) (0) sat_imm


USAT16<c> <Rd>, #<imm4>, <Rn>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 1 1 1 0 sat_imm Rd (1) (1) (1) (1) 0 0 1 1 Rn

Assembler syntax
USAT16{<c>}{<q>} <Rd>, #<imm>, <Rn>
where:
<imm> The bit position for saturation, in the range 0 to 15. This is encoded directly in the sat_imm field of
the instruction, meaning sat_imm takes the value of <imm>.
<Rn> The register that contains the values to be saturated.
Operation
(result1, sat1) = UnsignedSatQ(SInt(R[n]<15:0>), saturate_to);
(result2, sat2) = UnsignedSatQ(SInt(R[n]<31:16>), saturate_to);
R[d]<15:0> = ZeroExtend(result1, 16);
R[d]<31:16> = ZeroExtend(result2, 16);
APSR.Q = ‘1’;
Exceptions
None.
A8.8.269 USAX
Unsigned Subtract and Add with Exchange exchanges the two halfwords of the second operand, performs one
unsigned 16-bit integer subtraction and one unsigned 16-bit addition, and writes the results to the destination
register. It sets the APSR.GE bits according to the results.

USAX<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 1 1 0 Rn 1 1 1 1 Rd 0 1 0 0 Rm


USAX<c> <Rd>, <Rn>, <Rm>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 1 0 1 Rn Rd (1) (1) (1) (1) 0 1 0 1 Rm

Assembler syntax
USAX{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
The pre-UAL syntax USUBADDX<c> is equivalent to USAX<c>.
Operation
R[d]<15:0> = sum<15:0>;
R[d]<31:16> = diff<15:0>;
APSR.GE<1:0> = if sum >= 0x10000 then ‘11’ else ‘00’;
Exceptions
None.
A8.8.270 USUB16
Unsigned Subtract 16 performs two 16-bit unsigned integer subtractions, and writes the results to the destination
register. It sets the APSR.GE bits according to the results of the subtractions.

USUB16<c> <Rd>, <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 1 0 1 Rn 1 1 1 1 Rd 0 1 0 0 Rm


31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 1 0 1 Rn Rd (1) (1) (1) (1) 0 1 1 1 Rm

Assembler syntax
USUB16{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
Operation
R[d]<15:0> = diff1<15:0>;
R[d]<31:16> = diff2<15:0>;
Exceptions
None.
A8.8.271 USUB8
Unsigned Subtract 8 performs four 8-bit unsigned integer subtractions, and writes the results to the destination
register. It sets the APSR.GE bits according to the results of the subtractions.

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 1 1 0 0 Rn 1 1 1 1 Rd 0 1 0 0 Rm


31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 0 1 0 1 Rn Rd (1) (1) (1) (1) 1 1 1 1 Rm

Assembler syntax
USUB8{<c>}{<q>} {<Rd>,} <Rn>, <Rm>
where:
Operation
R[d]<7:0> = diff1<7:0>;
R[d]<15:8> = diff2<7:0>;
R[d]<23:16> = diff3<7:0>;
R[d]<31:24> = diff4<7:0>;
Exceptions
None.
A8.8.272 UXTAB
Unsigned Extend and Add Byte extracts an 8-bit value from a register, zero-extends it to 32 bits, adds the result to
the value in another register, and writes the final result to the destination register. The instruction can specify a

UXTAB<c> <Rd>, <Rn>, <Rm>{, <rotation>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 0 1 0 1 Rn 1 1 1 1 Rd 1 (0) rotate Rm
if Rn == ‘1111’ then SEE UXTB;


UXTAB<c> <Rd>, <Rn>, <Rm>{, <rotation>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if Rn == ‘1111’ then SEE UXTB;

Assembler syntax
UXTAB{<c>}{<q>} {<Rd>,} <Rn>, <Rm> {, <rotation>}
where:

Note
disassembly.
Operation
R[d] = R[n] + ZeroExtend(rotated<7:0>, 32);
Exceptions
None.
A8.8.273 UXTAB16
Unsigned Extend and Add Byte 16 extracts two 8-bit values from a register, zero-extends them to 16 bits each, adds
the results to two 16-bit values from another register, and writes the final results to the destination register. The
instruction can specify a rotation by 0, 8, 16, or 24 bits before extracting the 8-bit values.

UXTAB16<c> <Rd>, <Rn>, <Rm>{, <rotation>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 0 0 1 1 Rn 1 1 1 1 Rd 1 (0) rotate Rm
if Rn == ‘1111’ then SEE UXTB16;


UXTAB16<c> <Rd>, <Rn>, <Rm>{, <rotation>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if Rn == ‘1111’ then SEE UXTB16;

Assembler syntax
UXTAB16{<c>}{<q>} {<Rd>,} <Rn>, <Rm> {, <rotation>}
where:

Note
disassembly.
Operation
R[d]<15:0> = R[n]<15:0> + ZeroExtend(rotated<7:0>, 16);
R[d]<31:16> = R[n]<31:16> + ZeroExtend(rotated<23:16>, 16);
Exceptions
None.
A8.8.274 UXTAH
Unsigned Extend and Add Halfword extracts a 16-bit value from a register, zero-extends it to 32 bits, adds the result
to a value from another register, and writes the final result to the destination register. The instruction can specify a

UXTAH<c> <Rd>, <Rn>, <Rm>{, <rotation>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 0 0 0 1 Rn 1 1 1 1 Rd 1 (0) rotate Rm
if Rn == ‘1111’ then SEE UXTH;


UXTAH<c> <Rd>, <Rn>, <Rm>{, <rotation>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if Rn == ‘1111’ then SEE UXTH;

Assembler syntax
UXTAH{<c>}{<q>} {<Rd>,} <Rn>, <Rm> {, <rotation>}
where:

Note
disassembly.
Operation
R[d] = R[n] + ZeroExtend(rotated<15:0>, 32);
Exceptions
None.
A8.8.275 UXTB
Unsigned Extend Byte extracts an 8-bit value from a register, zero-extends it to 32 bits, and writes the result to the
destination register. The instruction can specify a rotation by 0, 8, 16, or 24 bits before extracting the 8-bit value.

UXTB<c> <Rd>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 1 0 0 1 0 1 1 Rm Rd

UXTB<c>.W <Rd>, <Rm>{, <rotation>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 0 1 0 1 1 1 1 1 1 1 1 1 Rd 1 (0) rotate Rm


UXTB<c> <Rd>, <Rm>{, <rotation>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 1 1 1 0 1 1 1 1 Rd rotate (0) (0) 0 1 1 1 Rm

Assembler syntax
UXTB{<c>}{<q>} {<Rd>,} <Rm> {, <rotation>}
where:

Note
disassembly.
The pre-UAL syntax UEXT8<c> is equivalent to UXTB<c>.
Operation
R[d] = ZeroExtend(rotated<7:0>, 32);
Exceptions
None.
A8.8.276 UXTB16
Unsigned Extend Byte 16 extracts two 8-bit values from a register, zero-extends them to 16 bits each, and writes
the results to the destination register. The instruction can specify a rotation by 0, 8, 16, or 24 bits before extracting
the 8-bit values.

UXTB16<c> <Rd>, <Rm>{, <rotation>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 0 0 1 1 1 1 1 1 1 1 1 1 Rd 1 (0) rotate Rm


UXTB16<c> <Rd>, <Rm>{, <rotation>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 1 1 0 0 1 1 1 1 Rd rotate (0) (0) 0 1 1 1 Rm

Assembler syntax
UXTB16{<c>}{<q>} {<Rd>,} <Rm> {, <rotation>}
where:

Note
disassembly.
Operation
R[d]<15:0> = ZeroExtend(rotated<7:0>, 16);
R[d]<31:16> = ZeroExtend(rotated<23:16>, 16);
Exceptions
None.
A8.8.277 UXTH
Unsigned Extend Halfword extracts a 16-bit value from a register, zero-extends it to 32 bits, and writes the result to
the destination register. The instruction can specify a rotation by 0, 8, 16, or 24 bits before extracting the 16-bit
value.

UXTH<c> <Rd>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 1 0 0 1 0 1 0 Rm Rd

UXTH<c>.W <Rd>, <Rm>{, <rotation>}
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 1 0 0 0 0 1 1 1 1 1 1 1 1 1 Rd 1 (0) rotate Rm


UXTH<c> <Rd>, <Rm>{, <rotation>}
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 1 1 0 1 1 1 1 1 1 1 1 Rd rotate (0) (0) 0 1 1 1 Rm

Assembler syntax
UXTH{<c>}{<q>} {<Rd>,} <Rm> {, <rotation>}
where:

Note
disassembly.
The pre-UAL syntax UEXT16<c> is equivalent to UXTH<c>.
Operation
R[d] = ZeroExtend(rotated<15:0>, 32);
Exceptions
None.
A8.8.278 VABA, VABAL

Vector Absolute Difference and Accumulate {Long} subtracts the elements of one vector from the corresponding
elements of another vector, and accumulates the absolute values of the results into the elements of the destination
vector.
Operand and result elements are either all integers of the same length, or optionally the results can be double the
length of the operands.
Depending on settings in the CPACR, NSACR, and HCPTR registers, and the security state and mode in which the
instruction is executed, an attempt to execute the instruction might be UNDEFINED, or trapped to Hyp mode.
Summary of access controls for Advanced SIMD functionality on page B1-1232 summarizes these controls.
ARM deprecates the conditional execution of any Advanced SIMD instruction that is not also available as a VFP
instruction, see Conditional execution on page A8-286.
Encoding T1/A1 Advanced SIMD

VABA<c>.<dt> <Qd>, <Qn>, <Qm>
VABA<c>.<dt> <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 U 1 1 1 1 0 D size Vn Vd 0 1 1 1 N Q M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 U 0 D size Vn Vd 0 1 1 1 N Q M 1 Vm
if size == ‘11’ then UNDEFINED;

if Q == ‘1’ && (Vd<0> == ‘1’ || Vn<0> == ‘1’ || Vm<0> == ‘1’) then UNDEFINED;
unsigned = (U == ‘1’); long_destination = FALSE;
esize = 8 << UInt(size); elements = 64 DIV esize;
d = UInt(D:Vd); n = UInt(N:Vn); m = UInt(M:Vm); regs = if Q == ‘0’ then 1 else 2;

VABAL<c>.<dt> <Qd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 U 1 1 1 1 1 D size Vn Vd 0 1 0 1 N 0 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 U 1 D size Vn Vd 0 1 0 1 N 0 M 0 Vm
if size == ‘11’ then SEE “Related encodings”;

if Vd<0> == ‘1’ then UNDEFINED;
unsigned = (U == ‘1’); long_destination = TRUE;
d = UInt(D:Vd); n = UInt(N:Vn); m = UInt(M:Vm); regs = 1;
Related encodings See Advanced SIMD data-processing instructions on page A7-259.
Assembler syntax
VABA{<c>}{<q>}.<dt> <Qd>, <Qn>, <Qm> Encoding T1/A1, Q = 1
VABA{<c>}{<q>}.<dt> <Dd>, <Dn>, <Dm> Encoding T1/A1, Q = 0
VABAL{<c>}{<q>}.<dt> <Qd>, <Dn>, <Dm> Encoding T2/A2
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VABA or VABAL instruction
must be unconditional. ARM strongly recommends that a Thumb VABA or VABAL instruction
is unconditional, see Conditional execution on page A8-286.
<dt> The data type for the elements of the operands. It must be one of:
S8 encoded as size = 0b00, U = 0.
U8 encoded as size = 0b00, U = 1.
<Qd>, <Qn>, <Qm> The destination vector and the operand vectors, for a quadword operation.
<Dd>, <Dn>, <Dm> The destination vector and the operand vectors, for a doubleword operation.
<Qd>, <Dn>, <Dm> The destination vector and the operand vectors, for a long operation.
Operation
EncodingSpecificOperations(); CheckAdvSIMDEnabled();
for r = 0 to regs-1
for e = 0 to elements-1
op1 = Elem[Din[n+r],e,esize];
op2 = Elem[Din[m+r],e,esize];
absdiff = Abs(Int(op1,unsigned) - Int(op2,unsigned));
if long_destination then
Elem[Q[d>>1],e,2*esize] = Elem[Qin[d>>1],e,2*esize] + absdiff;
else
Elem[D[d+r],e,esize] = Elem[Din[d+r],e,esize] + absdiff;
Exceptions
A8.8.279 VABD, VABDL (integer)

Vector Absolute Difference {Long} (integer) subtracts the elements of one vector from the corresponding elements
of another vector, and places the absolute values of the results in the elements of the destination vector.
Operand and result elements are either all integers of the same length, or optionally the results can be double the
length of the operands.

VABD<c>.<dt> <Qd>, <Qn>, <Qm>
VABD<c>.<dt> <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

unsigned = (U == ‘1’); long_destination = FALSE;

VABDL<c>.<dt> <Qd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 U 1 1 1 1 1 D size Vn Vd 0 1 1 1 N 0 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 U 1 D size Vn Vd 0 1 1 1 N 0 M 0 Vm

unsigned = (U == ‘1’); long_destination = TRUE;
Assembler syntax
VABD{<c>}{<q>}.<dt> {<Qd>, }<Qn>, <Qm> Encoding T1/A1, Q = 1
VABD{<c>}{<q>}.<dt> {<Dd>, }<Dn>, <Dm> Encoding T1/A1, Q = 0
VABDL{<c>}{<q>}.<dt> <Qd>, <Dn>, <Dm> Encoding T2/A2
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VABD or VABDL instruction
must be unconditional. ARM strongly recommends that a Thumb VABD or VABDL instruction
Operation
for r = 0 to regs-1
op1 = Elem[Din[n+r],e,esize];
op2 = Elem[Din[m+r],e,esize];
absdiff = Abs(Int(op1,unsigned) - Int(op2,unsigned));
Elem[Q[d>>1],e,2*esize] = absdiff<2*esize-1:0>;
else
Elem[D[d+r],e,esize] = absdiff<esize-1:0>;
Exceptions
A8.8.280 VABD (floating-point)

Vector Absolute Difference (floating-point) subtracts the elements of one vector from the corresponding elements
of another vector, and places the absolute values of the results in the elements of the destination vector.
Operand and result elements are all single-precision floating-point numbers.
Encoding T1/A1 Advanced SIMD (UNDEFINED in integer-only variant)

VABD<c>.F32 <Qd>, <Qn>, <Qm>
VABD<c>.F32 <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 0 D 1 sz Vn Vd 1 1 0 1 N Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 0 D 1 sz Vn Vd 1 1 0 1 N Q M 0 Vm
if sz == ‘1’ then UNDEFINED;
esize = 32; elements = 2;
Assembler syntax
VABD{<c>}{<q>}.F32 {<Qd>, }<Qn>, <Qm> Encoded as Q = 1, sz = 0
VABD{<c>}{<q>}.F32 {<Dd>, }<Dn>, <Dm> Encoded as Q = 0, sz = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VABD instruction must be
unconditional. ARM strongly recommends that a Thumb VABD instruction is unconditional,
see Conditional execution on page A8-286.
Operation
for r = 0 to regs-1
op1 = Elem[D[n+r],e,esize]; op2 = Elem[D[m+r],e,esize];
Elem[D[d+r],e,esize] = FPAbs(FPSub(op1,op2,FALSE));
Exceptions
Input Denormal, Invalid Operation, Overflow, Underflow, Inexact.
A8.8.281 VABS
Vector Absolute takes the absolute value of each element in a vector, and places the results in a second vector. The
floating-point version only clears the sign bit.
Depending on settings in the CPACR, NSACR, HCPTR, and FPEXC registers, and the security state and mode in
which the instruction is executed, an attempt to execute the instruction might be UNDEFINED, or trapped to Hyp
mode. Summary of general controls of CP10 and CP11 functionality on page B1-1230 and Summary of access
controls for Advanced SIMD functionality on page B1-1232 summarize these controls.
Encoding T1/A1 Advanced SIMD (F = 1 UNDEFINED in integer-only variants)

VABS<c>.<dt> <Qd>, <Qm>
VABS<c>.<dt> <Dd>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 size 0 1 Vd 0 F 1 1 0 Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 size 0 1 Vd 0 F 1 1 0 Q M 0 Vm
if size == ‘11’ || (F == ‘1’ && size != ‘10’) then UNDEFINED;

if Q == ‘1’ && (Vd<0> == ‘1’ || Vm<0> == ‘1’) then UNDEFINED;
advsimd = TRUE; floating_point = (F == ‘1’);
d = UInt(D:Vd); m = UInt(M:Vm); regs = if Q == ‘0’ then 1 else 2;
Encoding T2/A2 VFPv2, VFPv3, VFPv4 (sz = 1 UNDEFINED in single-precision only variants)
VABS<c>.F64 <Dd>, <Dm>
VABS<c>.F32 <Sd>, <Sm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 0 1 D 1 1 0 0 0 0 Vd 1 0 1 sz 1 1 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 1 0 1 D 1 1 0 0 0 0 Vd 1 0 1 sz 1 1 M 0 Vm
if FPSCR.Len != ‘000’ || FPSCR.Stride != ‘00’ then SEE “VFP vectors”;

advsimd = FALSE; dp_operation = (sz == ‘1’);
d = if dp_operation then UInt(D:Vd) else UInt(Vd:D);
m = if dp_operation then UInt(M:Vm) else UInt(Vm:M);
VFP vectors Encoding T2/A2 can operate on VFP vectors under control of the FPSCR.{Len, Stride}
fields. For details see Appendix D11 VFP Vector Operation Support.
Assembler syntax
VABS{<c>}{<q>}.<dt> <Qd>, <Qm> Encoding T1/A1
VABS{<c>}{<q>}.<dt> <Dd>, <Dm> Encoding T1/A1
VABS{<c>}{<q>}.F32 <Sd>, <Sm> Floating-point only, encoding T2/A2, encoded as sz = 0
VABS{<c>}{<q>}.F64 <Dd>, <Dm> Encoding T2/A2, encoded as sz = 1
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM Advanced SIMD VABS instruction
must be unconditional. ARM strongly recommends that a Thumb Advanced SIMD VABS instruction
<dt> The data type for the elements of the vectors. It must be one of:
S8 Encoded as size = 0b00, F = 0.
F32 Encoded as size = 0b10, F = 1.
<Qd>, <Qm> The destination vector and the operand vector, for a quadword operation.
<Dd>, <Dm> The destination vector and the operand vector, for a doubleword operation.
<Sd>, <Sm> The destination vector and the operand vector, for a singleword operation.
Operation
EncodingSpecificOperations(); CheckAdvSIMDOrVFPEnabled(TRUE, advsimd);
if advsimd then // Advanced SIMD instruction
for r = 0 to regs-1
if floating_point then
Elem[D[d+r],e,esize] = FPAbs(Elem[D[m+r],e,esize]);
else
result = Abs(SInt(Elem[D[m+r],e,esize]));
Elem[D[d+r],e,esize] = result<esize-1:0>;
else // VFP instruction
if dp_operation then
D[d] = FPAbs(D[m]);
else
S[d] = FPAbs(S[m]);
Exceptions
A8.8.282 VACGE, VACGT, VACLE, VACLT

VACGE (Vector Absolute Compare Greater Than or Equal) and VACGT (Vector Absolute Compare Greater Than) take
the absolute value of each element in a vector, and compare it with the absolute value of the corresponding element
of a second vector. If the condition is true, the corresponding element in the destination vector is set to all ones.
Otherwise, it is set to all zeros.
VACLE (Vector Absolute Compare Less Than or Equal) is a pseudo-instruction, equivalent to a VACGE instruction with
the operands reversed. Disassembly produces the VACGE instruction.
VACLT (Vector Absolute Compare Less Than) is a pseudo-instruction, equivalent to a VACGT instruction with the
operands reversed. Disassembly produces the VACGT instruction.
The operands and result can be quadword or doubleword vectors. They must all be the same size.
The operand vector elements must be 32-bit floating-point numbers.
The result vector elements are 32-bit fields.

V<op><c>.F32 <Qd>, <Qn>, <Qm>
V<op><c>.F32 <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 0 D op sz Vn Vd 1 1 1 0 N Q M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 0 D op sz Vn Vd 1 1 1 0 N Q M 1 Vm
or_equal = (op == ‘0’); esize = 32; elements = 2;
Assembler syntax
V<op>{<c>}{<q>}.F32 {<Qd>,} <Qn>, <Qm> Encoded as Q = 1
V<op>{<c>}{<q>}.F32 {<Dd>,} <Dn>, <Dm> Encoded as Q = 0
where:
<op> The operation. It must be one of:

ACGE Absolute Compare Greater than or Equal, encoded as op = 0.
ACGT Absolute Compare Greater Than, encoded as op = 1.
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VACGE, VACGT, VACLE, or
VACLT instruction must be unconditional.ARM strongly recommends that a Thumb VACGE,
VACGT, VACLE, or VACLT instruction is unconditional, see Conditional execution on
page A8-286.
Operation
for r = 0 to regs-1
op1 = FPAbs(Elem[D[n+r],e,esize]); op2 = FPAbs(Elem[D[m+r],e,esize]);
if or_equal then
test_passed = FPCompareGE(op1, op2, FALSE);
else
test_passed = FPCompareGT(op1, op2, FALSE);
Elem[D[d+r],e,esize] = if test_passed then Ones(esize) else Zeros(esize);
Exceptions
Input Denormal, Invalid Operation.
A8.8.283 VADD (integer)

Vector Add adds corresponding elements in two vectors, and places the results in the destination vector.
ARM deprecates the conditional execution of any Advanced SIMD instruction encoding that is not also available
as a VFP instruction encoding, see Conditional execution on page A8-286.

VADD<c>.<dt> <Qd>, <Qn>, <Qm>
VADD<c>.<dt> <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 1 0 D size Vn Vd 1 0 0 0 N Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 0 0 D size Vn Vd 1 0 0 0 N Q M 0 Vm
Assembler syntax
VADD{<c>}{<q>}.<dt> {<Qd>,} <Qn>, <Qm>
VADD{<c>}{<q>}.<dt> {<Dd>,} <Dn>, <Dm>
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM Advanced SIMD VADD
instruction must be unconditional. ARM strongly recommends that a Thumb Advanced
SIMD VADD instruction is unconditional, see Conditional execution on page A8-286.
I8 size = 0b00.
I16 size = 0b01.
I32 size = 0b10.
I64 size = 0b11.
Operation
for r = 0 to regs-1
Elem[D[d+r],e,esize] = Elem[D[n+r],e,esize] + Elem[D[m+r],e,esize];
Exceptions
A8.8.284 VADD (floating-point)

Vector Add adds corresponding elements in two vectors, and places the results in the destination vector.

VADD<c>.F32 <Qd>, <Qn>, <Qm>
VADD<c>.F32 <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 1 0 D 0 sz Vn Vd 1 1 0 1 N Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 0 0 D 0 sz Vn Vd 1 1 0 1 N Q M 0 Vm
advsimd = TRUE; esize = 32; elements = 2;
VADD<c>.F64 <Dd>, <Dn>, <Dm>
VADD<c>.F32 <Sd>, <Sn>, <Sm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 0 0 D 1 1 Vn Vd 1 0 1 sz N 0 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 1 0 0 D 1 1 Vn Vd 1 0 1 sz N 0 M 0 Vm

n = if dp_operation then UInt(N:Vn) else UInt(Vn:N);
Assembler syntax
VADD{<c>}{<q>}.F32 {<Qd>,} <Qn>, <Qm> Encoding T1/A1, encoded as Q = 1, sz = 0
VADD{<c>}{<q>}.F32 {<Dd>,} <Dn>, <Dm> Encoding T1/A1, encoded as Q = 0, sz = 0
VADD{<c>}{<q>}.F32 {<Sd>,} <Sn>, <Sm> Encoding T2/A2, encoded as sz = 0
VADD{<c>}{<q>}.F64 {<Dd>,} <Dn>, <Dm> Encoding T2/A2, encoded as sz = 1
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM Advanced SIMD VADD
SIMD VADD instruction is unconditional, see Conditional execution on page A8-286
<Sd>, <Sn>, <Sm> The destination vector and the operand vectors, for a singleword operation.
Operation
for r = 0 to regs-1
Elem[D[d+r],e,esize] = FPAdd(Elem[D[n+r],e,esize], Elem[D[m+r],e,esize], FALSE);
D[d] = FPAdd(D[n], D[m], TRUE);
else
S[d] = FPAdd(S[n], S[m], TRUE);
Exceptions
A8.8.285 VADDHN
Vector Add and Narrow, returning High Half adds corresponding elements in two quadword vectors, and places the
most significant half of each result in a doubleword vector. The results are truncated. (For rounded results, see
VRADDHN on page A8-1023).
The operand elements can be 16-bit, 32-bit, or 64-bit integers. There is no distinction between signed and unsigned
integers.

VADDHN<c>.<dt> <Dd>, <Qn>, <Qm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 1 1 D size Vn Vd 0 1 0 0 N 0 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 0 1 D size Vn Vd 0 1 0 0 N 0 M 0 Vm

if Vn<0> == ‘1’ || Vm<0> == ‘1’ then UNDEFINED;
d = UInt(D:Vd); n = UInt(N:Vn); m = UInt(M:Vm);
Assembler syntax
VADDHN{<c>}{<q>}.<dt> <Dd>, <Qn>, <Qm>
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VADDHN instruction must be
unconditional.ARM strongly recommends that a Thumb VADDHN instruction is unconditional,
I16 size = 0b00.
I32 size = 0b01.
I64 size = 0b10.
<Dd>, <Qn>, <Qm> The destination vector, the first operand vector, and the second operand vector.
Operation
result = Elem[Qin[n>>1],e,2*esize] + Elem[Qin[m>>1],e,2*esize];
Elem[D[d],e,esize] = result<2*esize-1:esize>;
Exceptions
A8.8.286 VADDL, VADDW

VADDL (Vector Add Long) adds corresponding elements in two doubleword vectors, and places the results in a
quadword vector. Before adding, it sign-extends or zero-extends the elements of both operands.
VADDW (Vector Add Wide) adds corresponding elements in one quadword and one doubleword vector, and places the
results in a quadword vector. Before adding, it sign-extends or zero-extends the elements of the doubleword
operand.

VADDL<c>.<dt> <Qd>, <Dn>, <Dm>
VADDW<c>.<dt> <Qd>, <Qn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 U 1 1 1 1 1 D size Vn Vd 0 0 0 op N 0 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 U 1 D size Vn Vd 0 0 0 op N 0 M 0 Vm

if Vd<0> == ‘1’ || (op == ‘1’ && Vn<0> == ‘1’) then UNDEFINED;
unsigned = (U == ‘1’);
esize = 8 << UInt(size); elements = 64 DIV esize; is_vaddw = (op == ‘1’);
Assembler syntax
VADDL{<c>}{<q>}.<dt> <Qd>, <Dn>, <Dm> Encoded as op = 0
VADDW{<c>}{<q>}.<dt> {<Qd>,} <Qn>, <Dm> Encoded as op = 1
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VADDL or VADDW instruction must be
unconditional. ARM strongly recommends that a Thumb VADDL or VADDW instruction is unconditional,
<dt> The data type for the elements of the second operand vector. It must be one of:
<Qd> The destination register. If this register is omitted in a VADDW instruction, it is the same register as
<Qn>.
<Qn>, <Dm> The first and second operand registers for a VADDW instruction.
<Dn>, <Dm> The first and second operand registers for a VADDL instruction.
Operation
if is_vaddw then
op1 = Int(Elem[Qin[n>>1],e,2*esize], unsigned);
else
op1 = Int(Elem[Din[n],e,esize], unsigned);
result = op1 + Int(Elem[Din[m],e,esize],unsigned);
Elem[Q[d>>1],e,2*esize] = result<2*esize-1:0>;
Exceptions
A8.8.287 VAND (immediate)

This is a pseudo-instruction, equivalent to a VBIC (immediate) instruction with the immediate value bitwise inverted.
For details see VBIC (immediate) on page A8-839.
A8.8.288 VAND (register)

This instruction performs a bitwise AND operation between two registers, and places the result in the destination
register.

VAND<c> <Qd>, <Qn>, <Qm>
VAND<c> <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 1 0 D 0 0 Vn Vd 0 0 0 1 N Q M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 0 0 D 0 0 Vn Vd 0 0 0 1 N Q M 1 Vm
Assembler syntax
VAND{<c>}{<q>}{.<dt>} {<Qd>,} <Qn>, <Qm> Encoded as Q = 1
VAND{<c>}{<q>}{.<dt>} {<Dd>,} <Dn>, <Dm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VAND instruction must be
unconditional. ARM strongly recommends that a Thumb VAND instruction is unconditional,
<dt> An optional data type. It is ignored by assemblers, and does not affect the encoding.
Operation
for r = 0 to regs-1
D[d+r] = D[n+r] AND D[m+r];
Exceptions
A8.8.289 VBIC (immediate)

Vector Bitwise Bit Clear (immediate) performs a bitwise AND between a register value and the complement of an
immediate value, and returns the result into the destination vector. For the range of constants available, see One
register and a modified immediate value on page A7-267.

VBIC<c>.<dt> <Qd>, #<imm>
VBIC<c>.<dt> <Dd>, #<imm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 i 1 1 1 1 1 D 0 0 0 imm3 Vd cmode 0 Q 1 1 imm4
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 i 1 D 0 0 0 imm3 Vd cmode 0 Q 1 1 imm4
if cmode<0> == ‘0’ || cmode<3:2> == ‘11’ then SEE “Related encodings”;

if Q == ‘1’ && Vd<0> == ‘1’ then UNDEFINED;
imm64 = AdvSIMDExpandImm(‘1’, cmode, i:imm3:imm4);
d = UInt(D:Vd); regs = if Q == ‘0’ then 1 else 2;
Related encodings See One register and a modified immediate value on page A7-267.
Assembler syntax
VBIC{<c>}{<q>}.<dt> {<Qd>,} <Qd>, #<imm> Encoded as Q = 1
VBIC{<c>}{<q>}.<dt> {<Dd>,} <Dd>, #<imm>> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VBIC instruction must be
unconditional. ARM strongly recommends that a Thumb VBIC instruction is unconditional, see
<dt> The data type used for <imm>. It can be either I16 or I32.
I8, I64, and F32 are also permitted, but the resulting syntax is a pseudo-instruction.
<Qd> The destination vector for a quadword operation.
<Dd> The destination vector for a doubleword operation.
<imm> A constant of the type specified by <dt>. This constant is replicated enough times to fill the
destination register. For example, VBIC.I32 D0, #10 ANDs the complement of 0x0000000A0000000A
with D0, and puts the result into D0.
For details of the range of constants available and the encoding of <dt> and <imm>, see One register and a modified
immediate value on page A7-267.
Operation
for r = 0 to regs-1
D[d+r] = D[d+r] AND NOT(imm64);
Exceptions
Pseudo-instructions
VAND can be used with a range of constants that are the bitwise inverse of the available constants for VBIC. This is
assembled as the equivalent VBIC instruction. Disassembly produces the VBIC form.
One register and a modified immediate value on page A7-267 describes pseudo-instructions with a combination of
<dt> and <imm> that is not supported by hardware, but that generates the same destination register value as a different
combination that is supported by hardware.
A8.8.290 VBIC (register)

Vector Bitwise Bit Clear (register) performs a bitwise AND between a register value and the complement of a
register value, and places the result in the destination register.

VBIC<c> <Qd>, <Qn>, <Qm>
VBIC<c> <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 1 0 D 0 1 Vn Vd 0 0 0 1 N Q M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 0 0 D 0 1 Vn Vd 0 0 0 1 N Q M 1 Vm
Assembler syntax
VBIC{<c>}{<q>}{.<dt>} {<Qd>,} <Qn>, <Qm> Encoded as Q = 1
VBIC{<c>}{<q>}{.<dt>} {<Dd>,} <Dn>, <Dm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VBIC instruction must be
unconditional. ARM strongly recommends that a Thumb VBIC instruction is unconditional,
Operation
for r = 0 to regs-1
D[d+r] = D[n+r] AND NOT(D[m+r]);
Exceptions
A8.8.291 VBIF, VBIT, VBSL

VBIF (Vector Bitwise Insert if False), VBIT (Vector Bitwise Insert if True), and VBSL (Vector Bitwise Select) perform
bitwise selection under the control of a mask, and place the results in the destination register. The registers can be
either quadword or doubleword, and must all be the same size.

V<op><c> <Qd>, <Qn>, <Qm>
V<op><c> <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 0 D op Vn Vd 0 0 0 1 N Q M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 0 D op Vn Vd 0 0 0 1 N Q M 1 Vm
if op == ‘00’ then SEE VEOR;
if op == ‘01’ then operation = VBitOps_VBSL;
if op == ‘10’ then operation = VBitOps_VBIT;
if op == ‘11’ then operation = VBitOps_VBIF;
Assembler syntax
V<op>{<c>}{<q>}{.<dt>} {<Qd>,} <Qn>, <Qm> Encoded as Q = 1
V<op>{<c>}{<q>}{.<dt>} {<Dd>,} <Dn>, <Dm> Encoded as Q = 0
where:

BIF Bitwise Insert if False, encoded as op = 0b11. Inserts each bit from Vn into Vd
if the corresponding bit of Vm is 0, otherwise leaves the Vd bit unchanged.
BIT Bitwise Insert if True, encoded as op = 0b10. Inserts each bit from Vn into Vd if
the corresponding bit of Vm is 1, otherwise leaves the Vd bit unchanged.
BSL Bitwise Select, encoded as op = 0b01. Selects each bit from Vn into Vd if the
corresponding bit of Vd is 1, otherwise selects the bit from Vm.
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VBIF, VBIT, or VBSL
instruction must be unconditional. ARM strongly recommends that a Thumb VBIF, VBIT, or
VBSL instruction is unconditional, see Conditional execution on page A8-286.
Operation
enumeration VBitOps {VBitOps_VBIF, VBitOps_VBIT, VBitOps_VBSL};
for r = 0 to regs-1
case operation of
when VBitOps_VBIF D[d+r] = (D[d+r] AND D[m+r]) OR (D[n+r] AND NOT(D[m+r]));
when VBitOps_VBIT D[d+r] = (D[n+r] AND D[m+r]) OR (D[d+r] AND NOT(D[m+r]));
when VBitOps_VBSL D[d+r] = (D[n+r] AND D[d+r]) OR (D[m+r] AND NOT(D[d+r]));
Exceptions
A8.8.292 VCEQ (register)

VCEQ (Vector Compare Equal) takes each element in a vector, and compares it with the corresponding element of a
second vector. If they are equal, the corresponding element in the destination vector is set to all ones. Otherwise, it
is set to all zeros.
The operand vector elements can be any one of:

• 8-bit, 16-bit, or 32-bit integers. There is no distinction between signed and unsigned integers.
• 32-bit floating-point numbers.
The result vector elements are fields the same size as the operand vector elements.

VCEQ<c>.<dt> <Qd>, <Qn>, <Qm> <dt> an integer type
VCEQ<c>.<dt> <Dd>, <Dn>, <Dm> <dt> an integer type
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 0 D size Vn Vd 1 0 0 0 N Q M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 0 D size Vn Vd 1 0 0 0 N Q M 1 Vm
int_operation = TRUE; esize = 8 << UInt(size); elements = 64 DIV esize;

VCEQ<c>.F32 <Qd>, <Qn>, <Qm>
VCEQ<c>.F32 <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 1 0 D 0 sz Vn Vd 1 1 1 0 N Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 0 0 D 0 sz Vn Vd 1 1 1 0 N Q M 0 Vm
int_operation = FALSE; esize = 32; elements = 2;
Assembler syntax
VCEQ{<c>}{<q>}.<dt> {<Qd>,} <Qn>, <Qm> Encoded as Q = 1
VCEQ{<c>}{<q>}.<dt> {<Dd>,} <Dn>, <Dm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VCEQ instruction must be
unconditional. ARM strongly recommends that a Thumb VCEQ instruction is unconditional,
<dt> The data types for the elements of the operands. It must be one of:
I8 encoding T1/A1, size = 0b00.
F32 encoding T2/A2, sz = 0.
Operation
for r = 0 to regs-1
if int_operation then
test_passed = (op1 == op2);
else
test_passed = FPCompareEQ(op1, op2, FALSE);
Exceptions
A8.8.293 VCEQ (immediate #0)

VCEQ #0 (Vector Compare Equal to zero) takes each element in a vector, and compares it with zero. If it is equal to
zero, the corresponding element in the destination vector is set to all ones. Otherwise, it is set to all zeros.

• 8-bit, 16-bit, or 32-bit integers. There is no distinction between signed and unsigned integers.

VCEQ<c>.<dt> <Qd>, <Qm>, #0
VCEQ<c>.<dt> <Dd>, <Dm>, #0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 size 0 1 Vd 0 F 0 1 0 Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 size 0 1 Vd 0 F 0 1 0 Q M 0 Vm

floating_point = (F == ‘1’);
Assembler syntax
VCEQ{<c>}{<q>}.<dt> {<Qd>,} <Qm>, #0 Encoded as Q = 1
VCEQ{<c>}{<q>}.<dt> {<Dd>,} <Dm>, #0 Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VCEQ instruction must be
unconditional. ARM strongly recommends that a Thumb VCEQ instruction is unconditional, see
I8 encoded as size = 0b00, F = 0.
F32 encoded as size = 0b10, F = 1.
Operation
for r = 0 to regs-1
test_passed = FPCompareEQ(Elem[D[m+r],e,esize], FPZero(‘0’,esize), FALSE);
else
test_passed = (Elem[D[m+r],e,esize] == Zeros(esize));
Exceptions
A8.8.294 VCGE (register)

VCGE (Vector Compare Greater Than or Equal) takes each element in a vector, and compares it with the
corresponding element of a second vector. If the first is greater than or equal to the second, the corresponding
element in the destination vector is set to all ones. Otherwise, it is set to all zeros.

• 8-bit, 16-bit, or 32-bit signed integers
• 8-bit, 16-bit, or 32-bit unsigned integers

VCGE<c>.<dt> <Qd>, <Qn>, <Qm> <dt> an integer type
VCGE<c>.<dt> <Dd>, <Dn>, <Dm> <dt> an integer type
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
type = if U == ‘1’ then VCGEtype_unsigned else VCGEtype_signed;

VCGE<c>.F32 <Qd>, <Qn>, <Qm>
VCGE<c>.F32 <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 0 D 0 sz Vn Vd 1 1 1 0 N Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 0 D 0 sz Vn Vd 1 1 1 0 N Q M 0 Vm
type = VCGEtype_fp; esize = 32; elements = 2;
Assembler syntax
VCGE{<c>}{<q>}.<dt> {<Qd>,} <Qn>, <Qm> Encoded as Q = 1
VCGE{<c>}{<q>}.<dt> {<Dd>,} <Dn>, <Dm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VCGE instruction must be
unconditional. ARM strongly recommends that a Thumb VCGE instruction is unconditional,
S8 encoding T1/A1, encoded as size = 0b00, U = 0.
U8 encoding T1/A1, encoded as size = 0b00, U = 1.
F32 encoding T2/A2, encoded as sz = 0.
Operation
enumeration VCGEtype {VCGEtype_signed, VCGEtype_unsigned, VCGEtype_fp};
for r = 0 to regs-1
case type of
when VCGEtype_signed test_passed = (SInt(op1) >= SInt(op2));
when VCGEtype_unsigned test_passed = (UInt(op1) >= UInt(op2));
when VCGEtype_fp test_passed = FPCompareGE(op1, op2, FALSE);
Exceptions
A8.8.295 VCGE (immediate #0)

VCGE #0 (Vector Compare Greater Than or Equal to Zero) take each element in a vector, and compares it with zero.
If it is greater than or equal to zero, the corresponding element in the destination vector is set to all ones. Otherwise,
it is set to all zeros.


VCGE<c>.<dt> <Qd>, <Qm>, #0
VCGE<c>.<dt> <Dd>, <Dm>, #0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 size 0 1 Vd 0 F 0 0 1 Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 size 0 1 Vd 0 F 0 0 1 Q M 0 Vm

Assembler syntax
VCGE{<c>}{<q>}.<dt> {<Qd>,} <Qm>, #0 Encoded as Q = 1
VCGE{<c>}{<q>}.<dt> {<Dd>,} <Dm>, #0 Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VCGE instruction must be
unconditional. ARM strongly recommends that a Thumb VCGE instruction is unconditional, see
S8 encoded as size = 0b00, F = 0.
Operation
for r = 0 to regs-1
test_passed = FPCompareGE(Elem[D[m+r],e,esize], FPZero(‘0’,esize), FALSE);
else
test_passed = (SInt(Elem[D[m+r],e,esize]) >= 0);
Exceptions
A8.8.296 VCGT (register)

VCGT (Vector Compare Greater Than) takes each element in a vector, and compares it with the corresponding element
of a second vector. If the first is greater than the second, the corresponding element in the destination vector is set
to all ones. Otherwise, it is set to all zeros.


VCGT<c>.<dt> <Qd>, <Qn>, <Qm> <dt> an integer type
VCGT<c>.<dt> <Dd>, <Dn>, <Dm> <dt> an integer type
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
type = if U == ‘1’ then VCGTtype_unsigned else VCGTtype_signed;

VCGT<c>.F32 <Qd>, <Qn>, <Qm>
VCGT<c>.F32 <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 0 D 1 sz Vn Vd 1 1 1 0 N Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 0 D 1 sz Vn Vd 1 1 1 0 N Q M 0 Vm
type = VCGTtype_fp; esize = 32; elements = 2;
Assembler syntax
VCGT{<c>}{<q>}.<dt> {<Qd>,} <Qn>, <Qm> Encoded as Q = 1
VCGT{<c>}{<q>}.<dt> {<Dd>,} <Dn>, <Dm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VCGT instruction must be
unconditional. ARM strongly recommends that a Thumb VCGT instruction is unconditional,
F32 encoding T2/A2, encoded as sz = 0.
Operation
enumeration VCGTtype {VCGTtype_signed, VCGTtype_unsigned, VCGTtype_fp};
for r = 0 to regs-1
case type of
when VCGTtype_signed test_passed = (SInt(op1) > SInt(op2));
when VCGTtype_unsigned test_passed = (UInt(op1) > UInt(op2));
when VCGTtype_fp test_passed = FPCompareGT(op1, op2, FALSE);
Exceptions
A8.8.297 VCGT (immediate #0)

VCGT #0 (Vector Compare Greater Than Zero) take each element in a vector, and compares it with zero. If it is greater
than zero, the corresponding element in the destination vector is set to all ones. Otherwise, it is set to all zeros.


VCGT<c>.<dt> <Qd>, <Qm>, #0
VCGT<c>.<dt> <Dd>, <Dm>, #0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 size 0 1 Vd 0 F 0 0 0 Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 size 0 1 Vd 0 F 0 0 0 Q M 0 Vm

Assembler syntax
VCGT{<c>}{<q>}.<dt> {<Qd>,} <Qm>, #0 Encoded as Q = 1
VCGT{<c>}{<q>}.<dt> {<Dd>,} <Dm>, #0 Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VCGT instruction must be
unconditional. ARM strongly recommends that a Thumb VCGT instruction is unconditional, see
Operation
for r = 0 to regs-1
test_passed = FPCompareGT(Elem[D[m+r],e,esize], FPZero(‘0’,esize), FALSE);
else
test_passed = (SInt(Elem[D[m+r],e,esize]) > 0);
Exceptions
A8.8.298 VCLE (register)

VCLE is a pseudo-instruction, equivalent to a VCGE instruction with the operands reversed. For details see VCGE
(register) on page A8-849.
A8.8.299 VCLE (immediate #0)

VCLE #0 (Vector Compare Less Than or Equal to Zero) take each element in a vector, and compares it with zero. If
it is less than or equal to zero, the corresponding element in the destination vector is set to all ones. Otherwise, it is
set to all zeros.


VCLE<c>.<dt> <Qd>, <Qm>, #0
VCLE<c>.<dt> <Dd>, <Dm>, #0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 size 0 1 Vd 0 F 0 1 1 Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 size 0 1 Vd 0 F 0 1 1 Q M 0 Vm

Assembler syntax
VCLE{<c>}{<q>}.<dt> {<Qd>,} <Qm>, #0 Encoded as Q = 1
VCLE{<c>}{<q>}.<dt> {<Dd>,} <Dm>, #0 Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VCLE instruction must be
unconditional. ARM strongly recommends that a Thumb VCLE instruction is unconditional,
Operation
for r = 0 to regs-1
test_passed = FPCompareGE(FPZero(‘0’,esize), Elem[D[m+r],e,esize], FALSE);
else
test_passed = (SInt(Elem[D[m+r],e,esize]) <= 0);
Exceptions
A8.8.300 VCLS
Vector Count Leading Sign Bits counts the number of consecutive bits following the topmost bit, that are the same
as the topmost bit, in each element in a vector, and places the results in a second vector. The count does not include
the topmost bit itself.
The operand vector elements can be any one of 8-bit, 16-bit, or 32-bit signed integers.
The result vector elements are the same data type as the operand vector elements.

VCLS<c>.<dt> <Qd>, <Qm>
VCLS<c>.<dt> <Dd>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 size 0 0 Vd 0 1 0 0 0 Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 size 0 0 Vd 0 1 0 0 0 Q M 0 Vm

Assembler syntax
VCLS{<c>}{<q>}.<dt> <Qd>, <Qm> Encoded as Q = 1
VCLS{<c>}{<q>}.<dt> <Dd>, <Dm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VCLS instruction must be
unconditional. ARM strongly recommends that a Thumb VCLS instruction is unconditional, see
<dt> The data size for the elements of the operands. It must be one of:
S8 encoded as size = 0b00.
Operation
for r = 0 to regs-1
Elem[D[d+r],e,esize] = CountLeadingSignBits(Elem[D[m+r],e,esize])<esize-1:0>;
Exceptions
A8.8.301 VCLT (register)

VCLT is a pseudo-instruction, equivalent to a VCGT instruction with the operands reversed. For details see VCGT
(register) on page A8-853.
A8.8.302 VCLT (immediate #0)

VCLT #0 (Vector Compare Less Than Zero) take each element in a vector, and compares it with zero. If it is less than
zero, the corresponding element in the destination vector is set to all ones. Otherwise, it is set to all zeros.


VCLT<c>.<dt> <Qd>, <Qm>, #0
VCLT<c>.<dt> <Dd>, <Dm>, #0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 size 0 1 Vd 0 F 1 0 0 Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 size 0 1 Vd 0 F 1 0 0 Q M 0 Vm

Assembler syntax
VCLT{<c>}{<q>}.<dt> {<Qd>,} <Qm>, #0 Encoded as Q = 1
VCLT{<c>}{<q>}.<dt> {<Dd>,} <Dm>, #0 Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VCLT instruction must be
unconditional. ARM strongly recommends that a Thumb VCLT instruction is unconditional,
Operation
for r = 0 to regs-1
test_passed = FPCompareGT(FPZero(‘0’,esize), Elem[D[m+r],e,esize], FALSE);
else
test_passed = (SInt(Elem[D[m+r],e,esize]) < 0);
Exceptions
A8.8.303 VCLZ
Vector Count Leading Zeros counts the number of consecutive zeros, starting from the most significant bit, in each
element in a vector, and places the results in a second vector.
The operand vector elements can be any one of 8-bit, 16-bit, or 32-bit integers. There is no distinction between
signed and unsigned integers.
The result vector elements are the same data type as the operand vector elements.

VCLZ<c>.<dt> <Qd>, <Qm>
VCLZ<c>.<dt> <Dd>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 size 0 0 Vd 0 1 0 0 1 Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 size 0 0 Vd 0 1 0 0 1 Q M 0 Vm

Assembler syntax
VCLZ{<c>}{<q>}.<dt> <Qd>, <Qm> Encoded as Q = 1
VCLZ{<c>}{<q>}.<dt> <Dd>, <Dm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VCLZ instruction must be
unconditional. ARM strongly recommends that a Thumb VCLZ instruction is unconditional, see
<dt> The data size for the elements of the operands. It must be one of:
I8 encoded as size = 0b00.
Operation
for r = 0 to regs-1
Elem[D[d+r],e,esize] = CountLeadingZeroBits(Elem[D[m+r],e,esize])<esize-1:0>;
Exceptions
A8.8.304 VCMP, VCMPE

This instruction compares two floating-point registers, or one floating-point register and zero. It writes the result to
the FPSCR flags. These are normally transferred to the ARM flags by a subsequent VMRS instruction.
It can optionally raise an Invalid Operation exception if either operand is any type of NaN. It always raises an Invalid
Operation exception if either operand is a signaling NaN.
Summary of general controls of CP10 and CP11 functionality on page B1-1230 summarizes these controls.
VCMP{E}<c>.F64 <Dd>, <Dm>
VCMP{E}<c>.F32 <Sd>, <Sm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 0 1 D 1 1 0 1 0 0 Vd 1 0 1 sz E 1 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 1 0 1 D 1 1 0 1 0 0 Vd 1 0 1 sz E 1 M 0 Vm
dp_operation = (sz == ‘1’); quiet_nan_exc = (E == ‘1’); with_zero = FALSE;

VCMP{E}<c>.F64 <Dd>, #0.0
VCMP{E}<c>.F32 <Sd>, #0.0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 0 1 D 1 1 0 1 0 1 Vd 1 0 1 sz E 1 (0) 0 (0) (0) (0) (0)
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 1 0 1 D 1 1 0 1 0 1 Vd 1 0 1 sz E 1 (0) 0 (0) (0) (0) (0)
dp_operation = (sz == ‘1’); quiet_nan_exc = (E == ‘1’); with_zero = TRUE;

Assembler syntax
VCMP{E}{<c>}{<q>}.F64 <Dd>, <Dm> Encoding T1/A1, encoded as sz = 1
VCMP{E}{<c>}{<q>}.F32 <Sd>, <Sm> Encoding T1/A1, encoded as sz = 0
VCMP{E}{<c>}{<q>}.F64 <Dd>, #0.0 Encoding T2/A2, encoded as sz = 1
VCMP{E}{<c>}{<q>}.F32 <Sd>, #0.0 Encoding T2/A2, encoded as sz = 0
where:
E If present, any NaN operand causes an Invalid Operation exception. Encoded as E = 1.

Otherwise, only a signaling NaN causes the exception. Encoded as E = 0.
<Dd>, <Dm> The operand vectors, for a doubleword operation.
<Sd>, <Sm> The operand vectors, for a singleword operation.
Operation
EncodingSpecificOperations(); CheckVFPEnabled(TRUE);
op64 = if with_zero then FPZero(‘0’,64) else D[m];
(FPSCR.N, FPSCR.Z, FPSCR.C, FPSCR.V) = FPCompare(D[d], op64, quiet_nan_exc, TRUE);
else
op32 = if with_zero then FPZero(‘0’,32) else S[m];
(FPSCR.N, FPSCR.Z, FPSCR.C, FPSCR.V) = FPCompare(S[d], op32, quiet_nan_exc, TRUE);
Exceptions
Invalid Operation, Input Denormal.
NaNs
The IEEE 754 standard specifies that the result of a comparison is precisely one of <, ==, > or unordered. If either
or both of the operands are NaNs, they are unordered, and all three of (Operand1 < Operand2),
(Operand1 == Operand2) and (Operand1 > Operand2) are false. This results in the FPSCR flags being set as N=0,
Z=0, C=1 and V=1.
VCMPE raises an Invalid Operation exception if either operand is any type of NaN, and is suitable for testing for <, <=,
>, >=, and other predicates that raise an exception when the operands are unordered.
A8.8.305 VCNT
This instruction counts the number of bits that are one in each element in a vector, and places the results in a second
vector.
The operand vector elements must be 8-bit fields.
The result vector elements are 8-bit integers.

VCNT<c>.8 <Qd>, <Qm>
VCNT<c>.8 <Dd>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 size 0 0 Vd 0 1 0 1 0 Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 size 0 0 Vd 0 1 0 1 0 Q M 0 Vm
if size != ‘00’ then UNDEFINED;

Assembler syntax
VCNT{<c>}{<q>}.8 <Qd>, <Qm> Encoded as Q = 1
VCNT{<c>}{<q>}.8 <Dd>, <Dm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VCNT instruction must be
unconditional. ARM strongly recommends that a Thumb VCNT instruction is unconditional,
Operation
for r = 0 to regs-1
Elem[D[d+r],e,esize] = BitCount(Elem[D[m+r],e,esize])<esize-1:0>;
Exceptions
A8.8.306 VCVT (between floating-point and integer, Advanced SIMD)

This instruction converts each element in a vector from floating-point to integer, or from integer to floating-point,
and places the results in a second vector.
The vector elements must be 32-bit floating-point numbers, or 32-bit integers. Signed and unsigned integers are
distinct.
The floating-point to integer operation uses the Round towards Zero rounding mode. The integer to floating-point
operation uses the Round to Nearest rounding mode.

VCVT<c>.<Td>.<Tm> <Qd>, <Qm>
VCVT<c>.<Td>.<Tm> <Dd>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 size 1 1 Vd 0 1 1 op Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 size 1 1 Vd 0 1 1 op Q M 0 Vm

to_integer = (op<1> == ‘1’); unsigned = (op<0> == ‘1’); esize = 32; elements = 2;
if to_integer then
round_zero = TRUE; // Variable name indicates purpose of FPToFixed() argument
else
round_nearest = TRUE; // Variable name indicates purpose of FixedToFP() argument
Assembler syntax
VCVT{<c>}{<q>}.<Td>.<Tm> <Qd>, <Qm> Encoded as Q = 1
VCVT{<c>}{<q>}.<Td>.<Tm> <Dd>, <Dm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM Advanced SIMD VCVT instruction
must be unconditional. ARM strongly recommends that a Thumb Advanced SIMD VCVT instruction
.<Td>.<Tm> The data types for the elements of the vectors. They must be one of:
.S32.F32 encoded as op = 0b10, size = 0b10.
.U32.F32 encoded as op = 0b11, size = 0b10.
.F32.S32 encoded as op = 0b00, size = 0b10.
.F32.U32 encoded as op = 0b01, size = 0b10.
Operation
for r = 0 to regs-1
op = Elem[D[m+r],e,esize];
if to_integer then
result = FPToFixed(op, esize, 0, unsigned, round_zero, FALSE);
else
result = FixedToFP(op, esize, 0, unsigned, round_nearest, FALSE);
Elem[D[d+r],e,esize] = result;
Exceptions
Input Denormal, Invalid Operation, Inexact.
A8.8.307 VCVT, VCVTR (between floating-point and integer, Floating-point)

These instructions convert a value in a register from floating-point to a 32-bit integer, or from a 32-bit integer to
floating-point, and place the result in a second register.
The floating-point to integer operation normally uses the Round towards Zero rounding mode, but can optionally
use the rounding mode specified by the FPSCR. The integer to floating-point operation uses the rounding mode
specified by the FPSCR.
VCVT (between floating-point and fixed-point, Floating-point) on page A8-875 describes conversions between
floating-point and 16-bit integers.
mode. Summary of general controls of CP10 and CP11 functionality on page B1-1230 summarizes these controls.
VCVT{R}<c>.S32.F64 <Sd>, <Dm>
VCVT{R}<c>.S32.F32 <Sd>, <Sm>
VCVT{R}<c>.U32.F64 <Sd>, <Dm>
VCVT{R}<c>.U32.F32 <Sd>, <Sm>
VCVT<c>.F64.<Tm> <Dd>, <Sm>
VCVT<c>.F32.<Tm> <Sd>, <Sm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 0 1 D 1 1 1 opc2 Vd 1 0 1 sz op 1 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 1 0 1 D 1 1 1 opc2 Vd 1 0 1 sz op 1 M 0 Vm
if opc2 != ‘000’ && !(opc2 IN “10x”) then SEE “Related encodings”;

to_integer = (opc2<2> == ‘1’); dp_operation = (sz == 1);
if to_integer then
unsigned = (opc2<0> == ‘0’); round_zero = (op == ‘1’);
d = UInt(Vd:D); m = if dp_operation then UInt(M:Vm) else UInt(Vm:M);
else
unsigned = (op == ‘0’); round_nearest = FALSE; // FALSE selects FPSCR rounding
m = UInt(Vm:M); d = if dp_operation then UInt(D:Vd) else UInt(Vd:D);
Related encodings See Floating-point data-processing instructions on page A7-270.
Assembler syntax
VCVT{R}{<c>}{<q>}.S32.F64 <Sd>, <Dm> Encoded as opc2 = 0b101, sz = 1
VCVT{R}{<c>}{<q>}.S32.F32 <Sd>, <Sm> Encoded as opc2 = 0b101, sz = 0
VCVT{R}{<c>}{<q>}.U32.F64 <Sd>, <Dm> Encoded as opc2 = 0b100, sz = 1
VCVT{R}{<c>}{<q>}.U32.F32 <Sd>, <Sm> Encoded as opc2 = 0b100, sz = 0
VCVT{<c>}{<q>}.F64.<Tm> <Dd>, <Sm> Encoded as opc2 = 0b000, sz = 1
VCVT{<c>}{<q>}.F32.<Tm> <Sd>, <Sm> Encoded as opc2 = 0b000, sz = 0
where:
R If R is specified, the operation uses the rounding mode specified by the FPSCR. Encoded as op = 0.
If R is omitted. the operation uses the Round towards Zero rounding mode. For syntaxes in which R
is optional, op is encoded as 1 if R is omitted.
<Tm> The data type for the operand. It must be one of:
S32 encoded as op = 1
U32 encoded as op = 0.
<Sd>, <Dm> The destination register and the operand register, for a double-precision operand.
<Dd>, <Sm> The destination register and the operand register, for a double-precision result.
<Sd>, <Sm> The destination register and the operand register, for a single-precision operand or result.
Operation
if to_integer then
S[d] = FPToFixed(D[m], 32, 0, unsigned, round_zero, TRUE);
else
S[d] = FPToFixed(S[m], 32, 0, unsigned, round_zero, TRUE);
else
D[d] = FixedToFP(S[m], 64, 0, unsigned, round_nearest, TRUE);
else
S[d] = FixedToFP(S[m], 32, 0, unsigned, round_nearest, TRUE);
Exceptions
A8.8.308 VCVT (between floating-point and fixed-point, Advanced SIMD)

This instruction converts each element in a vector from floating-point to fixed-point, or from fixed-point to
floating-point, and places the results in a second vector.
The vector elements must be 32-bit floating-point numbers, or 32-bit integers. Signed and unsigned integers are
distinct.
The floating-point to fixed-point operation uses the Round towards Zero rounding mode. The fixed-point to
floating-point operation uses the Round to Nearest rounding mode.

VCVT<c>.<Td>.<Tm> <Qd>, <Qm>, #<fbits>
VCVT<c>.<Td>.<Tm> <Dd>, <Dm>, #<fbits>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 U 1 1 1 1 1 D imm6 Vd 1 1 1 op 0 Q M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 U 1 D imm6 Vd 1 1 1 op 0 Q M 1 Vm
if imm6 IN “000xxx” then SEE “Related encodings”;

if imm6 IN “0xxxxx” then UNDEFINED;
to_fixed = (op == ‘1’); unsigned = (U == ‘1’);
if to_fixed then
round_zero = TRUE; // Variable name indicates purpose of FPToFixed() argument
else
round_nearest = TRUE; // Variable name indicates purpose of FixedToFP() argument
esize = 32; frac_bits = 64 - UInt(imm6); elements = 2;
Assembler syntax
VCVT{<c>}{<q>}.<Td>.<Tm> <Qd>, <Qm>, #<fbits> Encoded as Q = 1
VCVT{<c>}{<q>}.<Td>.<Tm> <Dd>, <Dm>, #<fbits> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM Advanced SIMD VCVT instruction
must be unconditional. ARM strongly recommends that a Thumb Advanced SIMD VCVT instruction
.<Td>.<Tm> The data types for the elements of the vectors. They must be one of:
.S32.F32 encoded as op = 1, U = 0
.U32.F32 encoded as op = 1, U = 1
.F32.S32 encoded as op = 0, U = 0
.F32.U32 encoded as op = 0, U = 1.
<fbits> The number of fraction bits in the fixed point number, in the range 1 to 32:
• (64 - <fbits>) is encoded in imm6.
An assembler can permit an <fbits> value of 0. This is encoded as floating-point to integer or integer
to floating-point instruction, see VCVT (between floating-point and integer, Advanced SIMD) on
page A8-869.
Operation
for r = 0 to regs-1
op = Elem[D[m+r],e,esize];
if to_fixed then
result = FPToFixed(op, esize, frac_bits, unsigned, round_zero, FALSE);
else
result = FixedToFP(op, esize, frac_bits, unsigned, round_nearest, FALSE);
Exceptions
A8.8.309 VCVT (between floating-point and fixed-point, Floating-point)

This instruction converts a value in a register from floating-point to fixed-point, or from fixed-point to
floating-point. Software can specify the fixed-point value as either signed or unsigned.
The floating-point value can be single-precision or double-precision.
The fixed-point value can be 16-bit or 32-bit. Conversions from fixed-point values take their operand from the
low-order bits of the source register and ignore any remaining bits. Signed conversions to fixed-point values
sign-extend the result value to the destination register width. Unsigned conversions to fixed-point values
zero-extend the result value to the destination register width.
The floating-point to fixed-point operation uses the Round towards Zero rounding mode. The fixed-point to
floating-point operation uses the Round to Nearest rounding mode.
Encoding T1/A1 VFPv3, VFPv4 (sf = 1 UNDEFINED in single-precision only variants)

VCVT<c>.<Td>.F64 <Dd>, <Dd>, #<fbits>
VCVT<c>.<Td>.F32 <Sd>, <Sd>, #<fbits>
VCVT<c>.F64.<Td> <Dd>, <Dd>, #<fbits>
VCVT<c>.F32.<Td> <Sd>, <Sd>, #<fbits>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 0 1 D 1 1 1 op 1 U Vd 1 0 1 sf sx 1 i 0 imm4
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 1 0 1 D 1 1 1 op 1 U Vd 1 0 1 sf sx 1 i 0 imm4
to_fixed = (op == ‘1’); dp_operation = (sf == ‘1’); unsigned = (U == ‘1’);

size = if sx == ‘0’ then 16 else 32;
frac_bits = size - UInt(imm4:i);
if to_fixed then
round_zero = TRUE;
else
round_nearest = TRUE;
if frac_bits < 0 then UNPREDICTABLE;
Assembler syntax
VCVT{<c>}{<q>}.<Td>.F64 <Dd>, <Dd>, #<fbits> Encoded as op = 1, sf = 1
VCVT{<c>}{<q>}.<Td>.F32 <Sd>, <Sd>, #<fbits> Encoded as op = 1, sf = 0
VCVT{<c>}{<q>}.F64.<Td> <Dd>, <Dd>, #<fbits> Encoded as op = 0, sf = 1
VCVT{<c>}{<q>}.F32.<Td> <Sd>, <Sd>, #<fbits> Encoded as op = 0, sf = 0
where:
<Td> The data type for the fixed-point number. It must be one of:
S16 encoded as U = 0, sx = 0
U16 encoded as U = 1, sx = 0
S32 encoded as U = 0, sx = 1
U32 encoded as U = 1, sx = 1.
<Dd> The destination and operand register, for a double-precision operand.
<Sd> The destination and operand register, for a single-precision operand.
<fbits> The number of fraction bits in the fixed-point number:

• If <Td> is S16 or U16, <fbits> must be in the range 0-16. (16 - <fbits>) is encoded in [imm4, i]
• I f <Td> is S32 or U32, <fbits> must be in the range 1-32. (32 - <fbits>) is encoded in [imm4, i].
Operation
if to_fixed then
result = FPToFixed(D[d], size, frac_bits, unsigned, round_zero, TRUE);
D[d] = if unsigned then ZeroExtend(result, 64) else SignExtend(result, 64);
else
result = FPToFixed(S[d], size, frac_bits, unsigned, round_zero, TRUE);
S[d] = if unsigned then ZeroExtend(result, 32) else SignExtend(result, 32);
else
D[d] = FixedToFP(D[d]<size-1:0>, 64, frac_bits, unsigned, round_nearest, TRUE);
else
S[d] = FixedToFP(S[d]<size-1:0>, 32, frac_bits, unsigned, round_nearest, TRUE);
Exceptions
A8.8.310 VCVT (between double-precision and single-precision)

This instruction does one of the following:
• converts the value in a double-precision register to single-precision and writes the result to a single-precision
register
• converts the value in a single-precision register to double-precision and writes the result to a double-precision
register.
Encoding T1/A1 VFPv2, VFPv3, VFPv4 (UNDEFINED in single-precision only variants)

VCVT<c>.F64.F32 <Dd>, <Sm>
VCVT<c>.F32.F64 <Sd>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 0 1 D 1 1 0 1 1 1 Vd 1 0 1 sz 1 1 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 1 0 1 D 1 1 0 1 1 1 Vd 1 0 1 sz 1 1 M 0 Vm
double_to_single = (sz == ‘1’);

d = if double_to_single then UInt(Vd:D) else UInt(D:Vd);
m = if double_to_single then UInt(M:Vm) else UInt(Vm:M);
Assembler syntax
VCVT{<c>}{<q>}.F64.F32 <Dd>, <Sm> Encoded as sz = 0
VCVT{<c>}{<q>}.F32.F64 <Sd>, <Dm> Encoded as sz = 1
where:
<Dd>, <Sm> The destination register and the operand register, for a single-precision operand.
<Sd>, <Dm> The destination register and the operand register, for a double-precision operand.
Operation
if double_to_single then
S[d] = FPDoubleToSingle(D[m], TRUE);
else
D[d] = FPSingleToDouble(S[m], TRUE);
Exceptions
Invalid Operation, Input Denormal, Overflow, Underflow, Inexact.
A8.8.311 VCVT (between half-precision and single-precision, Advanced SIMD)

This instruction converts each element in a vector from single-precision to half-precision floating-point or from
half-precision to single-precision, and places the results in a second vector.
The vector elements must be 32-bit floating-point numbers, or 16-bit floating-point numbers.
Encoding T1/A1 Advanced SIMD with Half-precision Extension (UNDEFINED in integer-only variant)
VCVT<c>.F32.F16 <Qd>, <Dm>
VCVT<c>.F16.F32 <Dd>, <Qm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 size 1 0 Vd 0 1 1 op 0 0 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 size 1 0 Vd 0 1 1 op 0 0 M 0 Vm
half_to_single = (op == ‘1’);

if half_to_single && Vd<0> == ‘1’ then UNDEFINED;
if !half_to_single && Vm<0> == ‘1’ then UNDEFINED;
m = UInt(M:Vm); d = UInt(D:Vd);
Assembler syntax
VCVT{<c>}{<q>}.F32.F16 <Qd>, <Dm> Encoded as op = 1
VCVT{<c>}{<q>}.F16.F32 <Dd>, <Qm> Encoded as op = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VCVT instruction must be
unconditional. ARM strongly recommends that a Thumb VCVT instruction is unconditional, see
<Qd>, <Dm> The destination vector and the operand vector for a half-precision to single-precision operation.
<Dd>, <Qm> The destination vector and the operand vectors for a single-precision to half-precision operation.
Operation
if half_to_single then
Elem[Q[d>>1],e,2*esize] = FPHalfToSingle(Elem[Din[m],e,esize], FALSE);
else
Elem[D[d],e,esize] = FPSingleToHalf(Elem[Qin[m>>1],e,2*esize], FALSE);
Exceptions
A8.8.312 VCVTB, VCVTT

Vector Convert Bottom and Vector Convert Top do one of the following:
• convert the half-precision value in the top or bottom half of a single-precision register to single-precision and
write the result to a single-precision register
• convert the value in a single-precision register to half-precision and write the result into the top or bottom
half of a single-precision register, preserving the other half of the target register.
Encoding T1/A1 VFPv3 Half-precision Extension, VFPv4

VCVT<y><c>.F32.F16 <Sd>, <Sm>
VCVT<y><c>.F16.F32 <Sd>, <Sm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 0 1 D 1 1 0 0 1 op Vd 1 0 1 (0) T 1 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 1 0 1 D 1 1 0 0 1 op Vd 1 0 1 (0) T 1 M 0 Vm
half_to_single = (op == ‘0’);

lowbit = if T == ‘1’ then 16 else 0;
m = UInt(Vm:M); d = UInt(Vd:D);
Assembler syntax
VCVT<y>{<c>}{<q>}.F32.F16 <Sd>, <Sm> Encoded as op = 0
VCVT<y>{<c>}{<q>}.F16.F32 <Sd>, <Sm> Encoded as op = 1
where:
<y> Specifies which half of the operand register <Sm> or destination register <Sd> is used for the operand
or destination. One of:
B Encoded as T = 0.
Instruction uses the bottom half of the register, bits[15:0].
T Encoded as T = 1.
Instruction uses the top half of the register, bits[31:16].
<Sd> The destination register.
<Sm> The operand register.
Operation
if half_to_single then
S[d] = FPHalfToSingle(S[m]<lowbit+15:lowbit>, TRUE);
else
S[d]<lowbit+15:lowbit> = FPSingleToHalf(S[m], TRUE);
Exceptions
A8.8.313 VDIV
This instruction divides one floating-point value by another floating-point value and writes the result to a third
floating-point register.
VDIV<c>.F64 <Dd>, <Dn>, <Dm>
VDIV<c>.F32 <Sd>, <Sn>, <Sm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 0 1 D 0 0 Vn Vd 1 0 1 sz N 0 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

dp_operation = (sz == ‘1’);
VFP vectors This instruction can operate on VFP vectors under control of the FPSCR.{Len, Stride} fields.
For details see Appendix D11 VFP Vector Operation Support.
Assembler syntax
VDIV{<c>}{<q>}.F64 {<Dd>,} <Dn>, <Dm> Encoded as sz = 1
VDIV{<c>}{<q>}.F32 {<Sd>,} <Sn>, <Sm> Encoded as sz = 0
where:
<Dd>, <Dn>, <Dm> The destination register and the operand registers, for a double-precision operation.
<Sd>, <Sn>, <Sm> The destination register and the operand registers, for a single-precision operation.
Operation
D[d] = FPDiv(D[n], D[m], TRUE);
else
S[d] = FPDiv(S[n], S[m], TRUE);
Exceptions
Invalid Operation, Division by Zero, Overflow, Underflow, Inexact, Input Denormal.
A8.8.314 VDUP (scalar)

Vector Duplicate duplicates a scalar into every element of the destination vector.
The scalar, and the destination vector elements, can be any one of 8-bit, 16-bit, or 32-bit fields. There is no
distinction between data types.
For more information about scalars see Advanced SIMD scalars on page A7-257.

VDUP<c>.<size> <Qd>, <Dm[x]>
VDUP<c>.<size> <Dd>, <Dm[x]>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 imm4 Vd 1 1 0 0 0 Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 imm4 Vd 1 1 0 0 0 Q M 0 Vm
if imm4 IN “x000” then UNDEFINED;

case imm4 of
when “xxx1” esize = 8; elements = 8; index = UInt(imm4<3:1>);
when “xx10” esize = 16; elements = 4; index = UInt(imm4<3:2>);
when “x100” esize = 32; elements = 2; index = UInt(imm4<3>);
Assembler syntax
VDUP{<c>}{<q>}.<size> <Qd>, <Dm[x]> Encoded as Q = 1
VDUP{<c>}{<q>}.<size> <Dd>, <Dm[x]> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VDUP instruction must be
unconditional. ARM strongly recommends that a Thumb VDUP instruction is unconditional, see
<size> The data size. It must be one of:

8 Encoded as imm4<0> = '1'. imm4<3:1> encodes the index [x] of the scalar.
16 Encoded as imm4<1:0> = '10'. imm4<3:2> encodes the index [x] of the scalar.
32 Encoded as imm4<2:0> = '100'. imm4<3> encodes the index [x] of the scalar.
<Dm[x]> The scalar. For details of how [x] is encoded, see the description of <size>.
Operation
scalar = Elem[D[m],index,esize];
for r = 0 to regs-1
Elem[D[d+r],e,esize] = scalar;
Exceptions
A8.8.315 VDUP (ARM core register)

This instruction duplicates an element from an ARM core register into every element of the destination vector.
The destination vector elements can be 8-bit, 16-bit, or 32-bit fields. The source element is the least significant 8,
16, or 32 bits of the ARM core register. There is no distinction between data types.

VDUP<c>.<size> <Qd>, <Rt>
VDUP<c>.<size> <Dd>, <Rt>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 0 1 B Q 0 Vd Rt 1 0 1 1 D 0 E 1 (0) (0) (0) (0)
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 1 0 1 B Q 0 Vd Rt 1 0 1 1 D 0 E 1 (0) (0) (0) (0)

d = UInt(D:Vd); t = UInt(Rt); regs = if Q == ‘0’ then 1 else 2;
case B:E of
when ‘00’ esize = 32; elements = 2;
when ‘11’ UNDEFINED;
if t == 15 || (CurrentInstrSet() != InstrSet_ARM && t == 13) then UNPREDICTABLE;
Assembler syntax
VDUP{<c>}{<q>}.<size> <Qd>, <Rt> Encoded as Q = 1
VDUP{<c>}{<q>}.<size> <Dd>, <Rt> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. ARM strongly recommends that any VDUP
instruction is unconditional, see Conditional execution on page A8-286.
<size> The data size for the elements of the destination vector. It must be one of:
8 encoded as [b, e] = 0b10.
<Rt> The ARM source register.
Operation
scalar = R[t]<esize-1:0>;
for r = 0 to regs-1
Elem[D[d+r],e,esize] = scalar;
Exceptions
A8.8.316 VEOR
Vector Bitwise Exclusive OR performs a bitwise Exclusive OR operation between two registers, and places the
result in the destination register. The operand and result registers can be quadword or doubleword. They must all be
the same size.

VEOR<c> <Qd>, <Qn>, <Qm>
VEOR<c> <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 0 D 0 0 Vn Vd 0 0 0 1 N Q M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 0 D 0 0 Vn Vd 0 0 0 1 N Q M 1 Vm
Assembler syntax
VEOR{<c>}{<q>}{.<dt>} {<Qd>,} <Qn>, <Qm> Encoded as Q = 1
VEOR{<c>}{<q>}{.<dt>} {<Dd>,} <Dn>, <Dm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VEOR instruction must be
unconditional. ARM strongly recommends that a Thumb VEOR instruction is unconditional,
Operation
for r = 0 to regs-1
D[d+r] = D[n+r] EOR D[m+r];
Exceptions
A8.8.317 VEXT
Vector Extract extracts elements from the bottom end of the second operand vector and the top end of the first,
concatenates them and places the result in the destination vector. See Figure A8-1 for an example.
The elements of the vectors are treated as being 8-bit fields. There is no distinction between data types.
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Vm Vn
Vd
Figure A8-1 VEXT doubleword operation for imm = 3

VEXT<c>.8 <Qd>, <Qn>, <Qm>, #<imm>
VEXT<c>.8 <Dd>, <Dn>, <Dm>, #<imm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 1 1 D 1 1 Vn Vd imm4 N Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 0 1 D 1 1 Vn Vd imm4 N Q M 0 Vm
if Q == ‘0’ && imm4<3> == ‘1’ then UNDEFINED;
quadword_operation = (Q == ‘1’); position = 8 * UInt(imm4);
Assembler syntax
VEXT{<c>}{<q>}.<size> {<Qd>,} <Qn>, <Qm>, #<imm> Encoded as Q = 1
VEXT{<c>}{<q>}.<size> {<Dd>,} <Dn>, <Dm>, #<imm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VEXT instruction must be
unconditional. ARM strongly recommends that a Thumb VEXT instruction is unconditional,
<size> Size of the operation. The value can be:

• 8, 16, or 32 for doubleword operations
• 8, 16, 32, or 64 for quadword operations.
If the value is 16, 32, or 64, the syntax is a pseudo-instruction for a VEXT instruction
specifying the equivalent number of bytes. The following examples show how an assembler
treats values greater than 8:
VEXT.16 D0, D1, #x is treated as VEXT.8 D0, D1, #(x*2)
VEXT.32 D0, D1, #x is treated as VEXT.8 D0, D1, #(x*4)
VEXT.64 Q0, Q1, #x is treated as VEXT.8 Q0, Q1, #(x*8).
<imm> The location of the extracted result in the concatenation of the operands, as a number of
bytes from the least significant end, in the range 0-7 for a doubleword operation or 0-15 for
a quadword operation.
Operation
if quadword_operation then
Q[d>>1] = (Q[m>>1]:Q[n>>1])<position+127:position>;
else
D[d] = (D[m]:D[n])<position+63:position>;
Exceptions
A8.8.318 VFMA, VFMS

Vector Fused Multiply Accumulate multiplies corresponding elements of two vectors, and accumulates the results
into the elements of the destination vector. The instruction does not round the result of the multiply before the
accumulation.
Vector Fused Multiply Subtract negates the elements of one vector and multiplies them with the corresponding
elements of another vector, adds the products to the corresponding elements of the destination vector, and places the
results in the destination vector. The instruction does not round the result of the multiply before the addition.
Encoding T1/A1 Advanced SIMDv2 (UNDEFINED in integer-only variant)

VFM<y><c>.F32 <Qd>, <Qn>, <Qm>
VFM<y><c>.F32 <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 1 0 D op sz Vn Vd 1 1 0 0 N Q M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 0 0 D op sz Vn Vd 1 1 0 0 N Q M 1 Vm
advsimd = TRUE; op1_neg = (op == ‘1’); esize = 32; elements = 2;
regs = if Q == ‘0’ then 1 else 2;
Encoding T2/A2 VFPv4 (sz = 1 UNDEFINED in single-precision only variants)

VFM<y><c>.F64 <Dd>, <Dn>, <Dm>
VFM<y><c>.F32 <Sd>, <Sn>, <Sm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 0 1 D 1 0 Vn Vd 1 0 1 sz N op M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 1 0 1 D 1 0 Vn Vd 1 0 1 sz N op M 0 Vm
if FPSCR.Len != ‘000’ || FPSCR.Stride != ‘00’ then UNPREDICTABLE;

advsimd = FALSE; dp_operation = (sz == ‘1’); op1_neg = (op == ‘1’);
Assembler syntax
VFM<y><c><q>.F32 <Qd>, <Qn>, <Qm> Encoding T1/A1, encoded as Q = 1, sz = 0
VFM<y><c><q>.F32 <Dd>, <Dn>, <Dm> Encoding T1/A1, encoded as Q = 0, sz = 0
VFM<y><c><q>.F64 <Dd>, <Dn>, <Dm> Encoding T2/A2, encoded as sz = 1
VFM<y><c><q>.F32 <Sd>, <Sn>, <Sm> Encoding T2/A2, encoded as sz = 0
where:
<y> One of:

A Specifies VFMA, encoded as op = 0.
S Specifies VFMS, encoded as op = 1.
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM Advanced SIMD VFMA or
VMFS instruction must be unconditional. ARM strongly recommends that a Thumb Advanced
SIMD VFMA or VMFS instruction is unconditional, see Conditional execution on page A8-286.
Operation
for r = 0 to regs-1
op1 = Elem[D[n+r],e,esize];
if op1_neg then op1 = FPNeg(op1);
Elem[D[d+r],e,esize] = FPMulAdd(Elem[D[d+r],e,esize],
op1, Elem[D[m+r],e,esize], FALSE);

op64 = if op1_neg then FPNeg(D[n]) else D[n];
D[d] = FPMulAdd(D[d], op64, D[m], TRUE);
else
op32 = if op1_neg then FPNeg(S[n]) else S[n];
S[d] = FPMulAdd(S[d], op32, S[m], TRUE);
Exceptions
The operation (QNaN + (0 × infinity)) causes an Invalid Operation floating-point exception.
A8.8.319 VFNMA, VFNMS

Vector Fused Negate Multiply Accumulate negates one floating-point register value and multiplies it by another
floating-point register value, adds the negation of the floating-point value in the destination register to the product,
and writes the result back to the destination register. The instruction does not round the result of the multiply before
the addition.
Vector Fused Negate Multiply Subtract multiplies together two floating-point register values, adds the negation of
the floating-point value in the destination register to the product, and writes the result back to the destination
register. The instruction does not round the result of the multiply before the addition.
Encoding T1/A1 VFPv4 (sz = 1 UNDEFINED in single-precision only variants)

VFNM<y><c>.F64 <Dd>, <Dn>, <Dm>
VFNM<y><c>.F32 <Sd>, <Sn>, <Sm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 0 1 D 0 1 Vn Vd 1 0 1 sz N op M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if FPSCR.Len != ‘000’ || FPSCR.Stride != ‘00’ then UNPREDICTABLE;

op1_neg = (op == ‘1’);
Assembler syntax
VFNM<y><c><q>.F64 <Dd>, <Dn>, <Dm> Encoding T1/A1, encoded as sz = 1
VFNM<y><c><q>.F32 <Sd>, <Sn>, <Sm> Encoding T1/A1, encoded as sz = 0
where:
<y> One of:

A Specifies VFNMA, encoded as op = 1.
S Specifies VFNMS, encoded as op = 0.
Operation
op64 = if op1_neg then FPNeg(D[n]) else D[n];
D[d] = FPMulAdd(FPNeg(D[d]), op64, D[m], TRUE);
else
op32 = if op1_neg then FPNeg(S[n]) else S[n];
S[d] = FPMulAdd(FPNeg(S[d]), op32, S[m], TRUE);
Exceptions
The operation (QNaN + (0 × infinity)) causes an Invalid Operation floating-point exception.
A8.8.320 VHADD, VHSUB

Vector Halving Add adds corresponding elements in two vectors of integers, shifts each result right one bit, and
places the final results in the destination vector. The results of the halving operations are truncated (for rounded
results see VRHADD on page A8-1031).
Vector Halving Subtract subtracts the elements of the second operand from the corresponding elements of the first
operand, shifts each result right one bit, and places the final results in the destination vector. The results of the
halving operations are truncated (there is no rounding version).
The operand and result elements are all the same type, and can be any one of:

VH<op><c> <Qd>, <Qn>, <Qm>
VH<op><c> <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 U 1 1 1 1 0 D size Vn Vd 0 0 op 0 N Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 U 0 D size Vn Vd 0 0 op 0 N Q M 0 Vm
add = (op == ‘0’); unsigned = (U == ‘1’);
Assembler syntax
VH<op>{<c>}{<q>}.<dt> {<Qd>,} <Qn>, <Qm> Encoded as Q = 1
VH<op>{<c>}{<q>}.<dt> {<Dd>,} <Dn>, <Dm> Encoded as Q = 0
where:
<op> The operation, It must be one of:

ADD encoded as op = 0.
SUB encoded as op = 1.
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VHADD or VHSUB instruction
must be unconditional. ARM strongly recommends that a Thumb VHADD or VHSUB instruction
Operation
for r = 0 to regs-1
op1 = Int(Elem[D[n+r],e,esize], unsigned);
op2 = Int(Elem[D[m+r],e,esize], unsigned);
result = if add then op1+op2 else op1-op2;
Elem[D[d+r],e,esize] = result<esize:1>;
Exceptions
A8.8.321 VLD1 (multiple single elements)

This instruction loads elements from memory into one, two, three, or four registers, without de-interleaving. Every
element of each register is loaded. For details of the addressing mode see Advanced SIMD addressing mode on
page A7-275.

VLD1<c>.<size> <list>, [<Rn>{:<align>}]{!}
VLD1<c>.<size> <list>, [<Rn>{:<align>}], <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 1 0 D 1 0 Rn Vd type size align Rm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
case type of
when ‘0111’
regs = 1; if align<1> == ‘1’ then UNDEFINED;
when ‘1010’
regs = 2; if align == ‘11’ then UNDEFINED;
when ‘0110’
when ‘0010’
regs = 4;
otherwise
SEE “Related encodings”;
alignment = if align == ‘00’ then 1 else 4 << UInt(align);
ebytes = 1 << UInt(size); esize = 8 * ebytes; elements = 8 DIV ebytes;
d = UInt(D:Vd); n = UInt(Rn); m = UInt(Rm);
wback = (m != 15); register_index = (m != 15 && m != 13);
if n == 15 || d+regs > 32 then UNPREDICTABLE;
Related encodings See Advanced SIMD element or structure load/store instructions on page A7-273.
Assembler syntax
VLD1{<c>}{<q>}.<size> <list>, [<Rn>{:<align>}] Encoded as Rm = 0b1111
VLD1{<c>}{<q>}.<size> <list>, [<Rn>{:<align>}]! Encoded as Rm = 0b1101
VLD1{<c>}{<q>}.<size> <list>, [<Rn>{:<align>}], <Rm> Rm cannot be 0b11x1
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VLD1 instruction must be
unconditional. ARM strongly recommends that a Thumb VLD1 instruction is unconditional, see

8 encoded as size = 0b00.
<list> The list of registers to load. It must be one of:

{<Dd>} encoded as D:Vd = <Dd>, type = 0b0111.
{<Dd>, <Dd+1>} encoded as D:Vd = <Dd>, type = 0b1010.
{<Dd>, <Dd+1>, <Dd+2>} encoded as D:Vd = <Dd>, type = 0b0110.
{<Dd>, <Dd+1>, <Dd+2>, <Dd+3>}
encoded as D:Vd = <Dd>, type = 0b0010.
<Rn> Contains the base address for the access.
<align> The alignment. It can be one of:

64 8-byte alignment, encoded as align = 0b01.
128 16-byte alignment, available only if <list> contains two or four registers, encoded as
align = 0b10.
256 32-byte alignment, available only if <list> contains four registers, encoded as
align = 0b11.
omitted Standard alignment, see Unaligned data access on page A3-106. Encoded as
align = 0b00.
: is the preferred separator before the <align> value, but the alignment can be specified as @<align>,
see Advanced SIMD addressing mode on page A7-275.
! If present, specifies writeback.
<Rm> Contains an address offset applied after the access.
For more information about <Rn>, !, and <Rm>, see Advanced SIMD addressing mode on page A7-275.
Operation
EncodingSpecificOperations(); CheckAdvSIMDEnabled(); NullCheckIfThumbEE(n);
address = R[n]; if (address MOD alignment) != 0 then AlignmentFault(address, FALSE);
for r = 0 to regs-1
if ebytes != 8 then
data<esize-1:0> = MemU[address,ebytes];
else
if SCTLR.A == ‘1’ && address != Align(address, 8) then AlignmentFault(address, FALSE);
data<31:0> = if BigEndian() then MemU[address+4,4] else MemU[address,4];
data<63:32> = if BigEndian() then MemU[address,4] else MemU[address+4,4];
Elem[D[d+r],e, esize] = data<esize-1:0>;
address = address + ebytes;
if wback then R[n] = R[n] + (if register_index then R[m] else 8*regs);
Exceptions
Undefined Instruction, Hyp Trap, Data Abort.
A8.8.322 VLD1 (single element to one lane)

This instruction loads one element from memory into one element of a register. Elements of the register that are not
loaded are unchanged. For details of the addressing mode see Advanced SIMD addressing mode on page A7-275.

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 1 1 D 1 0 Rn Vd size 0 0 index_align Rm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if size == ‘11’ then SEE VLD1 (single element to all lanes);

case size of
when ‘00’
if index_align<0> != ‘0’ then UNDEFINED;
ebytes = 1; esize = 8; index = UInt(index_align<3:1>); alignment = 1;
when ‘01’
ebytes = 2; esize = 16; index = UInt(index_align<3:2>);
alignment = if index_align<0> == ‘0’ then 1 else 2;
when ‘10’
if index_align<1:0> != ‘00’ && index_align<1:0> != ‘11’ then UNDEFINED;
ebytes = 4; esize = 32; index = UInt(index_align<3>);
alignment = if index_align<1:0> == ‘00’ then 1 else 4;
Assembler syntax
where:

<list> The register containing the element to load. It must be {<Dd[x]>}. The register <Dd> is encoded in
D:Vd.

16 2-byte alignment, available only if <size> is 16
omitted Standard alignment, see Unaligned data access on page A3-106.
Table A8-4 shows the encoding of index and alignment for the different <size> values.
Table A8-4 Encoding of index and alignment
<size> == 8 <size> == 16 <size> == 32
Index index_align[3:1] = x index_align[3:2] = x index_align[3] = x
<align> omitted index_align[0] = 0 index_align[1:0] = '00' index_align[2:0] = '000'
<align> == 16 - index_align[1:0] = '01' -
<align> == 32 - - index_align[2:0] = '011'
Operation
Elem[D[d], index, esize] = MemU[address, ebytes];
if wback then R[n] = R[n] + (if register_index then R[m] else ebytes);
Exceptions
A8.8.323 VLD1 (single element to all lanes)

This instruction loads one element from memory into every element of one or two vectors. For details of the
addressing mode see Advanced SIMD addressing mode on page A7-275.

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 1 1 D 1 0 Rn Vd 1 1 0 0 size T a Rm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 1 0 0 1 D 1 0 Rn Vd 1 1 0 0 size T a Rm
if size == ‘11’ || (size == ‘00’ && a == ‘1’) then UNDEFINED;

ebytes = 1 << UInt(size); elements = 8 DIV ebytes; regs = if T == ‘0’ then 1 else 2;
alignment = if a == ‘0’ then 1 else ebytes;
Assembler syntax
where:


{<Dd[]>} encoded as D:Vd = <Dd>, T = 0.
{<Dd[]>, <Dd+1[]>} encoded as D:Vd = <Dd>, T = 1.

16 2-byte alignment, available only if <size> is 16, encoded as a = 1.
omitted Standard alignment, see Unaligned data access on page A3-106. Encoded as a = 0.
Operation
replicated_element = Replicate(MemU[address,ebytes], elements);
for r = 0 to regs-1
D[d+r] = replicated_element;
Exceptions
A8.8.324 VLD2 (multiple 2-element structures)

This instruction loads multiple 2-element structures from memory into two or four registers, with de-interleaving.
For more information, see Element and structure load/store instructions on page A4-179. Every element of each
register is loaded. For details of the addressing mode see Advanced SIMD addressing mode on page A7-275.

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

case type of
when ‘1000’
regs = 1; inc = 1; if align == ‘11’ then UNDEFINED;
when ‘1001’
when ‘0011’
regs = 2; inc = 2;
otherwise
d = UInt(D:Vd); d2 = d + inc; n = UInt(Rn); m = UInt(Rm);
if n == 15 || d2+regs > 32 then UNPREDICTABLE;
Assembler syntax
where:


{<Dd>, <Dd+1>} Single-spaced registers, encoded as D:Vd = <Dd>, type = 0b1000.
{<Dd>, <Dd+2>} Double-spaced registers, encoded as D:Vd = <Dd>, type = 0b1001.
{<Dd>, <Dd+1>, <Dd+2>, <Dd+3>}
Single-spaced registers, encoded as D:Vd = <Dd>, type = 0b0011.

256 32-byte alignment, available only if <list> contains four registers. Encoded as align
= 0b11.
align = 0b00.
Operation
for r = 0 to regs-1
Elem[D[d+r], e, esize] = MemU[address, ebytes];
Elem[D[d2+r], e, esize] = MemU[address+ebytes, ebytes];
address = address + 2*ebytes;
Exceptions
A8.8.325 VLD2 (single 2-element structure to one lane)

This instruction loads one 2-element structure from memory into corresponding elements of two registers. Elements
of the registers that are not loaded are unchanged. For details of the addressing mode see Advanced SIMD
addressing mode on page A7-275.

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if size == ‘11’ then SEE VLD2 (single 2-element structure to all lanes);
case size of
when ‘00’
ebytes = 1; esize = 8; index = UInt(index_align<3:1>); inc = 1;
when ‘01’
inc = if index_align<1> == ‘0’ then 1 else 2;
when ‘10’
if n == 15 || d2 > 31 then UNPREDICTABLE;
Assembler syntax
where:

<list> The registers containing the structure. Encoded with D:Vd = <Dd>. It must be one of:
{<Dd[x]>, <Dd+1[x]>} Single-spaced registers, see Table A8-5 on page A8-908.
{<Dd[x]>, <Dd+2[x]>} Double-spaced registers, see Table A8-5 on page A8-908.
This is not available if <size> == 8.

For more information about <Rn>, !, and <Rm> see Advanced SIMD addressing mode on page A7-275.
Table A8-5 Encoding of index, alignment, and register spacing
<size> == 8 <size> == 16 <size> == 32
Single-spacing - index_align[1] = 0 index_align[2] = 0
Double-spacing - index_align[1] = 1 index_align[2] = 1
<align> omitted index_align[0] = 0 index_align[0] = 0 index_align[1:0] = '00'
<align> == 16 index_align[0] = 1 - -
<align> == 32 - index_align[0] = 1 -
Operation
Elem[D[d2], index, esize] = MemU[address+ebytes, ebytes];
if wback then R[n] = R[n] + (if register_index then R[m] else 2*ebytes);
Exceptions
A8.8.326 VLD2 (single 2-element structure to all lanes)

This instruction loads one 2-element structure from memory into all lanes of two registers. For details of the

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 1 1 D 1 0 Rn Vd 1 1 0 1 size T a Rm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 1 0 0 1 D 1 0 Rn Vd 1 1 0 1 size T a Rm

ebytes = 1 << UInt(size); elements = 8 DIV ebytes;
alignment = if a == ‘0’ then 1 else 2*ebytes;
inc = if T == ‘0’ then 1 else 2;
Assembler syntax
where:

<list> The registers containing the structure. It must be one of:

{<Dd[]>, <Dd+1[]>} Single-spaced registers, encoded as D:Vd = <Dd>, T = 0.
{<Dd[]>, <Dd+2[]>} Double-spaced registers, encoded as D:Vd = <Dd>, T = 1.

Operation
D[d] = Replicate(MemU[address, ebytes], elements);
D[d2] = Replicate(MemU[address+ebytes, ebytes], elements);
Exceptions

This instruction loads multiple 3-element structures from memory into three registers, with de-interleaving. For
more information, see Element and structure load/store instructions on page A4-179. Every element of each register
is loaded. For details of the addressing mode see Advanced SIMD addressing mode on page A7-275.

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if size == ‘11’ || align<1> == ‘1’ then UNDEFINED;

case type of
when ‘0100’
inc = 1;
when ‘0101’
inc = 2;
otherwise
alignment = if align<0> == ‘0’ then 1 else 8;
d = UInt(D:Vd); d2 = d + inc; d3 = d2 + inc; n = UInt(Rn); m = UInt(Rm);
Assembler syntax
where:


{<Dd>, <Dd+1>, <Dd+2>}
{<Dd>, <Dd+2>, <Dd+4>}
Double-spaced registers, encoded as D:Vd = <Dd>, type = 0b0101.
<align> The alignment. It can be:

align = 0b00.
Operation
Elem[D[d], e, esize] = MemU[address, ebytes];
Elem[D[d2], e, esize] = MemU[address+ebytes, ebytes];
Elem[D[d3], e, esize] = MemU[address+2*ebytes, ebytes];
if wback then R[n] = R[n] + (if register_index then R[m] else 24);
Exceptions

This instruction loads one 3-element structure from memory into corresponding elements of three registers.
Elements of the registers that are not loaded are unchanged. For details of the addressing mode see Advanced SIMD

VLD3<c>.<size> <list>, [<Rn>]{!}
VLD3<c>.<size> <list>, [<Rn>], <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
case size of
when ‘00’
when ‘01’
when ‘10’
if index_align<1:0> != ‘00’ then UNDEFINED;
Assembler syntax
VLD3{<c>}{<q>}.<size> <list>, [<Rn>] Encoded as Rm = 0b1111
VLD3{<c>}{<q>}.<size> <list>, [<Rn>]! Encoded as Rm = 0b1101
VLD3{<c>}{<q>}.<size> <list>, [<Rn>], <Rm> Rm cannot be 0b11x1
where:

{<Dd[x]>, <Dd+1[x]>, <Dd+2[x]>}
Single-spaced registers, see Table A8-6.
{<Dd[x]>, <Dd+2[x]>, <Dd+4[x]>}
Double-spaced registers, see Table A8-6.
This is not available if <size> == 8.
Table A8-6 Encoding of index and register spacing
<size> == 8 <size> == 16 <size> == 32
Single-spacing index_align[0] = 0 index_align[1:0] = '00' index_align[2:0] = '000'
Double-spacing - index_align[1:0] = '10' index_align[2:0] = '100'
Alignment
Standard alignment rules apply, see Unaligned data access on page A3-106.
Operation
address = R[n];
Elem[D[d3], index, esize] = MemU[address+2*ebytes, ebytes];
Exceptions

This instruction loads one 3-element structure from memory into all lanes of three registers. For details of the

VLD3<c>.<size> <list>, [<Rn>]{!}
VLD3<c>.<size> <list>, [<Rn>], <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 1 1 D 1 0 Rn Vd 1 1 1 0 size T a Rm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 1 0 0 1 D 1 0 Rn Vd 1 1 1 0 size T a Rm
if size == ‘11’ || a == ‘1’ then UNDEFINED;

Assembler syntax
VLD3{<c>}{<q>}.<size> <list>, [<Rn>] Encoded as Rm = 0b1111
VLD3{<c>}{<q>}.<size> <list>, [<Rn>]! Encoded as Rm = 0b1101
VLD3{<c>}{<q>}.<size> <list>, [<Rn>], <Rm> Rm cannot be 0b11x1
where:

<list> The registers containing the structures. It must be one of:

{<Dd[]>, <Dd+1[]>, <Dd+2[]>}
Single-spaced registers, encoded as D:Vd = <Dd>, T = 0.
{<Dd[]>, <Dd+2[]>, <Dd+4[]>}
Double-spaced registers, encoded as D:Vd = <Dd>, T = 1.
Alignment
The a bit must be encoded as 0.
Operation
address = R[n];
D[d] = Replicate(MemU[address, ebytes], elelments);
D[d3] = Replicate(MemU[address+2*ebytes, ebytes], elements);
Exceptions

This instruction loads multiple 4-element structures from memory into four registers, with de-interleaving. For more
information, see Element and structure load/store instructions on page A4-179. Every element of each register is
loaded. For details of the addressing mode see Advanced SIMD addressing mode on page A7-275.

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

case type of
when ‘0000’
inc = 1;
when ‘0001’
inc = 2;
otherwise
d = UInt(D:Vd); d2 = d + inc; d3 = d2 + inc; d4 = d3 + inc; n = UInt(Rn); m = UInt(Rm);
Assembler syntax
where:


{<Dd>, <Dd+1>, <Dd+2>, <Dd+3>}
{<Dd>, <Dd+2>, <Dd+4>, <Dd+6>}
Double-spaced registers, encoded as D:Vd = <Dd>, type = 0b0001.

align = 0b00.
Operation
Elem[D[d], e, esize] = MemU[address, ebytes];
Elem[D[d2], e, esize] = MemU[address+ebytes, ebytes];
Exceptions

This instruction loads one 4-element structure from memory into corresponding elements of four registers. Elements
of the registers that are not loaded are unchanged. For details of the addressing mode see Advanced SIMD

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
case size of
when ‘00’
when ‘01’
when ‘10’
if index_align<1:0> == ‘11’ then UNDEFINED;
alignment = if index_align<1:0> == ‘00’ then 1 else 4 << UInt(index_align<1:0>);
Assembler syntax
where:
{<Dd[x]>, <Dd+1[x]>, <Dd+2[x]>, <Dd+3[x]>}
Single-spaced registers, see Table A8-7 on page A8-920.
{<Dd[x]>, <Dd+2[x]>, <Dd+4[x]>, <Dd+6[x]>}
Double-spaced registers, see Table A8-7 on page A8-920.
Not available if <size> == 8.

<Rn> The base address for the access.
32 4-byte alignment, available only if <size> is 8.
64 8-byte alignment, available only if <size> is 16 or 32.
For more information about <Rn>, !, and <Rm> see Advanced SIMD addressing mode on page A7-275.
<size> == 8 <size> == 16 <size> == 32
<align> == 64 - index_align[0] = 1 index_align[1:0] = '01'
Operation
Exceptions

This instruction loads one 4-element structure from memory into all lanes of four registers. For details of the

VLD4<c>.<size> <list>, [<Rn>{ :<align>}]{!}
VLD4<c>.<size> <list>, [<Rn>{ :<align>}], <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 0 0 1 1 D 1 0 Rn Vd 1 1 1 1 size T a Rm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 1 0 0 1 D 1 0 Rn Vd 1 1 1 1 size T a Rm
if size == ‘11’ && a == ‘0’ then UNDEFINED;

if size == ‘11’ then
ebytes = 4; elements = 2; alignment = 16;
else
if size == ‘10’ then
alignment = if a == ‘0’ then 1 else 8;
else
alignment = if a == ‘0’ then 1 else 4*ebytes;
Assembler syntax
VLD4{<c>}{<q>}.<size> <list>, [<Rn>{ :<align>}] Encoded as Rm = 0b1111
VLD4{<c>}{<q>}.<size> <list>, [<Rn>{ :<align>}]! Encoded as Rm = 0b1101
VLD4{<c>}{<q>}.<size> <list>, [<Rn>{ :<align>}], <Rm> Rm cannot be 0b11x1
where:

32 encoded as size = 0b10, or 0b11 for 16-byte alignment.
<list> The registers containing the structures. It must be one of:

{<Dd[]>, <Dd+1[]>, <Dd+2[]>, <Dd+3[]>}
Single-spaced registers, encoded as D:Vd = <Dd>, T = 0
{<Dd[]>, <Dd+2[]>, <Dd+4[]>, <Dd+6[]>}
Double-spaced registers, encoded as D:Vd = <Dd>, T = 1.

64 8-byte alignment, available only if <size> is 16 or 32, encoded as a = 1.
128 16-byte alignment, available only if <size> is 32, encoded as a = 1, size = 0b11.
Operation
D[d] = Replicate(MemU[address, ebytes], elements);
Exceptions
A8.8.333 VLDM
Vector Load Multiple loads multiple extension registers from consecutive memory locations using an address from
an ARM core register.
Encoding T1/A1 VFPv2, VFPv3, VFPv4, Advanced SIMD

VLDM{mode}<c> <Rn>{!}, <list> <list> is consecutive 64-bit registers
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 0 P U D W 1 Rn Vd 1 0 1 1 imm8
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 0 P U D W 1 Rn Vd 1 0 1 1 imm8
if P == ‘0’ && U == ‘0’ && W == ‘0’ then SEE “Related encodings”;

if P == ‘0’ && U == ‘1’ && W == ‘1’ && Rn == ‘1101’ then SEE VPOP;
if P == ‘1’ && W == ‘0’ then SEE VLDR;
if P == U && W == ‘1’ then UNDEFINED;
// Remaining combinations are PUW = 010 (IA without !), 011 (IA with !), 101 (DB with !)
single_regs = FALSE; add = (U == ‘1’); wback = (W == ‘1’);
d = UInt(D:Vd); n = UInt(Rn); imm32 = ZeroExtend(imm8:’00’, 32);
regs = UInt(imm8) DIV 2; // If UInt(imm8) is odd, see “FLDMX”.
if regs == 0 || regs > 16 || (d+regs) > 32 then UNPREDICTABLE;
if VFPSmallRegisterBank() && (d+regs) > 16 then UNPREDICTABLE;
Encoding T2/A2 VFPv2, VFPv3, VFPv4

VLDM{mode}<c> <Rn>{!}, <list> <list> is consecutive 32-bit registers
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 0 P U D W 1 Rn Vd 1 0 1 0 imm8
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

if P == ‘0’ && U == ‘1’ && W == ‘1’ && Rn == ‘1101’ then SEE VPOP;
if P == ‘1’ && W == ‘0’ then SEE VLDR;
single_regs = TRUE; add = (U == ‘1’); wback = (W == ‘1’); d = UInt(Vd:D); n = UInt(Rn);
imm32 = ZeroExtend(imm8:’00’, 32); regs = UInt(imm8);
if regs == 0 || (d+regs) > 32 then UNPREDICTABLE;
Related encodings See 64-bit transfers between ARM core and extension registers on page A7-277.
FLDMX Encoding T1/A1 behaves as described by the pseudocode if imm8 is odd. However,
there is no UAL syntax for such encodings and ARM deprecates their use. For more
information, see FLDMX, FSTMX on page A8-389.
Assembler syntax
VLDM{<mode>}{<c>}{<q>}{.<size>} <Rn>{!}, <list>
where:
<mode> The addressing mode:

IA Increment After. The consecutive addresses start at the address specified in <Rn>. This
is the default and can be omitted. Encoded as P = 0, U = 1.
DB Decrement Before. The consecutive addresses end just before the address specified in
<Rn>. Encoded as P = 1, U = 0.
<size> An optional data size specifier. If present, it must be equal to the size in bits, 32 or 64, of the registers
in <list>.
<Rn> The base register. The SP can be used. In the ARM instruction set, if ! is not specified the PC can
be used, but ARM deprecates this use of the PC.
! Causes the instruction to write a modified value back to <Rn>. This is required if <mode> == DB, and
is optional if <mode> == IA. Encoded as W = 1.
<list> The extension registers to be loaded, as a list of consecutively numbered doubleword (encoding
T1/A1) or singleword (encoding T2/A2) registers, separated by commas and surrounded by
brackets. It is encoded in the instruction by setting D and Vd to specify the first register in the list,
and imm8 to twice the number of registers in the list (encoding T1/A1) or the number of registers
in the list (encoding T2/A2). <list> must contain at least one register. If it contains doubleword
registers it must not contain more than 16 registers.
Operation
EncodingSpecificOperations(); CheckVFPEnabled(TRUE); NullCheckIfThumbEE(n);
address = if add then R[n] else R[n]-imm32;
for r = 0 to regs-1
if single_regs then
S[d+r] = MemA[address,4]; address = address+4;
else
word1 = MemA[address,4]; word2 = MemA[address+4,4]; address = address+8;
// Combine the word-aligned words in the correct order for current endianness.
D[d+r] = if BigEndian() then word1:word2 else word2:word1;
if wback then R[n] = if add then R[n]+imm32 else R[n]-imm32;
Exceptions
A8.8.334 VLDR
This instruction loads a single extension register from memory, using an address from an ARM core register, with
an optional offset.

VLDR<c> <Dd>, [<Rn>{, #+/-<imm>}]
VLDR<c> <Dd>, <label>
VLDR<c> <Dd>, [PC, #-0] Special case
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 0 1 U D 0 1 Rn Vd 1 0 1 1 imm8
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 0 1 U D 0 1 Rn Vd 1 0 1 1 imm8
single_reg = FALSE; add = (U == ‘1’); imm32 = ZeroExtend(imm8:’00’, 32);

d = UInt(D:Vd); n = UInt(Rn);

VLDR<c> <Sd>, [<Rn>{, #+/-<imm>}]
VLDR<c> <Sd>, <label>
VLDR<c> <Sd>, [PC, #-0] Special case
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 0 1 U D 0 1 Rn Vd 1 0 1 0 imm8
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 0 1 U D 0 1 Rn Vd 1 0 1 0 imm8
single_reg = TRUE; add = (U == ‘1’); imm32 = ZeroExtend(imm8:’00’, 32);

d = UInt(Vd:D); n = UInt(Rn);
Assembler syntax
VLDR{<c>}{<q>}{.64} <Dd>, [<Rn> {, #+/-<imm>}] Encoding T1/A1, immediate form
VLDR{<c>}{<q>}{.64} <Dd>, <label> Encoding T1/A1, normal literal form
VLDR{<c>}{<q>}{.64} <Dd>, [PC, #+/-<imm>] Encoding T1/A1, alternative literal form
VLDR{<c>}{<q>}{.32} <Sd>, [<Rn> {, #+/-<imm>}] Encoding T2/A2, immediate form
VLDR{<c>}{<q>}{.32} <Sd>, <label> Encoding T2/A2, normal literal form
VLDR{<c>}{<q>}{.32} <Sd>, [PC, #+/-<imm>] Encoding T2/A2, alternative literal form
where:
.32, .64 Optional data size specifiers.
<Dd> The destination register for a doubleword load.
<Sd> The destination register for a singleword load.
<imm> The immediate offset used for forming the address. For the immediate forms of the syntax, <imm>
can be omitted, in which case the #0 form of the instruction is assembled. Permitted values are
multiples of 4 in the range 0 to 1020.
<label> The label of the literal data item to be loaded. The assembler calculates the required value of the
offset from the Align(PC, 4) value of the instruction to this label. Permitted values are multiples of
4 in the range -1020 to 1020.
For the literal forms of the instruction, the base register is encoded as 0b1111 to indicate that the PC is the base
register.
Operation
base = if n == 15 then Align(PC,4) else R[n];
if single_reg then
S[d] = MemA[address,4];
else
word1 = MemA[address,4]; word2 = MemA[address+4,4];
D[d] = if BigEndian() then word1:word2 else word2:word1;
Exceptions
A8.8.335 VMAX, VMIN (integer)

Vector Maximum compares corresponding elements in two vectors, and copies the larger of each pair into the
corresponding element in the destination vector.
Vector Minimum compares corresponding elements in two vectors, and copies the smaller of each pair into the

The result vector elements are the same size as the operand vector elements.

V<op><c>.<dt> <Qd>, <Qn>, <Qm>
V<op><c>.<dt> <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 U 1 1 1 1 0 D size Vn Vd 0 1 1 0 N Q M op Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 U 0 D size Vn Vd 0 1 1 0 N Q M op Vm
maximum = (op == ‘0’); unsigned = (U == ‘1’);
Assembler syntax
V<op>{<c>}{<q>}.<dt> {<Qd>,} <Qn>, <Qm> Encoded as Q = 1
V<op>{<c>}{<q>}.<dt> {<Dd>,} <Dn>, <Dm> Encoded as Q = 0
where:

MAX encoded as op = 0.
MIN encoded as op = 1.
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VMAX or VMIN instruction
must be unconditional. ARM strongly recommends that a Thumb VMAX or VMIN instruction is
unconditional, see Conditional execution on page A8-286.
<dt> The data types for the elements of the vectors. It must be one of:
Operation
for r = 0 to regs-1
result = if maximum then Max(op1,op2) else Min(op1,op2);
Exceptions
A8.8.336 VMAX, VMIN (floating-point)

Vector Maximum compares corresponding elements in two vectors, and copies the larger of each pair into the
Vector Minimum compares corresponding elements in two vectors, and copies the smaller of each pair into the
The operand vector elements are 32-bit floating-point numbers.

V<op><c>.F32 <Qd>, <Qn>, <Qm>
V<op><c>.F32 <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 1 0 D op sz Vn Vd 1 1 1 1 N Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 0 0 D op sz Vn Vd 1 1 1 1 N Q M 0 Vm
maximum = (op == ‘0’); esize = 32; elements = 2;
Assembler syntax
V<op>{<c>}{<q>}.F32 {<Qd>,} <Qn>, <Qm> Encoded as Q = 1
V<op>{<c>}{<q>}.F32 {<Dd>,} <Dn>, <Dm> Encoded as Q = 0
where:

MAX Encoded as op = 0.
MIN Encoded as op = 1.
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VMAX or VMIN instruction
must be unconditional. ARM strongly recommends that a Thumb VMAX or VMIN instruction is
Operation
for r = 0 to regs-1
Elem[D[d+r],e,esize] = if maximum then FPMax(op1,op2,FALSE) else FPMin(op1,op2,FALSE);
Exceptions
Floating-point maximum and minimum

• max(+0.0, –0.0) = +0.0
• min(+0.0, –0.0) = –0.0
• If any input is a NaN, the corresponding result element is the default NaN.
A8.8.337 VMLA, VMLAL, VMLS, VMLSL (integer)

Vector Multiply Accumulate and Vector Multiply Subtract multiply corresponding elements in two vectors, and
either add the products to, or subtract them from, the corresponding elements of the destination vector. Vector
Multiply Accumulate Long and Vector Multiply Subtract Long do the same thing, but with destination vector
elements that are twice as long as the elements that are multiplied.

V<op><c>.<dt> <Qd>, <Qn>, <Qm>
V<op><c>.<dt> <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 op 1 1 1 1 0 D size Vn Vd 1 0 0 1 N Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 op 0 D size Vn Vd 1 0 0 1 N Q M 0 Vm

add = (op == ‘0’); long_destination = FALSE;
unsigned = FALSE; // “Don’t care” value: TRUE produces same functionality

V<op>L<c>.<dt> <Qd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 U 1 1 1 1 1 D size Vn Vd 1 0 op 0 N 0 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 U 1 D size Vn Vd 1 0 op 0 N 0 M 0 Vm

add = (op == ‘0’); long_destination = TRUE; unsigned = (U == ‘1’);
Assembler syntax
V<op>{<c>}{<q>}.<type><size> <Qd>, <Qn>, <Qm> Encoding T1/A1, encoded as Q = 1
V<op>{<c>}{<q>}.<type><size> <Dd>, <Dn>, <Dm> Encoding T1/A1, encoded as Q = 0
V<op>L{<c>}{<q>}.<type><size> <Qd>, <Dn>, <Dm> Encoding T2/A2
where:

MLA Vector Multiply Accumulate. Encoded as op = 0.
MLS Vector Multiply Subtract. Encoded as op = 1.
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM Advanced SIMD VMLA,
VMLAL, VMLS, or VMLSL instruction must be unconditional. ARM strongly recommends that a
Thumb Advanced SIMD VMLA, VMLAL, VMLS, or VMLSL instruction is unconditional, see
<type> The data type for the elements of the operands. It must be one of:
S Optional in encoding T1/A1. Encoded as U = 0 in encoding T2/A2.
U Optional in encoding T1/A1. Encoded as U = 1 in encoding T2/A2.
I Available only in encoding T1/A1.
<size> The data size for the elements of the operands. It must be one of:
8 Encoded as size = 0b00.
Operation
for r = 0 to regs-1
product = Int(Elem[Din[n+r],e,esize],unsigned) * Int(Elem[Din[m+r],e,esize],unsigned);
addend = if add then product else -product;
Elem[Q[d>>1],e,2*esize] = Elem[Qin[d>>1],e,2*esize] + addend;
else
Elem[D[d+r],e,esize] = Elem[Din[d+r],e,esize] + addend;
Exceptions
A8.8.338 VMLA, VMLS (floating-point)

Vector Multiply Accumulate multiplies corresponding elements in two vectors, and accumulates the results into the
elements of the destination vector.
Vector Multiply Subtract multiplies corresponding elements in two vectors, subtracts the products from
corresponding elements of the destination vector, and places the results in the destination vector.
Note
ARM recommends that software does not use the VMLS instruction in the Round towards Plus Infinity and Round
towards Minus Infinity rounding modes, because the rounding of the product and of the sum can change the result
of the instruction in opposite directions, defeating the purpose of these rounding modes.

V<op><c>.F32 <Qd>, <Qn>, <Qm>
V<op><c>.F32 <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 1 0 D op sz Vn Vd 1 1 0 1 N Q M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 0 0 D op sz Vn Vd 1 1 0 1 N Q M 1 Vm
advsimd = TRUE; add = (op == ‘0’); esize = 32; elements = 2;
V<op><c>.F64 <Dd>, <Dn>, <Dm>
V<op><c>.F32 <Sd>, <Sn>, <Sm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 0 0 D 0 0 Vn Vd 1 0 1 sz N op M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

advsimd = FALSE; dp_operation = (sz == ‘1’); add = (op == ‘0’);
VFP vectors Encoding T2/A2 can operate on VFP vectors under control of the FPSCR.{Len, Stride} fields.
Assembler syntax
V<op>{<c>}{<q>}.F32 <Qd>, <Qn>, <Qm> Encoding T1/A1, encoded as Q = 1, sz = 0
V<op>{<c>}{<q>}.F32 <Dd>, <Dn>, <Dm> Encoding T1/A1, encoded as Q = 0, sz = 0
V<op>{<c>}{<q>}.F64 <Dd>, <Dn>, <Dm> Encoding T2/A2, encoded as sz = 1
V<op>{<c>}{<q>}.F32 <Sd>, <Sn>, <Sm> Encoding T2/A2, encoded as sz = 0
where:

<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM Advanced SIMD VMLA or
VMLS instruction must be unconditional. ARM strongly recommends that a Thumb Advanced
SIMD VMLA or VMLS instruction is unconditional, see Conditional execution on page A8-286.
Operation
for r = 0 to regs-1
product = FPMul(Elem[D[n+r],e,esize], Elem[D[m+r],e,esize], FALSE);
addend = if add then product else FPNeg(product);
Elem[D[d+r],e,esize] = FPAdd(Elem[D[d+r],e,esize], addend, FALSE);
addend64 = if add then FPMul(D[n], D[m], TRUE) else FPNeg(FPMul(D[n], D[m], TRUE));
D[d] = FPAdd(D[d], addend64, TRUE);
else
addend32 = if add then FPMul(S[n], S[m], TRUE) else FPNeg(FPMul(S[n], S[m], TRUE));
S[d] = FPAdd(S[d], addend32, TRUE);
Exceptions
A8.8.339 VMLA, VMLAL, VMLS, VMLSL (by scalar)

Vector Multiply Accumulate and Vector Multiply Subtract multiply elements of a vector by a scalar, and either add
the products to, or subtract them from, corresponding elements of the destination vector. Vector Multiply
Accumulate Long and Vector Multiply Subtract Long do the same thing, but with destination vector elements that
are twice as long as the elements that are multiplied.

V<op><c>.<dt> <Qd>, <Qn>, <Dm[x]>
V<op><c>.<dt> <Dd>, <Dn>, <Dm[x]>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 Q 1 1 1 1 1 D size Vn Vd 0 op 0 F N 1 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 Q 1 D size Vn Vd 0 op 0 F N 1 M 0 Vm

if size == ‘00’ || (F == ‘1’ && size == ‘01’) then UNDEFINED;
if Q == ‘1’ && (Vd<0> == ‘1’ || Vn<0> == ‘1’) then UNDEFINED;
add = (op == ‘0’); floating_point = (F == ‘1’); long_destination = FALSE;
d = UInt(D:Vd); n = UInt(N:Vn); regs = if Q == ‘0’ then 1 else 2;
if size == ‘01’ then esize = 16; elements = 4; m = UInt(Vm<2:0>); index = UInt(M:Vm<3>);
if size == ‘10’ then esize = 32; elements = 2; m = UInt(Vm); index = UInt(M);

V<op>L<c>.<dt> <Qd>, <Dn>, <Dm[x]>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 U 1 1 1 1 1 D size Vn Vd 0 op 1 0 N 1 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 U 1 D size Vn Vd 0 op 1 0 N 1 M 0 Vm

if size == ‘00’ || Vd<0> == ‘1’ then UNDEFINED;
unsigned = (U == ‘1’); add = (op == ‘0’); floating_point = FALSE; long_destination = TRUE;
d = UInt(D:Vd); n = UInt(N:Vn); regs = 1;
Assembler syntax
V<op>{<c>}{<q>}.<type><size> <Qd>, <Qn>, <Dm[x]> Encoding T1/A1, encoded as Q = 1
V<op>{<c>}{<q>}.<type><size> <Dd>, <Dn>, <Dm[x]> Encoding T1/A1, encoded as Q = 0
V<op>L{<c>}{<q>}.<type><size> <Qd>, <Dn>, <Dm[x]> Encoding T2/A2
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM Advanced SIMD VMLA, VMLAL, VMLS,
or VMLSL instruction must be unconditional. ARM strongly recommends that a Thumb Advanced
SIMD VMLA, VMLAL, VMLS, or VMLSL instruction is unconditional, see Conditional execution on
page A8-286.
S Encoding T2/A2, encoded as U = 0.
U Encoding T2/A2, encoded as U = 1.
I Encoding T1/A1, encoded as F = 0.
F Encoding T1/A1, encoded as F = 1. <size> must be 32.
<size> The operand element data size. It can be:
16 Encoded as size = 01.
32 Encoded as size = 10.
<Qd>, <Qn> The accumulate vector, and the operand vector, for a quadword operation.
<Dd>, <Dn> The accumulate vector, and the operand vector, for a doubleword operation.
<Qd>, <Dn> The accumulate vector, and the operand vector, for a long operation.
<Dm[x]> The scalar. Dm is restricted to D0-D7 if <size> is 16, or D0-D15 otherwise.
Operation
op2 = Elem[Din[m],index,esize]; op2val = Int(op2, unsigned);
for r = 0 to regs-1
op1 = Elem[Din[n+r],e,esize]; op1val = Int(op1, unsigned);
fp_addend = if add then FPMul(op1,op2,FALSE) else FPNeg(FPMul(op1,op2,FALSE));
Elem[D[d+r],e,esize] = FPAdd(Elem[Din[d+r],e,esize], fp_addend, FALSE);
else
addend = if add then op1val*op2val else -op1val*op2val;
Elem[Q[d>>1],e,2*esize] = Elem[Qin[d>>1],e,2*esize] + addend;
else
Elem[D[d+r],e,esize] = Elem[Din[d+r],e,esize] + addend;
Exceptions
A8.8.340 VMOV (immediate)

This instruction places an immediate constant into every element of the destination register.

VMOV<c>.<dt> <Qd>, #<imm>
VMOV<c>.<dt> <Dd>, #<imm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 i 1 1 1 1 1 D 0 0 0 imm3 Vd cmode 0 Q op 1 imm4
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 i 1 D 0 0 0 imm3 Vd cmode 0 Q op 1 imm4
if op == ‘0’ && cmode<0> == ‘1’ && cmode<3:2> != ‘11’ then SEE VORR (immediate);
if op == ‘1’ && cmode != ‘1110’ then SEE “Related encodings”;
single_register = FALSE; advsimd = TRUE; imm64 = AdvSIMDExpandImm(op, cmode, i:imm3:imm4);
Encoding T2/A2 VFPv3, VFPv4 (sz = 1 UNDEFINED in single-precision only variants)

VMOV<c>.F64 <Dd>, #<imm>
VMOV<c>.F32 <Sd>, #<imm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 0 1 D 1 1 imm4H Vd 1 0 1 sz (0) 0 (0) 0 imm4L
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 1 0 1 D 1 1 imm4H Vd 1 0 1 sz (0) 0 (0) 0 imm4L

single_register = (sz == ‘0’); advsimd = FALSE;
if single_register then
d = UInt(Vd:D); imm32 = VFPExpandImm(imm4H:imm4L, 32);
else
d = UInt(D:Vd); imm64 = VFPExpandImm(imm4H:imm4L, 64); regs = 1;
Assembler syntax
VMOV{<c>}{<q>}.<dt> <Qd>, #<imm> Encoding T1/A1, encoded as Q = 1
VMOV{<c>}{<q>}.<dt> <Dd>, #<imm> Encoding T1/A1, encoded as Q = 0
VMOV{<c>}{<q>}.F64 <Dd>, #<imm> Encoding T2/A2, encoded as sz = 1
VMOV{<c>}{<q>}.F32 <Sd>, #<imm> Encoding T2/A2, encoded as sz = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM Advanced SIMD VMOV (immediate)
instruction must be unconditional. ARM strongly recommends that a Thumb Advanced SIMD VMOV
(immediate) instruction is unconditional, see Conditional execution on page A8-286.
<dt> The data type. It must be one of I8, I16, I32, I64, or F32.
<Qd> The destination register for a quadword operation.
<Dd> The destination register for a doubleword operation.
<Sd> The destination register for a singleword operation.
destination register. For example, VMOV.I32 D0, #10 writes 0x0000000A0000000A to D0.
For the range of constants available, and the encoding of <dt> and <imm>, see:
• One register and a modified immediate value on page A7-267 for encoding T1/A1
• Floating-point data-processing instructions on page A7-270 for encoding T2/A2.
Operation
S[d] = imm32;
else
for r = 0 to regs-1
D[d+r] = imm64;
Exceptions
Pseudo-instructions
A8.8.341 VMOV (register)

This instruction copies the contents of one register to another.

VMOV<c> <Qd>, <Qm>
VMOV<c> <Dd>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 1 0 D 1 0 Vm Vd 0 0 0 1 M Q M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 0 0 D 1 0 Vm Vd 0 0 0 1 M Q M 1 Vm
if !Consistent(M) || !Consistent(Vm) then SEE VORR (register);

single_register = FALSE; advsimd = TRUE;
VMOV<c>.F64 <Dd>, <Dm>
VMOV<c>.F32 <Sd>, <Sm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 0 1 D 1 1 0 0 0 0 Vd 1 0 1 sz 0 1 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 1 0 1 D 1 1 0 0 0 0 Vd 1 0 1 sz 0 1 M 0 Vm

single_register = (sz == ‘0’); advsimd = FALSE;
d = UInt(Vd:D); m = UInt(Vm:M);
else
d = UInt(D:Vd); m = UInt(M:Vm); regs = 1;
Assembler syntax
VMOV{<c>}{<q>}{.<dt>} <Qd>, <Qm> Encoding T1/A1, encoded as Q = 1
VMOV{<c>}{<q>}{.<dt>} <Dd>, <Dm> Encoding T1/A1, encoded as Q = 0
VMOV{<c>}{<q>}.F64 <Dd>, <Dm> Encoding T2/A2, encoded as sz = 1
VMOV{<c>}{<q>}.F32 <Sd>, <Sm> Encoding T2/A2, encoded as sz = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM Advanced SIMD VMOV
(register) instruction must be unconditional. ARM strongly recommends that a Thumb
Advanced SIMD VMOV (register) instruction is unconditional, see Conditional execution on
page A8-286.
<dt> An optional data type. <dt> must not be F64, but it is otherwise ignored.
<Qd>, <Qm> The destination register and the source register, for a quadword operation.
<Dd>, <Dm> The destination register and the source register, for a doubleword operation.
<Sd>, <Sm> The destination register and the source register, for a singleword operation.
Operation
S[d] = S[m];
else
for r = 0 to regs-1
D[d+r] = D[m+r];
Exceptions
A8.8.342 VMOV (ARM core register to scalar)

This instruction copies a byte, halfword, or word from an ARM core register into an Advanced SIMD scalar.
On a Floating-point-only system, this instruction transfers one word to the upper or lower half of a double-precision
floating-point register from an ARM core register. This is an identical operation to the Advanced SIMD single word
transfer.
Encoding T1/A1 Word version (opc1:opc2 == '0x00'): VFPv2, VFPv3, VFPv4, Advanced SIMD
Advanced SIMD otherwise
VMOV<c>.<size> <Dd[x]>, <Rt>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 0 0 opc1 0 Vd Rt 1 0 1 1 D opc2 1 (0) (0) (0) (0)
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 1 0 0 opc1 0 Vd Rt 1 0 1 1 D opc2 1 (0) (0) (0) (0)
case opc1:opc2 of
when “1xxx” advsimd = TRUE; esize = 8; index = UInt(opc1<0>:opc2);
when “0xx1” advsimd = TRUE; esize = 16; index = UInt(opc1<0>:opc2<1>);
when “0x00” advsimd = FALSE; esize = 32; index = UInt(opc1<0>);
when “0x10” UNDEFINED;
d = UInt(D:Vd); t = UInt(Rt);
Assembler syntax
VMOV{<c>}{<q>}{.<size>} <Dd[x]>, <Rt>
where:

8 Encoded as opc1<1> = 1. [x] is encoded in opc1<0>, opc2.
16 Encoded as opc1<1> = 0, opc2<0> = 1. [x] is encoded in opc1<0>, opc2<1>.
32 Encoded as opc1<1> = 0, opc2 = 0b00. [x] is encoded in opc1<0>.
omitted Equivalent to 32.
<Dd[x]> The scalar. The register <Dd> is encoded in D:Vd. For details of how [x] is encoded, see the
description of <size>.
<Rt> The source ARM core register.
Operation
Elem[D[d],index,esize] = R[t]<esize-1:0>;
Exceptions
A8.8.343 VMOV (scalar to ARM core register)

This instruction copies a byte, halfword, or word from an Advanced SIMD scalar to an ARM core register. Bytes
and halfwords can be either zero-extended or sign-extended.
On a Floating-point-only system, this instruction transfers one word from the upper or lower half of a
double-precision floating-point register to an ARM core register. This is an identical operation to the Advanced
SIMD single word transfer.
Encoding T1/A1 Word version (U:opc1:opc2 == '00x00'): VFPv2, VFPv3, VFPv4, Advanced SIMD
Advanced SIMD otherwise
VMOV<c>.<dt> <Rt>, <Dn[x]>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 0 U opc1 1 Vn Rt 1 0 1 1 N opc2 1 (0) (0) (0) (0)
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 1 0 U opc1 1 Vn Rt 1 0 1 1 N opc2 1 (0) (0) (0) (0)
case U:opc1:opc2 of
when “x1xxx” advsimd = TRUE; esize = 8; index = UInt(opc1<0>:opc2);
when “x0xx1” advsimd = TRUE; esize = 16; index = UInt(opc1<0>:opc2<1>);
when “00x00” advsimd = FALSE; esize = 32; index = UInt(opc1<0>);
when “10x00” UNDEFINED;
when “x0x10” UNDEFINED;
t = UInt(Rt); n = UInt(N:Vn); unsigned = (U == ‘1’);
Assembler syntax
VMOV{<c>}{<q>}{.<dt>} <Rt>, <Dn[x]>
where:
<dt> The data type. It must be one of:

S8 Encoded as U = 0, opc1<1> = 1. [x] is encoded in opc1<0>, opc2.
S16 Encoded as U = 0, opc1<1> = 0, opc2<0> = 1. [x] is encoded in opc1<0>, opc2<1>.
U8 Encoded as U = 1, opc1<1> = 1. [x] is encoded in opc1<0>, opc2.
U16 Encoded as U = 1, opc1<1> = 0, opc2<0> = 1. [x] is encoded in opc1<0>, opc2<1>.
32 Encoded as U = 0, opc1<1> = 0, opc2 = 0b00. [x] is encoded in opc1<0>.
omitted Equivalent to 32.
<Dn[x]> The scalar. For details of how [x] is encoded see the description of <dt>.
<Rt> The destination ARM core register.
Operation
if unsigned then
R[t] = ZeroExtend(Elem[D[n],index,esize], 32);
else
R[t] = SignExtend(Elem[D[n],index,esize], 32);
Exceptions
A8.8.344 VMOV (between ARM core register and single-precision register)

This instruction transfers the contents of a single-precision Floating-point register to an ARM core register, or the
contents of an ARM core register to a single-precision Floating-point register.

VMOV<c> <Sn>, <Rt>
VMOV<c> <Rt>, <Sn>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 0 0 0 0 op Vn Rt 1 0 1 0 N (0) (0) 1 (0) (0) (0) (0)
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 1 0 0 0 0 op Vn Rt 1 0 1 0 N (0) (0) 1 (0) (0) (0) (0)
to_arm_register = (op == ‘1’); t = UInt(Rt); n = UInt(Vn:N);

Assembler syntax
VMOV{<c>}{<q>} <Sn>, <Rt> Encoded as op = 0
VMOV{<c>}{<q>} <Rt>, <Sn> Encoded as op = 1
where:
<Sn> The single-precision VFP register.
<Rt> The ARM core register.
Operation
if to_arm_register then
R[t] = S[n];
else
S[n] = R[t];
Exceptions
A8.8.345 VMOV (between two ARM core registers and two single-precision registers)
This instruction transfers the contents of two consecutively numbered single-precision Floating-point registers to
two ARM core registers, or the contents of two ARM core registers to a pair of single-precision Floating-point
registers. The ARM core registers do not have to be contiguous.

VMOV<c> <Sm>, <Sm1>, <Rt>, <Rt2>
VMOV<c> <Rt>, <Rt2>, <Sm>, <Sm1>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 0 0 0 1 0 op Rt2 Rt 1 0 1 0 0 0 M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 0 0 0 1 0 op Rt2 Rt 1 0 1 0 0 0 M 1 Vm
to_arm_registers = (op == ‘1’); t = UInt(Rt); t2 = UInt(Rt2); m = UInt(Vm:M);

if t == 15 || t2 == 15 || m == 31 then UNPREDICTABLE;
if CurrentInstrSet() != InstrSet_ARM && (t == 13 || t2 == 13) then UNPREDICTABLE;
if to_arm_registers && t == t2 then UNPREDICTABLE;
Assembler syntax
VMOV{<c>}{<q>} <Sm>, <Sm1>, <Rt>, <Rt2> Encoded as op = 0
VMOV{<c>}{<q>} <Rt>, <Rt2>, <Sm>, <Sm1> Encoded as op = 1
where:
<Sm> The first single-precision Floating-point register.
<Sm1> The second single-precision Floating-point register. This is the next single-precision Floating-point
register after <Sm>.
<Rt> The ARM core register that <Sm> is transferred to or from.
<Rt2> The ARM core register that <Sm1> is transferred to or from.
Operation
if to_arm_registers then
R[t] = S[m];
R[t2] = S[m+1];
else
S[m] = R[t];
S[m+1] = R[t2];
Exceptions
A8.8.346 VMOV (between two ARM core registers and a doubleword extension register)
This instruction copies two words from two ARM core registers into a doubleword extension register, or from a
doubleword extension register to two ARM core registers.

VMOV<c> <Dm>, <Rt>, <Rt2>
VMOV<c> <Rt>, <Rt2>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 0 0 0 1 0 op Rt2 Rt 1 0 1 1 0 0 M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 0 0 0 1 0 op Rt2 Rt 1 0 1 1 0 0 M 1 Vm
to_arm_registers = (op == ‘1’); t = UInt(Rt); t2 = UInt(Rt2); m = UInt(M:Vm);

if CurrentInstrSet() != InstrSet_ARM && (t == 13 || t2 == 13) then UNPREDICTABLE;
if to_arm_registers && t == t2 then UNPREDICTABLE;
Assembler syntax
VMOV{<c>}{<q>} <Dm>, <Rt>, <Rt2> Encoded as op = 0
VMOV{<c>}{<q>} <Rt>, <Rt2>, <Dm> Encoded as op = 1
where:
<Dm> The doubleword extension register.
<Rt>, <Rt2> The two ARM core registers.
Operation
if to_arm_registers then
R[t] = D[m]<31:0>;
R[t2] = D[m]<63:32>;
else
D[m]<31:0> = R[t];
D[m]<63:32> = R[t2];
Exceptions
A8.8.347 VMOVL
Vector Move Long takes each element in a doubleword vector, sign or zero-extends them to twice their original
length, and places the results in a quadword vector.

VMOVL<c>.<dt> <Qd>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 U 1 1 1 1 1 D imm3 0 0 0 Vd 1 0 1 0 0 0 M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 U 1 D imm3 0 0 0 Vd 1 0 1 0 0 0 M 1 Vm
if imm3 == ‘000’ then SEE “Related encodings”;

if imm3 != ‘001’ && imm3 != ‘010’ && imm3 != ‘100’ then SEE VSHLL;
esize = 8 * UInt(imm3);
unsigned = (U == ‘1’); elements = 64 DIV esize;
d = UInt(D:Vd); m = UInt(M:Vm);
Assembler syntax
VMOVL{<c>}{<q>}.dt> <Qd>, <Dm>
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VMOVL instruction must be
unconditional. ARM strongly recommends that a Thumb VMOVL instruction is unconditional, see
<dt> The data type for the elements of the operand. It must be one of:
S8 Encoded as U = 0, imm3 = 0b001.
U8 Encoded as U = 1, imm3 = 0b001.
<Qd>, <Dm> The destination vector and the operand vector.
Operation
result = Int(Elem[Din[m],e,esize], unsigned);
Exceptions
A8.8.348 VMOVN
Vector Move and Narrow copies the least significant half of each element of a quadword vector into the
corresponding elements of a doubleword vector.
The operand vector elements can be any one of 16-bit, 32-bit, or 64-bit integers. There is no distinction between
signed and unsigned integers.

VMOVN<c>.<dt> <Dd>, <Qm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 size 1 0 Vd 0 0 1 0 0 0 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 size 1 0 Vd 0 0 1 0 0 0 M 0 Vm

if Vm<0> == ‘1’ then UNDEFINED;
Assembler syntax
VMOVN{<c>}{<q>}.<dt> <Dd>, <Qm>
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VMOVN instruction must be
unconditional. ARM strongly recommends that a Thumb VMOVN instruction is unconditional, see
<dt> The data type for the elements of the operand. It must be one of:
I16 Encoded as size = 0b00.
<Dd>, <Qm> The destination vector and the operand vector.
Operation
Elem[D[d],e,esize] = Elem[Qin[m>>1],e,2*esize]<esize-1:0>;
Exceptions
A8.8.349 VMRS
Move to ARM core register from Advanced SIMD and Floating-point Extension System Register moves the value
of the FPSCR to an ARM core register.
For details of system level use of this instruction, see VMRS on page B9-2000.

VMRS<c> <Rt>, FPSCR
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 0 1 1 1 1 0 0 0 1 Rt 1 0 1 0 (0) (0) (0) 1 (0) (0) (0) (0)
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 1 0 1 1 1 1 0 0 0 1 Rt 1 0 1 0 (0) (0) (0) 1 (0) (0) (0) (0)
t = UInt(Rt);
if t == 13 && CurrentInstrSet() != InstrSet_ARM then UNPREDICTABLE;
Assembler syntax
VMRS{<c>}{<q>} <Rt>, FPSCR
where:
<Rt> The destination ARM core register. This register can be R0-R14 or APSR_nzcv. APSR_nzcv is
encoded as Rt = 0b1111, and the instruction transfers the FPSCR.{N, Z, C, V} condition flags to the
APSR.{N, Z, C, V} condition flags.
The pre-UAL instruction FMSTAT is equivalent to VMRS APSR_nzcv, FPSCR.
Operation
SerializeVFP(); VFPExcBarrier();
if t != 15 then
R[t] = FPSCR;
else
APSR.N = FPSCR.N;
APSR.Z = FPSCR.Z;
APSR.C = FPSCR.C;
APSR.V = FPSCR.V;
Exceptions
A8.8.350 VMSR
Move to Advanced SIMD and Floating-point Extension System Register from ARM core register moves the value
of an ARM core register to the FPSCR.
For details of system level use of this instruction, see VMSR on page B9-2002.

VMSR<c> FPSCR, <Rt>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 0 1 1 1 0 0 0 0 1 Rt 1 0 1 0 (0) (0) (0) 1 (0) (0) (0) (0)
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 1 0 1 1 1 0 0 0 0 1 Rt 1 0 1 0 (0) (0) (0) 1 (0) (0) (0) (0)
t = UInt(Rt);
if t == 15 || (t == 13 && CurrentInstrSet() != InstrSet_ARM) then UNPREDICTABLE;
Assembler syntax
VMSR{<c>}{<q>} FPSCR, <Rt>
where:
<Rt> The ARM core register to be transferred to the FPSCR.
Operation
SerializeVFP(); VFPExcBarrier();
FPSCR = R[t];
Exceptions
A8.8.351 VMUL, VMULL (integer and polynomial)

Vector Multiply multiplies corresponding elements in two vectors. Vector Multiply Long does the same thing, but
with destination vector elements that are twice as long as the elements that are multiplied.
For information about multiplying polynomials see Polynomial arithmetic over {0, 1} on page A2-92.

VMUL<c>.<dt> <Qd>, <Qn>, <Qm>
VMUL<c>.<dt> <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 op 1 1 1 1 0 D size Vn Vd 1 0 0 1 N Q M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 op 0 D size Vn Vd 1 0 0 1 N Q M 1 Vm
if size == ‘11’ || (op == ‘1’ && size != ‘00’) then UNDEFINED;

polynomial = (op == ‘1’); long_destination = FALSE;

VMULL<c>.<dt> <Qd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 U 1 1 1 1 1 D size Vn Vd 1 1 op 0 N 0 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 U 1 D size Vn Vd 1 1 op 0 N 0 M 0 Vm

if op == ‘1’ && (U != ‘0’ || size != ‘00’) then UNDEFINED;
polynomial = (op == ‘1’); long_destination = TRUE; unsigned = (U == ‘1’);
Assembler syntax
VMUL{<c>}{<q>}.<type><size> {<Qd>,} <Qn>, <Qm> Encoding T1/A1, encoded as Q = 1
VMUL{<c>}{<q>}.<type><size> {<Dd>,} <Dn>, <Dm> Encoding T1/A1, encoded as Q = 0
VMULL{<c>}{<q>}.<type><size> <Qd>, <Dn>, <Dm> Encoding T2/A2
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM Advanced SIMD VMUL or
VMULL instruction must be unconditional. ARM strongly recommends that a Thumb
Advanced SIMD VMUL or VMULL instruction is unconditional, see Conditional execution on
page A8-286.
S Encoded as op = 0 in both encodings, with U = 0 in encoding T2/A2.
U Encoded as op = 0 in both encodings, with U = 1 in encoding T2/A2.
I Encoding T1/A1 only, encoded as op = 0.
P Encoded as op = 1 in both encodings, with U= 0 in encoding T2/A2.
When <type> is P, <size> must be 8.
Operation
for r = 0 to regs-1
op2 = Elem[Din[m+r],e,esize]; op2val = Int(op2, unsigned);
if polynomial then
product = PolynomialMult(op1,op2);
else
product = (op1val*op2val)<2*esize-1:0>;
Elem[Q[d>>1],e,2*esize] = product;
else
Elem[D[d+r],e,esize] = product<esize-1:0>;
Exceptions
A8.8.352 VMUL (floating-point)

Vector Multiply multiplies corresponding elements in two vectors, and places the results in the destination vector.

VMUL<c>.F32 <Qd>, <Qn>, <Qm>
VMUL<c>.F32 <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 0 D 0 sz Vn Vd 1 1 0 1 N Q M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 0 D 0 sz Vn Vd 1 1 0 1 N Q M 1 Vm
VMUL<c>.F64 <Dd>, <Dn>, <Dm>
VMUL<c>.F32 <Sd>, <Sn>, <Sm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 0 0 D 1 0 Vn Vd 1 0 1 sz N 0 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Assembler syntax
VMUL{<c>}{<q>}.F32 {<Qd>,} <Qn>, <Qm> Encoding T1/A1, encoded as Q = 1, sz = 0
VMUL{<c>}{<q>}.F32 {<Dd>,} <Dn>, <Dm> Encoding T1/A1, encoded as Q = 0, sz = 0
VMUL{<c>}{<q>}.F64 {<Dd>,} <Dn>, <Dm> Encoding T2/A2, encoded as sz = 1
VMUL{<c>}{<q>}.F32 {<Sd>,} <Sn>, <Sm> Encoding T2/A2, encoded as sz = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM Advanced SIMD VMUL
SIMD VMUL instruction is unconditional, see Conditional execution on page A8-286.
Operation
for r = 0 to regs-1
Elem[D[d+r],e,esize] = FPMul(Elem[D[n+r],e,esize], Elem[D[m+r],e,esize], FALSE);
D[d] = FPMul(D[n], D[m], TRUE);
else
S[d] = FPMul(S[n], S[m], TRUE);
Exceptions
A8.8.353 VMUL, VMULL (by scalar)

Vector Multiply multiplies each element in a vector by a scalar, and places the results in a second vector. Vector
Multiply Long does the same thing, but with destination vector elements that are twice as long as the elements that
are multiplied.

VMUL<c>.<dt> <Qd>, <Qn>, <Dm[x]>
VMUL<c>.<dt> <Dd>, <Dn>, <Dm[x]>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 Q 1 1 1 1 1 D size Vn Vd 1 0 0 F N 1 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 Q 1 D size Vn Vd 1 0 0 F N 1 M 0 Vm

if size == ‘00’ || (F == ‘1’ && size == ‘01’) then UNDEFINED;
floating_point = (F == ‘1’); long_destination = FALSE;
d = UInt(D:Vd); n = UInt(N:Vn); regs = if Q == ‘0’ then 1 else 2;

VMULL<c>.<dt> <Qd>, <Dn>, <Dm[x]>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 U 1 1 1 1 1 D size Vn Vd 1 0 1 0 N 1 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 U 1 D size Vn Vd 1 0 1 0 N 1 M 0 Vm

unsigned = (U == ‘1’); long_destination = TRUE; floating_point = FALSE;
d = UInt(D:Vd); n = UInt(N:Vn); regs = 1;
Assembler syntax
VMUL{<c>}{<q>}.<dt> {<Qd>,} <Qn>, <Dm[x]> Encoding T1/A1, encoded as Q = 1
VMUL{<c>}{<q>}.<dt> {<Dd>,} <Dn>, <Dm[x]> Encoding T1/A1, encoded as Q = 0
VMULL{<c>}{<q>}.<dt> <Qd>, <Dn>, <Dm[x]> Encoding T2/A2
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM Advanced SIMD VMUL or VMULL
instruction must be unconditional. ARM strongly recommends that a Thumb Advanced SIMD VMUL
or VMULL instruction is unconditional, see Conditional execution on page A8-286.
<dt> The data type for the scalar, and the elements of the operand vector. It must be one of:
I16 Encoding T1/A1, encoded as size = 0b01, F = 0.
I32 Encoding T1/A1, encoded as size = 0b10, F = 0.
F32 Encoding T1/A1, encoded as size = 0b10, F = 1.
S16 Encoding T2/A2, encoded as size = 0b01, U = 0.
U16 Encoding T2/A2, encoded as size = 0b01, U = 1.
<Qd>, <Qn> The destination vector, and the operand vector, for a quadword operation.
<Dd>, <Dn> The destination vector, and the operand vector, for a doubleword operation.
<Qd>, <Dn> The destination vector, and the operand vector, for a long operation.
<Dm[x]> The scalar. Dm is restricted to D0-D7 if <dt> is I16, S16, or U16, or D0-D15 otherwise.
Operation
op2 = Elem[Din[m],index,esize]; op2val = Int(op2, unsigned);
for r = 0 to regs-1
Elem[D[d+r],e,esize] = FPMul(op1, op2, FALSE);
else
Elem[Q[d>>1],e,2*esize] = (op1val*op2val)<2*esize-1:0>;
else
Elem[D[d+r],e,esize] = (op1val*op2val)<esize-1:0>;
Exceptions
A8.8.354 VMVN (immediate)

Vector Bitwise NOT (immediate) places the bitwise inverse of an immediate integer constant into every element of
the destination register. For the range of constants available, see One register and a modified immediate value on
page A7-267.

VMVN<c>.<dt> <Qd>, #<imm>
VMVN<c>.<dt> <Dd>, #<imm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if (cmode<0> == ‘1’ && cmode<3:2> != ‘11’) || cmode<3:1> == ‘111’ then SEE “Related encodings”;
Assembler syntax
VMVN{<c>}{<q>}.dt> <Qd>, #<imm> Encoding T1/A1, encoded as Q = 1
VMVN{<c>}{<q>}.dt> <Dd>, #<imm> Encoding T1/A1, encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VMVN instruction must be
unconditional. ARM strongly recommends that a Thumb VMVN instruction is unconditional, see
<dt> The data type. It must be either I16 or I32.
<Qd> The destination register for a quadword operation.
<Dd> The destination register for a doubleword operation.
<imm> A constant of the specified type.
See One register and a modified immediate value on page A7-267 for the range of constants available, and the
encoding of <dt> and <imm>.
Operation
for r = 0 to regs-1
D[d+r] = NOT(imm64);
Exceptions
Pseudo-instructions
A8.8.355 VMVN (register)

Vector Bitwise NOT (register) takes a value from a register, inverts the value of each bit, and places the result in the
destination register. The registers can be either doubleword or quadword.

VMVN<c> <Qd>, <Qm>
VMVN<c> <Dd>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 size 0 0 Vd 0 1 0 1 1 Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 size 0 0 Vd 0 1 0 1 1 Q M 0 Vm

Assembler syntax
VMVN{<c>}{<q>}{.<dt>} <Qd>, <Qm>
VMVN{<c>}{<q>}{.<dt>} <Dd>, <Dm>
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VMVN instruction must be
unconditional. ARM strongly recommends that a Thumb VMVN instruction is unconditional, see
Operation
for r = 0 to regs-1
D[d+r] = NOT(D[m+r]);
Exceptions
A8.8.356 VNEG
Vector Negate negates each element in a vector, and places the results in a second vector. The floating-point version
only inverts the sign bit.

VNEG<c>.<dt> <Qd>, <Qm>
VNEG<c>.<dt> <Dd>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 size 0 1 Vd 0 F 1 1 1 Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 size 0 1 Vd 0 F 1 1 1 Q M 0 Vm

advsimd = TRUE; floating_point = (F == ‘1’);
VNEG<c>.F64 <Dd>, <Dm>
VNEG<c>.F32 <Sd>, <Sm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 0 1 D 1 1 0 0 0 1 Vd 1 0 1 sz 0 1 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 1 0 1 D 1 1 0 0 0 1 Vd 1 0 1 sz 0 1 M 0 Vm

Assembler syntax
VNEG{<c>}{<q>}.<dt> <Qd>, <Qm> Encoding T1/A1
VNEG{<c>}{<q>}.<dt> <Dd>, <Dm> Encoding T1/A1
VNEG{<c>}{<q>}.F32 <Sd>, <Sm> Floating-point only, encoding T2/A2, encoded as sz = 0
VNEG{<c>}{<q>}.F64 <Dd>, <Dm> Encoding T2/A2, encoded as sz = 1
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM Advanced SIMD VNEG instruction
must be unconditional. ARM strongly recommends that a Thumb Advanced SIMD VNEG instruction
F32 Encoded as size = 0b10, F = 1.
<Sd>, <Sm> The destination vector and the operand vector, for a singleword operation.
Operation
for r = 0 to regs-1
Elem[D[d+r],e,esize] = FPNeg(Elem[D[m+r],e,esize]);
else
result = -SInt(Elem[D[m+r],e,esize]);
D[d] = FPNeg(D[m]);
else
S[d] = FPNeg(S[m]);
Exceptions
A8.8.357 VNMLA, VNMLS, VNMUL

VNMLA multiplies together two floating-point register values, adds the negation of the floating-point value in the
destination register to the negation of the product, and writes the result back to the destination register.
VNMLS multiplies together two floating-point register values, adds the negation of the floating-point value in the
destination register to the product, and writes the result back to the destination register.
VNMUL multiplies together two floating-point register values, and writes the negation of the result to the destination
register.
Note
ARM recommends that software does not use the VNMLA instruction in the Round towards Plus Infinity and Round
towards Minus Infinity rounding modes, because the rounding of the product and of the sum can change the result
of the instruction in opposite directions, defeating the purpose of these rounding modes.
VNMLA<c>.F64 <Dd>, <Dn>, <Dm>
VNMLA<c>.F32 <Sd>, <Sn>, <Sm>
VNMLS<c>.F64 <Dd>, <Dn>, <Dm>
VNMLS<c>.F32 <Sd>, <Sn>, <Sm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 0 0 D 0 1 Vn Vd 1 0 1 sz N op M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

type = if op == ‘1’ then VFPNegMul_VNMLA else VFPNegMul_VNMLS;
VNMUL<c>.F64 <Dd>, <Dn>, <Dm>
VNMUL<c>.F32 <Sd>, <Sn>, <Sm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 0 0 D 1 0 Vn Vd 1 0 1 sz N 1 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

type = VFPNegMul_VNMUL;
VFP vectors These instructions can operate on VFP vectors under control of the FPSCR.{Len, Stride} fields.
Assembler syntax
VN<op>{<c>}{<q>}.F64 <Dd>, <Dn>, <Dm> Encoding T1/A1, encoded as sz = 1
VN<op>{<c>}{<q>}.F32 <Sd>, <Sn>, <Sm> Encoding T1/A1, encoded as sz = 0
VNMUL{<c>}{<q>}.F64 {<Dd>,} <Dn>, <Dm> Encoding T2/A2, encoded as sz = 1
VNMUL{<c>}{<q>}.F32 {<Sd>,} <Sn>, <Sm> Encoding T2/A2, encoded as sz = 0
where:

MLA Vector Negate Multiply Accumulate. Encoded as op = 0.
MLS Vector Negate Multiply Subtract. Encoded as op = 1.
<Dd>, <Dn>, <Dm> The destination register and the operand registers, for a double-precision operation.
<Sd>, <Sn>, <Sm> The destination register and the operand registers, for a single-precision operation.
Operation
enumeration VFPNegMul {VFPNegMul_VNMLA, VFPNegMul_VNMLS, VFPNegMul_VNMUL};
product64 = FPMul(D[n], D[m], TRUE);
case type of
when VFPNegMul_VNMLA D[d] = FPAdd(FPNeg(D[d]), FPNeg(product64), TRUE);
when VFPNegMul_VNMLS D[d] = FPAdd(FPNeg(D[d]), product64, TRUE);
when VFPNegMul_VNMUL D[d] = FPNeg(product64);
else
product32 = FPMul(S[n], S[m], TRUE);
case type of
when VFPNegMul_VNMLA S[d] = FPAdd(FPNeg(S[d]), FPNeg(product32), TRUE);
when VFPNegMul_VNMLS S[d] = FPAdd(FPNeg(S[d]), product32, TRUE);
when VFPNegMul_VNMUL S[d] = FPNeg(product32);
Exceptions
Invalid Operation, Overflow, Underflow, Inexact, Input Denormal.
A8.8.358 VORN (immediate)

VORN (immediate) is a pseudo-instruction, equivalent to a VORR (immediate) instruction with the immediate value
bitwise inverted. For details see VORR (immediate) on page A8-975.
A8.8.359 VORN (register)

This instruction performs a bitwise OR NOT operation between two registers, and places the result in the destination
register. The operand and result registers can be quadword or doubleword. They must all be the same size.

VORN<c> <Qd>, <Qn>, <Qm>
VORN<c> <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 1 0 D 1 1 Vn Vd 0 0 0 1 N Q M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 0 0 D 1 1 Vn Vd 0 0 0 1 N Q M 1 Vm
Assembler syntax
VORN{<c>}{<q>}{.<dt>} {<Qd>,} <Qn>, <Qm> Encoded as Q = 1
VORN{<c>}{<q>}{.<dt>} {<Dd>,} <Dn>, <Dm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VORN instruction must be
unconditional. ARM strongly recommends that a Thumb VORN instruction is unconditional,
Operation
for r = 0 to regs-1
D[d+r] = D[n+r] OR NOT(D[m+r]);
Exceptions
A8.8.360 VORR (immediate)

This instruction takes the contents of the destination vector, performs a bitwise OR with an immediate constant, and
returns the result into the destination vector. For the range of constants available, see One register and a modified

VORR<c>.<dt> <Qd>, #<imm>
VORR<c>.<dt> <Dd>, #<imm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if cmode<0> == ‘0’ || cmode<3:2> == ‘11’ then SEE VMOV (immediate);

Assembler syntax
VORR{<c>}{<q>}.<dt> {<Qd>,} <Qd>, #<imm> Encoded as Q = 1
VORR{<c>}{<q>}.<dt> {<Dd>,} <Dd>, #<imm>> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VORR instruction must be
unconditional. ARM strongly recommends that a Thumb VORR instruction is unconditional, see
<dt> The data type used for <imm>. It can be either I16 or I32.
I8, I64, and F32 are also permitted, but the resulting syntax is a pseudo-instruction.
destination register. For example, VORR.I32 D0, #10 ORs 0x0000000A0000000A into D0.
For details of the range of constants available, and the encoding of <dt> and <imm>, see One register and a modified
Operation
for r = 0 to regs-1
D[d+r] = D[d+r] OR imm64;
Exceptions
Pseudo-instructions
VORN can be used, with a range of constants that are the bitwise inverse of the available constants for VORR. This is
assembled as the equivalent VORR instruction. Disassembly produces the VORR form.
A8.8.361 VORR (register)

This instruction performs a bitwise OR operation between two registers, and places the result in the destination
register. The operand and result registers can be quadword or doubleword. They must all be the same size.

VORR<c> <Qd>, <Qn>, <Qm>
VORR<c> <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 1 0 D 1 0 Vn Vd 0 0 0 1 N Q M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 0 0 D 1 0 Vn Vd 0 0 0 1 N Q M 1 Vm
if N == M && Vn == Vm then SEE VMOV (register);

Assembler syntax
VORR{<c>}{<q>}{.<dt>} {<Qd>,} <Qn>, <Qm> Encoded as Q = 1
VORR{<c>}{<q>}{.<dt>} {<Dd>,} <Dn>, <Dm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VORR instruction must be
unconditional. ARM strongly recommends that a Thumb VORR instruction is unconditional,
Operation
for r = 0 to regs-1
D[d+r] = D[n+r] OR D[m+r];
Exceptions
A8.8.362 VPADAL
Vector Pairwise Add and Accumulate Long adds adjacent pairs of elements of a vector, and accumulates the results
into the elements of the destination vector.
The vectors can be doubleword or quadword. The operand elements can be 8-bit, 16-bit, or 32-bit integers. The
result elements are twice the length of the operand elements.
Figure A8-2 shows an example of the operation of VPADAL.
Dm
+ +
Dd
Figure A8-2 VPADAL doubleword operation for data type S16


VPADAL<c>.<dt> <Qd>, <Qm>
VPADAL<c>.<dt> <Dd>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 size 0 0 Vd 0 1 1 0 op Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 size 0 0 Vd 0 1 1 0 op Q M 0 Vm

unsigned = (op == ‘1’);
Assembler syntax
VPADAL{<c>}{<q>}.<dt> <Qd>, <Qm> Encoded as Q = 1
VPADAL{<c>}{<q>}.<dt> <Dd>, <Dm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VPADAL instruction must be
unconditional. ARM strongly recommends that a Thumb VPADAL instruction is unconditional, see
S8 Encoded as size = 0b00, op = 0.
U8 Encoded as size = 0b00, op = 1.
Operation
h = elements DIV 2;
for r = 0 to regs-1
for e = 0 to h-1
op1 = Elem[D[m+r],2*e,esize]; op2 = Elem[D[m+r],2*e+1,esize];
result = Int(op1, unsigned) + Int(op2, unsigned);
Elem[D[d+r],e,2*esize] = Elem[D[d+r],e,2*esize] + result;
Exceptions
A8.8.363 VPADD (integer)

Vector Pairwise Add (integer) adds adjacent pairs of elements of two vectors, and places the results in the destination
vector.
The operands and result are doubleword vectors.
The operand and result elements must all be the same type, and can be 8-bit, 16-bit, or 32-bit integers. There is no
distinction between signed and unsigned integers.
Figure A8-3 shows an example of the operation of VPADD.
Dm Dn
+ + + +
Dd
Figure A8-3 VPADD operation for data type I16


VPADD<c>.<dt> <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 1 0 D size Vn Vd 1 0 1 1 N Q M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 0 0 D size Vn Vd 1 0 1 1 N Q M 1 Vm
if size == ‘11’ || Q == ‘1’ then UNDEFINED;

Assembler syntax
VPADD{<c>}{<q>}.<dt> {<Dd>,} <Dn>, <Dm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VPADD instruction must be
unconditional. ARM strongly recommends that a Thumb VPADD instruction is unconditional,
I8 Encoding T1/A1, encoded as size = 0b00.
<Dd>, <Dn>, <Dm> The destination vector, the first operand vector, and the second operand vector.
Operation
bits(64) dest;
h = elements DIV 2;
for e = 0 to h-1
Elem[dest,e,esize] = Elem[D[n],2*e,esize] + Elem[D[n],2*e+1,esize];
Elem[dest,e+h,esize] = Elem[D[m],2*e,esize] + Elem[D[m],2*e+1,esize];
D[d] = dest;
Exceptions
A8.8.364 VPADD (floating-point)

Vector Pairwise Add (floating-point) adds adjacent pairs of elements of two vectors, and places the results in the
destination vector.
The operands and result are doubleword vectors.
The operand and result elements are 32-bit floating-point numbers.
Figure A8-3 on page A8-981 shows an example of the operation of VPADD.


VPADD<c>.F32 <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 0 D 0 sz Vn Vd 1 1 0 1 N Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 0 D 0 sz Vn Vd 1 1 0 1 N Q M 0 Vm
if sz == ‘1’ || Q == ‘1’ then UNDEFINED;

Assembler syntax
VPADD{<c>}{<q>}.F32 {<Dd>,} <Dn>, <Dm> Encoded as Q = 0, sz = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VPADD instruction must be
unconditional. ARM strongly recommends that a Thumb VPADD instruction is unconditional,
<Dd>, <Dn>, <Dm> The destination vector, the first operand vector, and the second operand vector.
Operation
bits(64) dest;
h = elements DIV 2;
for e = 0 to h-1
Elem[dest,e,esize] = FPAdd(Elem[D[n],2*e,esize], Elem[D[n],2*e+1,esize], FALSE);
Elem[dest,e+h,esize] = FPAdd(Elem[D[m],2*e,esize], Elem[D[m],2*e+1,esize], FALSE);
D[d] = dest;
Exceptions
A8.8.365 VPADDL
Vector Pairwise Add Long adds adjacent pairs of elements of two vectors, and places the results in the destination
vector.
The vectors can be doubleword or quadword. The operand elements can be 8-bit, 16-bit, or 32-bit integers. The
result elements are twice the length of the operand elements.
Figure A8-4 shows an example of the operation of VPADDL.
Dm
+ +
Dd
Figure A8-4 VPADDL doubleword operation for data type S16


VPADDL<c>.<dt> <Qd>, <Qm>
VPADDL<c>.<dt> <Dd>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 size 0 0 Vd 0 0 1 0 op Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 size 0 0 Vd 0 0 1 0 op Q M 0 Vm

unsigned = (op == ‘1’);
Assembler syntax
VPADDL{<c>}{<q>}.<dt> <Qd>, <Qm> Encoded as Q = 1
VPADDL{<c>}{<q>}.<dt> <Dd>, <Dm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VPADDL instruction must be
unconditional. ARM strongly recommends that a Thumb VPADDL instruction is unconditional, see
Operation
h = elements DIV 2;
for r = 0 to regs-1
for e = 0 to h-1
op1 = Elem[D[m+r],2*e,esize]; op2 = Elem[D[m+r],2*e+1,esize];
result = Int(op1, unsigned) + Int(op2, unsigned);
Elem[D[d+r],e,2*esize] = result<2*esize-1:0>;
Exceptions
A8.8.366 VPMAX, VPMIN (integer)

Vector Pairwise Maximum compares adjacent pairs of elements in two doubleword vectors, and copies the larger
of each pair into the corresponding element in the destination doubleword vector.
Vector Pairwise Minimum compares adjacent pairs of elements in two doubleword vectors, and copies the smaller
Figure A8-5 shows an example of the operation of VPMAX.
Dm Dn
max max max max
Dd
Figure A8-5 VPMAX operation for data type S16 or U16


VP<op><c>.<dt> <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 U 1 1 1 1 0 D size Vn Vd 1 0 1 0 N Q M op Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 U 0 D size Vn Vd 1 0 1 0 N Q M op Vm
if size == ‘11’ || Q == ‘1’ then UNDEFINED;

maximum = (op == ‘0’); unsigned = (U == ‘1’);
Assembler syntax
VP<op>{<c>}{<q>}.<dt> {<Dd>,} <Dn>, <Dm> Encoded as Q = 0
where:

<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VPMAX or VPMIN instruction
must be unconditional. ARM strongly recommends that a Thumb VPMAX or VPMIN instruction
<Dd>, <Dn>, <Dm> The destination vector and the operand vectors.
Operation
bits(64) dest;
h = elements DIV 2;
for e = 0 to h-1
op1 = Int(Elem[D[n],2*e,esize], unsigned);
op2 = Int(Elem[D[n],2*e+1,esize], unsigned);
Elem[dest,e,esize] = result<esize-1:0>;
op1 = Int(Elem[D[m],2*e,esize], unsigned);
op2 = Int(Elem[D[m],2*e+1,esize], unsigned);
Elem[dest,e+h,esize] = result<esize-1:0>;
D[d] = dest;
Exceptions
A8.8.367 VPMAX, VPMIN (floating-point)

Vector Pairwise Maximum compares adjacent pairs of elements in two doubleword vectors, and copies the larger
Vector Pairwise Minimum compares adjacent pairs of elements in two doubleword vectors, and copies the smaller
Figure A8-5 on page A8-987 shows an example of the operation of VPMAX.


VP<op><c>.F32 <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 0 D op sz Vn Vd 1 1 1 1 N Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 0 D op sz Vn Vd 1 1 1 1 N Q M 0 Vm
if sz == ‘1’ || Q == ‘1’ then UNDEFINED;

maximum = (op == ‘0’); esize = 32; elements = 2;
Assembler syntax
VP<op>{<c>}{<q>}.F32 {<Dd>,} <Dn>, <Dm> Encoded as Q = 0, sz = 0
where:

<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VPMAX or VPMIN instruction
must be unconditional. ARM strongly recommends that a Thumb VPMAX or VPMIN instruction
<Dd>, <Dn>, <Dm> The destination vector and the operand vectors.
Operation
bits(64) dest;
h = elements DIV 2;
for e = 0 to h-1
op1 = Elem[D[n],2*e,esize]; op2 = Elem[D[n],2*e+1,esize];
Elem[dest,e,esize] = if maximum then FPMax(op1,op2,FALSE) else FPMin(op1,op2,FALSE);
op1 = Elem[D[m],2*e,esize]; op2 = Elem[D[m],2*e+1,esize];
Elem[dest,e+h,esize] = if maximum then FPMax(op1,op2,FALSE) else FPMin(op1,op2,FALSE);
D[d] = dest;
Exceptions
A8.8.368 VPOP
Vector Pop loads multiple consecutive extension registers from the stack.

VPOP <list> <list> is consecutive 64-bit registers
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 0 0 1 D 1 1 1 1 0 1 Vd 1 0 1 1 imm8
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 0 0 1 D 1 1 1 1 0 1 Vd 1 0 1 1 imm8
single_regs = FALSE; d = UInt(D:Vd); imm32 = ZeroExtend(imm8:’00’, 32);

regs = UInt(imm8) DIV 2; // If UInt(imm8) is odd, see “FLDMX”.

VPOP <list> <list> is consecutive 32-bit registers
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 0 0 1 D 1 1 1 1 0 1 Vd 1 0 1 0 imm8
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 0 0 1 D 1 1 1 1 0 1 Vd 1 0 1 0 imm8
single_regs = TRUE; d = UInt(Vd:D); imm32 = ZeroExtend(imm8:’00’, 32);

regs = UInt(imm8);
FLDMX Encoding T1/A1 behaves as described by the pseudocode if imm8 is odd. However,
Assembler syntax
VPOP{<c>}{<q>}{.<size>} <list>
where:
in <list>.
<list> The extension registers to be loaded, as a list of consecutively numbered doubleword (encoding
in the list (encoding T2/A2). <list> must contain at least one register, and not more than sixteen.
Operation
EncodingSpecificOperations(); CheckVFPEnabled(TRUE); NullCheckIfThumbEE(13);
address = SP;
SP = SP + imm32;
if single_regs then
for r = 0 to regs-1
S[d+r] = MemA[address,4]; address = address+4;
else
for r = 0 to regs-1
word1 = MemA[address,4]; word2 = MemA[address+4,4]; address = address+8;
D[d+r] = if BigEndian() then word1:word2 else word2:word1;
Exceptions
A8.8.369 VPUSH
Vector Push stores multiple consecutive extension registers to the stack.

VPUSH<c> <list> <list> is consecutive 64-bit registers
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 0 1 0 D 1 0 1 1 0 1 Vd 1 0 1 1 imm8
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 0 1 0 D 1 0 1 1 0 1 Vd 1 0 1 1 imm8
single_regs = FALSE; d = UInt(D:Vd); imm32 = ZeroExtend(imm8:’00’, 32);

regs = UInt(imm8) DIV 2; // If UInt(imm8) is odd, see “FSTMX”.

VPUSH<c> <list> <list> is consecutive 32-bit registers
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 0 1 0 D 1 0 1 1 0 1 Vd 1 0 1 0 imm8
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 0 1 0 D 1 0 1 1 0 1 Vd 1 0 1 0 imm8
single_regs = TRUE; d = UInt(Vd:D);

FSTMX Encoding T1/A1 behaves as described by the pseudocode if imm8 is odd. However,
Assembler syntax
VPUSH{<c>}{<q>}{.<size>} <list>
where:
in <list>.
<list> The extension registers to be stored, as a list of consecutively numbered doubleword (encoding
and imm8 to twice the number of registers in the list (encoding T1/A1), or the number of registers
in the list (encoding T2/A2). <list> must contain at least one register, and not more than sixteen.
Operation
EncodingSpecificOperations(); CheckVFPEnabled(TRUE); NullCheckIfThumbEE(13);
address = SP - imm32;
SP = SP - imm32;
if single_regs then
for r = 0 to regs-1
MemA[address,4] = S[d+r]; address = address+4;
else
for r = 0 to regs-1
// Store as two word-aligned words in the correct order for current endianness.
MemA[address,4] = if BigEndian() then D[d+r]<63:32> else D[d+r]<31:0>;
MemA[address+4,4] = if BigEndian() then D[d+r]<31:0> else D[d+r]<63:32>;
address = address+8;
Exceptions
A8.8.370 VQABS
Vector Saturating Absolute takes the absolute value of each element in a vector, and places the results in the
destination vector.
If any of the results overflow, they are saturated. The cumulative saturation bit, FPSCR.QC, is set if saturation
occurs. For details see Pseudocode details of saturation on page A2-44.

VQABS<c>.<dt> <Qd>, <Qm>
VQABS<c>.<dt> <Dd>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 size 0 0 Vd 0 1 1 1 0 Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 size 0 0 Vd 0 1 1 1 0 Q M 0 Vm

Assembler syntax
VQABS{<c>}{<q>}.<dt> <Qd>, <Qm> Encoded as Q = 1
VQABS{<c>}{<q>}.<dt> <Dd>, <Dm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VQABS instruction must be
unconditional. ARM strongly recommends that a Thumb VQABS instruction is unconditional, see
S8 Encoded as size = 0b00.
Operation
for r = 0 to regs-1
result = Abs(SInt(Elem[D[m+r],e,esize]));
(Elem[D[d+r],e,esize], sat) = SignedSatQ(result, esize);
if sat then FPSCR.QC = ‘1’;
Exceptions
A8.8.371 VQADD
Vector Saturating Add adds the values of corresponding elements of two vectors, and places the results in the
destination vector.

VQADD<c>.<dt> <Qd>, <Qn>, <Qm>
VQADD<c>.<dt> <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Assembler syntax
VQADD{<c>}{<q>}.<type><size> {<Qd>,} <Qn>, <Qm> Encoded as Q = 1

VQADD{<c>}{<q>}.<type><size> {<Dd>,} <Dn>, <Dm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VQADD instruction must be
unconditional. ARM strongly recommends that a Thumb VQADD instruction is unconditional,
<type> The data type for the elements of the vectors. It must be one of:
S Signed, encoded as U = 0.
U Unsigned, encoded as U = 1.
<size> The data size for the elements of the vectors. It must be one of:
Operation
for r = 0 to regs-1
sum = Int(Elem[D[n+r],e,esize], unsigned) + Int(Elem[D[m+r],e,esize], unsigned);
(Elem[D[d+r],e,esize], sat) = SatQ(sum, esize, unsigned);
Exceptions
A8.8.372 VQDMLAL, VQDMLSL

Vector Saturating Doubling Multiply Accumulate Long multiplies corresponding elements in two doubleword
vectors, doubles the products, and accumulates the results into the elements of a quadword vector.
Vector Saturating Doubling Multiply Subtract Long multiplies corresponding elements in two doubleword vectors,
subtracts double the products from corresponding elements of a quadword vector, and places the results in the same
quadword vector.
In both instructions, the second operand can be a scalar instead of a vector. For more information about scalars see
Advanced SIMD scalars on page A7-257.

VQD<op><c>.<dt> <Qd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 1 1 D size Vn Vd 1 0 op 1 N 0 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 0 1 D size Vn Vd 1 0 op 1 N 0 M 0 Vm

add = (op == ‘0’);
scalar_form = FALSE; d = UInt(D:Vd); n = UInt(N:Vn); m = UInt(M:Vm);

VQD<op><c>.<dt> <Qd>, <Dn>, <Dm[x]>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 1 1 D size Vn Vd 0 op 1 1 N 1 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 0 1 D size Vn Vd 0 op 1 1 N 1 M 0 Vm

add = (op == ‘0’);
scalar_form = TRUE; d = UInt(D:Vd); n = UInt(N:Vn);
Assembler syntax
VQD<op>{<c>}{<q>}.<dt> <Qd>, <Dn>, <Dm>

VQD<op>{<c>}{<q>}.<dt> <Qd>, <Dn>, <Dm[x]>
where:

MLAL Encoded as op = 0.
MLSL Encoded as op = 1.
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VQDMLAL or VQDMLSL instruction must
be unconditional. ARM strongly recommends that a Thumb VQDMLAL or VQDMLSL instruction is
<Qd>, <Dn> The destination vector and the first operand vector.
<Dm> The second operand vector, for an all vector operation.
<Dm[x]> The scalar for a scalar operation. If <dt> is S16, Dm is restricted to D0-D7. If <dt> is S32, Dm is restricted
to D0-D15.
Operation
if scalar_form then op2 = SInt(Elem[Din[m],index,esize]);
if !scalar_form then op2 = SInt(Elem[Din[m],e,esize]);
op1 = SInt(Elem[Din[n],e,esize]);
// The following only saturates if both op1 and op2 equal -(2^(esize-1))
(product, sat1) = SignedSatQ(2*op1*op2, 2*esize);
if add then
result = SInt(Elem[Qin[d>>1],e,2*esize]) + SInt(product);
else
result = SInt(Elem[Qin[d>>1],e,2*esize]) - SInt(product);
(Elem[Q[d>>1],e,2*esize], sat2) = SignedSatQ(result, 2*esize);
if sat1 || sat2 then FPSCR.QC = ‘1’;
Exceptions
A8.8.373 VQDMULH
Vector Saturating Doubling Multiply Returning High Half multiplies corresponding elements in two vectors,
doubles the results, and places the most significant half of the final results in the destination vector. The results are
truncated (for rounded results see VQRDMULH on page A8-1009).
The second operand can be a scalar instead of a vector. For more information about scalars see Advanced SIMD
scalars on page A7-257.

VQDMULH<c>.<dt> <Qd>, <Qn>, <Qm>
VQDMULH<c>.<dt> <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 1 0 D size Vn Vd 1 0 1 1 N Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 0 0 D size Vn Vd 1 0 1 1 N Q M 0 Vm
if size == ‘00’ || size == ‘11’ then UNDEFINED;
scalar_form = FALSE; esize = 8 << UInt(size); elements = 64 DIV esize;

VQDMULH<c>.<dt> <Qd>, <Qn>, <Dm[x]>
VQDMULH<c>.<dt> <Dd>, <Dn>, <Dm[x]>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 Q 1 1 1 1 1 D size Vn Vd 1 1 0 0 N 1 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 Q 1 D size Vn Vd 1 1 0 0 N 1 M 0 Vm

scalar_form = TRUE; d = UInt(D:Vd); n = UInt(N:Vn); regs = if Q == ‘0’ then 1 else 2;
Assembler syntax
VQDMULH{<c>}{<q>}.<dt> {<Qd>,} <Qn>, <Qm> Encoding T1/A1, encoded as Q = 1

VQDMULH{<c>}{<q>}.<dt> {<Dd>,} <Dn>, <Dm> Encoding T1/A1, encoded as Q = 0
VQDMULH{<c>}{<q>}.<dt> {<Qd>,} <Qn>, <Dm[x]> Encoding T2/A2, encoded as Q = 1
VQDMULH{<c>}{<q>}.<dt> {<Dd>,} <Dn>, <Dm[x]> Encoding T2/A2, encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VQDMULH instruction must
be unconditional. ARM strongly recommends that a Thumb VQDMULH instruction is
<Qd>, <Qn> The destination vector and the first operand vector, for a quadword operation.
<Dd>, <Dn> The destination vector and the first operand vector, for a doubleword operation.
<Qm> The second operand vector, for a quadword all vector operation.
<Dm> The second operand vector, for a doubleword all vector operation.
<Dm[x]> The scalar for either a quadword or a doubleword scalar operation. If <dt> is S16, Dm is
restricted to D0-D7. If <dt> is S32, Dm is restricted to D0-D15.
Operation
if scalar_form then op2 = SInt(Elem[D[m],index,esize]);
for r = 0 to regs-1
if !scalar_form then op2 = SInt(Elem[D[m+r],e,esize]);
op1 = SInt(Elem[D[n+r],e,esize]);
(result, sat) = SignedSatQ((2*op1*op2) >> esize, esize);
Exceptions
A8.8.374 VQDMULL
Vector Saturating Doubling Multiply Long multiplies corresponding elements in two doubleword vectors, doubles
the products, and places the results in a quadword vector.

VQDMULL<c>.<dt> <Qd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 1 1 D size Vn Vd 1 1 0 1 N 0 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 0 1 D size Vn Vd 1 1 0 1 N 0 M 0 Vm

scalar_form = FALSE; d = UInt(D:Vd); n = UInt(N:Vn); m = UInt(M:Vm);

VQDMULL<c>.<dt> <Qd>, <Dn>, <Dm[x]>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 1 1 D size Vn Vd 1 0 1 1 N 1 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 0 1 D size Vn Vd 1 0 1 1 N 1 M 0 Vm

scalar_form = TRUE; d = UInt(D:Vd); n = UInt(N:Vn);
Assembler syntax
VQDMULL{<c>}{<q>}.<dt> <Qd>, <Dn>, <Dm>

VQDMULL{<c>}{<q>}.<dt> <Qd>, <Dn>, <Dm[x]>
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VQDMULL instruction must be
unconditional. ARM strongly recommends that a Thumb VQDMULL instruction is unconditional, see
<Qd>, <Dn> The destination vector and the first operand vector.
<Dm> The second operand vector, for an all vector operation.
<Dm[x]> The scalar for a scalar operation. If <dt> is S16, Dm is restricted to D0-D7. If <dt> is S32, Dm is restricted
to D0-D15.
Operation
if scalar_form then op2 = SInt(Elem[Din[m],index,esize]);
if !scalar_form then op2 = SInt(Elem[Din[m],e,esize]);
op1 = SInt(Elem[Din[n],e,esize]);
(product, sat) = SignedSatQ(2*op1*op2, 2*esize);
Elem[Q[d>>1],e,2*esize] = product;
Exceptions
A8.8.375 VQMOVN, VQMOVUN

Vector Saturating Move and Narrow copies each element of the operand vector to the corresponding element of the
destination vector.
The operand is a quadword vector. The elements can be any one of:
The result is a doubleword vector. The elements are half the length of the operand vector elements. If the operand
is unsigned, the results are unsigned. If the operand is signed, the results can be signed or unsigned.

VQMOV{U}N<c>.<type><size> <Dd>, <Qm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 size 1 0 Vd 0 0 1 0 op M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 size 1 0 Vd 0 0 1 0 op M 0 Vm
if op == ‘00’ then SEE VMOVN;

if size == ‘11’ || Vm<0> == ‘1’ then UNDEFINED;
src_unsigned = (op == ‘11’); dest_unsigned = (op<0> == ‘1’);
Assembler syntax
VQMOV{U}N{<c>}{<q>}.<type><size> <Dd>, <Qm>
where:
U If present, specifies that the operation produces unsigned results, even though the operands are
signed. Encoded as op = 0b01.
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VQMOVN or VQMOVUN instruction must
be unconditional. ARM strongly recommends that a Thumb VQMOVN or VQMOVUN instruction is
<type> The data type for the elements of the operand. It must be one of:
S Encoded as:
• op = 0b10 for VQMOVN.
• op = 0b01 for VQMOVUN.
U Encoded as op = 0b11. Not available for VQMOVUN.
<size> The data size for the elements of the operand. It must be one of:
Operation
operand = Int(Elem[Qin[m>>1],e,2*esize], src_unsigned);
(Elem[D[d],e,esize], sat) = SatQ(operand, esize, dest_unsigned);
Exceptions
A8.8.376 VQNEG
Vector Saturating Negate negates each element in a vector, and places the results in the destination vector.

VQNEG<c>.<dt> <Qd>, <Qm>
VQNEG<c>.<dt> <Dd>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 size 0 0 Vd 0 1 1 1 1 Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 size 0 0 Vd 0 1 1 1 1 Q M 0 Vm

Assembler syntax
VQNEG{<c>}{<q>}.<dt> <Qd>, <Qm> Encoded as Q = 1

VQNEG{<c>}{<q>}.<dt> <Dd>, <Dm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VQNEG instruction must be
unconditional. ARM strongly recommends that a Thumb VQNEG instruction is unconditional, see
Operation
for r = 0 to regs-1
result = -SInt(Elem[D[m+r],e,esize]);
(Elem[D[d+r],e,esize], sat) = SignedSatQ(result, esize);
Exceptions
A8.8.377 VQRDMULH
Vector Saturating Rounding Doubling Multiply Returning High Half multiplies corresponding elements in two
vectors, doubles the results, and places the most significant half of the final results in the destination vector. The
results are rounded (for truncated results see VQDMULH on page A8-1001).

VQRDMULH<c>.<dt> <Qd>, <Qn>, <Qm>
VQRDMULH<c>.<dt> <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 0 D size Vn Vd 1 0 1 1 N Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 0 D size Vn Vd 1 0 1 1 N Q M 0 Vm
if size == ‘00’ || size == ‘11’ then UNDEFINED;
scalar_form = FALSE; esize = 8 << UInt(size); elements = 64 DIV esize;

VQRDMULH<c>.<dt> <Qd>, <Qn>, <Dm[x]>
VQRDMULH<c>.<dt> <Dd>, <Dn>, <Dm[x]>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 Q 1 1 1 1 1 D size Vn Vd 1 1 0 1 N 1 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 Q 1 D size Vn Vd 1 1 0 1 N 1 M 0 Vm

scalar_form = TRUE; d = UInt(D:Vd); n = UInt(N:Vn); regs = if Q == ‘0’ then 1 else 2;
Assembler syntax
VQRDMULH{<c>}{<q>}.<dt> {<Qd>,} <Qn>, <Qm> Encoding T1/A1, encoded as Q = 1

VQRDMULH{<c>}{<q>}.<dt> {<Dd>,} <Dn>, <Dm> Encoding T1/A1, encoded as Q = 0
VQRDMULH{<c>}{<q>}.<dt> {<Qd>,} <Qn>, <Dm[x]> Encoding T2/A2, encoded as Q = 1
VQRDMULH{<c>}{<q>}.<dt> {<Dd>,} <Dn>, <Dm[x]> Encoding T2/A2, encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VQRDMULH instruction must
be unconditional. ARM strongly recommends that a Thumb VQRDMULH instruction is
<Qd>, <Qn> The destination vector and the first operand vector, for a quadword operation.
<Dd>, <Dn> The destination vector and the first operand vector, for a doubleword operation.
<Qm> The second operand vector, for a quadword all vector operation.
<Dm> The second operand vector, for a doubleword all vector operation.
<Dm[x]> The scalar for either a quadword or a doubleword scalar operation. If <dt> is S16, Dm is
restricted to D0-D7. If <dt> is S32, Dm is restricted to D0-D15.
Operation
round_const = 1 << (esize-1);
if scalar_form then op2 = SInt(Elem[D[m],index,esize]);
for r = 0 to regs-1
op1 = SInt(Elem[D[n+r],e,esize]);
if !scalar_form then op2 = SInt(Elem[D[m+r],e,esize]);
(result, sat) = SignedSatQ((2*op1*op2 + round_const) >> esize, esize);
Exceptions
A8.8.378 VQRSHL
Vector Saturating Rounding Shift Left takes each element in a vector, shifts them by a value from the least
significant byte of the corresponding element of a second vector, and places the results in the destination vector. If
the shift value is positive, the operation is a left shift. Otherwise, it is a right shift.
For truncated results see VQSHL (register) on page A8-1015.
The first operand and result elements are the same data type, and can be any one of:
• 8-bit, 16-bit, 32-bit, or 64-bit signed integers
• 8-bit, 16-bit, 32-bit, or 64-bit unsigned integers.
The second operand is a signed integer of the same size.

VQRSHL<c>.<type><size> <Qd>, <Qm>, <Qn>
VQRSHL<c>.<type><size> <Dd>, <Dm>, <Dn>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if Q == ‘1’ && (Vd<0> == ‘1’ || Vm<0> == ‘1’ || Vn<0> == ‘1’) then UNDEFINED;
d = UInt(D:Vd); m = UInt(M:Vm); n = UInt(N:Vn); regs = if Q == ‘0’ then 1 else 2;
Assembler syntax
VQRSHL{<c>}{<q>}.<type><size> {<Qd>,} <Qm>, <Qn> Encoded as Q = 1

VQRSHL{<c>}{<q>}.<type><size> {<Dd>,} <Dm>, <Dn> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VQRSHL instruction must be
unconditional. ARM strongly recommends that a Thumb VQRSHL instruction is
Together with the <size> field, this indicates the data type and size of the first operand and
the result.
<Qd>, <Qm>, <Qn> The destination vector and the operand vectors, for a quadword operation.
<Dd>, <Dm>, <Dn> The destination vector and the operand vectors, for a doubleword operation.
Operation
for r = 0 to regs-1
shift = SInt(Elem[D[n+r],e,esize]<7:0>);
round_const = 1 << (-1-shift); // 0 for left shift, 2^(n-1) for right shift
operand = Int(Elem[D[m+r],e,esize], unsigned);
(result, sat) = SatQ((operand + round_const) << shift, esize, unsigned);
Exceptions
A8.8.379 VQRSHRN, VQRSHRUN

Vector Saturating Rounding Shift Right, Narrow takes each element in a quadword vector of integers, right shifts
them by an immediate value, and places the rounded results in a doubleword vector.
For truncated results, see VQSHRN, VQSHRUN on page A8-1019.
The operand elements must all be the same size, and can be any one of:
The result elements are half the width of the operand elements. If the operand elements are signed, the results can
be either signed or unsigned. If the operand elements are unsigned, the result elements must also be unsigned.

VQRSHR{U}N<c>.<type><size> <Dd>, <Qm>, #<imm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 U 1 1 1 1 1 D imm6 Vd 1 0 0 op 0 1 M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 U 1 D imm6 Vd 1 0 0 op 0 1 M 1 Vm

if U == ‘0’ && op == ‘0’ then SEE VRSHRN;
case imm6 of
when “001xxx” esize = 8; elements = 8; shift_amount = 16 - UInt(imm6);
when “01xxxx” esize = 16; elements = 4; shift_amount = 32 - UInt(imm6);
when “1xxxxx” esize = 32; elements = 2; shift_amount = 64 - UInt(imm6);
src_unsigned = (U == ‘1’ && op == ‘1’); dest_unsigned = (U == ‘1’);
Assembler syntax
VQRSHR{U}N{<c>}{<q>}.<type><size> <Dd>, <Qm>, #<imm>
where:
U If present, specifies that the results are unsigned, although the operands are signed.
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VQRSHRN or VQRSHRUN instruction
must be unconditional. ARM strongly recommends that a Thumb VQRSHRN or VQRSHRUN instruction is
S Signed. Encoded as:
• U = 0, op = 1, for VQRSHRN.
• U = 1, op = 0, for VQRSHRUN.
U Unsigned:
• Encoded as U = 1, op = 1, for VQRSHRN.
• Not available for VQRSHRUN.
16 Encoded as imm6<5:3> = 0b001. (8 – <imm>) is encoded in imm6<2:0>.
64 Encoded as imm6<5> = 0b1. (32 – <imm>) is encoded in imm6<4:0>.
<imm> The immediate value, in the range 1 to <size>/2. See the description of <size> for how <imm> is
encoded.
Operation
round_const = 1 << (shift_amount - 1);
(result, sat) = SatQ((operand + round_const) >> shift_amount, esize, dest_unsigned);
Elem[D[d],e,esize] = result;
Exceptions
Pseudo-instructions
VQRSHRN.I<size> <Dd>, <Qm>, #0 is a synonym for VQMOVN.I<size> <Dd>, <Qm>

VQRSHRUN.I<size> <Dd>, <Qm>, #0 is a synonym for VQMOVUN.I<size> <Dd>, <Qm>
A8.8.380 VQSHL (register)

Vector Saturating Shift Left (register) takes each element in a vector, shifts them by a value from the least significant
byte of the corresponding element of a second vector, and places the results in the destination vector. If the shift
value is positive, the operation is a left shift. Otherwise, it is a right shift.
The results are truncated. For rounded results, see VQRSHL on page A8-1011.
The second operand is a signed integer of the same size.

VQSHL<c>.<type><size> <Qd>, <Qm>, <Qn>
VQSHL<c>.<type><size> <Dd>, <Dm>, <Dn>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Assembler syntax
VQSHL{<c>}{<q>}.<type><size> {<Qd>,} <Qm>, <Qn> Encoded as Q = 1

VQSHL{<c>}{<q>}.<type><size> {<Dd>,} <Dm>, <Dn> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VQSHL instruction must be
unconditional. ARM strongly recommends that a Thumb VQSHL instruction is unconditional,
the result.
Operation
for r = 0 to regs-1
operand = Int(Elem[D[m+r],e,esize], unsigned);
(result,sat) = SatQ(operand << shift, esize, unsigned);
Exceptions
A8.8.381 VQSHL, VQSHLU (immediate)

Vector Saturating Shift Left (immediate) takes each element in a vector of integers, left shifts them by an immediate
value, and places the results in a second vector.
The result elements are the same size as the operand elements. If the operand elements are signed, the results can

VQSHL{U}<c>.<type><size> <Qd>, <Qm>, #<imm>
VQSHL{U}<c>.<type><size> <Dd>, <Dm>, #<imm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 U 1 1 1 1 1 D imm6 Vd 0 1 1 op L Q M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 U 1 D imm6 Vd 0 1 1 op L Q M 1 Vm
if (L:imm6) IN “0000xxx” then SEE “Related encodings”;

if U == ‘0’ && op == ‘0’ then UNDEFINED;
case L:imm6 of
when “0001xxx” esize = 8; elements = 8; shift_amount = UInt(imm6) - 8;
when “001xxxx” esize = 16; elements = 4; shift_amount = UInt(imm6) - 16;
when “01xxxxx” esize = 32; elements = 2; shift_amount = UInt(imm6) - 32;
when “1xxxxxx” esize = 64; elements = 1; shift_amount = UInt(imm6);
Assembler syntax
VQSHL{U}{<c>}{<q>}.<type><size> {<Qd>,} <Qm>, #<imm> Encoded as Q = 1

VQSHL{U}{<c>}{<q>}.<type><size> {<Dd>,} <Dm>, #<imm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VQSHL or VQSHLU instruction must be
unconditional. ARM strongly recommends that a Thumb VQSHL or VQSHLU instruction is
• U = 0, op = 1, for VQSHL.
• U = 1, op = 0, for VQSHLU.
U Unsigned:
• Encoded as U = 1, op = 1, for VQSHL.
• Not available for VQSHLU.
8 Encoded as L = 0, imm6<5:3> = 0b001. <imm> is encoded in imm6<2:0>.
32 Encoded as L = 0, imm6<5> = 0b1. <imm> is encoded in imm6<4:0>.
64 Encoded as L = 1. <imm> is encoded in imm6<5:0>.
<Qd>, <Qm> The destination vector, and the operand vector, for a quadword operation.
<Dd>, <Dm> The destination vector, and the operand vector, for a doubleword operation.
<imm> The immediate value, in the range 0 to <size>-1. See the description of <size> for how <imm> is
encoded.
Operation
for r = 0 to regs-1
operand = Int(Elem[D[m+r],e,esize], src_unsigned);
(result, sat) = SatQ(operand << shift_amount, esize, dest_unsigned);
Exceptions
A8.8.382 VQSHRN, VQSHRUN

Vector Saturating Shift Right, Narrow takes each element in a quadword vector of integers, right shifts them by an
immediate value, and places the truncated results in a doubleword vector.
For rounded results, see VQRSHRN, VQRSHRUN on page A8-1013.
The result elements are half the width of the operand elements. If the operand elements are signed, the results can

VQSHR{U}N<c>.<type><size> <Dd>, <Qm>, #<imm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 U 1 1 1 1 1 D imm6 Vd 1 0 0 op 0 0 M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 U 1 D imm6 Vd 1 0 0 op 0 0 M 1 Vm

if U == ‘0’ && op == ‘0’ then SEE VSHRN;
case imm6 of
Assembler syntax
VQSHR{U}N{<c>}{<q>}.<type><size> <Dd>, <Qm>, #<imm>
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VQSHRN or VQSHRUN instruction must
be unconditional. ARM strongly recommends that a Thumb VQSHRN or VQSHRUN instruction is
• U = 0, op = 1, for VQSHRN.
• U = 1, op = 0, for VQSHRUN.
U Unsigned:
• Encoded as U = 1, op = 1, for VQSHRN.
• Not available for VQSHRUN.
<Dd>, <Qm> The destination vector, and the operand vector.
encoded.
Operation
(result, sat) = SatQ(operand >> shift_amount, esize, dest_unsigned);
Elem[D[d],e,esize] = result;
Exceptions
Pseudo-instructions
VQSHRN.I<size> <Dd>, <Qm>, #0 is a synonym for VQMOVN.I<size> <Dd>, <Qm>

VQSHRUN.I<size> <Dd>, <Qm>, #0 is a synonym for VQMOVUN.I<size> <Dd>, <Qm>
A8.8.383 VQSUB
Vector Saturating Subtract subtracts the elements of the second operand vector from the corresponding elements of
the first operand vector, and places the results in the destination vector. Signed and unsigned operations are distinct.
The operand and result elements must all be the same type, and can be any one of:

VQSUB<c>.<type><size> <Qd>, <Qn>, <Qm>
VQSUB<c>.<type><size> <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Assembler syntax
VQSUB{<c>}{<q>}.<type><size> {<Qd>,} <Qn>, <Qm> Encoded as Q = 1

VQSUB{<c>}{<q>}.<type><size> {<Dd>,} <Dn>, <Dm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VQSUB instruction must be
unconditional. ARM strongly recommends that a Thumb VQSUB instruction is unconditional,
Operation
for r = 0 to regs-1
diff = Int(Elem[D[n+r],e,esize], unsigned) - Int(Elem[D[m+r],e,esize], unsigned);
(Elem[D[d+r],e,esize], sat) = SatQ(diff, esize, unsigned);
Exceptions
A8.8.384 VRADDHN
Vector Rounding Add and Narrow, returning High Half adds corresponding elements in two quadword vectors, and
places the most significant half of each result in a doubleword vector. The results are rounded. (For truncated results,
see VADDHN on page A8-833.)
integers.

VRADDHN<c>.<dt> <Dd>, <Qn>, <Qm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D size Vn Vd 0 1 0 0 N 0 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D size Vn Vd 0 1 0 0 N 0 M 0 Vm

Assembler syntax
VRADDHN{<c>}{<q>}.<dt> <Dd>, <Qn>, <Qm>
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VRADDHN instruction must
be unconditional. ARM strongly recommends that a Thumb VRADDHN instruction is
<Dd>, <Qn>, <Qm> The destination vector and the operand vectors.
Operation
result = Elem[Qin[n>>1],e,2*esize] + Elem[Qin[m>>1],e,2*esize] + round_const;
Exceptions
A8.8.385 VRECPE
Vector Reciprocal Estimate finds an approximate reciprocal of each element in the operand vector, and places the
results in the destination vector.
The operand and result elements are the same type, and can be 32-bit floating-point numbers, or 32-bit unsigned
integers.
For details of the operation performed by this instruction see Floating-point reciprocal estimate and step on
page A2-84.

VRECPE<c>.<dt> <Qd>, <Qm>
VRECPE<c>.<dt> <Dd>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 size 1 1 Vd 0 1 0 F 0 Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 size 1 1 Vd 0 1 0 F 0 Q M 0 Vm

floating_point = (F == ‘1’); esize = 32; elements = 2;
Assembler syntax
VRECPE{<c>}{<q>}.<dt> <Qd>, <Qm> Encoded as Q = 1

VRECPE{<c>}{<q>}.<dt> <Dd>, <Dm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VRECPE instruction must be
unconditional. ARM strongly recommends that a Thumb VRECPE instruction is unconditional, see
U32 Encoded as F = 0, size = 0b10.
F32 Encoded as F = 1, size = 0b10.
Operation
for r = 0 to regs-1
Elem[D[d+r],e,esize] = FPRecipEstimate(Elem[D[m+r],e,esize]);
else
Elem[D[d+r],e,esize] = UnsignedRecipEstimate(Elem[D[m+r],e,esize]);
Exceptions
Input Denormal, Invalid Operation, Underflow, Division by Zero.
Newton-Raphson iteration
For details of the operation performed and how it can be used in a Newton-Raphson iteration to calculate the
reciprocal of a number, see Floating-point reciprocal estimate and step on page A2-84.
A8.8.386 VRECPS
Vector Reciprocal Step multiplies the elements of one vector by the corresponding elements of another vector,
subtracts each of the products from 2.0, and places the results into the elements of the destination vector.
For details of the operation performed by this instruction see Floating-point reciprocal estimate and step on
page A2-84.

VRECPS<c>.F32 <Qd>, <Qn>, <Qm>
VRECPS<c>.F32 <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 1 0 D 0 sz Vn Vd 1 1 1 1 N Q M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 0 0 D 0 sz Vn Vd 1 1 1 1 N Q M 1 Vm
Assembler syntax
VRECPS{<c>}{<q>}.F32 {<Qd>,} <Qn>, <Qm> Encoded as Q = 1

VRECPS{<c>}{<q>}.F32 {<Dd>,} <Dn>, <Dm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VRECPS instruction must be
unconditional. ARM strongly recommends that a Thumb VRECPS instruction is
<Qd>, <Qn>, <Qm> The destination vector and the operand vectors for a quadword operation.
<Dd>, <Dn>, <Dm> The destination vector and the operand vectors for a doubleword operation.
Operation
for r = 0 to regs-1
Elem[D[d+r],e,esize] = FPRecipStep(Elem[D[n+r],e,esize], Elem[D[m+r],e,esize]);
Exceptions
reciprocal of a number, see Floating-point reciprocal estimate and step on page A2-84.
A8.8.387 VREV16, VREV32, VREV64

VREV16 (Vector Reverse in halfwords) reverses the order of 8-bit elements in each halfword of the vector, and places
the result in the corresponding destination vector.
VREV32 (Vector Reverse in words) reverses the order of 8-bit or 16-bit elements in each word of the vector, and places
the result in the corresponding destination vector.
VREV64 (Vector Reverse in doublewords) reverses the order of 8-bit, 16-bit, or 32-bit elements in each doubleword
of the vector, and places the result in the corresponding destination vector.
There is no distinction between data types, other than size.
Figure A8-6 shows two examples of the operation of VREV.
VREV64.8, doubleword VREV64.32, quadword

Dm Qm
Dd Qm
Figure A8-6 VREV operation examples


VREV<n><c>.<size> <Qd>, <Qm>
VREV<n><c>.<size> <Dd>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 size 0 0 Vd 0 0 0 op Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 size 0 0 Vd 0 0 0 op Q M 0 Vm
if UInt(op)+UInt(size) >= 3 then UNDEFINED;

groupsize = (1 << (3-UInt(op)-UInt(size))); // elements per reversing group: 2, 4 or 8
reverse_mask = (groupsize-1)<esize-1:0>; // EORing mask used for index calculations
Assembler syntax
VREV<n>{<c>}{<q>}.<size> <Qd>, <Qm> Encoded as Q = 1

VREV<n>{<c>}{<q>}.<size> <Dd>, <Dm> Encoded as Q = 0
where:
<n> The size of the regions in which the vector elements are reversed. It must be one of:
16 Encoded as op = 0b10.
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VREV instruction must be
unconditional. ARM strongly recommends that a Thumb VREV instruction is unconditional, see
<size> The size of the vector elements. It must be one of:

<size> must specify a smaller size than <n>.
If op + size >= 3, the instruction is reserved.
Operation
bits(64) dest;
for r = 0 to regs-1
// Calculate destination element index by bitwise EOR on source element index:
e_bits = e<esize-1:0>; d_bits = e_bits EOR reverse_mask; d = UInt(d_bits);
Elem[dest,d,esize] = Elem[D[m+r],e,esize];
D[d+r] = dest;
Exceptions
A8.8.388 VRHADD
Vector Rounding Halving Add adds corresponding elements in two vectors of integers, shifts each result right one
bit, and places the final results in the destination vector.
The operand and result elements are all the same type, and can be any one of:
The results of the halving operations are rounded. For truncated results see VHADD, VHSUB on page A8-897.

VRHADD<c> <Qd>, <Qn>, <Qm>
VRHADD<c> <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Assembler syntax
VRHADD{<c>}{<q>}.<dt> {<Qd>,} <Qn>, <Qm> Encoded as Q = 1

VRHADD{<c>}{<q>}.<dt> {<Dd>,} <Dn>, <Dm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VRHADD instruction must be
unconditional. ARM strongly recommends that a Thumb VRHADD instruction is
S8 Encoded as size = 0b00, U = 0.
U8 Encoded as size = 0b00, U = 1.
Operation
for r = 0 to regs-1
result = op1 + op2 + 1;
Elem[D[d+r],e,esize] = result<esize:1>;
Exceptions
A8.8.389 VRSHL
Vector Rounding Shift Left takes each element in a vector, shifts them by a value from the least significant byte of
the corresponding element of a second vector, and places the results in the destination vector. If the shift value is
positive, the operation is a left shift. If the shift value is negative, it is a rounding right shift. (For a truncating shift,
see VSHL (register) on page A8-1049).
The second operand is always a signed integer of the same size.

VRSHL<c>.<type><size> <Qd>, <Qm>, <Qn>
VRSHL<c>.<type><size> <Dd>, <Dm>, <Dn>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Assembler syntax
VRSHL{<c>}{<q>}.<type><size> {<Qd>,} <Qm>, <Qn> Encoded as Q = 1

VRSHL{<c>}{<q>}.<type><size> {<Dd>,} <Dm>, <Dn> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VRSHL instruction must be
unconditional. ARM strongly recommends that a Thumb VRSHL instruction is unconditional,
the result.
Operation
for r = 0 to regs-1
round_const = 1 << (-shift-1); // 0 for left shift, 2^(n-1) for right shift
result = (Int(Elem[D[m+r],e,esize], unsigned) + round_const) << shift;
Exceptions
A8.8.390 VRSHR
Vector Rounding Shift Right takes each element in a vector, right shifts them by an immediate value, and places the
rounded results in the destination vector. For truncated results, see VSHR on page A8-1053.
The operand and result elements must be the same size, and can be any one of:
• 8-bit, 16-bit, 32-bit, or 64-bit signed integers.

VRSHR<c>.<type><size> <Qd>, <Qm>, #<imm>
VRSHR<c>.<type><size> <Dd>, <Dm>, #<imm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 U 1 1 1 1 1 D imm6 Vd 0 0 1 0 L Q M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 U 1 D imm6 Vd 0 0 1 0 L Q M 1 Vm

case L:imm6 of
when “1xxxxxx” esize = 64; elements = 1; shift_amount = 64 - UInt(imm6);
unsigned = (U == ‘1’); d = UInt(D:Vd); m = UInt(M:Vm); regs = if Q == ‘0’ then 1 else 2;
Assembler syntax
VRSHR{<c>}{<q>}.<type><size> {<Qd>,} <Qm>, #<imm> Encoded as Q = 1

VRSHR{<c>}{<q>}.<type><size> {<Dd>,} <Dm>, #<imm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VRSHR instruction must be
unconditional. ARM strongly recommends that a Thumb VRSHR instruction is unconditional, see
S Signed, encoded as U = 0
8 Encoded as L = 0, imm6<5:3> = 0b001. (8 – <imm>) is encoded in imm6<2:0>.
32 Encoded as L = 0, imm6<5> = 0b1. (32 – <imm>) is encoded in imm6<4:0>.
64 Encoded as L = 1. (64 – <imm>) is encoded in imm6<5:0>.
<imm> The immediate value, in the range 1 to <size>. See the description of <size> for how <imm> is
encoded.
Operation
for r = 0 to regs-1
result = (Int(Elem[D[m+r],e,esize], unsigned) + round_const) >> shift_amount;
Exceptions
Pseudo-instructions
VRSHR.<type><size> <Qd>, <Qm>, #0 is a synonym for VMOV <Qd>, <Qm>

VRSHR.<type><size> <Dd>, <Dm>, #0 is a synonym for VMOV <Dd>, <Dm>
For details see VMOV (register) on page A8-939.
A8.8.391 VRSHRN
Vector Rounding Shift Right and Narrow takes each element in a vector, right shifts them by an immediate value,
and places the rounded results in the destination vector. For truncated results, see VSHRN on page A8-1055.
integers. The destination elements are half the size of the source elements.

VRSHRN<c>.I<size> <Dd>, <Qm>, #<imm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 1 1 D imm6 Vd 1 0 0 0 0 1 M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 0 1 D imm6 Vd 1 0 0 0 0 1 M 1 Vm

case imm6 of
Assembler syntax
VRSHRN{<c>}{<q>}.I<size> <Dd>, <Qm>, #<imm>
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VRSHRN instruction must be
unconditional. ARM strongly recommends that a Thumb VRSHRN instruction is unconditional, see
encoded.
Operation
round_const = 1 << (shift_amount-1);
result = LSR(Elem[Qin[m>>1],e,2*esize] + round_const, shift_amount);
Elem[D[d],e,esize] = result<esize-1:0>;
Exceptions
Pseudo-instructions
VRSHRN.I<size> <Dd>, <Qm>, #0 is a synonym for VMOVN.I<size> <Dd>, <Qm>
For details see VMOVN on page A8-953.
A8.8.392 VRSQRTE
Vector Reciprocal Square Root Estimate finds an approximate reciprocal square root of each element in a vector,
and places the results in a second vector.
The operand and result elements are the same type, and can be 32-bit floating-point numbers, or 32-bit unsigned
integers.
For details of the operation performed by this instruction see Floating-point reciprocal square root estimate and
step on page A2-86.

VRSQRTE<c>.<dt> <Qd>, <Qm>
VRSQRTE<c>.<dt> <Dd>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 size 1 1 Vd 0 1 0 F 1 Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 size 1 1 Vd 0 1 0 F 1 Q M 0 Vm

floating_point = (F == ‘1’); esize = 32; elements = 2;
Assembler syntax
VRSQRTE{<c>}{<q>}.<dt> <Qd>, <Qm> Encoded as Q = 1

VRSQRTE{<c>}{<q>}.<dt> <Dd>, <Dm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VRSQRTE instruction must be
unconditional. ARM strongly recommends that a Thumb VRSQRTE instruction is unconditional, see
U32 Encoded as F = 0, size = 0b10.
F32 Encoded as F = 1, size = 0b10.
Operation
for r = 0 to regs-1
Elem[D[d+r],e,esize] = FPRSqrtEstimate(Elem[D[m+r],e,esize]);
else
Elem[D[d+r],e,esize] = UnsignedRSqrtEstimate(Elem[D[m+r],e,esize]);
Exceptions
Input Denormal, Invalid Operation, Division by Zero.
reciprocal of the square root of a number, see Floating-point reciprocal square root estimate and step on
page A2-86.
A8.8.393 VRSQRTS
Vector Reciprocal Square Root Step multiplies the elements of one vector by the corresponding elements of another
vector, subtracts each of the products from 3.0, divides these results by 2.0, and places the results into the elements
of the destination vector.
For details of the operation performed by this instruction see Floating-point reciprocal square root estimate and
step on page A2-86.

VRSQRTS<c>.F32 <Qd>, <Qn>, <Qm>
VRSQRTS<c>.F32 <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 1 0 D 1 sz Vn Vd 1 1 1 1 N Q M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 0 0 D 1 sz Vn Vd 1 1 1 1 N Q M 1 Vm
Assembler syntax
VRSQRTS{<c>}{<q>}.F32 {<Qd>,} <Qn>, <Qm> Encoded as Q = 1, sz = 0

VRSQRTS{<c>}{<q>}.F32 {<Dd>,} <Dn>, <Dm> Encoded as Q = 0, sz = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VRSQRTS instruction must
be unconditional. ARM strongly recommends that a Thumb VRSQRTS instruction is
<Qd>, <Qn>, <Qm> The destination vector and the operand vectors for a quadword operation.
<Dd>, <Dn>, <Dm> The destination vector and the operand vectors for a doubleword operation.
Operation
for r = 0 to regs-1
Elem[D[d+r],e,esize] = FPRSqrtStep(Elem[D[n+r],e,esize], Elem[D[m+r],e,esize]);
Exceptions
reciprocal of the square root of a number, see Floating-point reciprocal square root estimate and step on
page A2-86.
A8.8.394 VRSRA
Vector Rounding Shift Right and Accumulate takes each element in a vector, right shifts them by an immediate
value, and accumulates the rounded results into the destination vector. (For truncated results, see VSRA on
page A8-1061.)

VRSRA<c>.<type><size> <Qd>, <Qm>, #<imm>
VRSRA<c>.<type><size> <Dd>, <Dm>, #<imm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 U 1 1 1 1 1 D imm6 Vd 0 0 1 1 L Q M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 U 1 D imm6 Vd 0 0 1 1 L Q M 1 Vm

case L:imm6 of
Assembler syntax
VRSRA{<c>}{<q>}.<type><size> {<Qd>,} <Qm>, #<imm> Encoded as Q = 1

VRSRA{<c>}{<q>}.<type><size> {<Dd>,} <Dm>, #<imm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VRSRA instruction must be
unconditional. ARM strongly recommends that a Thumb VRSRA instruction is unconditional, see
encoded.
Operation
for r = 0 to regs-1
result = (Int(Elem[D[m+r],e,esize], unsigned) + round_const) >> shift_amount;
Elem[D[d+r],e,esize] = Elem[D[d+r],e,esize] + result;
Exceptions
A8.8.395 VRSUBHN
Vector Rounding Subtract and Narrow, returning High Half subtracts the elements of one quadword vector from the
corresponding elements of another quadword vector takes the most significant half of each result, and places the
final results in a doubleword vector. The results are rounded. (For truncated results, see VSUBHN on
page A8-1089.)
integers.

VRSUBHN<c>.<dt> <Dd>, <Qn>, <Qm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D size Vn Vd 0 1 1 0 N 0 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D size Vn Vd 0 1 1 0 N 0 M 0 Vm

Assembler syntax
VRSUBHN{<c>}{<q>}.<dt> <Dd>, <Qn>, <Qm>
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VRSUBHN instruction must
be unconditional. ARM strongly recommends that a Thumb VRSUBHN instruction is
<Dd>, <Qn>, <Qm> The destination vector and the operand vectors.
Operation
result = Elem[Qin[n>>1],e,2*esize] - Elem[Qin[m>>1],e,2*esize] + round_const;
Exceptions
A8.8.396 VSHL (immediate)

Vector Shift Left (immediate) takes each element in a vector of integers, left shifts them by an immediate value, and
places the results in the destination vector.
Bits shifted out of the left of each element are lost.
The elements must all be the same size, and can be 8-bit, 16-bit, 32-bit, or 64-bit integers. There is no distinction
between signed and unsigned integers.

VSHL<c>.I<size> <Qd>, <Qm>, #<imm>
VSHL<c>.I<size> <Dd>, <Dm>, #<imm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 1 1 D imm6 Vd 0 1 0 1 L Q M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 0 1 D imm6 Vd 0 1 0 1 L Q M 1 Vm
if L:imm6 IN “0000xxx” then SEE “Related encodings”;

case L:imm6 of
Assembler syntax
VSHL{<c>}{<q>}.I<size> {<Qd>,} <Qm>, #<imm> Encoded as Q = 1

VSHL{<c>}{<q>}.I<size> {<Dd>,} <Dm>, #<imm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VSHL instruction must be
unconditional. ARM strongly recommends that a Thumb VSHL instruction is unconditional, see
encoded.
Operation
for r = 0 to regs-1
Elem[D[d+r],e,esize] = LSL(Elem[D[m+r],e,esize], shift_amount);
Exceptions
A8.8.397 VSHL (register)

Vector Shift Left (register) takes each element in a vector, shifts them by a value from the least significant byte of
the corresponding element of a second vector, and places the results in the destination vector. If the shift value is
positive, the operation is a left shift. If the shift value is negative, it is a truncating right shift.
Note
For a rounding shift, see VRSHL on page A8-1033.
The second operand is always a signed integer of the same size.

VSHL<c>.<type><size> <Qd>, <Qm>, <Qn>
VSHL<c>.<type><size> <Dd>, <Dm>, <Dn>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Assembler syntax
VSHL{<c>}{<q>}.<type><size> {<Qd>,} <Qm>, <Qn> Encoded as Q = 1

VSHL{<c>}{<q>}.<type><size> {<Dd>,} <Dm>, <Dn> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VSHL instruction must be
unconditional. ARM strongly recommends that a Thumb VSHL instruction is unconditional,
the result.
Operation
for r = 0 to regs-1
result = Int(Elem[D[m+r],e,esize], unsigned) << shift;
Exceptions
A8.8.398 VSHLL
Vector Shift Left Long takes each element in a doubleword vector, left shifts them by an immediate value, and places
the results in a quadword vector.
The operand elements can be:

• 8-bit, 16-bit, or 32-bit untyped integers (maximum shift only).
The result elements are twice the length of the operand elements.

VSHLL<c>.<type><size> <Qd>, <Dm>, #<imm> (0 < <imm> < <size>)
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 U 1 1 1 1 1 D imm6 Vd 1 0 1 0 0 0 M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 U 1 D imm6 Vd 1 0 1 0 0 0 M 1 Vm

case imm6 of
if shift_amount == 0 then SEE VMOVL;
unsigned = (U == ‘1’); d = UInt(D:Vd); m = UInt(M:Vm);

VSHLL<c>.<type><size> <Qd>, <Dm>, #<imm> (<imm> == <size>)
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 size 1 0 Vd 0 0 1 1 0 0 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 size 1 0 Vd 0 0 1 1 0 0 M 0 Vm

esize = 8 << UInt(size); elements = 64 DIV esize; shift_amount = esize;
unsigned = FALSE; // Or TRUE without change of functionality
Assembler syntax
VSHLL{<c>}{<q>}.<type><size> <Qd>, <Dm>, #<imm>
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VSHLL instruction must be
unconditional. ARM strongly recommends that a Thumb VSHLL instruction is unconditional, see
<type> The data type for the elements of the operand. It must be one of:
S Signed. In encoding T1/A1, encoded as U = 0.
U Unsigned. In encoding T1/A1, encoded as U = 1.
I Untyped integer, Available only in encoding T2/A2.
<size> The data size for the elements of the operand. Table A8-8 shows the permitted values and their
encodings:
Table A8-8 VSHLL <size> field encoding
<size> Encoding T1/A1 Encoding T2/A2
8 Encoded as imm6<5:3> = 0b001 Encoded as size = 0b00
16 Encoded as imm6<5:4> = 0b01 Encoded as size = 0b01
32 Encoded as imm6<5> = 1 Encoded as size = 0b10
<Qd>, <Dm> The destination vector and the operand vector.
<imm> The immediate value. <imm> must lie in the range 1 to <size>, and:
• if <size> == <imm>, the encoding is T2/A2
• otherwise, the encoding is T1/A1, and:
— if <size> == 8, <imm> is encoded in imm6<2:0>
— if <size> == 16, <imm> is encoded in imm6<3:0>
— if <size> == 32, <imm> is encoded in imm6<4:0>.
Operation
result = Int(Elem[Din[m],e,esize], unsigned) << shift_amount;
Exceptions
A8.8.399 VSHR
Vector Shift Right takes each element in a vector, right shifts them by an immediate value, and places the truncated
results in the destination vector. For rounded results, see VRSHR on page A8-1035.
The operand and result elements must be the same size, and can be any one of:

VSHR<c>.<type><size> <Qd>, <Qm>, #<imm>
VSHR<c>.<type><size> <Dd>, <Dm>, #<imm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 U 1 1 1 1 1 D imm6 Vd 0 0 0 0 L Q M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 U 1 D imm6 Vd 0 0 0 0 L Q M 1 Vm

case L:imm6 of
Assembler syntax
VSHR{<c>}{<q>}.<type><size> {<Qd>,} <Qm>, #<imm> Encoded as Q = 1

VSHR{<c>}{<q>}.<type><size> {<Dd>,} <Dm>, #<imm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VSHR instruction must be
unconditional. ARM strongly recommends that a Thumb VSHR instruction is unconditional, see
encoded.
Operation
for r = 0 to regs-1
result = Int(Elem[D[m+r],e,esize], unsigned) >> shift_amount;
Exceptions
Pseudo-instructions
VSHR.<type><size> <Qd>, <Qm>, #0 is a synonym for VMOV <Qd>, <Qm>

VSHR.<type><size> <Dd>, <Dm>, #0 is a synonym for VMOV <Dd>, <Dm>
A8.8.400 VSHRN
Vector Shift Right Narrow takes each element in a vector, right shifts them by an immediate value, and places the
truncated results in the destination vector. For rounded results, see VRSHRN on page A8-1037.
integers. The destination elements are half the size of the source elements.

VSHRN<c>.I<size> <Dd>, <Qm>, #<imm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 1 1 D imm6 Vd 1 0 0 0 0 0 M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 0 1 D imm6 Vd 1 0 0 0 0 0 M 1 Vm

case imm6 of
Assembler syntax
VSHRN{<c>}{<q>}.I<size> <Dd>, <Qm>, #<imm>
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VSHRN instruction must be
unconditional. ARM strongly recommends that a Thumb VSHRN instruction is unconditional, see
encoded.
Operation
result = LSR(Elem[Qin[m>>1],e,2*esize], shift_amount);
Elem[D[d],e,esize] = result<esize-1:0>;
Exceptions
Pseudo-instructions
VSHRN.I<size> <Dd>, <Qm>, #0 is a synonym for VMOVN.I<size> <Dd>, <Qm>
For details see VMOVN on page A8-953.
A8.8.401 VSLI
Vector Shift Left and Insert takes each element in the operand vector, left shifts them by an immediate value, and
inserts the results in the destination vector. Bits shifted out of the left of each element are lost.
The elements must all be the same size, and can be 8-bit, 16-bit, 32-bit, or 64-bit. There is no distinction between
data types.

VSLI<c>.<size> <Qd>, <Qm>, #<imm>
VSLI<c>.<size> <Dd>, <Dm>, #<imm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D imm6 Vd 0 1 0 1 L Q M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D imm6 Vd 0 1 0 1 L Q M 1 Vm

case L:imm6 of
Assembler syntax
VSLI{<c>}{<q>}.<size> {<Qd>,} <Qm>, #<imm> Encoded as Q = 1

VSLI{<c>}{<q>}.<size> {<Dd>,} <Dm>, #<imm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VSLI instruction must be
unconditional. ARM strongly recommends that a Thumb VSLI instruction is unconditional, see
encoded.
Operation
mask = LSL(Ones(esize), shift_amount);
for r = 0 to regs-1
shifted_op = LSL(Elem[D[m+r],e,esize], shift_amount);
Elem[D[d+r],e,esize] = (Elem[D[d+r],e,esize] AND NOT(mask)) OR shifted_op;
Exceptions
A8.8.402 VSQRT
This instruction calculates the square root of the value in a floating-point register and writes the result to another
floating-point register.
VSQRT<c>.F64 <Dd>, <Dm>
VSQRT<c>.F32 <Sd>, <Sm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 0 1 D 1 1 0 0 0 1 Vd 1 0 1 sz 1 1 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 1 0 1 D 1 1 0 0 0 1 Vd 1 0 1 sz 1 1 M 0 Vm

VFP vectors This instruction can operate on VFP vectors under control of the FPSCR.{Len, Stride} fields.
Assembler syntax
VSQRT{<c>}{<q>}.F64 <Dd>, <Dm> Encoded as sz = 1
VSQRT{<c>}{<q>}.F32 <Sd>, <Sm> Encoded as sz = 0
where:
<Dd>, <Dm> The destination vector and the operand vector, for a double-precision operation.
<Sd>, <Sm> The destination vector and the operand vector, for a single-precision operation.
Operation
D[d] = FPSqrt(D[m]);
else
S[d] = FPSqrt(S[m]);
Exceptions
Invalid Operation, Inexact, Input Denormal.
A8.8.403 VSRA
Vector Shift Right and Accumulate takes each element in a vector, right shifts them by an immediate value, and
accumulates the truncated results into the destination vector. (For rounded results, see VRSRA on page A8-1043.)

VSRA<c>.<type><size> <Qd>, <Qm>, #<imm>
VSRA<c>.<type><size> <Dd>, <Dm>, #<imm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 U 1 1 1 1 1 D imm6 Vd 0 0 0 1 L Q M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 U 1 D imm6 Vd 0 0 0 1 L Q M 1 Vm

case L:imm6 of
Assembler syntax
VSRA{<c>}{<q>}.<type><size> {<Qd>,} <Qm>, #<imm> Encoded as Q = 1

VSRA{<c>}{<q>}.<type><size> {<Dd>,} <Dm>, #<imm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VSRA instruction must be
unconditional. ARM strongly recommends that a Thumb VSRA instruction is unconditional, see
encoded.
Operation
for r = 0 to regs-1
result = Int(Elem[D[m+r],e,esize], unsigned) >> shift_amount;
Elem[D[d+r],e,esize] = Elem[D[d+r],e,esize] + result;
Exceptions
A8.8.404 VSRI
Vector Shift Right and Insert takes each element in the operand vector, right shifts them by an immediate value, and
inserts the results in the destination vector. Bits shifted out of the right of each element are lost.
The elements must all be the same size, and can be 8-bit, 16-bit, 32-bit, or 64-bit. There is no distinction between
data types.

VSRI<c>.<size> <Qd>, <Qm>, #<imm>
VSRI<c>.<size> <Dd>, <Dm>, #<imm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D imm6 Vd 0 1 0 0 L Q M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D imm6 Vd 0 1 0 0 L Q M 1 Vm

case L:imm6 of
Assembler syntax
VSRI{<c>}{<q>}.<size> {<Qd>,} <Qm>, #<imm> Encoded as Q = 1

VSRI{<c>}{<q>}.<size> {<Dd>,} <Dm>, #<imm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VSRI instruction must be
unconditional. ARM strongly recommends that a Thumb VSRI instruction is unconditional, see
encoded.
Operation
mask = LSR(Ones(esize), shift_amount);
for r = 0 to regs-1
shifted_op = LSR(Elem[D[m+r],e,esize], shift_amount);
Elem[D[d+r],e,esize] = (Elem[D[d+r],e,esize] AND NOT(mask)) OR shifted_op;
Exceptions
A8.8.405 VST1 (multiple single elements)

Vector Store (multiple single elements) stores elements to memory from one, two, three, or four registers, without
interleaving. Every element of each register is stored. For details of the addressing mode see Advanced SIMD

VST1<c>.<size> <list>, [<Rn>{:<align>}]{!}
VST1<c>.<size> <list>, [<Rn>{:<align>}], <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
case type of
when ‘0111’
when ‘1010’
regs = 2; if align == ‘11’ then UNDEFINED;
when ‘0110’
when ‘0010’
regs = 4;
otherwise
Assembler syntax
VST1{<c>}{<q>}.<size> <list>, [<Rn>{:<align>}] Encoded as Rm = 0b1111

VST1{<c>}{<q>}.<size> <list>, [<Rn>{:<align>}]! Encoded as Rm = 0b1101
VST1{<c>}{<q>}.<size> <list>, [<Rn>{:<align>}], <Rm> Rm cannot be 0b11x1
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VST1 instruction must be
unconditional. ARM strongly recommends that a Thumb VST1 instruction is unconditional, see

<list> The list of registers to store. It must be one of:

{<Dd>} Encoded as D:Vd = <Dd>, type = 0b0111.
{<Dd>, <Dd+1>} Encoded as D:Vd = <Dd>, type = 0b1010.
{<Dd>, <Dd+1>, <Dd+2>}
Encoded as D:Vd = <Dd>, type = 0b0110.
{<Dd>, <Dd+1>, <Dd+2>, <Dd+3>}

128 16-byte alignment, available only if <list> contains two or four registers, encoded as
align = 0b10.
align = 0b11.
align = 0b00.
Operation
address = R[n]; if (address MOD alignment) != 0 then AlignmentFault(address, TRUE);
for r = 0 to regs-1
for e = 0 to elements - 1
if ebytes != 8 then
MemU[address, ebytes] = Elem[D[d+r], e, esize];
else
if SCTLR.A == ‘1’ && address != Align(address, 8) then AlignmentFault(address, FALSE);
data = Elem[D[d+r], e, esize];
MemU[address, 4] = if BigEndian() then data<63:32> else data<31:0>;
MemU[address+4, 4] = if BigEndian() then data<31:0> else data<63:32>;
address = address + ebytes;
Exceptions
A8.8.406 VST1 (single element from one lane)

This instruction stores one element to memory from one element of a register. For details of the addressing mode

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

case size of
when ‘00’
ebytes = 1; esize = 8; index = UInt(index_align<3:1>); alignment = 1;
when ‘01’
when ‘10’
if index_align<1:0> != ‘00’ && index_align<1:0> != ‘11’ then UNDEFINED;
alignment = if index_align<1:0> == ‘00’ then 1 else 4;
Assembler syntax

where:

<list> The register containing the element to store. It must be {<Dd[x]>}. The register Dd is encoded in D:Vd

Table A8-9 shows the encoding of index and alignment for different <size> values.
Table A8-9 Encoding of index and alignment
<size> == 8 <size> == 16 <size> == 32
<align> omitted index_align[0] = 0 index_align[1:0] = '00' index_align[2:0] = '000'
<align> == 16 - index_align[1:0] = '01' -
Operation
MemU[address,ebytes] = Elem[D[d], index, esize];
Exceptions
A8.8.407 VST2 (multiple 2-element structures)

This instruction stores multiple 2-element structures from two or four registers to memory, with interleaving. For
more information, see Element and structure load/store instructions on page A4-179. Every element of each register
is saved. For details of the addressing mode see Advanced SIMD addressing mode on page A7-275.

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

case type of
when ‘1000’
when ‘1001’
when ‘0011’
regs = 2; inc = 2;
otherwise
if n == 15 || d2+regs > 32 then UNPREDICTABLE;
Assembler syntax

where:


{<Dd>, <Dd+1>, <Dd+2>, <Dd+3>}

align = 0b11.
align = 0b00.
Operation
for r = 0 to regs-1
MemU[address, ebytes] = Elem[D[d+r], e, esize];
MemU[address+ebytes, ebytes] = Elem[D[d2+r],e, esize];
Exceptions
A8.8.408 VST2 (single 2-element structure from one lane)

This instruction stores one 2-element structure to memory from corresponding elements of two registers. For details
of the addressing mode see Advanced SIMD addressing mode on page A7-275.

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

case size of
when ‘00’
when ‘01’
when ‘10’
Assembler syntax

where:

{<Dd[x]>, <Dd+1[x]>} Single-spaced registers, see Table A8-10 on page A8-1072.
{<Dd[x]>, <Dd+2[x]>} Double-spaced registers, see Table A8-10 on page A8-1072. This is not
available if <size> == 8.

<size> == 8 <size> == 16 <size> == 32
<align> == 32 - index_align[0] = 1 -
Operation
MemU[address, ebytes] = Elem[D[d], index, esize];
MemU[address+ebytes, ebytes] = Elem[D[d2], index, esize];
Exceptions

This instruction stores multiple 3-element structures to memory from three registers, with interleaving. For more
saved. For details of the addressing mode see Advanced SIMD addressing mode on page A7-275.

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
if size == ‘11’ || align<1> == ‘1’ then UNDEFINED;

case type of
when ‘0100’
inc = 1;
when ‘0101’
inc = 2;
otherwise
alignment = if align<0> == ‘0’ then 1 else 8;
Assembler syntax

where:


{<Dd>, <Dd+1>, <Dd+2>}
{<Dd>, <Dd+2>, <Dd+4>}

align = 0b00.
Operation
MemU[address, ebytes] = Elem[D[d], e, esize];
MemU[address+ebytes, ebytes] = Elem[D[d2], e, esize];
MemU[address+2*ebytes, ebytes] = Elem[D[d3], e, esize];
Exceptions

This instruction stores one 3-element structure to memory from corresponding elements of three registers. For
details of the addressing mode see Advanced SIMD addressing mode on page A7-275.

VST3<c>.<size> <list>, [<Rn>]{!}
VST3<c>.<size> <list>, [<Rn>], <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

case size of
when ‘00’
when ‘01’
when ‘10’
if index_align<1:0> != ‘00’ then UNDEFINED;
Assembler syntax
VST3{<c>}{<q>}.<size> <list>, [<Rn>] Encoded as Rm = 0b1111

VST3{<c>}{<q>}.<size> <list>, [<Rn>]! Encoded as Rm = 0b1101
VST3{<c>}{<q>}.<size> <list>, [<Rn>], <Rm> Rm cannot be 0b11x1
where:

{<Dd[x]>, <Dd+1[x]>, <Dd+2[x]>}
Single-spaced registers, see Table A8-11.
{<Dd[x]>, <Dd+2[x]>, <Dd+4[x]>}
Double-spaced registers, see Table A8-11. This is not available if <size> == 8.
Table A8-11 Encoding of index and register spacing
<size> == 8 <size> == 16 <size> == 32
Single-spacing index_align[0] = 0 index_align[1:0] = '00' index_align[2:0] = '000'
Double-spacing - index_align[1:0] = '10' index_align[2:0] = '100'
Alignment
Operation
address = R[n];
MemU[address+2*ebytes, ebytes] = Elem[D[d3], index, esize];
Exceptions

This instruction stores multiple 4-element structures to memory from four registers, with interleaving. For more
saved. For details of the addressing mode see Advanced SIMD addressing mode on page A7-275.

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

case type of
when ‘0000’
inc = 1;
when ‘0001’
inc = 2;
otherwise
Assembler syntax

where:


{<Dd>, <Dd+1>, <Dd+2>, <Dd+3>}
{<Dd>, <Dd+2>, <Dd+4>, <Dd+6>}

align = 0b00.
Operation
MemU[address, ebytes] = Elem[D[d], e, esize];
MemU[address+ebytes, ebytes] = Elem[D[d2], e, esize];
Exceptions

This instruction stores one 4-element structure to memory from corresponding elements of four registers. For details
of the addressing mode see Advanced SIMD addressing mode on page A7-275.

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

case size of
when ‘00’
when ‘01’
when ‘10’
if index_align<1:0> == ‘11’ then UNDEFINED;
alignment = if index_align<1:0> == ‘00’ then 1 else 4 << UInt(index_align<1:0>);
Assembler syntax

where:
{<Dd[x]>, <Dd+1[x]>, <Dd+2[x]>, <Dd+3[x]>}
Single-spaced registers, see Table A8-12 on page A8-1080.
{<Dd[x]>, <Dd+2[x]>, <Dd+4[x]>, <Dd+6[x]>}
Double-spaced registers, see Table A8-12 on page A8-1080. This is not available if
<size> == 8.

64 8-byte alignment, available only if <size> is 16 or 32.
<size> == 8 <size> == 16 <size> == 32
<align> == 64 - index_align[0] = 1 index_align[1:0] = '01'
Operation
Exceptions
A8.8.413 VSTM
Vector Store Multiple stores multiple extension registers to consecutive memory locations using an address from an
ARM core register.

VSTM{mode}<c> <Rn>{!}, <list> <list> is consecutive 64-bit registers
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 0 P U D W 0 Rn Vd 1 0 1 1 imm8
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

if P == ‘1’ && U == ‘0’ && W == ‘1’ && Rn == ‘1101’ then SEE VPUSH;
if P == ‘1’ && W == ‘0’ then SEE VSTR;
single_regs = FALSE; add = (U == ‘1’); wback = (W == ‘1’);
d = UInt(D:Vd); n = UInt(Rn); imm32 = ZeroExtend(imm8:’00’, 32);
regs = UInt(imm8) DIV 2; // If UInt(imm8) is odd, see “FSTMX”.

VSTM{mode}<c> <Rn>{!}, <list> <list> is consecutive 32-bit registers
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 0 P U D W 0 Rn Vd 1 0 1 0 imm8
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

if P == ‘1’ && U == ‘0’ && W == ‘1’ && Rn == ‘1101’ then SEE VPUSH;
if P == ‘1’ && W == ‘0’ then SEE VSTR;
single_regs = TRUE; add = (U == ‘1’); wback = (W == ‘1’); d = UInt(Vd:D); n = UInt(Rn);
Related encodings See 64-bit transfers between ARM core and extension registers on page A7-277.
FSTMX Encoding T1/A1 behaves as described by the pseudocode if imm8 is odd. However, there is
no UAL syntax for such encodings and ARM deprecates their use. For more information, see
FLDMX, FSTMX on page A8-389.
Assembler syntax
VSTM{<mode>}{<c>}{<q>}{.<size>} <Rn>{!}, <list>
where:
<mode> The addressing mode:

IA Increment After. The consecutive addresses start at the address specified in <Rn>. This
is the default and can be omitted. Encoded as P = 0, U = 1.
DB Decrement Before. The consecutive addresses end just before the address specified in
<Rn>. Encoded as P = 1, U = 0.
in <list>.
<Rn> The base register. The SP can be used. In the ARM instruction set, if ! is not specified the PC can
be used. However, ARM deprecates use of the PC.
! Causes the instruction to write a modified value back to <Rn>. Required if <mode> == DB. Encoded
as W = 1.
<list> The extension registers to be stored, as a list of consecutively numbered doubleword (encoding
(encoding T2/A2). <list> must contain at least one register. If it contains doubleword registers it
must not contain more than 16 registers.
Operation
address = if add then R[n] else R[n]-imm32;
for r = 0 to regs-1
if single_regs then
MemA[address,4] = S[d+r]; address = address+4;
else
MemA[address,4] = if BigEndian() then D[d+r]<63:32> else D[d+r]<31:0>;
MemA[address+4,4] = if BigEndian() then D[d+r]<31:0> else D[d+r]<63:32>;
address = address+8;
if wback then R[n] = if add then R[n]+imm32 else R[n]-imm32;
Exceptions
A8.8.414 VSTR
This instruction stores a single extension register to memory, using an address from an ARM core register, with an
optional offset.

VSTR<c> <Dd>, [<Rn>{, #+/-<imm>}]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 0 1 U D 0 0 Rn Vd 1 0 1 1 imm8
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 0 1 U D 0 0 Rn Vd 1 0 1 1 imm8
single_reg = FALSE; add = (U == ‘1’); imm32 = ZeroExtend(imm8:’00’, 32);

d = UInt(D:Vd); n = UInt(Rn);
if n == 15 && CurrentInstrSet() != InstrSet_ARM then UNPREDICTABLE;

VSTR<c> <Sd>, [<Rn>{, #+/-<imm>}]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 0 1 U D 0 0 Rn Vd 1 0 1 0 imm8
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 1 1 0 1 U D 0 0 Rn Vd 1 0 1 0 imm8
single_reg = TRUE; add = (U == ‘1’); imm32 = ZeroExtend(imm8:’00’, 32);

d = UInt(Vd:D); n = UInt(Rn);
if n == 15 && CurrentInstrSet() != InstrSet_ARM then UNPREDICTABLE;
Assembler syntax
VSTR{<c>}{<q>}{.64} <Dd>, [<Rn>{, #+/-<imm>}] Encoding T1/A1

VSTR{<c>}{<q>}{.32} <Sd>, [<Rn>{, #+/-<imm>}] Encoding T2/A2
where:
.32, .64 Optional data size specifiers.
<Dd> The source register for a doubleword store.
<Sd> The source register for a singleword store.
<Rn> The base register. The SP can be used. In the ARM instruction set the PC can be used. However,
<imm> can be omitted, meaning an offset of +0.
Operation
if single_reg then
MemA[address,4] = S[d];
else
MemA[address,4] = if BigEndian() then D[d]<63:32> else D[d]<31:0>;
MemA[address+4,4] = if BigEndian() then D[d]<31:0> else D[d]<63:32>;
Exceptions
A8.8.415 VSUB (integer)

Vector Subtract subtracts the elements of one vector from the corresponding elements of another vector, and places
the results in the destination vector.

VSUB<c>.<dt> <Qd>, <Qn>, <Qm>
VSUB<c>.<dt> <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 0 D size Vn Vd 1 0 0 0 N Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 0 D size Vn Vd 1 0 0 0 N Q M 0 Vm
Assembler syntax
VSUB{<c>}{<q>}.<dt> {<Qd>,} <Qn>, <Qm>
VSUB{<c>}{<q>}.<dt> {<Dd>,} <Dn>, <Dm>
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM Advanced SIMD VSUB
SIMD VSUB instruction is unconditional, see Conditional execution on page A8-286.
Operation
for r = 0 to regs-1
Elem[D[d+r],e,esize] = Elem[D[n+r],e,esize] - Elem[D[m+r],e,esize];
Exceptions
A8.8.416 VSUB (floating-point)

Vector Subtract subtracts the elements of one vector from the corresponding elements of another vector, and places
the results in the destination vector.

VSUB<c>.F32 <Qd>, <Qn>, <Qm>
VSUB<c>.F32 <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 1 0 D 1 sz Vn Vd 1 1 0 1 N Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 0 0 D 1 sz Vn Vd 1 1 0 1 N Q M 0 Vm
VSUB<c>.F64 <Dd>, <Dn>, <Dm>
VSUB<c>.F32 <Sd>, <Sn>, <Sm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 0 0 D 1 1 Vn Vd 1 0 1 sz N 1 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Assembler syntax
VSUB{<c>}{<q>}.F32 {<Qd>,} <Qn>, <Qm> Encoding T1/A1, encoded as Q = 1, sz = 0
VSUB{<c>}{<q>}.F32 {<Dd>,} <Dn>, <Dm> Encoding T1/A1, encoded as Q = 0, sz = 0
VSUB{<c>}{<q>}.F64 {<Dd>,} <Dn>, <Dm> Encoding T2/A2, encoded as sz = 1
VSUB{<c>}{<q>}.F32 {<Sd>,} <Sn>, <Sm> Encoding T2/A2, encoded as sz = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM Advanced SIMD VSUB
SIMD VSUB instruction is unconditional, see Conditional execution on page A8-286.
Operation
for r = 0 to regs-1
Elem[D[d+r],e,esize] = FPSub(Elem[D[n+r],e,esize], Elem[D[m+r],e,esize], FALSE);
D[d] = FPSub(D[n], D[m], TRUE);
else
S[d] = FPSub(S[n], S[m], TRUE);
Exceptions
A8.8.417 VSUBHN
Vector Subtract and Narrow, returning High Half subtracts the elements of one quadword vector from the
corresponding elements of another quadword vector, takes the most significant half of each result, and places the
final results in a doubleword vector. The results are truncated. (For rounded results, see VRSUBHN on
page A8-1045.
There is no distinction between signed and unsigned integers.

VSUBHN<c>.<dt> <Dd>, <Qn>, <Qm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 1 1 D size Vn Vd 0 1 1 0 N 0 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 0 1 D size Vn Vd 0 1 1 0 N 0 M 0 Vm

Assembler syntax
VSUBHN{<c>}{<q>}.<dt> <Dd>, <Qn>, <Qm>
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VSUBHN instruction must be
unconditional. ARM strongly recommends that a Thumb VSUBHN instruction is
<Dd>, <Qn>, <Qm> The destination vector, the first operand vector, and the second operand vector.
Operation
result = Elem[Qin[n>>1],e,2*esize] - Elem[Qin[m>>1],e,2*esize];
Exceptions
A8.8.418 VSUBL, VSUBW

Vector Subtract Long subtracts the elements of one doubleword vector from the corresponding elements of another
doubleword vector, and places the results in a quadword vector. Before subtracting, it sign-extends or zero-extends
the elements of both operands.
Vector Subtract Wide subtracts the elements of a doubleword vector from the corresponding elements of a quadword
vector, and places the results in another quadword vector. Before subtracting, it sign-extends or zero-extends the
elements of the doubleword operand.

VSUBL<c>.<dt> <Qd>, <Dn>, <Dm>
VSUBW<c>.<dt> <Qd>, <Qn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 U 1 1 1 1 1 D size Vn Vd 0 0 1 op N 0 M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 U 1 D size Vn Vd 0 0 1 op N 0 M 0 Vm

if Vd<0> == ‘1’ || (op == ‘1’ && Vn<0> == ‘1’) then UNDEFINED;
esize = 8 << UInt(size); elements = 64 DIV esize; is_vsubw = (op == ‘1’);
Assembler syntax
VSUBL{<c>}{<q>}.<dt> <Qd>, <Dn>, <Dm> Encoded as op = 0
VSUBW{<c>}{<q>}.<dt> {<Qd>,} <Qn>, <Dm> Encoded as op = 1
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VSUBL or VSUBW instruction must be
unconditional. ARM strongly recommends that a Thumb VSUBL or VSUBW instruction is unconditional,
<dt> The data type for the elements of the second operand. It must be one of:
<Qd> The destination register.
<Qn>, <Dm> The first and second operand registers for a VSUBW instruction.
<Dn>, <Dm> The first and second operand registers for a VSUBL instruction.
Operation
if is_vsubw then
op1 = Int(Elem[Qin[n>>1],e,2*esize], unsigned);
else
op1 = Int(Elem[Din[n],e,esize], unsigned);
result = op1 - Int(Elem[Din[m],e,esize], unsigned);
Exceptions
A8.8.419 VSWP
VSWP (Vector Swap) exchanges the contents of two vectors. The vectors can be either doubleword or quadword.
There is no distinction between data types.

VSWP<c> <Qd>, <Qm>
VSWP<c> <Dd>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 size 1 0 Vd 0 0 0 0 0 Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 size 1 0 Vd 0 0 0 0 0 Q M 0 Vm

Assembler syntax
VSWP{<c>}{<q>}{.<dt>} <Qd>, <Qm> Encoded as Q = 1, size = 0b00

VSWP{<c>}{<q>}{.<dt>} <Dd>, <Dm> Encoded as Q = 0, size = 0b00
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VSWP instruction must be
unconditional. ARM strongly recommends that a Thumb VSWP instruction is unconditional, see
<Qd>, <Qm> The vectors for a quadword operation.
<Dd>, <Dm> The vectors for a doubleword operation.
Operation
for r = 0 to regs-1
if d == m then
D[d+r] = bits(64) UNKNOWN;
else
D[d+r] = Din[m+r];
D[m+r] = Din[d+r];
Exceptions
A8.8.420 VTBL, VTBX

Vector Table Lookup uses byte indexes in a control vector to look up byte values in a table and generate a new
vector. Indexes out of range return 0.
Vector Table Extension works in the same way, except that indexes out of range leave the destination element
unchanged.

V<op><c>.8 <Dd>, <list>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 Vn Vd 1 0 len N op M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 Vn Vd 1 0 len N op M 0 Vm
is_vtbl = (op == ‘0’); length = UInt(len)+1;

if n+length > 32 then UNPREDICTABLE;
Assembler syntax
V<op>{<c>}{<q>}.8 <Dd>, <list>, <Dm>
where:

TBL Vector Table Lookup. Encoded as op = 0.
TBX Vector Table Extension. Encoded as op = 1.
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VTBL or VTBX instruction must be
unconditional. ARM strongly recommends that a Thumb VTBL or VTBX instruction is unconditional,
<Dd> The destination vector.
<list> The vectors containing the table. It must be one of:

{<Dn>} encoded as len = 0b00.
{<Dn>, <Dn+1>} encoded as len = 0b01.
{<Dn>, <Dn+1>, <Dn+2>} encoded as len = 0b10.
{<Dn>, <Dn+1>, <Dn+2>, <Dn+3>}
encoded as len = 0b11.
<Dm> The index vector.
Operation
// Create 256-bit = 32-byte table variable, with zeros in entries that will not be used.
table3 = if length == 4 then D[n+3] else Zeros(64);
table2 = if length >= 3 then D[n+2] else Zeros(64);
table1 = if length >= 2 then D[n+1] else Zeros(64);
table = table3 : table2 : table1 : D[n];
for i = 0 to 7
index = UInt(Elem[D[m],i,8]);
if index < 8*length then
Elem[D[d],i,8] = Elem[table,index,8];
else
if is_vtbl then
Elem[D[d],i,8] = Zeros(8);
// else Elem[D[d],i,8] unchanged
Exceptions
A8.8.421 VTRN
Vector Transpose treats the elements of its operand vectors as elements of 2 × 2 matrices, and transposes the
matrices.
The elements of the vectors can be 8-bit, 16-bit, or 32-bit. There is no distinction between data types.
Figure A8-7 shows the operation of doubleword VTRN. Quadword VTRN performs the same operation as doubleword
VTRN twice, once on the upper halves of the quadword vectors, and once on the lower halves
VTRN.32 VTRN.16 VTRN.8

1 0 3 2 1 0 7 6 5 4 3 2 1 0
Dd Dd Dd
Dm Dm Dm
Figure A8-7 VTRN doubleword operation

VTRN<c>.<size> <Qd>, <Qm>
VTRN<c>.<size> <Dd>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 size 1 0 Vd 0 0 0 0 1 Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 size 1 0 Vd 0 0 0 0 1 Q M 0 Vm

Assembler syntax
VTRN{<c>}{<q>}.<size> <Qd>, <Qm> Encoded as Q = 1

VTRN{<c>}{<q>}.<size> <Dd>, <Dm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VTRN instruction must be
unconditional. ARM strongly recommends that a Thumb VTRN instruction is unconditional, see
Operation
h = elements DIV 2;
for r = 0 to regs-1
if d == m then
D[d+r] = bits(64) UNKNOWN;
else
for e = 0 to h-1
Elem[D[d+r],2*e+1,esize] = Elem[Din[m+r],2*e,esize];
Elem[D[m+r],2*e,esize] = Elem[Din[d+r],2*e+1,esize];
Exceptions
A8.8.422 VTST
Vector Test Bits takes each element in a vector, and bitwise ANDs it with the corresponding element of a second
vector. If the result is not zero, the corresponding element in the destination vector is set to all ones. Otherwise, it is
set to all zeros.

• 8-bit, 16-bit, or 32-bit fields.

VTST<c>.<size> <Qd>, <Qn>, <Qm>
VTST<c>.<size> <Dd>, <Dn>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 0 1 1 1 1 0 D size Vn Vd 1 0 0 0 N Q M 1 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 0 0 D size Vn Vd 1 0 0 0 N Q M 1 Vm
Assembler syntax
VTST{<c>}{<q>}.<size> {<Qd>,} <Qn>, <Qm> Encoded as Q = 1
VTST{<c>}{<q>}.<size> {<Dd>,} <Dn>, <Dm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VTST instruction must be
unconditional. ARM strongly recommends that a Thumb VTST instruction is unconditional,
Operation
for r = 0 to regs-1
if !IsZero(Elem[D[n+r],e,esize] AND Elem[D[m+r],e,esize]) then
Elem[D[d+r],e,esize] = Ones(esize);
else
Elem[D[d+r],e,esize] = Zeros(esize);
Exceptions
A8.8.423 VUZP
Vector Unzip de-interleaves the elements of two vectors. See Table A8-13 and Table A8-14 for examples of the
operation.

VUZP<c>.<size> <Qd>, <Qm>
VUZP<c>.<size> <Dd>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 size 1 0 Vd 0 0 0 1 0 Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 size 1 0 Vd 0 0 0 1 0 Q M 0 Vm
if size == ‘11’ || (Q == ‘0’ && size == ‘10’) then UNDEFINED;

quadword_operation = (Q == ‘1’); esize = 8 << UInt(size);
Table A8-13 shows the operation of a doubleword VUZP.8 instruction, and Table A8-14 shows the operation of a
quadword VUZP.32 instruction, and
Table A8-13 Operation of doubleword VUZP.8
Register state before operation Register state after operation
Dd A7 A6 A5 A4 A3 A2 A1 A0 B6 B4 B2 B0 A6 A4 A2 A0
Dm B7 B6 B5 B4 B3 B2 B1 B0 B7 B5 B3 B1 A7 A5 A3 A1
Table A8-14 Operation of quadword VUZP.32
Qd A3 A2 A1 A0 B2 B0 A2 A0
Qm B3 B2 B1 B0 B3 B1 A3 A1
Assembler syntax
VUZP{<c>}{<q>}.<size> <Qd>, <Qm> Encoded as Q = 1

VUZP{<c>}{<q>}.<size> <Dd>, <Dm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VUZP instruction must be
unconditional. ARM strongly recommends that a Thumb VUZP instruction is unconditional, see
32 Encoded as size = 0b10 for a quadword operation.
Doubleword operation with <size> = 32 is a pseudo-instruction.
Operation
if d == m then
Q[d>>1] = bits(128) UNKNOWN; Q[m>>1] = bits(128) UNKNOWN;
else
zipped_q = Q[m>>1]:Q[d>>1];
for e = 0 to (128 DIV esize) - 1
Elem[Q[d>>1],e,esize] = Elem[zipped_q,2*e,esize];
Elem[Q[m>>1],e,esize] = Elem[zipped_q,2*e+1,esize];
else
if d == m then
D[d] = bits(64) UNKNOWN; D[m] = bits(64) UNKNOWN;
else
zipped_d = D[m]:D[d];
Elem[D[d],e,esize] = Elem[zipped_d,2*e,esize];
Elem[D[m],e,esize] = Elem[zipped_d,2*e+1,esize];
Exceptions
Pseudo-instruction
VUZP.32 <Dd>, <Dm> is a synonym for VTRN.32 <Dd>, <Dm>. For details see VTRN on page A8-1097.
A8.8.424 VZIP
Vector Zip interleaves the elements of two vectors. See Table A8-15 and Table A8-16 for examples of the operation.

VZIP<c>.<size> <Qd>, <Qm>
VZIP<c>.<size> <Dd>, <Dm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 1 1 1 1 1 D 1 1 size 1 0 Vd 0 0 0 1 1 Q M 0 Vm
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 D 1 1 size 1 0 Vd 0 0 0 1 1 Q M 0 Vm
if size == ‘11’ || (Q == ‘0’ && size == ‘10’) then UNDEFINED;

quadword_operation = (Q == ‘1’); esize = 8 << UInt(size);
Table A8-15 shows the operation of a doubleword VZIP.8 instruction, and Table A8-16 shows the operation of a
quadword VZIP.32 instruction.
Table A8-15 Operation of doubleword VZIP.8
Dd A7 A6 A5 A4 A3 A2 A1 A0 B3 A3 B2 A2 B1 A1 B0 A0
Dm B7 B6 B5 B4 B3 B2 B1 B0 B7 A7 B6 A6 B5 A5 B4 A4
Table A8-16 Operation of quadword VZIP.32
Qd A3 A2 A1 A0 B1 A1 B0 A0
Qm B3 B2 B1 B0 B3 A3 B2 A2
Assembler syntax
VZIP{<c>}{<q>}.<size> <Qd>, <Qm> Encoded as Q = 1

VZIP{<c>}{<q>}.<size> <Dd>, <Dm> Encoded as Q = 0
where:
<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM VZIP instruction must be
unconditional. ARM strongly recommends that a Thumb VZIP instruction is unconditional, see
32 Encoded as size = 0b10 for a quadword operation.
Doubleword operation with <size> = 32 is a pseudo-instruction.
Operation
if d == m then
Q[d>>1] = bits(128) UNKNOWN; Q[m>>1] = bits(128) UNKNOWN;
else
bits(256) zipped_q;
Elem[zipped_q,2*e,esize] = Elem[Q[d>>1],e,esize];
Elem[zipped_q,2*e+1,esize] = Elem[Q[m>>1],e,esize];
Q[d>>1] = zipped_q<127:0>; Q[m>>1] = zipped_q<255:128>;
else
if d == m then
D[d] = bits(64) UNKNOWN; D[m] = bits(64) UNKNOWN;
else
bits(128) zipped_d;
Elem[zipped_d,2*e,esize] = Elem[D[d],e,esize];
Elem[zipped_d,2*e+1,esize] = Elem[D[m],e,esize];
D[d] = zipped_d<63:0>; D[m] = zipped_d<127:64>;
Exceptions
Pseudo-instructions
VZIP.32 <Dd>, <Dm> is a synonym for VTRN.32 <Dd>, <Dm>. For details see VTRN on page A8-1097.
A8.8.425 WFE
Wait For Event is a hint instruction that permits the processor to enter a low-power state until one of a number of
events occurs, including events signaled by executing the SEV instruction on any processor in the multiprocessor
system. For more information, see Wait For Event and Send Event on page B1-1199.
In an implementation that includes the Virtualization Extensions, if HCR.TWE is set to 1, execution of a WFE
instruction in a Non-secure mode other than Hyp mode generates a Hyp Trap exception if, ignoring the value of the
HCR.TWE bit, conditions permit the processor to suspend execution. For more information see Trapping use of the
WFI and WFE instructions on page B1-1253.

WFE<c>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 1 1 1 1 1 0 0 1 0 0 0 0 0

WFE<c>.W
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 0 1 0 (1) (1) (1) (1) 1 0 (0) 0 (0) 0 0 0 0 0 0 0 0 0 1 0

WFE<c>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 1 0 0 1 0 0 0 0 0 (1) (1) (1) (1) (0) (0) (0) (0) 0 0 0 0 0 0 1 0
Assembler syntax
WFE{<c>}{<q>}
where:
Operation
if EventRegistered() then
ClearEventRegister();
else
if HaveVirtExt() && !IsSecure() && !CurrentModeIsHyp() && HCR.TWE == ‘1’ then
else
WaitForEvent();
Exceptions
Hyp Trap.
A8.8.426 WFI
Wait For Interrupt is a hint instruction that permits the processor to enter a low-power state until one of a number
of asynchronous events occurs. For more information, see Wait For Interrupt on page B1-1202.
In an implementation that includes the Virtualization Extensions, if HCR.TWI is set to 1, execution of a WFI
instruction in a Non-secure mode other than Hyp mode generates a Hyp Trap exception if, ignoring the value of the
HCR.TWI bit, conditions permit the processor to suspend execution. For more information see Trapping use of the
WFI and WFE instructions on page B1-1253.

WFI<c>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 1 1 1 1 1 0 0 1 1 0 0 0 0

WFI<c>.W
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 0 1 0 (1) (1) (1) (1) 1 0 (0) 0 (0) 0 0 0 0 0 0 0 0 0 1 1

WFI<c>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 1 0 0 1 0 0 0 0 0 (1) (1) (1) (1) (0) (0) (0) (0) 0 0 0 0 0 0 1 1
Assembler syntax
WFI{<c>}{<q>}
where:
Operation
if HaveVirtExt() && !IsSecure() && !CurrentModeIsHyp() && HCR.TWI == ‘1’ then
else
WaitForInterrupt();
Exceptions
Hyp Trap.
A8.8.427 YIELD
YIELD is a hint instruction. Software with a multithreading capability can use a YIELD instruction to indicate to the
hardware that it is performing a task, for example a spin-lock, that could be swapped out to improve overall system
performance. Hardware can use this hint to suspend and resume multiple software threads if it supports the
capability.
For more information about the recommended use of this instruction see The Yield instruction on page A4-176.

YIELD<c>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 0 1 1 1 1 1 1 0 0 0 1 0 0 0 0

YIELD<c>.W
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 0 1 0 (1) (1) (1) (1) 1 0 (0) 0 (0) 0 0 0 0 0 0 0 0 0 0 1

YIELD<c>
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
cond 0 0 1 1 0 0 1 0 0 0 0 0 (1) (1) (1) (1) (0) (0) (0) (0) 0 0 0 0 0 0 0 1
Assembler syntax
YIELD{<c>}{<q>}
where:
Operation
Hint_Yield();
Exceptions
None.
Chapter A9
The ThumbEE Instruction Set
This chapter describes the ThumbEE instruction set. It contains the following sections:
• About the ThumbEE instruction set on page A9-1112
• ThumbEE instruction set encoding on page A9-1115
• Additional instructions in Thumb and ThumbEE instruction sets on page A9-1116
• ThumbEE instructions with modified behavior on page A9-1117
• Additional ThumbEE instructions on page A9-1123.
A9 The ThumbEE Instruction Set
A9.1 About the ThumbEE instruction set

In general, instructions in ThumbEE are identical to Thumb instructions, with the following exceptions:
• A small number of instructions are affected by modifications to transitions from ThumbEE state. For more
information, see ThumbEE state transitions.
• A substantial number of instructions have a null check on the base register before any other operation takes
place, but are identical (or almost identical) in all other respects. For more information, see Null checking on
page A9-1113.
• A small number of instructions are modified in additional ways. See Instructions with modifications on
page A9-1113.
• Three Thumb instructions, BLX (immediate), 16-bit LDM, and 16-bit STM, are removed in ThumbEE state.
The encoding corresponding to BLX (immediate) in Thumb is UNDEFINED in ThumbEE state.
16-bit LDM and STM are replaced by new instructions, for details see Additional ThumbEE instructions on
page A9-1123.
• Two new 32-bit instructions, ENTERX and LEAVEX, are introduced in both the Thumb instruction set and the
ThumbEE instruction set. See Additional instructions in Thumb and ThumbEE instruction sets on
page A9-1116. These instructions use previously UNDEFINED encodings.
Attempting to execute ThumbEE instructions at PL2 is UNPREDICTABLE.
A9.1.1 ThumbEE state transitions

Instruction set state transitions to ThumbEE state can occur implicitly as part of a return from exception, or
explicitly on execution of an ENTERX instruction.
Instruction set state transitions from ThumbEE state can only occur due to an exception, or due to a transition to
Thumb state using the LEAVEX instruction. Return from exception instructions (RFE and SUBS PC, LR, #imm) are
UNPREDICTABLE in ThumbEE state.
Any other Thumb instructions that can update the PC in ThumbEE state are UNPREDICTABLE if they attempt to
change to ARM state. Interworking of ARM and Thumb instructions is not supported in ThumbEE state. The
instructions affected are:
• LDR, LDM, and POP instructions that write to the PC, if bit[0] of the value loaded to the PC is 0
• BLX (register), BX, and BXJ, where Rm bit[0] == 0.
Note
SVC, BKPT, and UNDEFINED instructions cause an exception to occur.
If a BXJ <Rm> instruction is executed in ThumbEE state, with Rm bit[0] == 1, it does not enter Jazelle state. Instead,
it behaves like the corresponding BX <Rm> instruction and remains in ThumbEE state.
Debug state is a special case. For the rules governing changes to CPSR state bits and Debug state, see Executing
instructions in Debug state on page C5-2084.
A9.1.2 Null checking

A null check is performed for all load/store instructions when they are executed in ThumbEE state. If the value in
the base register is zero, execution branches to the NullCheck handler at HandlerBase – 4.
For most load/store instructions, this is the only difference from normal Thumb operation. Exceptions to this rule
are described in this chapter.
Note
• The null check examines the value in the base register, not any calculated value offset from the base register.
• If the base register is the SP or the PC, a zero value in the base register results in UNPREDICTABLE behavior.
• RFE and SRS instructions do not require null checking because they have UNPREDICTABLE behavior when
executed in ThumbEE state.
The instructions affected by null checking are:

• All instructions whose mnemonic starts with LD, ST, VLD, or VST
• POP, PUSH, TBB, TBH, VPOP, and VPUSH.
For each of these instructions, the pseudocode shown in the Operation section uses the following function:
// NullCheckIfThumbEE()
// ====================
NullCheckIfThumbEE(integer n)
if n == 15 then
if IsZero(Align(PC,4)) then UNPREDICTABLE;
elsif n == 13 then
if IsZero(SP) then UNPREDICTABLE;
else
if IsZero(R[n]) then
LR = PC<31:1> : '1'; // PC holds this instruction's address plus 4
ITSTATE.IT = '00000000';
BranchWritePC(TEEHBR - 4);
EndOfInstruction();
return;
A9.1.3 Instructions with modifications

In addition to the instructions described in ThumbEE state transitions on page A9-1112 and Null checking,
Table A9-1 shows other instructions that are modified in ThumbEE state. The pseudocode, including the null check
if any, is given in ThumbEE instructions with modified behavior on page A9-1117.
Table A9-1 Modified instructions
Instructions Rbase Modification
LDR (register) Rn Rm multiplied by 4, null check
LDRH (register) Rn Rm multiplied by 2, null check
LDRSH (register) Rn Rm multiplied by 2, null check
STR (register) Rn Rm multiplied by 4, null check
STRH (register) Rn Rm multiplied by 2, null check
A9.1.4 IT block and check handlers

CHKA, stores, and loads can occur anywhere in an IT block, except that a load to the PC is permitted only as the last
instruction in the block. If one of these instructions results in a branch to the null pointer or array index handlers,
the IT state bits in ITSTATE are cleared. This provides unconditional execution from the start of the handler.
The original IT state bits are not preserved.
A9.2 ThumbEE instruction set encoding
A9.2 ThumbEE instruction set encoding

In general, instructions in the ThumbEE instruction set are encoded in exactly the same way as Thumb instructions
described in Chapter A6 Thumb Instruction Set Encoding. The differences are as follows:
• There are no 16-bit LDM or STM instructions in the ThumbEE instruction set.
• The 16-bit encodings used for LDM and STM in the Thumb instruction set are used for different 16-bit
instructions in the ThumbEE instruction set. For details, see 16-bit ThumbEE instructions.
• There are two new 32-bit instructions in both Thumb state and ThumbEE state. For details, see Additional
instructions in Thumb and ThumbEE instruction sets on page A9-1116.
A9.2.1 16-bit ThumbEE instructions

The encoding of 16-bit ThumbEE instructions is:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 0 0 Opcode
Table A9-2 16-bit ThumbEE instructions
0000 Handler Branch with Parameter HBP on page A9-1127
0001 UNDEFINED -
001x Handler Branch, Handler Branch with Link HB, HBL on page A9-1125
01xx Handler Branch with Link and Parameter HBLP on page A9-1126
100x Load Register from a frame LDR (immediate) on page A9-1128
1010 Check Array CHKA on page A9-1124
1011 Load Register from a literal pool LDR (immediate) on page A9-1128
110x Load Register (array operations) LDR (immediate) on page A9-1128
111x Store Register to a frame STR (immediate) on page A9-1130
A9.3 Additional instructions in Thumb and ThumbEE instruction sets
A9.3 Additional instructions in Thumb and ThumbEE instruction sets

On a processor with the ThumbEE Extension, there are two additional 32-bit instructions, ENTERX and LEAVEX. These
are available in both Thumb state and ThumbEE state.
A9.3.1 ENTERX, LEAVEX

ENTERX causes a change from Thumb state to ThumbEE state, or has no effect in ThumbEE state.
ENTERX is UNDEFINED in Hyp mode.
LEAVEX causes a change from ThumbEE state to Thumb state, or has no effect in Thumb state.
Encoding T1 ThumbEE
ENTERX Not permitted in IT block.
LEAVEX Not permitted in IT block.
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 1 1 1 0 1 1 (1) (1) (1) (1) 1 0 (0) 0 (1) (1) (1) (1) 0 0 0 J (1) (1) (1) (1)
is_enterx = (J == '1');
Assembler syntax
ENTERX{<q>} Encoded as J = 1
LEAVEX{<q>} Encoded as J = 0
where:
<q> See Standard assembler syntax fields on page A8-285. An ENTERX or LEAVEX instruction must be
unconditional.
Operation
if is_enterx then
if CurrentModeIsHyp() then
UNDEFINED;
else
SelectInstrSet(InstrSet_ThumbEE);
else
SelectInstrSet(InstrSet_Thumb);
Exceptions
None.
A9.4 ThumbEE instructions with modified behavior

The 16-bit encodings of the following Thumb instructions have changed functionality in ThumbEE:
• LDR (register) on page A9-1118
• LDRH (register) on page A9-1119
• LDRSH (register) on page A9-1120
• STR (register) on page A9-1121
• STRH (register) on page A9-1122.
In ThumbEE state there are the following changes in the behavior of instructions:
• All load/store instructions perform null checks on their base register values, as described in Null checking on
page A9-1113. The pseudocode for these instructions in Chapter A8 Instruction Descriptions describes this
by calling the NullCheckIfThumbEE() pseudocode procedure.
• Instructions that attempt to enter ARM state are UNPREDICTABLE, as described in ThumbEE state transitions
on page A9-1112. The pseudocode for these instructions in Chapter A8 Instruction Descriptions describes
this by calling the SelectInstrSet() or BXWritePC() pseudocode procedure.
• The BXJ instruction behaves like the BX instruction, as described in ThumbEE state transitions on
page A9-1112. The pseudocode for the instruction, in BXJ on page A8-352, describes this directly.
A9.4.1 LDR (register)

from memory, and writes it to a register. The offset register value is shifted left by 2 bits. For information about
The similar Thumb instruction does not have a left shift.
Encoding T1 ThumbEE
LDR<c> <Rt>, [<Rn>, <, <Rm>, LSL #2]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 1 1 0 0 Rm Rn Rt
Assembler syntax
LDR{<c>}{<q>} <Rt>, [<Rn>, <Rm>, LSL #2]
where:
<Rn> The base register.
<Rm> Contains the offset that is shifted and applied to the value of <Rn> to form the address.
Operation
address = R[n] + LSL(R[m],2);
R[t] = MemU[address,4];
Exceptions and checks

Data Abort, NullCheck.
A9.4.2 LDRH (register)

Load Register Halfword (register) calculates an address from a base register value and an offset register value, loads
a halfword from memory, zero-extends it to form a 32-bit word, and writes it to a register. The offset register value
is shifted left by 1 bit. For information about memory accesses see Memory accesses on page A8-292.
Encoding T1 ThumbEE
LDRH<c> <Rt>, [<Rn>, <, <Rm>, LSL #1]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 1 1 0 1 Rm Rn Rt
Assembler syntax
LDRH{<c>}{<q>} <Rt>, [<Rn>, <Rm>, LSL #1]
where:
Operation

A9.4.3 LDRSH (register)

Load Register Signed Halfword (register) calculates an address from a base register value and an offset register
value, loads a halfword from memory, sign-extends it to form a 32-bit word, and writes it to a register. The offset
register value is shifted left by 1 bit. For information about memory accesses see Memory accesses on page A8-292.
Encoding T1 ThumbEE
LDRSH<c> <Rt>, [<Rn>, <Rm>, LSL #1]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 1 1 1 1 Rm Rn Rt
Assembler syntax
LDRSH{<c>}{<q>} <Rt>, [<Rn>, <Rm>, LSL #1]
where:
Operation

A9.4.4 STR (register)

Store Register (register) calculates an address from a base register value and an offset register value, and stores a
word from a register to memory. The offset register value is shifted left by 2 bits. For information about memory
Encoding T1 ThumbEE
STR<c> <Rt>, [<Rn>, <Rm>, LSL #2]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 1 0 0 0 Rm Rn Rt
Assembler syntax
STR{<c>}{<q>} <Rt>, [<Rn>, <Rm>, LSL #2]
where:
Operation

A9.4.5 STRH (register)

Store Register Halfword (register) calculates an address from a base register value and an offset register value, and
stores a halfword from a register to memory. The offset register value is shifted left by 1 bit. For information about
Encoding T1 ThumbEE
STRH<c> <Rt>, [<Rn>, <Rm>, LSL #1]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 1 0 1 0 0 1 Rm Rn Rt
Assembler syntax
STRH{<c>}{<q>} <Rt>, [<Rn>, <Rm>, LSL #1]
where:
Operation

A9.5 Additional ThumbEE instructions

The following instructions are available in ThumbEE state, but not in Thumb state:
• CHKA on page A9-1124
• HB, HBL on page A9-1125
• HBLP on page A9-1126
• HBP on page A9-1127
• LDR (immediate) on page A9-1128
• STR (immediate) on page A9-1130.
These are 16-bit instructions. They occupy the instruction encoding space that STMIA and LDMIA occupy in Thumb
state.
A9.5.1 CHKA
CHKA (Check Array) compares the unsigned values in two registers. If the first is lower than, or the same as, the
second, it copies the PC to the LR, and causes a branch to the IndexCheck handler.
Encoding E1 ThumbEE
CHKA<c> <Rn>, <Rm>
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 0 0 1 0 1 0 N Rm Rn
n = UInt(N:Rn); m = UInt(Rm);
Assembler syntax
CHKA{<c>}{<q>} <Rn>, <Rm>
where:
<Rn> The first operand register. This contains the array size. Use of the SP is permitted.
<Rm> The second operand register. This contains the array index.
Operation
if UInt(R[n]) <= UInt(R[m]) then
LR = PC<31:1> : '1'; // PC holds this instruction's address + 4
ITSTATE.IT = '00000000';
BranchWritePC(TEEHBR - 8);

IndexCheck.
Usage
Use CHKA to check that an array index is in bounds.
CHKA does not modify the APSR condition flags.
A9.5.2 HB, HBL

Handler Branch branches to a specified handler.
Handler Branch with Link saves a return address to the LR, and then branches to a specified handler.
Encoding E1 ThumbEE
HB{L}<c> #<HandlerID> Outside or last in IT block
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 0 0 0 0 1 L handler
generate_link = (L == '1'); handler_offset = ZeroExtend(handler:'00000', 32);

Assembler syntax
HB{<c>}{<q>} #<HandlerID> Encoded as L = 0
HBL{<c>}{<q>} #<HandlerID> Encoded as L = 1
where:
<HandlerID> The index number of the handler to be called, in the range 0-255.
Operation
if generate_link then
LR = next_instr_addr<31:1> : '1';
BranchWritePC(TEEHBR + handler_offset);
Exceptions
None.
Usage
HB{L} makes a large number of handlers available.
A9.5.3 HBLP
HBLP (Handler Branch with Link and Parameter) saves a return address to the LR, and then branches to a specified
handler. It passes a 5-bit parameter to the handler in R8.
Encoding E1 ThumbEE
HBLP<c> #<imm>, #<HandlerID> Outside or last in IT block
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 0 0 0 1 imm5 handler
imm32 = ZeroExtend(imm5, 32); handler_offset = ZeroExtend(handler:'00000', 32);

Assembler syntax
HBLP{<c>}{<q>} #<imm>, #<HandlerID>
where:
<imm> The parameter to pass to the handler, in the range 0-31.
Operation
R[8] = imm32;
LR = next_instr_addr<31:1> : '1';
Exceptions
None.
A9.5.4 HBP
HBP (Handler Branch with Parameter) causes a branch to a specified handler. It passes a 3-bit parameter to the
handler in R8.
Encoding E1 ThumbEE
HBP<c> #<imm>, #<HandlerID> Outside or last in IT block
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 0 0 0 0 0 0 imm3 handler
imm32 = ZeroExtend(imm3, 32); handler_offset = ZeroExtend(handler:'00000', 32);

Assembler syntax
HBP{<c>}{<q>} #<imm>, #<HandlerID>
where:
<imm> The parameter to pass to the handler, in the range 0-7.
Operation
R[8] = imm32;
Exceptions
None.
A9.5.5 LDR (immediate)

Load Register (immediate) provides 16-bit instructions to load words using:
• R9 as base register, with a positive offset of up to 63 words, for loading from a frame
• R10 as base register, with a positive offset of up to 31 words, for loading from a literal pool
• R0-R7 as base register, with a negative offset of up to 7 words, for array operations.
Encoding E1 ThumbEE
LDR<c> <Rt>, [R9{, #<imm>}]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 0 0 1 1 0 imm6 Rt
t = UInt(Rt); n = 9; imm32 = ZeroExtend(imm6:'00', 32); add = TRUE;
Encoding E2 ThumbEE
LDR<c> <Rt>, [R10{, #<imm>}]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 0 0 1 0 1 1 imm5 Rt
t = UInt(Rt); n = 10; imm32 = ZeroExtend(imm5:'00', 32); add = TRUE;
Encoding E3 ThumbEE
LDR<c> <Rt>, [<Rn>{, #-<imm>}]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 0 0 1 0 0 imm3 Rn Rt
t = UInt(Rt); n = UInt(Rn); imm32 = ZeroExtend(imm3:'00', 32); add = FALSE;
Assembler syntax
LDR{<c>}{<q>} <Rt>, [<Rn>{, #<imm>}]
where:
<Rn> The base register. This register is:

• R9 for encoding E1
• R10 for encoding E2
• any of R0-R7 for encoding E3.
<imm> The immediate offset used for forming the address. Values are multiples of 4 in the range:
0-252 encoding E1
0-124 encoding E2
–28-0 encoding E3.
Operation
R[t] = MemU[address,4];

A9.5.6 STR (immediate)

Store Register (immediate) provides a 16-bit word store instruction using R9 as base register, with a positive offset
of up to 63 words, for storing to a frame.
Encoding E1 ThumbEE
STR<c> <Rt>, [R9, #<imm>]
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 0 0 1 1 1 imm6 Rt
t = UInt(Rt); imm32 = ZeroExtend(imm6:'00', 32);
Assembler syntax
STR{<c>}{<q>} <Rt>, [R9, #<imm>]
where:
<imm> The immediate offset applied to the value of R9 to form the address. Values are multiples of 4 in the
range 0-252.
Operation
address = R[9] + imm32;

Part B
System Level Architecture
Chapter B1
System Level Programmers’ Model
This chapter provides a system level view of the programmers’ model. It contains the following sections:
• About the System level programmers’ model on page B1-1134
• System level concepts and terminology on page B1-1135
• ARM processor modes and ARM core registers on page B1-1139
• Instruction set states on page B1-1155
• The Security Extensions on page B1-1156
• The Large Physical Address Extension on page B1-1159
• The Virtualization Extensions on page B1-1161
• Exception handling on page B1-1164
• Exception descriptions on page B1-1204
• Coprocessors and system control on page B1-1225
• Advanced SIMD and floating-point support on page B1-1228
• Thumb Execution Environment on page B1-1239
• Jazelle direct bytecode execution on page B1-1240
• Traps to the hypervisor on page B1-1246.
Note
Registers in a VMSA implementation, for example SCTLR. If the register is included in a PMSA implementation,
ARM DDI 0406C.d Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved. B1-1133
B1 System Level Programmers’ Model
B1.1 About the System level programmers’ model
B1.1 About the System level programmers’ model

An application programmer has only a restricted view of the system. The System level programmers’ model
supports this application level view of the system, and includes features required for an operating system (OS) to
provide the programming environment seen by an application.
The system level programmers’ model includes all of the system features required to support operating systems and
to handle hardware events.
System level concepts and terminology on page B1-1135 gives a system level introduction to the basic concepts of
the ARM architecture, and the terminology used for describing the architecture. The rest of this chapter describes
the system level programmers’ model.
The other chapters in this part describe:
• The memory system architectures:

— Chapter B2 Common Memory System Architecture Features describes common features of the
memory system architectures.
— Chapter B3 Virtual Memory System Architecture (VMSA) describes the Virtual Memory System
Architecture (VMSA) used in the ARMv7-A profile.
— Chapter B5 Protected Memory System Architecture (PMSA) describes the Protected Memory System
Architecture (PMSA) used in the ARMv7-R profile.
• The CPUID mechanism, that an OS can use to determine the capabilities of the processor it is running on.
See Chapter B7 The CPUID Identification Scheme.
• The instructions that provide system level functionality, such as returning from an exception. See Chapter B9
System Instructions.
B1-1134 Copyright © 1996-1998, 2000, 2004-2012, 2014, 2018 ARM Limited. All rights reserved. ARM DDI 0406C.d
B1.2 System level concepts and terminology

The following sections introduce a number of concepts that are critical to understanding the system level description
of the architecture:
• Mode, state, and privilege level.
• Exceptions on page B1-1136.
The Virtualization Extensions, described in The Virtualization Extensions on page B1-1161, significantly affect
some areas of ARM terminology. For consistency, this manual applies these changes across all ARMv7
implementations.
B1.2.1 Mode, state, and privilege level

Mode, state, and privilege level are key concepts in the ARM architecture.
Mode
The ARM architecture A and R profiles provide a set of modes that support normal software execution and handle
exceptions. The current mode determines:
• The set of registers that are available to the processor.
• The privilege level of the executing software.
For more information, see ARM processor modes and ARM core registers on page B1-1139.
State
In the ARM architecture, state describes the following distinct concepts:
Instruction set state

ARMv7 provides four instruction set states. The instruction set state determines the instruction set
that is being executed, and is one of ARM state, Thumb state, Jazelle state, or ThumbEE state.
Instruction set state register, ISETSTATE on page A2-50 gives more information about these states.
Execution state
The execution state consists of the instruction set state and some control bits that modify how the
instruction stream is decoded. For details, see Execution state registers on page A2-50 and Program
Status Registers (PSRs) on page B1-1147.
Security state In the ARM architecture, the number of security states depends on whether an implementation
includes the Security Extensions:
• An implementation that includes the Security Extensions provides two security states, Secure
state and Non-secure state. Each security state has its own system registers and memory
address space.
The security state is largely independent of the processor mode. The only exceptions to this
independence of security state and processor mode are:
— Monitor mode, that exists only in the Secure state, and supports transitions between
Secure and Non-secure state.
— Hyp mode, part of the Virtualization Extensions, that exits only in the Non-secure
state, because the Virtualization Extensions only support virtualization of the
Non-secure state.
Some system control resources are only accessible from the Secure state.
For more information, see The Security Extensions on page B1-1156.
• An implementation that does not include the Security Extensions provides only a single
security state.
In this manual:
• Secure software means software running in Secure state.
• Non-secure software means software running in Non-secure state.
Debug state Debug state refers to the processor being halted for debug purposes, because a debug event has
occurred when the processor is configured to Halting debug-mode. See Invasive debug on
page C1-2009.
When the processor is not in Debug state it is described as being in Non-debug state.
Except where explicitly stated otherwise, parts A and B of this manual describe processor behavior
and instruction execution in Non-debug state. Chapter C5 Debug State describes the differences in
Debug state.
Privilege level
Privilege level is an attribute of software execution, in a particular security state, determined by the processor mode,
as follows:
Secure state In Secure state there are two privilege levels:

PL0 Software executed in User mode executes at PL0.
PL1 Software executed in any mode other than User mode executes at PL1.
Non-secure state
In Non-secure state there are two or three privilege levels:
PL0 Software executed in User mode executes at PL0.
PL1 Software executed in any mode other than User or Hyp mode executes at PL1.
PL2 In an implementation that includes the Virtualization Extensions, software executed in
Hyp mode executes at PL2.
Software execution at PL0 is sometimes described as unprivileged execution. A mode associated with a particular
privilege level, PLn, can be described as a PLn mode.
Note
• The privilege level defines the ability to access resources in the current security state, and does not imply
anything about the ability to access resources in the other security state.
• An implementation that does not include the Virtualization Extensions has no Non-secure resources that can
be accessed only from the PL2 privilege level.
For more information see Processor privilege levels, execution privilege, and access privilege on page A3-139.
B1.2.2 Exceptions
An exception is a condition that changes the normal flow of control in a program. The change of flow switches
execution to an exception handler, and the state of the system at the point where the exception occurred is presented
to the exception handler. A key component of the state presented to the handler is the return address, that indicates
the point in the instruction stream from which the exception was taken.
The ARM architecture provides a number of different exceptions as described in Exception handling on
page B1-1164. The architecture defines the mode each exception is taken to. The Security Extensions and
Virtualization Extensions add configuration settings that can determine the mode to which an exception is taken.
Terminology for describing exceptions

In this manual, a number of terms have specific meanings when describing exceptions:
• An exception is generated in one of the following ways:

— Directly as a result of the execution or attempted execution of the instruction stream. For example, an
exception is generated as a result of an undefined instruction.
— Indirectly, as a result of something in the state of the system. For example, an exception is generated
as a result of an interrupt signaled by a peripheral.
• An exception is taken by a processor at the point where it causes a change to the normal flow of control in
the program.
The mode in use immediately before an exception is taken is described as the mode the exception is taken
from. The mode that is used on taking the exception is described as the mode the exception is taken to.
The mode an exception is taken to is determined by:
— The type of exception.
— The mode the exception is taken from.
— Configuration settings in the Security Extensions and Virtualization Extensions.
The architecture defines the mode to which each exception is taken in an implementation that does not
include the Security Extensions. This is called the default mode for that exception.This default mode is
unchanged in an implementation that includes the Security Extensions, however in some circumstances
controls provided by the Security Extensions, or by the Virtualization Extensions, might mean that an
exception is not taken to the default mode for that exception, see Processor mode for taking exceptions on
page B1-1172.
• An exception is described as synchronous if both of the following apply:

— The exception is generated as a result of direct execution or attempted execution of the instruction
stream.
— The return address presented to the exception handler is guaranteed to indicate the instruction that
caused the exception.
• An exception is described as asynchronous if either of the following applies:

— The exception is not generated as a result of direct execution or attempted execution of the instruction
stream.
— The return address presented to the exception handler is not guaranteed to indicate the instruction that
caused the exception.
Note
For a synchronous exception, the exception is taken from the mode in which it was generated. However, for an
asynchronous exception, the processor mode might change after the exception is generated and before it is taken.
Asynchronous exceptions are classified as:
Precise asynchronous exceptions

The state presented to the exception handler is guaranteed to be consistent with the state at an
identifiable instruction boundary in the execution stream from which the exception was taken.
Imprecise asynchronous exceptions

The state presented to the exception handler is not guaranteed to be consistent with any point in the
execution stream from which the exception was taken.
Exceptions, privilege, and security state

ARMv7 has the following security state and privilege requirements for exception handling:
• Exceptions must be taken to a mode with a privilege level of PL1 or higher.
• Within a particular security state:

— An exception must be taken to a mode with a privilege level greater than or equal to the privilege level
of the mode the exception is taken from.
— Exception return must be made to a mode with a privilege level less than or equal to the privilege level
at which the exception handler is executing.
In an implementation that does not include the Security Extensions, this requirement applies to the single
security state of the processor.
• In an implementation that includes the Security Extensions:

— An exception can be taken from any Non-secure mode, including Hyp mode, to Secure Monitor mode.
Note
In ARMv7, privilege levels are defined independently in each security state. Therefore, the rule about
privilege levels is not relevant to taking an exception from a Non-secure mode to a Secure mode.
— An exception can never be taken from a Secure mode to a Non-secure mode.
One effect of these requirements is that an exception taken from Non-secure Hyp mode must be taken to either:
• Non-secure Hyp mode
• Secure Monitor mode.
B1.3 ARM processor modes and ARM core registers

The following sections describe the ARM processor modes and the ARM core registers:
• ARM processor modes.
• ARM core registers on page B1-1143.
• Program Status Registers (PSRs) on page B1-1147.
• ELR_hyp on page B1-1154.
B1.3.1 ARM processor modes

Table B1-1 shows the processor modes defined by the ARM architecture. In this table:
• The Processor mode column gives the name of each mode and the abbreviation used, for example, in the
ARM core register name suffixes used in ARM core registers on page B1-1143.
• The Privilege level column gives the privilege level of software executing in that mode, see Privilege level
on page B1-1136.
• The Encoding column gives the corresponding CPSR.M field.
• The Security state column applies only to processors that implement the Security Extensions.
Table B1-1 ARM processor modes
Processor mode Encoding Privilege level Implemented Security state
User usr 10000 PL0 Always Both
FIQ fiq 10001 PL1 Always Both
IRQ irq 10010 PL1 Always Both
Supervisor svc 10011 PL1 Always Both
Monitor mon 10110 PL1 With Security Extensions Secure only
Abort abt 10111 PL1 Always Both
Hyp hyp 11010 PL2 With Virtualization Extensions Non-secure only
Undefined und 11011 PL1 Always Both
System sys 11111 PL1 Always Both
Mode changes can be made under software control, or can be caused by an external or internal exception.
Notes on the ARM processor modes

User mode An operating system runs applications in User mode to restrict the use of system resources. Software
executing in User mode executes at PL0. Execution in User mode is sometimes described as
unprivileged execution. Application programs normally execute in User mode, and any program
executed in User mode:
• Makes only unprivileged accesses to system resources, meaning it cannot access protected
system resources.
• Makes only unprivileged access to memory.
• Cannot change mode except by causing an exception, see Exception handling on
page B1-1164.
System mode Software executing in System mode executes at PL1. System mode has the same registers available
as User mode, and is not entered by any exception.
Supervisor mode
Supervisor mode is the default mode to which a Supervisor Call exception is taken.
Executing a SVC (Supervisor Call) instruction generates an Supervisor Call exception, that is taken
to Supervisor mode.
A processor enters Supervisor mode on Reset.
Abort mode Abort mode is the default mode to which a Data Abort exception or Prefetch Abort exception is
taken.
Undefined mode
Undefined mode is the default mode to which an instruction-related exception, including any
attempt to execute an UNDEFINED instruction, is taken.
FIQ mode FIQ mode is the default mode to which an FIQ interrupt is taken.
IRQ mode IRQ mode is the default mode to which an IRQ interrupt is taken.
Hyp mode Hyp mode is the Non-secure PL2 mode, implemented as part of the Virtualization Extensions. Hyp
mode is entered on taking an exception from Non-secure state that must be taken to PL2
The Hypervisor Call exception and Hyp Trap exception are exceptions that are implemented as part
of the Virtualization Extensions, and that are always taken in Hyp mode.
Note
This means that Hypervisor Call exceptions and Hyp Trap exceptions cannot be taken from Secure
state.
In a Non-secure PL1 mode, executing a HVC (Hypervisor Call) instruction generates a Hypervisor
Call exception.
For more information, see Hyp mode on page B1-1141.
Monitor mode
Monitor mode is the mode to which a Secure Monitor Call exception is taken.
In a PL1 mode, executing an SMC (Secure Monitor Call) instruction generates a Secure Monitor Call
exception.
Monitor mode is a Secure mode, meaning it is always in the Secure state, regardless of the value of
the SCR.NS bit.
Software running in Monitor mode has access to both the Secure and Non-secure copies of system
registers. This means Monitor mode provides the normal method of changing between the Secure
and Non-secure security states.
Note
It is important to distinguish between:
Monitor mode
This is a processor mode that is only available when an implementation includes the
Security Extensions. It is used in normal operation, as a mechanism to transfer between
Secure and Non-secure state, as described in this section.
Monitor debug-mode
This is a debug mode and is available regardless of whether the implementation includes
the Security Extensions. For more information, see About the ARM Debug architecture
on page C1-2009.
Monitor mode is implemented only as part of the Security Extensions. For more information, see
The Security Extensions on page B1-1156.
Secure and Non-secure modes

In a processor that implements the Security Extensions, most mode names can be qualified as
Secure or Non-secure, to indicate whether the processor is also in Secure state or Non-secure state.
For example:
• If a processor is in Supervisor mode and Secure state, it is in Secure Supervisor mode.
• If a processor is in User mode and Non-secure state, it is in Non-secure User mode.
Note
As indicated in the appropriate Mode descriptions:
• Monitor mode is a Secure mode, meaning it is always in the Secure state
• Hyp mode is a Non-secure mode, meaning it is accessible only in Non-secure state.
Figure B1-1 shows the modes, privilege levels, and security states, for an implementation that includes the Security
Extensions and the Virtualization Extensions.
Non-secure state Secure state

Non-secure PL0 Secure PL0
User mode User mode
Non-secure PL1 Secure PL1

System mode System mode SCR.NS set to 0,
Supervisor mode Supervisor mode Secure
SCR.NS set to 1,
Non-secure FIQ mode FIQ mode
IRQ mode IRQ mode
Undef mode Undef mode
Abort mode Abort mode
Non-secure PL2
Hyp mode
Secure PL1 SCR.NS

Monitor mode can be 0 or 1
Figure B1-1 Modes, privilege levels, and security states
Hyp mode
Hyp mode is a Non-secure mode, implemented only as part of the Virtualization Extensions. It provides the usual
method of controlling almost all of the functionality of the Virtualization Extensions.
Note
The alternative method of controlling this functionality is by accessing the Hyp mode controls from Secure Monitor
mode, with the SCR.NS bit set to 1.
This section summarizes how Hyp mode differs from the other modes, and references where the features of Hyp
mode are described in more detail:
• Software executing in Hyp mode executes at PL2, see Mode, state, and privilege level on page B1-1135.
• Hyp mode is accessible only in Non-secure state. When the processor is in Secure state, setting CPSR.M to
0b11010, the encoding for Hyp mode, has no meaning. Therefore, in Secure state, the effect of attempting to
set CPSR.M to 0b11010 is UNPREDICTABLE. For more information see The Current Program Status Register
(CPSR) on page B1-1147.
• In Non-debug state, the only mechanisms for changing to Hyp mode are:
— An exception taken from a Non-secure PL1 or PL0 mode.
— An exception return from Secure Monitor mode.
• In Hyp mode, the only exception return is execution of an ERET instruction, see ERET on page B9-1968.
• In Hyp mode, the CPACR has no effect on the execution of coprocessor, floating-point, or Advanced SIMD
instructions. The HCPTR controls execution of these instructions in Hyp mode.
• If software running in Hyp mode executes an SVC instruction, the Supervisor Call exception generated by the
instruction is taken to Hyp mode, see SVC (previously SWI) on page A8-721.
• The effect of an exception return with the restored CPSR specifying Hyp mode is UNPREDICTABLE if either:
— SCR.NS is set to 0.
— The return is from a Non-secure PL1 mode.
• The instructions described in the following sections are UNDEFINED if executed in Hyp mode:
— SRS (Thumb) on page B9-1990.
— SRS (ARM) on page B9-1992.
— RFE on page B9-1986.
— LDM (exception return) on page B9-1972.
— LDM (User registers) on page B9-1974.
— STM (User registers) on page B9-1994.
— SUBS PC, LR and related instructions (ARM) on page B9-1998.
— SUBS PC, LR (Thumb) on page B9-1996, when executed with a nonzero constant.
Note
In Thumb state, ERET is encoded as SUBS PC, LR, #0, and therefore this is a valid instruction.
• The unprivileged Load unprivileged and Store unprivileged instructions LDRT, LDRSHT, LDRHT, LDRBT, STRT,
STRHT, and STRBT, are UNPREDICTABLE if executed in Hyp mode.
From reset, the HVC instruction is UNDEFINED in Non-secure PL1 modes, meaning entry to Hyp mode is disabled by
default. To permit entry to Hyp mode using the Hypervisor Call exception, Secure software must enable use of the
HVC instruction by setting the SCR.HCE bit to 1. In addition, when SCR.HCE is set to 0, HVC is UNPREDICTABLE in
Hyp mode.
Pseudocode details of mode operations

The BadMode() function tests whether a 5-bit mode number corresponds to one of the permitted modes:
// BadMode()
// =========
boolean BadMode(bits(5) mode)

case mode of
when '10000' result = FALSE; // User mode
when '10001' result = FALSE; // FIQ mode
when '10010' result = FALSE; // IRQ mode
when '10011' result = FALSE; // Supervisor mode
when '10110' result = !HaveSecurityExt(); // Monitor mode
when '10111' result = FALSE; // Abort mode
when '11010' result = !HaveVirtExt(); // Hyp mode
when '11011' result = FALSE; // Undefined mode
when '11111' result = FALSE; // System mode
otherwise result = TRUE;
return result;
The following pseudocode functions provide information about the current mode:
// CurrentModeIsNotUser()
// ======================
boolean CurrentModeIsNotUser()
if BadMode(CPSR.M) then UNPREDICTABLE;
if CPSR.M == '10000' then return FALSE; // User mode
return TRUE; // Other modes
// CurrentModeIsUserOrSystem()
// ===========================
boolean CurrentModeIsUserOrSystem()
if CPSR.M == '10000' then return TRUE; // User mode
if CPSR.M == '11111' then return TRUE; // System mode
return FALSE; // Other modes
// CurrentModeIsHyp()
// ==================
boolean CurrentModeIsHyp()
if CPSR.M == '11010' then return TRUE; // Hyp mode
return FALSE; // Other modes
B1.3.2 ARM core registers

ARM core registers on page A2-45 describes the application level view of the ARM core registers. This view
provides 16 ARM core registers, R0 to R12, the stack pointer (SP), the link register (LR), and the program counter
(PC). These registers are selected from a larger set of registers, that includes Banked copies of some registers, with
the current register selected by the execution mode. The implementation and banking of the ARM core registers
depends on whether or not the implementation includes the Security Extensions, or the Virtualization Extensions.
Figure B1-2 on page B1-1144 shows the full set of Banked ARM core registers, the Program Status Registers CPSR
and SPSR, and the ELR_hyp Special register.
Note
• The architecture uses system level register names, such as R0_usr, R8_usr, and R8_fiq, when it must identify
a specific register. The application level names refer to the registers for the current mode, and usually are
sufficient to identify a register.
• The Security Extensions and Virtualization Extensions are supported only in the ARMv7-A architecture
profile.
• The Virtualization Extensions require implementation of the Security Extensions.
Application
level view System level view
User System Hyp † Supervisor Abort Undefined Monitor ‡ IRQ FIQ

R0 R0_usr
R1 R1_usr
R2 R2_usr
R3 R3_usr
R4 R4_usr
R5 R5_usr
R6 R6_usr
R7 R7_usr
R8 R8_usr R8_fiq
R9 R9_usr R9_fiq
R10 R10_usr R10_fiq
R11 R11_usr R11_fiq
R12 R12_usr R12_fiq
SP SP_usr SP_hyp SP_svc SP_abt SP_und SP_mon SP_irq SP_fiq
LR LR_usr LR_svc LR_abt LR_und LR_mon LR_irq LR_fiq
PC PC
APSR CPSR
SPSR_hyp SPSR_svc SPSR_abt SPSR_und SPSR_mon SPSR_irq SPSR_fiq
ELR_hyp
‡ Part of the Security Extensions. Exists only in Secure state.
† Part of the Virtualization Extensions. Exists only in Non-secure state.
Cells with no entry indicate that the User mode register is used.
Figure B1-2 ARM core registers, PSRs, and ELR_hyp, showing register banking
As described in Processor mode for taking exceptions on page B1-1172, on taking an exception the processor
changes mode, unless it is already in the mode to which it must take the exception. Each mode that the processor
might enter in this way has:
• A Banked copy of the stack pointer, for example SP_irq and SP_hyp.
• A register that holds a preferred return address for the exception. This is:
— For each PL1 mode, a Banked copy of the link register, for example LR_und and LR_mon.
— For the PL2 mode, Hyp mode, the special register ELR_hyp.
• A saved copy of the CPSR, made on exception entry, for example SPSR_irq and SPSR_hyp.
In addition FIQ mode has Banked copies of the ARM core registers R8 to R12.
User mode and System mode share the same ARM core registers.
User mode, System mode, and Hyp mode share the same LR.
For more information about the application level view of the SP, LR, and PC, and the alternative descriptions of
them as R13, R14 and R15, see ARM core registers on page A2-45.
Pseudocode details of ARM core register operations

The following pseudocode gives access to the ARM core registers:
// The names of the Banked core registers.
enumeration RName {RName_0usr, RName_1usr, RName_2usr, RName_3usr, RName_4usr, RName_5usr,

RName_6usr, RName_7usr, RName_8usr, RName_8fiq, RName_9usr, RName_9fiq,
RName_10usr, RName_10fiq, RName_11usr, RName_11fiq, RName_12usr, RName_12fiq,
RName_SPusr, RName_SPfiq, RName_SPirq, RName_SPsvc,
RName_SPabt, RName_SPund, RName_SPmon, RName_SPhyp,
RName_LRusr, RName_LRfiq, RName_LRirq, RName_LRsvc,
RName_LRabt, RName_LRund, RName_LRmon,

RName_PC};
// The physical array of Banked core registers.

//
// _R[RName_PC] is defined to be the address of the current instruction. The
// offset of 4 or 8 bytes is applied to it by the register access functions.
array bits(32) _R[RName];
// RBankSelect()
// =============
RName RBankSelect(bits(5) mode, RName usr, RName fiq, RName irq,

RName svc, RName abt, RName und, RName mon, RName hyp)
if BadMode(mode) then
UNPREDICTABLE;
else
case mode of
when '10000' result = usr; // User mode
when '10001' result = fiq; // FIQ mode
when '10010' result = irq; // IRQ mode
when '10011' result = svc; // Supervisor mode
when '10110' result = mon; // Monitor mode
when '10111' result = abt; // Abort mode
when '11010' result = hyp; // Hyp mode
when '11011' result = und; // Undefined mode
when '11111' result = usr; // System mode uses User mode registers
return result;
// RfiqBankSelect()
// ================
RName RfiqBankSelect(bits(5) mode, RName usr, RName fiq)

return RBankSelect(mode, usr, fiq, usr, usr, usr, usr, usr, usr);
// LookUpRName()
// =============
RName LookUpRName(integer n, bits(5) mode)

assert n >= 0 && n <= 14;
case n of
when 0 result =RName_0usr;
when 8 result =RfiqBankSelect(mode, RName_8usr, RName_8fiq);
when 9 result =RfiqBankSelect(mode, RName_9usr, RName_9fiq);
when 10 result = RfiqBankSelect(mode, RName_10usr, RName_10fiq);
when 13 result = RBankSelect(mode, RName_SPusr, RName_SPfiq, RName_SPirq,
RName_SPsvc, RName_SPabt, RName_SPund, RName_SPmon, RName_SPhyp);
when 14 result = RBankSelect(mode, RName_LRusr, RName_LRfiq, RName_LRirq,
RName_LRsvc, RName_LRabt, RName_LRund, RName_LRmon, RName_LRusr);
return result;
// Rmode[] - non-assignment form

// =============================
bits(32) Rmode[integer n, bits(5) mode]

assert n >= 0 && n <= 14;
// In Non-secure state, check for attempted use of Monitor mode ('10110'), or of FIQ
// mode ('10001') when the Security Extensions are reserving the FIQ registers. The
// definition of UNPREDICTABLE does not permit this to be a security hole.
if !IsSecure() && mode == '10110' then UNPREDICTABLE;
if !IsSecure() && mode == '10001' && NSACR.RFR == '1' then UNPREDICTABLE;
return _R[LookUpRName(n,mode)];
// Rmode[] - assignment form

// =========================
Rmode[integer n, bits(5) mode] = bits(32) value

assert n >= 0 && n <= 14;
// In Non-secure state, check for attempted use of Monitor mode ('10110'), or of FIQ
// mode ('10001') when the Security Extensions are reserving the FIQ registers. The
// definition of UNPREDICTABLE does not permit this to be a security hole.
if !IsSecure() && mode == '10110' then UNPREDICTABLE;
if !IsSecure() && mode == '10001' && NSACR.RFR == '1' then UNPREDICTABLE;
// Writes of non word-aligned values to SP are only permitted in ARM state.

if n == 13 && value<1:0> != '00' && CurrentInstrSet() != InstrSet_ARM then UNPREDICTABLE;
_R[LookUpRName(n,mode)] = value;
return;
// R[] - non-assignment form

// =========================
bits(32) R[integer n]
assert n >= 0 && n <= 15;
if n == 15 then
offset = if CurrentInstrSet() == InstrSet_ARM then 8 else 4;
result = _R[RName_PC] + offset;
else
result = Rmode[n, CPSR.M];
return result;
// R[] - assignment form

// =====================
R[integer n] = bits(32) value

assert n >= 0 && n <= 14;
Rmode[n, CPSR.M] = value;
return;
// SP - non-assignment form
// ========================
bits(32) SP
return R[13];
// SP - assignment form
// ====================
SP = bits(32) value
R[13] = value;
// LR - non-assignment form
// ========================
bits(32) LR
return R[14];
// LR - assignment form
// ====================
LR = bits(32) value
R[14] = value;
// PC - non-assignment form
// ========================
bits(32) PC
return R[15];
// BranchTo()
// ==========
BranchTo(bits(32) address)
_R[RName_PC] = address;
return;
B1.3.3 Program Status Registers (PSRs)

The Application level programmers’ model provides the Application Program Status Register, see The Application
Program Status Register (APSR) on page A2-49. This is an application level alias for the Current Program Status
Register (CPSR). The system level view of the CPSR extends the register, adding system level information.
Every mode that an exception can be taken to has its own saved copy of the CPSR, the Saved Program Status
Register (SPSR), as shown in Figure B1-2 on page B1-1144. For example, the SPSR for Monitor mode is called
SPSR_mon.
The Current Program Status Register (CPSR)

The Current Program Status Register (CPSR) holds processor status and control information:
• The APSR, see The Application Program Status Register (APSR) on page A2-49.
• The current instruction set state, see Instruction set state register, ISETSTATE on page A2-50.
• The execution state bits for the Thumb If-Then instruction, see IT block state register, ITSTATE on
page A2-51.
• The current endianness, see Endianness mapping register, ENDIANSTATE on page A2-53.
• The current processor mode.
• Interrupt and asynchronous abort disable bits.
The non-APSR bits of the CPSR have defined reset values. These are shown in the TakeReset() pseudocode
function, see Reset on page B1-1204.
Writes to the CPSR have side-effects on various aspects of processor operation. All of these side-effects, except for
those on memory accesses associated with fetching instructions, are synchronous to the CPSR write. This means
they are guaranteed:
• Not to be visible to earlier instructions in the execution stream.
• To be visible to later instructions in the execution stream.
The privilege level and address space of memory accesses associated with fetching instructions depend on the
current privilege level and security state. Writes to CPSR.M can change one of both of the privilege level and
security state. The effect, on memory accesses associated with fetching instructions, of a change of privilege level
or security state is:
• Synchronous to the change of privilege level or security state, if that change is caused by an exception entry
or exception return.
• Guaranteed not to be visible to any memory access caused by fetching an earlier instruction in the execution
stream.
• Guaranteed to be visible to any memory access caused by fetching any instruction after the next context
synchronization operation in the execution stream.
Note
See Context synchronization operation for the definition of this term.
• Might or might not affect memory accesses caused by fetching instructions between the mode change
instruction and the point where the mode change is guaranteed to be visible.
See Exception return on page B1-1193 for the definition of exception return instructions.
The Saved Program Status Registers (SPSRs)

The purpose of an SPSR is to record the pre-exception value of the CPSR. On taking an exception, the CPSR is
copied to the SPSR of the mode to which the exception is taken. Saving this value means the exception handler can:
• On exception return, restore the CPSR to the value it had immediately before the exception was taken.
• Examine the value that the CPSR had when the exception was taken, for example to determine the instruction
set state and privilege level in which the instruction that caused an Undefined Instruction exception was
executed.
Figure B1-2 on page B1-1144 shows the banking of the SPSRs.
The SPSRs are UNKNOWN on reset. Any operation in a Non-secure PL1 or PL0 mode makes SPSR_hyp UNKNOWN.
Format of the CPSR and SPSRs

The CPSR and SPSR bit assignments are:
31 30 29 28 27 26 25 24 23 20 19 16 15 10 9 8 7 6 5 4 3 2 1 0
Reserved,
N Z C V Q J GE[3:0] IT[7:2] E A I F T M[4:0]
RAZ/SBZP
Condition flags IT[1:0] Mask bits
Condition flags, bits[31:28]

Set on the result of instruction execution. The flags are:
N, bit[31] Negative condition flag.
Z, bit[30] Zero condition flag.
C, bit[29] Carry condition flag.
V, bit[28] Overflow condition flag.
The condition flags can be read or written in any mode, and are described in The Application
Program Status Register (APSR) on page A2-49.
Q, bit[27] Cumulative saturation bit. This bit can be read or written in any mode, and is described in The
IT[7:0], bits[15:10, 26:25]

If-Then execution state bits for the Thumb IT (If-Then) instruction. IT block state register, ITSTATE
on page A2-51 describes the encoding of these bits. CPSR.IT[7:0] are the IT[7:0] bits described
there. For more information, see IT on page A8-391.
For details of how these bits can be accessed see Accessing the execution state bits on page B1-1150.
J, bit[24] Jazelle bit, see the description of the T bit, bit[5].
Bits[23:20] Reserved. RAZ/SBZP.
GE[3:0], bits[19:16]
Greater than or Equal flags, for the parallel addition and subtraction (SIMD) instructions described
in Parallel addition and subtraction instructions on page A4-169.
The GE[3:0] field can be read or written in any mode, and is described in The Application Program
Status Register (APSR) on page A2-49.
E, bit[9] Endianness execution state bit. Controls the load and store endianness for data accesses:
0 Little-endian operation.
1 Big-endian operation.
Instruction fetches ignore this bit.
Endianness mapping register, ENDIANSTATE on page A2-53 describes the encoding of this bit.
CPSR.E is the ENDIANSTATE bit described there.
For details of how this bit can be accessed see Accessing the execution state bits on page B1-1150.
When the reset value of the SCTLR.EE bit is defined by a configuration input signal, that value also
applies to the CPSR.E bit on reset, and therefore applies to software execution from reset.
Mask bits, bits[8:6]

These bits are:
A, bit[8] Asynchronous abort mask bit.
I, bit[7] IRQ mask bit.
F, bit[6] FIQ mask bit.
The possible values of each bit are:
0 Exception not masked.
1 Exception masked.
The A bit has no effect on any Data Abort exception generated by a Watchpoint debug event, even
if that exception is asynchronous. For more information see Debug exception on Watchpoint debug
event on page C4-2077.
In an implementation that does not include the Security Extensions, setting a mask bit masks the
corresponding exception, meaning it cannot be taken. However, the Security Extensions and
Virtualization Extensions significantly alter the behavior and effect of these bits, see Effects of the
Security Extensions on the CPSR A and F bits on page B1-1151 and Asynchronous exception
masking on page B1-1183.
In Non-debug state, the mask bits can be written only at PL1 or higher. Their values can be read in
any mode, but ARM deprecates any use of their values, or attempt to change them, by software
executing at PL0.
For more information about the behavior of these bits in Debug state, see Behavior of MRS and MSR
instructions that access the CPSR in Debug state on page C5-2085.
Updates to the F bit are restricted if Non-maskable FIQs (NMFIs) are supported, see Non-maskable
FIQs on page B1-1151.
T, bit[5] Thumb execution state bit. This bit and the J execution state bit, bit[24], determine the instruction
set state of the processor, ARM, Thumb, Jazelle, or ThumbEE. Instruction set state register,
ISETSTATE on page A2-50 describes the encoding of these bits. CPSR.J and CPSR.T are the same
bits as ISETSTATE.J and ISETSTATE.T respectively. For more information, see Instruction set
states on page B1-1155.
For details of how these bits can be accessed see Accessing the execution state bits on page B1-1150.
M[4:0], bits[4:0]
Mode field. This field determines the current mode of the processor. The permitted values of this
field are listed in Table B1-1 on page B1-1139. All other values of M[4:0] are reserved. The effect
of setting M[4:0] to a reserved value is UNPREDICTABLE.
Note
See the entry for UNPREDICTABLE in the Glossary for the restrictions on UNPREDICTABLE
behavior. These restrictions mean that, for any CPSR.M value that is defined as UNPREDICTABLE in
Non-secure state, the UNPREDICTABLE behavior must not cause entry to Secure state, or to any mode
that the current configuration settings mean is not accessible in Non-secure state.
For more information about the processor modes see ARM processor modes on page B1-1139.
Figure B1-2 on page B1-1144 shows the registers that can be accessed in each mode.
In a Non-debug state, this field can be written only at PL1 or higher. Its value can be read in any
mode, but ARM deprecates software executing at PL0 making any use of its value, or attempting to
change it.
In an implementation that includes the Security Extensions, except as a result of an exception entry
or exception return:
• Attempting to change CPSR.M to enter Monitor mode from Non-secure state is
UNPREDICTABLE.
• When NSACR.RFR is set to 1, attempting to change CPSR.M to enter FIQ mode from
Non-secure state is UNPREDICTABLE.
From the introduction of the Virtualization Extensions, ARM deprecates any use of
NSACR.RFR.
In an implementation that includes the Virtualization Extensions, except as a result of an exception
entry or exception return:
• Attempting to change CPSR.M to enter Hyp mode from any mode other than Hyp mode is
UNPREDICTABLE.
• Attempting to change CPSR.M to enter any mode other than Hyp mode from Hyp mode is
UNPREDICTABLE.
For more information about the behavior of this field in Debug state, see Behavior of MRS and MSR
instructions that access the CPSR in Debug state on page C5-2085.
Accessing the execution state bits

The execution state bits are the IT[7:0], J, E, and T bits. If the current mode has an SPSR, software can read or write
these bits in the SPSR.
In the CPSR, unless the processor is in Debug state:

• The execution state bits, other than the E bit, are RAZ when read by an MRS instruction.
• Writes to the execution state bits, other than the E bit, by an MSR instruction are:
— For ARMv7 and ARMv6T2, ignored in all modes.
— For architecture variants before ARMv6T2, ignored in User mode and required to write zeros in other
modes. If a nonzero value is written at PL1, behavior is UNPREDICTABLE.
Instructions other than MRS and MSR that access the execution state bits can read and write them in any mode.
Unlike the other execution state bits in the CPSR, at PL1 or above CPSR.E can be read by an MRS instruction and
written by an MSR instruction. However, ARM deprecates:
• Using the CPSR.E value read by an MRS instruction.
• Using an MSR instruction to change the value of CPSR.E.
At PL0, a read of the CPSR by an MSR instruction returns an UNKNOWN value for the E bit, and a write by an MSR
instruction has no effect on the E bit.
Note
• Software can use the SETEND instruction to change the current endianness.
• To determine the current endianness, software can use an LDR instruction to load a word of memory with a
known value that differs if the endianness is reversed. For example, using an LDR (literal) instruction to load
a word whose four bytes are 0x01, 0x00, 0x00, and 0x00 in ascending order of memory address loads the
destination register with:
— 0x00000001 if the current endianness is little-endian.
— 0x01000000 if the current endianness is big-endian.
For more information about the behavior of these bits in Debug state see Behavior of MRS and MSR instructions
that access the CPSR in Debug state on page C5-2085.
Non-maskable FIQs
Some ARMv7 implementations can be configured so that the CPSR.F bit cannot be set to 1 by an MSR or CPS
instruction. This is defined as Non-maskable FIQ (NMFI) operation. In such an implementation, this configuration
is controlled by a configuration input signal, that is asserted HIGH to enable NMFI operation.
Note
There is no software control of NMFI operation.
The Virtualization Extensions do not support NMFIs. Otherwise, it is IMPLEMENTATION DEFINED whether an
ARMv7 processor supports NMFIs. In all cases, software can detect whether FIQs are maskable by reading the
SCTLR.NMFI bit:
NMFI == 0 Software can mask FIQs by setting the CPSR.F bit to 1.
NMFI == 1 Software cannot set the CPSR.F bit to 1. This means software cannot mask FIQs.
For more information see either:

• SCTLR, System Control Register, VMSA on page B4-1700.
• SCTLR, System Control Register, PMSA on page B6-1921.
When the SCTLR.NMFI bit is 1:
• An instruction writing 0 to the CPSR.F bit clears it to 0, but an instruction attempting to write 1 to it leaves
it unchanged.
• CPSR.F can be set to 1 only by exception entries, as described in CPSR.{A, I, F, M} values on exception entry
on page B1-1181.
In an implementation that includes the Security Extensions, this restriction on accessing CPSR.F interacts with the
SCR.FW control, as described in Effects of the Security Extensions on the CPSR A and F bits.
Effects of the Security Extensions on the CPSR A and F bits

In an implementation that includes the Security Extensions:
• If the implementation does not include the Virtualization Extensions, when the processor is in Non-secure
state:
— The CPSR.F bit cannot be changed if the SCR.FW bit is set to 0.
— The CPSR.A bit cannot be changed if the SCR.AW bit is set to 0.
• If the implementation includes the Virtualization Extensions, clearing the SCR.FW and SCR.AW bits to 0
does not affect the ability to change the CPSR.F and CPSR.A bits, but does prevent those bit from masking
exceptions in some situations.
For more information see Asynchronous exception masking on page B1-1183.
Note
For an implementation that includes the Security Extensions but not the Virtualization Extensions, when the
processor is in the Non-secure state, software executing at PL1 can change the SPSR.F and SPSR.A bits even if the
corresponding bits in the SCR are set to 0. However, when the SPSR is copied to the CPSR the CPSR.F and CPSR.A
bits are not updated if the corresponding bits in the SCR are set to 0.
For an implementation that includes the Security Extensions but not the Virtualization Extensions, Table B1-2
shows how, in Non-secure state, SCR.FW interacts with SCTLR.NMFI to control possible updates to CPSR.F bit.
The table includes the SCTLR.NMFI controls in Secure state.
Table B1-2 NMFI behavior, Security Extensions implemented without the Virtualization Extensions
Security state SCR.FW bit SCTLR.NMFI bit CPSR.F bit properties
Secure x 0 F bit can be written to 0 or 1
1 F bit can be written to 0 but not to 1
Non-secure 0 x F bit cannot be written
1 0 F bit can be written to 0 or 1
1 F bit can be written to 0 but not to 1
Note
The SCTLR.NMFI bit is common to the Secure and Non-secure versions of the SCTLR, because it is a read-only
bit that reflects the value of a configuration input signal.
The Virtualization Extensions do not support NMFIs. In an implementation that includes the Virtualization
Extensions, SCTLR.NMFI is RAZ.
Pseudocode details of PSR operations

The following pseudocode gives access to the PSRs:
bits(32) CPSR, SPSR_fiq, SPSR_irq, SPSR_svc, SPSR_mon, SPSR_abt, SPSR_und, SPSR_hyp;
// SPSR[] - non-assignment form

// ============================
bits(32) SPSR[]
if BadMode(CPSR.M) then
UNPREDICTABLE;
else
bits(32) result;
case CPSR.M of
when '10001' result = SPSR_fiq; // FIQ mode
when '10010' result = SPSR_irq; // IRQ mode
when '10011' result = SPSR_svc; // Supervisor mode
when '10110' result = SPSR_mon; // Monitor mode
when '10111' result = SPSR_abt; // Abort mode
when '11010' result = SPSR_hyp; // Hyp mode
when '11011' result = SPSR_und; // Undefined mode
otherwise UNPREDICTABLE;
return result;
// SPSR[] - assignment form

// ========================
SPSR[] = bits(32) value

if BadMode(CPSR.M) then
UNPREDICTABLE;
else
case CPSR.M of
when '10001' SPSR_fiq = value; // FIQ mode
when '10010' SPSR_irq = value; // IRQ mode
when '10011' SPSR_svc = value; // Supervisor mode
when '10110' SPSR_mon = value; // Monitor mode
when '10111' SPSR_abt = value; // Abort mode
when '11010' SPSR_hyp = value; // Hyp mode
when '11011' SPSR_und = value; // Undefined mode

otherwise UNPREDICTABLE;
return;
// CPSRWriteByInstr()
// ==================
CPSRWriteByInstr(bits(32) value, bits(4) bytemask, boolean is_excpt_return)

privileged = CurrentModeIsNotUser();
nmfi = (SCTLR.NMFI == '1');
if bytemask<3> == '1' then

CPSR<31:27> = value<31:27>; // N,Z,C,V,Q flags
if is_excpt_return then
CPSR<26:24> = value<26:24>; // IT<1:0>,J execution state bits

// bits <23:20> are reserved SBZP bits
CPSR<19:16> = value<19:16>; // GE<3:0> flags

CPSR<15:10> = value<15:10>; // IT<7:2> execution state bits
CPSR<9> = value<9>; // E bit is user-writable
if privileged && (IsSecure() || SCR.AW == '1' || HaveVirtExt()) then
CPSR<8> = value<8>; // A interrupt mask

if privileged then
CPSR<7> = value<7>; // I interrupt mask
if privileged && (!nmfi || value<6> == '0') &&
(IsSecure() || SCR.FW == '1' || HaveVirtExt()) then
CPSR<6> = value<6>; // F interrupt mask
CPSR<5> = value<5>; // T execution state bit
if privileged then
if BadMode(value<4:0>) then
UNPREDICTABLE;
else
// Check for attempts to enter modes only permitted in Secure state from
// Non-secure state. These are Monitor mode ('10110'), and FIQ mode ('10001')
// if the Security Extensions have reserved it. The definition of UNPREDICTABLE
// does not permit the resulting behavior to be a security hole.
if !IsSecure() && value<4:0> == '10110' then UNPREDICTABLE;
if !IsSecure() && value<4:0> == '10001' && NSACR.RFR == '1' then UNPREDICTABLE;
// There is no Hyp mode ('11010') in Secure state, so that is UNPREDICTABLE
if SCR.NS == '0' && value<4:0> == '11010' then UNPREDICTABLE;
// Cannot move into Hyp mode directly from a Non-secure PL1 mode
if !IsSecure() && CPSR.M != '11010' && value<4:0> == '11010' then
UNPREDICTABLE;
// Cannot move out of Hyp mode with this function except on an exception return
if CPSR.M == '11010' && value<4:0> != '11010' && !is_excpt_return then
UNPREDICTABLE;
CPSR.M = value<4:0>; // CPSR<4:0>, mode bits
return;
// SPSRWriteByInstr()
// ==================
SPSRWriteByInstr(bits(32) value, bits(4) bytemask)
if CurrentModeIsUserOrSystem() then UNPREDICTABLE;

SPSR[]<31:24> = value<31:24>; // N,Z,C,V,Q flags, IT<1:0>,J execution state bits
// bits <23:20> are reserved SBZP bits

SPSR[]<19:16> = value<19:16>; // GE<3:0> flags

SPSR[]<15:8> = value<15:8>; // IT<7:2> execution state bits, E bit, A interrupt mask

SPSR[]<7:5> = value<7:5>; // I,F interrupt masks, T execution state bit
if BadMode(value<4:0>) then // Mode bits
UNPREDICTABLE;
else
SPSR[]<4:0> = value<4:0>;
return;
B1.3.4 ELR_hyp
Hyp mode does not provide its own Banked copy of LR. Instead, on taking an exception to Hyp mode, the preferred
return address is stored in ELR_hyp, a 32-bit Special register implemented for this purpose.
ELR_hyp is implemented only as part of the Virtualization Extensions.
ELR_hyp can be accessed explicitly only by executing:

• An MRS or MSR instruction that targets ELR_hyp, see:
— MRS (Banked register) on page B9-1978.
— MSR (Banked register) on page B9-1980.
The ERET instruction uses the value in ELR_hyp as the return address for the exception. For more information, see
ERET on page B9-1968.
Software execution in any Non-secure PL1 or PL0 mode makes ELR_hyp UNKNOWN.
For more information about the use of ELR_hyp see Exceptions on page B1-1136.
B1.4 Instruction set states
B1.4 Instruction set states

The instruction set states are described in Chapter A2 Application Level Programmers’ Model and application level
operations on them are described there. This section supplies more information about how they interact with system
level functionality, in the sections:
• Exceptions and instruction set state.
• Unimplemented instruction sets.
B1.4.1 Exceptions and instruction set state

If an exception is taken to a PL1 mode, the SCTLR.TE bit for the security state the exception is taken to determines
the processor instruction set state that handles the exception, and if necessary, the processor changes to this
instruction set state on exception entry.
If the exception is taken to Hyp mode, the HSCTLR.TE bit determines the processor instruction set state that
handles the exception, and if necessary, the processor changes to this instruction set state on exception entry.
On coming out of reset, the processor starts execution in Supervisor mode, in the instruction set state determined by
the reset value of SCTLR.TE.
For more information see:
• For a VMSA implementation:
— SCTLR, System Control Register, VMSA on page B4-1700.
— HSCTLR, Hyp System Control Register, Virtualization Extensions on page B4-1587.
• For a PMSA implementation, SCTLR, System Control Register, PMSA on page B6-1921.
For more information about exception entry see Overview of exception entry on page B1-1169.
B1.4.2 Unimplemented instruction sets

The CPSR.J and CPSR.T bits define the current instruction set state, see Instruction set state register, ISETSTATE
on page A2-50.
In the ARMv7 architecture:
• The Jazelle state:

— Before the introduction of the Virtualization Extensions, is optional. ARM does not recommend
support for Jazelle state in any ARMv7 implementation.
— Is obsoleted by the introduction of the Virtualization Extensions. An ARMv7-A implementation that
includes the Virtualization Extensions cannot support Jazelle state.
• The ThumbEE state is optional in the ARMv7-R architecture. ARM does not recommend support for
ThumbEE state in any ARMv7-R implementation.
Some system instructions permit setting CPSR.{J, T} to values that select an unimplemented instruction set state,
for example setting CPSR.J to 1 and CPSR.T to 0 on an processor that does not implement the Jazelle state. If such
values are written to CPSR.{J, T}, the implementation behaves in one of these ways:
• Sets CPSR.{J, T} to the requested values and causes the next instruction to generate an Undefined Instruction
exception, as described in Exception return to an unimplemented instruction set state on page B1-1196.
• Does not set CPSR.{J, T} to the requested values. The processor might change the value of one or both of
the bits in such a way that the new values correspond to an implemented instruction set state. If this is done
then the instruction set state changes to this new state. The detailed behavior of the attempt to change to an
unimplemented state is IMPLEMENTATION DEFINED.
B1.5 The Security Extensions

The Security Extensions are an OPTIONAL extension to the ARMv7-A architecture profile. When implemented, the
Security Extensions integrate hardware security features into the architecture, to facilitate the development of secure
applications. Many features of the architecture are extended to integrate with the Security Extensions, and because
of this integration of the Security Extensions into the architecture, features of the Security Extensions are described
in many sections of this manual.
Note
The Security Extensions are also permitted as an extension to the ARMv6K architecture. The resulting combination
is sometimes called the ARMv6Z or ARMv6KZ architecture.
The following sections give general information about the Security Extensions:
• Security states.
• Impact of the Security Extensions on the modes and exception model on page B1-1157.
• Security Extensions features added by the Virtualization Extensions on page B1-1158.
• Classification of system control registers on page B3-1447.
B1.5.1 Security states

The Security Extensions define two security states, Secure state and Non-secure state. All instruction execution
takes place either in Secure state or in Non-secure state:
• Each security state operates in its own virtual memory address space, with its own translation regime.
Note
Figure B3-1 on page B3-1307 shows the different translation regimes.
• Many system controls can be set independently in each of the security states.
• All of the processor modes that are available in a system that does not implement the Security Extensions are
available in each of the security states. However:
— In any implementation that includes the Security Extensions, Monitor mode is available only in Secure
state.
— In an implementation that also includes the Virtualization Extensions, Hyp mode is available only in
Non-secure state.
The Security Extensions also define an additional processor mode, Monitor mode, that provides a bridge between
software running in Non-secure state and software running in Secure state, see Changing from Secure to Non-secure
state on page B1-1157.
The following features mean the two security states can provide more security than is typically provided by systems
using the split between the different levels of execution privilege:
• The memory system provides mechanisms that prevent the Non-secure state accessing regions of the physical
memory designated as Secure.
• System controls that apply to the Secure state are not accessible from the Non-secure state.
• Entry to the Secure state from the Non-secure state is provided only by a small number of exceptions.
• Exit from the Secure state to the Non-secure state is provided only by a small number of mechanisms.
• Many operating system and hypervisor exceptions can be handled without changing security state.
The fundamental mechanism that determines the security state is the SCR.NS bit:
• For all modes other than Monitor mode and Hyp mode, the SCR.NS bit determines the security state for
software execution.
• In an implementation that includes the Virtualization Extensions, Hyp mode is available only in Non-secure
state, meaning it is available only when the SCR.NS bit is set to 1.
• Software executing in Monitor mode executes in the Secure state regardless of the value of the SCR.NS bit.
The ARM core registers and the processor status registers are not Banked between the Secure and the Non-secure
states. ARM expects that, when switching execution between the Non-secure and Secure states, a kernel running
mostly in Monitor mode will switch the values of these registers.
The registers LR_mon and SPSR_mon are UNKNOWN when executing in Non-secure state.
Many of the system registers referred to in Coprocessors and system control on page B1-1225 are Banked between
the Secure and Non-secure security states. A Banked copy of a register applies only to execution in the appropriate
security state. A small number of system registers are not Banked but apply to both the Secure and Non-secure
security states. The registers that are not Banked relate to global system configuration options that ARM expects to
be common to the two security states.
Changing from Secure to Non-secure state

Monitor mode is provided to support switching between Secure and Non-secure states. Except in Monitor mode and
Hyp mode, the security state is controlled by the SCR.NS bit. Software executing in a Secure PL1 mode can change
the SCR, but ARM strongly recommends that software obeys the following rules for changing SCR.NS:
• To avoid security holes, software must not:

— Change from Secure to Non-secure state by using an MSR or CPS instruction to switch from Monitor
mode to some other mode while SCR.NS is 1.
— Use an MCR instruction that writes SCR.NS to change from Secure to Non-secure state. This means
ARM recommends that software does not alter SCR.NS in any mode except Monitor mode. ARM
deprecates changing SCR.NS in any other mode.
Note
When the value of NSACR.RFR is 1, if the processor is in Secure FIQ mode, the effect of changing SCR.NS
to 1 is UNPREDICTABLE.
• The usual mechanism for changing from Secure to Non-secure state is an exception return.To return to
Non-secure state, software executing in Monitor mode sets SCR.NS to 1 and then performs the exception
return.
Pseudocode details of Secure state operations

The HaveSecurityExt() function returns TRUE if the implementation includes the Security Extensions, and FALSE
otherwise.
The IsSecure() function returns TRUE if the processor is in Secure state, or if the implementation does not include
the Security Extensions, and FALSE otherwise.
// IsSecure()
// ==========
boolean IsSecure()
return !HaveSecurityExt() || SCR.NS == '0' || CPSR.M == '10110'; // Monitor mode
B1.5.2 Impact of the Security Extensions on the modes and exception model
This section gives an overview of the effect of the Security Extensions on the modes and exception model:
• Monitor mode is implemented only as part of the Security Extensions. For more information, see ARM
processor modes on page B1-1139 and Security states on page B1-1156.
• The Secure Monitor Call (SMC) exception is implemented only as part of the Security Extensions. The SMC
instruction generates this exception. For more information, see Secure Monitor Call (SMC) exception on
page B1-1210 and SMC (previously SMI) on page B9-1988.
• For exceptions taken to any PL1 mode, because the SCTLR is Banked between the Secure and Non-secure
states, the V and VE bits are defined independently for the Secure and Non-secure states. For each state:
— The SCTLR.V bit controls whether the low or the high exception vectors are used.
— For the IRQ and FIQ exceptions, the SCTLR.VE bit controls whether the IRQ and FIQ vectors are
For more information, see Exception vectors and the exception base address on page B1-1164.
• For exceptions taken to any PL1 mode, the base address for the low exception vectors is held in a register
that is Banked between the two security states, meaning this base address is defined independently for each
security state.
Another register holds the base address for exceptions taken to Monitor mode.
For more information, see Exception vectors and the exception base address on page B1-1164.
• Setting bits in the SCR to 1 causes one or more of external aborts, IRQs and FIQs to be taken to Monitor
mode and to use the Monitor exception base address, see Asynchronous exception routing controls on
page B1-1174.
• When an exception is taken from Monitor mode in Non-debug state, SCR.NS is set to zero, to ensure that the
exception is taken to Secure state. However, if an exception is taken from Monitor mode in Debug state, the
exception entry does not change the value of SCR.NS.
Note
Many uses of the Security Extensions can be simplified if the system is designed so that exceptions cannot
be taken from Monitor mode.
• Clearing bits in the SCR to 0 prevents software executing in Non-secure state from being able to mask one
or both of asynchronous aborts and FIQs. The mechanism to do this depends on whether the implementation
includes the Virtualization Extensions, see Asynchronous exception masking on page B1-1183. With either
mechanism:
— Clearing the SCR.AW bit to 0 prevents Non-secure masking of asynchronous aborts that are taken to
Monitor mode.
— Clearing the SCR.FW bit to 0 prevents Non-secure masking of FIQs that are taken to Monitor mode.
B1.5.3 Security Extensions features added by the Virtualization Extensions

In an implementation that includes the Virtualization Extensions, the following features are added to the Security
Extensions:
• When the SCR.SIF bit is set to 1, any instruction fetched from Non-secure physical memory cannot be
executed in Secure state. For more information, see Restriction on Secure instruction fetch on page B3-1357.
• SCTLR and HSCTLR include WXN bits that, when set to 1, prevent instruction execution from writable
memory regions.
Similarly, setting SCTLR.UWXN to 1 prevents instruction execution from any memory region that
unprivileged software can write to.
For more information see Preventing execution from writable locations on page B3-1357.
• When the SCR.SCD bit is set to 1, entry to Secure state by taking a Secure Monitor Call exception is disabled.
This means that, when SCR.SCD is set to 1:
— An SMC instruction executed in Non-secure state, and not trapped by the HCR.TSC mechanism
described in Trapping use of the SMC instruction on page B1-1253, is UNDEFINED.
— An SMC instruction executed in a Secure PL1 mode is UNPREDICTABLE.
For more information, see SMC (previously SMI) on page B9-1988.
B1.6 The Large Physical Address Extension

The Large Physical Address Extension is an OPTIONAL extension to the ARMv7-A architecture profile. Any
implementation that includes the Large Physical Address Extension must also include the Multiprocessing
Extensions.
The Large Physical Address Extension adds a new translation table format:
• The format used in an implementation that does not include the Large Physical Address Extension is now
called the Short-descriptor format, see Short-descriptor translation table format on page B3-1321.
• The format added by the Large Physical Address Extension is the Long-descriptor format, see
Long-descriptor translation table format on page B3-1334.
An implementation that includes the Large Physical Address Extension must support both translation table formats.
Other effects of the Large Physical Address Extension are described throughout this manual, and include:
• Changes to the permitted attributes for Device memory regions, see Summary of ARMv7 memory attributes
on page A3-124 and Device and Strongly-ordered memory shareability, Large Physical Address Extension
on page A3-135.
Note
The ordering requirements for Device accesses are identical to those for Strongly-ordered accesses, see
Ordering requirements for memory accesses on page A3-146.
• The addition of a requirement that LDRD and STRD accesses to 64-bit aligned locations are 64-bit single-copy
atomic as seen by translation table walks and accesses to translation tables, see Single-copy atomicity on
page A3-125.
• Requiring the Short-descriptor translation table format to include the Privileged execute-never (PXN)
attribute, see Memory attributes in the Short-descriptor translation table format descriptors on
page B3-1325.
Note
— In an implementation that does not include the Large Physical Address Extension, the inclusion of the
PXN attribute in the Short-descriptor translation table format is OPTIONAL.
— The Long-descriptor translation table format always includes the PXN attribute.
• An implementation that includes the Large Physical Address Extension must implement the Multiprocessing
Extensions and therefore cannot include the FCSE, see Use of the Fast Context Switch Extension on
page D9-2463.
• The Large Physical Address Extension:

— Extends the DBGDRAR and DBGDSAR to 64 bits, to hold PAs of up to 40 bits.
— Defines new formats for the DFSR, IFSR, and TTBCR, for use with the Long-descriptor translation
table format.
— Adds bits to the DFSR and IFSR formats used with the Long-descriptor translation table format.
DFSR.CM indicates when a fault is caused by a cache maintenance or address translation operation.
DFSR.LPAE and IFSR.LPAE indicate the translation table format in use when the fault was generated.
— Extends the PAR to 64 bits, to hold PAs of up to 40 bits.
— Extends TTBR0 and TTBR1 to 64 bits, to support the Long-descriptor translation table format.
— Defines two Memory Attribute Indirection Registers, MAIR0 and MAIR1, to replace PRRR and
NMRR when using the Long-descriptor translation table format.
— Provides two IMPLEMENTATION DEFINED Auxiliary Memory Attribute Indirection Registers 0
AMAIR0 and AMAIR1.
• The introduction of the Large Physical Address Extension changes:

— Some terminology used for MMU faults, see VMSAv7 MMU fault terminology on page B3-1395.
— The naming of the address translation operations, see Naming of the address translation operations,
and operation summary on page B3-1434.
B1.7 The Virtualization Extensions

The Virtualization Extensions are an OPTIONAL extension to the ARMv7-A architecture profile. Any
implementation that includes the Virtualization Extensions must include the Security Extensions, the Large Physical
Address Extension, and the Multiprocessing Extensions.
When implemented, the Virtualization Extensions provide a set of hardware features that support virtualizing the
Non-secure state of an ARM VMSAv7 implementation. The basic model of a virtualized system involves:
• A hypervisor, running in Non-secure Hyp mode, that is responsible for switching Guest operating systems.
• A number of Guest operating systems, each of which runs in the Non-secure PL1 and PL0 modes.
• For each Guest operating system, applications, that usually run in User mode.
Note
A Guest OS runs on a virtual machine. However, its own view is that it is running on an ARM processor. Normally,
a Guest OS is completely unaware:
• That it is running on a virtual machine.
• Of any other Guest OS.
Another way of describing virtualization is that:
• A Guest operating system, including all applications and tasks running under that operating system, runs on
a virtual machine.
• A hypervisor switches between virtual machines.
Each virtual machine is identified by a virtual machine identifier (VMID), assigned by the hypervisor.
Many features of the architecture are extended to integrate with the Virtualization Extensions, and because of this
integration of the Virtualization Extensions into the architecture, features of the Virtualization Extensions are
described in many sections of this manual. The key features are:
• Hyp mode is implemented only in Non-secure state, to support Guest OS management. Hyp mode operates
in its own Non-secure virtual address space, that is different from the Non-secure virtual address space
accessed from Non-secure PL0 and PL1 modes.
• The Virtualization Extensions provide controls to:

— Define virtual values for a small number of identification registers. A read of the identification register
by a Guest OS or its applications returns the virtual value.
— Trap various other operations, including accesses to many other registers, and memory management
operations. A trapped operation generates an exception that is taken to Hyp mode.
These controls are configured by software executing in Hyp mode.
• With the Security Extensions, the Virtualization Extensions control the routing of interrupts and
asynchronous Data Abort exceptions to the appropriate one of:
— The current Guest OS.
— A Guest OS that is not currently running.
— The hypervisor.
— The Secure monitor.
• When an implementation includes the Virtualization Extensions, it provides independent translation regimes
for memory accesses from:
— Secure modes, the Secure PL1&0 translation regime.
— Non-secure Hyp mode, the Non-secure PL2 translation regime.
— Non-secure PL1 and PL0 modes, the Non-secure PL1&0 translation regime.
Figure B3-1 on page B3-1307 shows these translation regimes.
• In the Non-secure PL1&0 translation regime, address translation occurs in two stages:
— Stage 1 maps the Virtual Address (VA) to an Intermediate Physical Address (IPA). Typically, the Guest
OS configures and controls this stage, and believes that the IPA is the Physical Address (PA).
— Stage 2 maps the IPA to the PA. Typically, the hypervisor controls this stage, and a Guest OS is
completely unaware of this translation.
For more information, see About address translation on page B3-1309.
Impact of the Virtualization Extensions on the modes and exception model gives more information about many of
these features.
B1.7.1 Impact of the Virtualization Extensions on the modes and exception model
This section summarizes the effect of the Virtualization Extensions on the modes and exception model. An
implementation that includes the Virtualization Extensions:
• Implements a new Non-secure mode, Hyp mode. Hyp mode on page B1-1141 summarizes how Hyp mode
differs from the other processor modes.
• Implements new exceptions, see:

— Hypervisor Call (HVC) exception on page B1-1211.
— Hyp Trap exception on page B1-1208.
— Virtual IRQ exception on page B1-1220.
— Virtual FIQ exception on page B1-1222.
— Virtual Abort exception on page B1-1217.
The Hypervisor Call and Hyp Trap exceptions are always taken to Hyp mode. The virtual exceptions are
taken to Non-secure IRQ, FIQ, or Abort mode, see The virtual exceptions.
• Implements a new register that holds the exception vector base address for exceptions taken to Hyp mode,
the HVBAR.
• Provides controls that can be used to route IRQs, FIQs, and asynchronous aborts, to Hyp mode. This is
possible only if Secure software has not routed the exception to Monitor mode, and applies only to exceptions
taken from a Non-secure mode.
For more information see Asynchronous exception routing controls on page B1-1174.
• Provides controls that can be used to route some synchronous exceptions, taken from Non-secure modes, to
Hyp mode. For more information see Routing general exceptions to Hyp mode on page B1-1190 and Routing
Debug exceptions to Hyp mode on page B1-1193.
• Provide mechanisms to trap processor functions to Hyp mode, using the Hyp Trap exception, see Traps to
the hypervisor on page B1-1246.
When an operation is trapped to Hyp mode, the hypervisor typically either:
— Emulates the required operation, so the application running in the Guest OS is unaware of the trap to
Hyp mode.
— Returns an error to the Guest OS.
• Implements enhanced exception reporting for exceptions taken to Hyp mode, see Reporting exceptions taken
to the Non-secure PL2 mode on page B3-1417. These exceptions are reported using the HSR, see Use of the
HSR on page B3-1421,
• Implements a new exception return instruction, ERET, for return from Hyp mode. For more information see
Hyp mode on page B1-1141.
The virtual exceptions

The Virtualization Extensions introduce three virtual exceptions:
• The Virtual IRQ exception, that corresponds to the physical IRQ exception.
• The Virtual FIQ exception, that corresponds to the physical FIQ exception.
• The Virtual Abort exception, that corresponds to a physical asynchronous External Data Abort exception.
Software executing in Hyp mode can use these to signal exceptions to the other Non-secure modes. A Non-secure
PL1 or PL0 mode cannot distinguish a virtual exception from the corresponding physical exception.
A usage model for these exceptions is that physical IRQs, FIQs and asynchronous aborts that occur when the
processor is in a Non-secure PL1 or PL0 mode are routed to Hyp mode. The exception handler, executing in Hyp
mode, determines whether the exception can be handled in Hyp mode or requires routing to a Guest OS. When an
exception requires handling by a Guest OS it is marked as pending for that Guest OS. When the hypervisor switches
to a particular Guest OS, it uses the appropriate virtual exception to signal any pending virtual exception to that
Guest OS.
For more information see Virtual exceptions in the Virtualization Extensions on page B1-1196.
B1.8 Exception handling

An exception causes the processor to suspend program execution to handle an event, such as an externally generated
interrupt or an attempt to execute an undefined instruction. Exceptions can be generated by internal and external
sources.
Normally, when an exception is taken the processor state is preserved immediately, before handling the exception.
This means that, when the event has been handled, the original state can be restored and program execution resumed
from the point where the exception was taken.
More than one exception might be generated at the same time, and a new exception can be generated while the
processor is handling an exception.
The following sections describe exception handling:

• Exception vectors and the exception base address.
• Exception priority order on page B1-1168.
• Overview of exception entry on page B1-1169.
• Processor mode for taking exceptions on page B1-1172.
• Processor state on exception entry on page B1-1181.
• Asynchronous exception masking on page B1-1183.
• Summaries of asynchronous exception behavior on page B1-1185.
• Routing general exceptions to Hyp mode on page B1-1190.
• Routing Debug exceptions to Hyp mode on page B1-1193.
• Exception return on page B1-1193.
• Virtual exceptions in the Virtualization Extensions on page B1-1196.
• Low interrupt latency configuration on page B1-1197.
• Wait For Event and Send Event on page B1-1199.
• Wait For Interrupt on page B1-1202.
Exception descriptions on page B1-1204 then describes each exception.
B1.8.1 Exception vectors and the exception base address

When an exception is taken, processor execution is forced to an address that corresponds to the type of exception.
This address is called the exception vector for that exception.
A set of exception vectors comprises eight consecutive word-aligned memory addresses, starting at an exception
base address. These eight vectors form a vector table. For the IRQ and FIQ exceptions only, when the exceptions
are taken to IRQ mode and FIQ mode, software can change the exception vectors from the vector table values by
setting the SCTLR.VE bit to 1, see Vectored interrupt support on page B1-1167.
The number of possible exception base addresses, and therefore the number of vector tables, depends on the
implemented architecture profile and extensions, as follows:
Implementation that does not include the Security Extensions

This section applied to all ARMv7-R implementations.
An implementation that does not include the Security Extensions has a single vector table, the base
address of which is selected by SCTLR.V, see SCTLR, System Control Register, VMSA on
page B4-1700 or SCTLR, System Control Register, PMSA on page B6-1921:
V == 0 Exception base address = 0x00000000. This setting is referred to as normal vectors, or as
low vectors.
V == 1 Exception base address = 0xFFFF0000. This setting is referred to as high vectors, or
Hivecs.
Note
ARM deprecates using the Hivecs setting, SCTLR.V == 1, in ARMv7-R. ARM recommends that
Hivecs is used only in ARMv7-A implementations.
Implementation that includes the Security Extensions

Any implementation that includes the Security Extensions has the following vector tables:
• One for exceptions taken to Secure Monitor mode. This is the Monitor vector table, and is in
the address space of the Secure PL1&0 translation regime.
• One for exceptions taken to Secure PL1 modes other than Monitor mode. This is the Secure
vector table, and is in the address space of the Secure PL1&0 translation regime.
• One for exceptions taken to Non-secure PL1 modes. This is the Non-secure vector table, and
is in the address space of the Non-secure PL1&0 translation regime.
For the Monitor vector table, MVBAR holds the exception base address.
For the Secure vector table:
• the Secure SCTLR.V bit determines the exception base address:
V == 0 The Secure VBAR holds the exception base address.
V == 1 Exception base address = 0xFFFF0000, the Hivecs setting.
For the Non-secure vector table:
• the Non-secure SCTLR.V bit determines the exception base address:
V == 0 The Non-secure VBAR holds the exception base address.
V == 1 Exception base address = 0xFFFF0000, the Hivecs setting.
Implementation that includes the Virtualization Extensions

An implementation that includes the Virtualization Extensions must include the Security
Extensions, and also includes an additional vector table. Therefore, it has the following vector
tables:
• One for exceptions taken to Secure Monitor mode. This is the Monitor vector table, and is in
the address space of the Secure PL1&0 translation regime.
• One for exceptions taken to Secure PL1 modes other than Monitor mode. This is the Secure
vector table, and is in the address space of the Secure PL1&0 translation regime.
• One for exceptions taken to Hyp mode, the Non-secure PL2 mode. This is the Hyp vector
table, and is in the address space of the Non-secure PL2 translation regime.
• One for exceptions taken to Non-secure PL1 modes. This is the Non-secure vector table, and
is in the address space of the Non-secure PL1&0 translation regime.
The exception base addresses of the Monitor vector table, the Secure vector table, and the
Non-secure vector table are determined in the same way as for an implementation that includes the
Security extensions but not the Virtualization extensions.
For the Hyp vector table, HVBAR holds the exception base address.
The following subsections give more information:

• The vector tables and exception offsets.
• Vectored interrupt support on page B1-1167.
• Pseudocode determination of the exception base address on page B1-1167.
The vector tables and exception offsets

Table B1-3 on page B1-1166 defines the vector table entries. In this table:
• The Hyp mode column defines the vector table entries for exceptions taken to Hyp mode.
• The Monitor mode column defines the vector table entries for exceptions taken to Monitor mode.
• The Secure and Non-secure columns define the Secure and Non-secure vector table entries, that are used for
exceptions taken to PL1 modes other than Monitor mode. Table B1-4 on page B1-1166 shows the mode to
which each of these exceptions is taken. Each of these modes is described as the default mode for taking the
corresponding exception.
For more information about determining the mode to which an exception is taken, see Processor mode for taking
exceptions on page B1-1172.
The Virtualization Extensions provide a number of additional exceptions, some of which are not shown explicitly
in the vector tables. For more information, see Offsets of exceptions introduced by the Virtualization Extensions.
Table B1-3 The vector tables
Vector tables
Offset
Hyp a Monitor b Secure Non-secure
0x00 Not used Not used Reset Not used
0x04 Undefined Instruction, from Hyp mode Not used Undefined Instruction Undefined Instruction
0x08 Hypervisor Call, from Hyp mode Secure Monitor Call Supervisor Call Supervisor Call
0x0C Prefetch Abort, from Hyp mode Prefetch Abort Prefetch Abort Prefetch Abort
0x10 Data Abort, from Hyp mode Data Abort Data Abort Data Abort
0x14 Hyp Trap, or Hyp mode entry c Not used Not used Not used
0x18 IRQ interrupt IRQ interrupt IRQ interrupt IRQ interrupt
0x1C FIQ interrupt FIQ interrupt FIQ interrupt FIQ interrupt
a. Non-secure state only. Implemented only if the implementation includes the Virtualization Extensions.
b. Secure state only. Implemented only if the implementation includes the Security Extensions.
c. See Use of offset 0x14 in the Hyp vector table on page B1-1167.
Table B1-4 Modes for taking exceptions using the Secure or Non-secure vector table
Exception PL1 Mode taken to
Reset Supervisor
Undefined Instruction Undefined
Supervisor Call Supervisor
Prefetch Abort Abort
Data Abort Abort
IRQ interrupt IRQ
FIQ interrupt FIQ
For more information about use of the vector tables see Overview of exception entry on page B1-1169.
Offsets of exceptions introduced by the Virtualization Extensions
The Virtualization Extensions introduce the following new exceptions. The processor enters the handlers for these
exceptions using the following vector table entries shown in Table B1-3:
Hypervisor Call
If taken from Hyp mode, shown explicitly in the Hyp mode vector table. Otherwise, see Use of offset
0x14 in the Hyp vector table on page B1-1167.
Hyp Trap Shown explicitly in the Hyp mode vector table.
Virtual Abort Entered through the Data Abort vector in the Non-secure vector table.
Virtual IRQ Entered through the IRQ vector in the Non-secure vector table.
Virtual FIQ Entered through the FIQ vector in the Non-secure vector table.
Note
The virtual exceptions on page B1-1162 summarizes these exceptions, and Virtual exceptions in the Virtualization
Extensions on page B1-1196 gives more information.
Use of offset 0x14 in the Hyp vector table
The vector at offset 0x14 in the Hyp vector table is used for exceptions that cause entry to Hyp mode. This means it
is:
• Always used for the Hyp Trap exception.
• Used for the following exceptions, when the exception is not taken from Hyp mode:
— Hypervisor Call.
— Supervisor Call, when caused by execution of an SVC instruction in Non-secure User mode when
HCR.TGE is set to 1.
— Undefined Instruction.
— Prefetch Abort.
— Data Abort.
Table B1-3 on page B1-1166 shows the offsets used for these exceptions when they are taken from Hyp
mode.
• Never used for IRQ exceptions, Virtual IRQ exceptions, FIQ exceptions, or Virtual FIQ exceptions.
For more information, see Processor mode for taking exceptions on page B1-1172.
Pseudocode determination of the exception base address
For an exception taken to a PL1 mode other than Monitor mode, the ExcVectorBase() function determines the
exception base address:
// ExcVectorBase()
// ===============
bits(32) ExcVectorBase()
if SCTLR.V == '1' then // Hivecs selected, base = 0xFFFF0000
return Ones(16):Zeros(16);
elsif HaveSecurityExt() then
return VBAR;
else
return Zeros(32);
Vectored interrupt support

At reset, any implemented vectored interrupt mechanism is disabled, and the IRQ and FIQ exception vectors are at
fixed offsets from the exception base address that is being used. With this configuration, an FIQ or IRQ handler
typically starts with an instruction sequence that determines the cause of the interrupt and then branches to an
appropriate routine to handle it.
If an implementation supports vectored interrupts, enabling this feature means an interrupt controller can prioritize
interrupts and provide the address of the required interrupt handler directly to the processor, for use as the interrupt
vector. For interrupts taken to PL1 modes other than Monitor mode, vectored interrupt behavior is enabled by setting
the SCTLR.VE bit to 1, see either:
The hardware that supports vectored interrupts is IMPLEMENTATION DEFINED, and an implementation might not
include any support for this operation.
• The SCTLR.VE bit is Banked between Secure and Non-secure states to provide independent control of
whether vectored interrupt support is enabled.
• Interrupts can be routed to Monitor mode, by setting either or both of the SCR.IRQ and SCR.FIQ bits to 1.
When an interrupt is routed to Monitor mode it uses the vector in the vector table at the Monitor exception
base address held in MVBAR, regardless of the value of either Banked copy of the SCTLR.VE bit.
The Virtualization Extensions do not support this vectoring of the IRQ and FIQ exceptions when these exceptions
are routed to Hyp mode. When an interrupt is routed to Hyp mode, it uses the vector in the vector table at the Hyp
exception base address held in HVBAR, regardless of the value of either Banked copy of the SCTLR.VE bit.
From the introduction of the Virtualization Extensions, ARM deprecates any use of the SCTLR.VE bit.
B1.8.2 Exception priority order

An instruction is not valid if it generates a synchronous Prefetch Abort exception. Therefore, if an instruction
generates a Prefetch Abort exception, no other synchronous exception or debug event is generated on that
instruction.
A Breakpoint debug event, or an address matching form of the Vector catch debug event, is associated with the
instruction. This means the corresponding exception is taken before the instruction is executed. Therefore, when a
Breakpoint or address matching Vector catch debug event occurs, no other synchronous exception or debug event,
that might have occurred as a result of executing the instruction, can occur.
Note
• The Exception trapping form of the Vector catch debug event, introduced in v7.1 Debug, causes a debug
event as a result of trapping an exception that has been prioritized as described in this section. This means it
is outside the scope of the description in this section. For more information see Vector catch debug events on
page C3-2053.
• In v7 Debug, the only supported Vector catch debug events are address matching Vector catch debug events.
Otherwise:
• An instruction that generates an Undefined Instruction exception or a Hyp Trap exception cannot cause any
memory access, and therefore cannot cause a Data Abort exception.
• If an instruction generates both an Undefined Instruction exception and a Hyp Trap exception then, unless
this manual explicitly states otherwise, the Undefined Instruction exception has priority.
• If a system call is configured to generate an Undefined Instruction exception or a Hyp Trap exception, then
the Undefined Instruction exception or the Hyp Trap exception has priority over the system call. The system
calls are the SVC, HVC, and SMC instructions.
• A memory access that generates an MMU fault, an MPU fault, or a synchronous Watchpoint debug event
must not generate an external abort.
• All other synchronous exceptions are mutually exclusive and are derived from a decode of the instruction.
• Debug event prioritization on page C3-2064 for information about the prioritization of debug events,
including their prioritization relative to MMU faults, MPU faults, and synchronous external aborts
• Prioritization of aborts on page B3-1404, for information about:

— The prioritization of aborts on a single memory access in a VMSA implementation.
— The prioritization of exceptions generated during address translation.
• Prioritization of aborts on page B5-1760, for information about the prioritization of aborts on a single
memory access in a PMSA implementation.
Architectural requirements for taking asynchronous exceptions

The ARM architecture does not define when asynchronous exceptions are taken, but sets the following limits on
when they are taken:
• An asynchronous exception that is pending before one of the following context synchronizing events is taken
before the first instruction after the context synchronizing event completes its execution, provided that the
pending asynchronous event is not masked after the context synchronizing event. The context synchronizing
events are:
— Execution of an ISB instruction.
— Taking an exception.
— Return from an exception.
— Exit from Debug state.
The ISR identifies any pending asynchronous exceptions.
Note
If the first instruction after the context synchronizing event generates a synchronous exception, then the
architecture does not define the order in which that synchronous exception and the asynchronous exception
are taken.
• In the absence of an specific requirement to take an asynchronous exception, because of a context

synchronizing event, the only requirement of the architecture is that an unmasked asynchronous exception is
taken in finite time.
Note
The taking of an unmasked asynchronous exception in finite time must occur with all code sequences,
including with a sequence that consists of unconditional loops.
Within these limits, the prioritization of asynchronous exceptions relative to other exceptions, both synchronous and
asynchronous, is IMPLEMENTATION DEFINED.
Note
A special requirement applies to asynchronous watchpoints, see Debug event prioritization on page C3-2064.
The CPSR includes a mask bit for each type of asynchronous exception. Setting one of these bits to 1 can prevent
the corresponding asynchronous exception from being taken, see Summaries of asynchronous exception behavior
on page B1-1185.
Taking an exception sets an exception-dependent subset of these mask bits.
Note
The subset of the CPSR mask bits that is set on taking an exception can prioritize the execution of FIQ handlers over
that of IRQ and asynchronous abort handlers.
B1.8.3 Overview of exception entry

On taking an exception:
1. The hardware determines the mode to which the exception must be taken, see Processor mode for taking
2. A link value, indicating the preferred return address for the exception, is saved. This is a possible return
address for the exception handler, and depends on:
• The exception type.
• Whether the exception is taken to a PL1 mode or a PL2 mode.
• For some exceptions taken to a PL1 mode, the instruction set state when the exception is taken.
Where the link value is saved depends on whether the exception is taken to a PL1 mode or a PL2 mode.
For more information see Link values saved on exception entry on page B1-1171.
3. The value of the CPSR is saved in the SPSR for the mode to which the exception must be taken. The value
saved in SPSR.IT[7:0] is always correct for the preferred return address.
4. In an implementation that includes the Security Exceptions:

• If the exception taken from Monitor mode, SCR.NS is cleared to 0.
• Otherwise, taking the exception leaves SCR.NS unchanged.
5. The CPSR is updated with new context information for the exception handler. This includes:
• Setting CPSR.M to the processor mode to which the exception is taken.
• Setting the appropriate CPSR mask bits. This can disable the corresponding exceptions, preventing
uncontrolled nesting of exception handlers.
• Setting the instruction set state to the state required for exception entry.
• Setting the endianness to the required value for exception entry.
• Clearing the CPSR.IT[7:0] bits to 0.
For more information, see Processor state on exception entry on page B1-1181.
6. The appropriate exception vector is loaded into the PC, see Exception vectors and the exception base address
on page B1-1164.
7. Execution continues from the address held in the PC.
For an exception taken to a PL1 mode, on exception entry, the exception handler can use the SRS instruction to store
the return state onto the stack of any mode at the same privilege level, and the CPS instruction to change mode. For
more information about the instructions, see SRS (Thumb) on page B9-1990, SRS (ARM) on page B9-1992, CPS
(Thumb) on page B9-1964, and CPS (ARM) on page B9-1966.
Later sections of this chapter describe each of the possible exceptions, and each of these descriptions includes a
pseudocode description of the processor state changes when it takes that exception. Table B1-5 gives an index to
these descriptions:
Table B1-5 Pseudocode descriptions of exception entry
Exception Description of exception entry
Reset Pseudocode description of taking the Reset exception on page B1-1205
Undefined Instruction Pseudocode description of taking the Undefined Instruction exception on page B1-1207
Supervisor Call Pseudocode description of taking the Supervisor Call exception on page B1-1209
Secure Monitor Call Pseudocode description of taking the Secure Monitor Call exception on page B1-1211
Hypervisor Call Pseudocode description of taking the Hypervisor Call exception on page B1-1211
Prefetch Abort Pseudocode description of taking the Prefetch Abort exception on page B1-1213
Data Abort Pseudocode description of taking the Data Abort exception on page B1-1214
IRQ Pseudocode description of taking the IRQ exception on page B1-1219
FIQ Pseudocode description of taking the FIQ exception on page B1-1221
Table B1-5 Pseudocode descriptions of exception entry (continued)
Exception Description of exception entry
Hyp Trap Pseudocode description of taking the Hyp Trap exception on page B1-1209
Virtual Abort Pseudocode description of taking the Virtual Abort exception on page B1-1217
Virtual IRQ Pseudocode description of taking the Virtual IRQ exception on page B1-1220
Virtual FIQ Pseudocode description of taking the Virtual FIQ exception on page B1-1222
The following sections give more information about the processor state changes, for different architecture
implementations. However, you must refer to the pseudocode for a full description of the state changes:
• Processor mode for taking exceptions on page B1-1172.
• Processor state on exception entry on page B1-1181.
Link values saved on exception entry

On exception entry, a link value for use on return from the exception, is saved. This link value is based on the
preferred return address for the exception, as shown in Table B1-6:
Table B1-6 Exception return addresses
Exception Preferred return address Taken to a mode at
Undefined Instruction Address of the UNDEFINED instruction PL1 a, or PL2 b
Supervisor Call Address of the instruction after the SVC instruction PL1 a or PL2 b
Secure Monitor Call Address of the instruction after the SMC instruction PL1, and only in Secure state
Hypervisor Call Address of the instruction after the HVC instruction PL2 only b
Prefetch Abort Address of aborted instruction fetch PL1 a or PL2 b
Data Abort Address of instruction that generated the abort PL1 a or PL2 b
Virtual Abort Address of next instruction to execute PL1, and only in Non-secure state
Hyp Trap Address of the trapped instruction PL2 only b
IRQ or FIQ Address of next instruction to execute PL1 a or PL2 b
Virtual IRQ or Virtual FIQ Address of next instruction to execute PL1, and only in Non-secure state
a. Secure or Non-secure.
b. PL2 is implemented only in Non-secure state. Therefore, an exception can be taken to PL2 mode only if it is taken from Non-secure state.
Note
• Although Reset is described as an exception, it differs significantly from other exceptions. The architecture
has no concept of a return from a Reset and therefore it is not listed in this section.
• For each exception, the preferred return address is not affected by whether the exception is taken from a PL1
mode or from a PL0 mode.
However, the link value saved, and where it is saved, depend on whether the exception is taken to a PL1 mode, or
to a PL2 mode, as follows:
Exception taken to a PL1 mode

The link value is saved in the LR for the mode to which the exception is taken.
The saved link value is the preferred return address for the exception, plus an offset that depends on
the instruction set state when the exception was taken, as Table B1-7 shows:
Table B1-7 Offsets applied to Link value for exceptions taken to PL1 modes
Offset, for processor state of:

Exception
ARM Thumb a Jazelle
Undefined Instruction +4 +2 -b
Supervisor Call None None -c
Secure Monitor Call None None -c
Prefetch Abort +4 +4 +4
Data Abort +8 +8 +8
Virtual Abort +8 +8 +8
IRQ or FIQ +4 +4 +4
Virtual IRQ or Virtual FIQ +4 +4 +4
a. Thumb or ThumbEE state.

b. See Undefined Instruction exception in Jazelle state on page B1-1207.
c. Exception cannot occur in Jazelle state.
Exception taken to a PL2 mode

The link value is saved in the ELR_hyp Special register.
The saved link value is the preferred return address for the exception, as shown in Table B1-6 on
page B1-1171, with no offset.
B1.8.4 Processor mode for taking exceptions

The following principles determine the mode to which an exception is taken:
• An exception cannot be taken to a PL0 mode.
• An exception is taken either:

— At the privilege level at which the processor was executing when it took the exception.
— At a higher privilege level.
This means that, in Secure state, an exception is always taken to a PL1 mode.
• Configuration options and other features provided by the Security Extensions and the Virtualization
Extensions can determine the mode to which some exceptions are taken, as follows:
In an implementation that does not include the Security Extensions
An exception is always taken to the default mode for that exception.
Note
An implementation that includes the Virtualization Extensions must also include the Security
Extensions.
In an implementation that includes the Security Extensions

A Secure Monitor Call exception is always taken to Secure Monitor mode.
IRQ, FIQ, and External abort exceptions can be configured to be taken to Secure Monitor mode.
Any exception taken from Secure state that is not taken to Secure Monitor mode is taken to
Secure state in the default mode for that exception.
If the implementation does not include the Virtualization Extensions, any exception taken from
Non-secure state that is not taken to Secure Monitor mode is taken to Non-secure state in the
default mode for that exception.
In an implementation that includes the Virtualization Extensions
An exception taken from Non-secure state that is not taken to Secure Monitor mode is taken to
Non-secure state and:
• If the exception is taken from Hyp mode then it is taken to Hyp mode.
• Otherwise, the exception is either taken to Hyp mode, as described in Exceptions taken to
Hyp mode, or taken to the default mode for the exception.
Note
The Virtualization Extensions have no effect on the handling of exceptions taken from Secure
state.
Table B1-4 on page B1-1166 shows the default mode to which each exception is taken.
Asynchronous exception routing controls on page B1-1174 describes the exception routing controls provided by the
Security Extensions and the Virtualization Extensions.
For a VMSA implementation, Routing of aborts on page B3-1393 gives more information about the modes to which
memory aborts are taken.
Summary of the possible modes for taking each exception on page B1-1174 shows all modes to which each
exception might be taken, in any implementation. That is, it applies to implementations:
• That include neither the Security Extensions, nor the Virtualization Extensions.
• That include the Security Extensions, but not the Virtualization Extensions.
• That include both the Security Extensions and the Virtualization Extensions.
Exceptions taken to Hyp mode

In an implementation that includes the Virtualization Extensions:
• Any exception taken from Hyp mode, that is not routed to Secure Monitor Mode by the controls described
in Asynchronous exception routing controls on page B1-1174, is taken to Hyp mode.
• The following exceptions, if taken from Non-secure state, are taken to Hyp mode:
— An abort that Routing of aborts on page B3-1393 identifies as taken to Hyp mode.
— A Hyp Trap exception, see Traps to the hypervisor on page B1-1246.
— A Hypervisor Call exception. This is generated by executing a HVC instruction in a Non-secure mode.
— An asynchronous abort, IRQ exception or FIQ exception that is not routed to Secure Monitor mode
but is explicitly routed to Hyp mode, as described in Asynchronous exception routing controls on
page B1-1174.
— A synchronous external abort, Alignment fault, Undefined Instruction exception, or Supervisor Call
exception taken from the Non-secure PL0 mode and explicitly routed to Hyp mode, as described in
Routing general exceptions to Hyp mode on page B1-1190.
Note
A synchronous external abort can be routed to Hyp mode only if it not routed to Secure Monitor mode.
— A debug exception that is explicitly routed to Hyp mode as described in Routing Debug exceptions to
Hyp mode on page B1-1193.
Note
The virtual exceptions cannot be taken to Hyp mode. They are always taken to a Non-secure PL1 mode.
Asynchronous exception routing controls

In an implementation that includes the Security Extensions, the following bits in the SCR control the routing of
asynchronous exceptions, and also the routing of synchronous external aborts:
SCR.EA When this bit is set to 1, any external abort is taken to Secure Monitor mode.
Note
• Unlike other controls described in this section, SCR.EA controls the routing of both
synchronous and asynchronous external aborts.
• The other classes of abort cannot be routed to Monitor mode. For more information about the
classification of aborts, see VMSA memory aborts on page B3-1392 or PMSA memory aborts
on page B5-1757.
SCR.FIQ When this bit is set to 1, any FIQ exception is taken to Secure Monitor mode.
SCR.IRQ When this bit is set to 1, any IRQ exception is taken to Secure Monitor mode.
Only Secure software can change the values of these bits.

In an implementation that includes the Virtualization Extensions, the following bits in the HCR route asynchronous
exceptions to Hyp mode, for exceptions that are both:
• Taken from a Non-secure PL1 or PL0 mode.
• Not configured, by the SCR.{EA, FIQ, IRQ} controls, to be taken to Secure Monitor mode.
HCR.AMO If SCR.EA is set to 0, when this bit is set to 1, an asynchronous external abort taken from a
Non-secure PL1 or PL0 mode is taken to Hyp mode, instead of to Non-secure Abort mode.
HCR.FMO If SCR.FIQ is set to 0, when this bit is set to 1, an FIQ exception taken from a Non-secure PL1 or
PL0 mode is taken to Hyp mode, instead of to Non-secure FIQ mode.
HCR.IMO If SCR.IRQ is set to 0, when this bit is set to 1, an IRQ exceptions taken from a Non-secure PL1 or
PL0 mode is taken to Hyp mode, instead of to Non-secure IRQ mode.
Only software executing in Hyp mode, or Secure software executing in Monitor mode when SCR.NS is set to 1, can
change the values of these bits.
See also Summaries of asynchronous exception behavior on page B1-1185.
The HCR.{AMO, FMO, IMO} bits also affect the masking of asynchronous exceptions in Non-secure state, as
described in Asynchronous exception masking on page B1-1183.
The SCR.{EA, FIQ, IRQ} and HCR.{AMO, FMO, IMO} bits have no effect on the routing of Virtual Abort, Virtual
FIQ, and Virtual IRQ exceptions.
Summary of the possible modes for taking each exception

The following subsections describe the modes to which each exception can be taken:
• Determining the mode to which the Undefined Instruction exception is taken on page B1-1175.
• Determining the mode to which the Supervisor Call exception is taken on page B1-1175.
• The mode to which the Secure Monitor Call exception is taken on page B1-1176.
• The mode to which the Hypervisor Call exception is taken on page B1-1176.
• The mode to which the Hyp Trap exception is taken on page B1-1176.
• Determining the mode to which the Prefetch Abort exception is taken on page B1-1177.
• Determining the mode to which the Data Abort exception is taken on page B1-1177.
• The mode to which the Virtual Abort exception is taken on page B1-1179.
• Determining the mode to which the IRQ exception is taken on page B1-1179.
• The mode to which the Virtual IRQ exception is taken on page B1-1179.
• Determining the mode to which the FIQ exception is taken on page B1-1179.
• The mode to which the Virtual FIQ exception is taken on page B1-1180.
These descriptions also show the vector offset for the exception entry for each mode.
For more information about:
• Vector offsets, see Exception vectors and the exception base address on page B1-1164.
• The routing of external aborts, IRQ and FIQ exceptions, and the virtual exceptions, see Asynchronous
exception routing controls on page B1-1174.
Determining the mode to which the Undefined Instruction exception is taken
Figure B1-3 shows how the implementation, state, and configuration options determine the mode to which an
Undefined Instruction exception is taken.
Undefined Instruction exception Have

Security Undefined mode,
No
Extensions vector offset 0x04
?
Yes
State is Secure Undefined mode,

Secure Yes
vector offset 0x04
?
No
Have
Virtualization Taken from Hyp mode,
Yes Yes
Extensions Hyp mode vector offset 0x04
? ?
From User mode only. The
No No
effect of executing in a PL1
mode with HCR.TGE set to
1 is UNPREDICTABLE.
HCR.TGE Hyp mode,
Yes
== 1 vector offset 0x14
?
No
Non-secure Undefined mode,
vector offset 0x04
Figure B1-3 The mode the Undefined Instruction exception is taken to
Determining the mode to which the Supervisor Call exception is taken
Figure B1-4 on page B1-1176 shows how the implementation, state, and configuration options determine the mode
to which a Supervisor Call exception is taken.
Supervisor Call exception Have

Security Supervisor mode,
No
?
Yes
State is Secure Supervisor mode,

Secure Yes
vector offset 0x08
?
No
Have
Virtualization Taken from Hyp mode,
Yes Yes
Extensions Hyp mode vector offset 0x08
? ?
No No From User mode only. The
effect of executing in a PL1
1 is UNPREDICTABLE.
HCR.TGE Hyp mode,
Yes
?
No
Non-secure Supervisor mode,
vector offset 0x08
Figure B1-4 The mode the Supervisor Call exception is taken to
The mode to which the Secure Monitor Call exception is taken
The Secure Monitor Call exception is supported only as part of the Security Extensions. A Secure Monitor Call
exception is taken to Monitor mode, using vector offset 0x08 from the Monitor exception base address.
Note
An SMC instruction that is trapped to Hyp mode because HCR.TSC is set to 1 generates a Hyp Trap exception, see
The mode to which the Hyp Trap exception is taken.
The mode to which the Hypervisor Call exception is taken

The Hypervisor Call exception is supported only as part of the Virtualization Extensions. A Hypervisor Call
exception is taken to Hyp mode, using a vector offset that depends on the mode from which the exception is taken,
as Figure B1-5 shows. This offset is from the Hyp exception base address.
Hypervisor Call exception

Taken from Hyp mode,
Yes
Hyp mode vector offset 0x08
?
No Hyp mode,
vector offset 0x14
Figure B1-5 The mode the Hypervisor Call exception is taken to
The mode to which the Hyp Trap exception is taken
The Hyp Trap exception is supported only as part of the Virtualization Extensions. A Hyp Trap exception is taken
to Hyp mode, using a vector offset of 0x14 from the Hyp exception base address.
Determining the mode to which the Prefetch Abort exception is taken
Figure B1-6 shows how the implementation, state, and configuration options determine the mode to which a
Prefetch Abort exception is taken.
Prefetch Abort exception Have

Security Abort mode,
No
Extensions vector offset 0x0C
?
Yes
External SCR.EA Monitor mode,

abort Yes Yes
== 1 vector offset 0x0C
? ?
No No
State is Secure Abort mode,

Secure Yes
vector offset 0x0C
?
No
Have
Virtualization Taken from Hyp mode, vector
Yes Yes
Extensions Hyp mode offset 0x0C
? ? From User mode only. The effect of
No No executing in a PL1 mode with
HCR.TGE set to 1 is UNPREDICTABLE.
External
Yes HCR.TGE Yes
abort
== 1
?
?
No No
1
Debug HDCR.TDE Hyp mode, vector
Yes Yes
exception == 1 offset 0x14
? ?
No No
On address
translation
1
Stage 2
Yes
abort
?
1
No
Non-secure Abort mode,
vector offset 0x0C
Figure B1-6 The mode the Prefetch Abort exception is taken to
Determining the mode to which the Data Abort exception is taken
Figure B1-7 on page B1-1178 shows how the implementation, state, and configuration options determine the mode
to which a Data Abort exception is taken.
Data Abort exception Have

Security Abort mode,
No
?
Yes
External SCR.EA Monitor mode,

Yes Yes
abort == 1 vector offset 0x10
? ?
No No
State is Secure Abort mode,

Secure Yes
vector offset 0x10
?
No
Have
Virtualization Taken from Hyp mode, vector
Yes Yes
Extensions Hyp mode offset 0x10
? ?
No No
Alignment
Yes
fault
? From User mode only. The
No effect of executing in a PL1
1 is UNPREDICTABLE.
External HCR.TGE
abort Yes Synchronous Yes Yes
? == 1
? ?
No No No
1
HCR.AMO Yes
== 1
?
No
1
Debug HDCR.TDE Hyp mode, vector
exception Yes Yes
== 1 offset 0x14
? ?
On address No No
translation
1
Stage 2
abort Yes
?
No 1
Non-secure Abort mode,
vector offset 0x10
Figure B1-7 The mode the Data Abort exception is taken to
The mode to which the Virtual Abort exception is taken
The Virtual Abort exception is supported only as part of the Virtualization Extensions. A Virtual Abort exception is
taken from a Non-secure PL1 or PL0 mode, and is taken to Non-secure Abort mode, using a vector offset of 0x10
from the Non-secure exception base address.
For more information about this exception see Virtual exceptions in the Virtualization Extensions on page B1-1196.
Determining the mode to which the IRQ exception is taken
Figure B1-8 shows how the implementation, state, and configuration options determine the mode to which an IRQ
exception is taken.
IRQ exception Have

Security SCTLR.VE IRQ mode,
No No
Extensions == 1 vector offset 0x18
? ?
Yes Yes IRQ mode, vector is
IMPLEMENTATION DEFINED
SCR.IRQ Monitor mode,

Yes
?
No
State is Secure IRQ mode,

Yes SCTLR.VE No
Secure vector offset 0x18
== 1
?
?
No Yes Secure IRQ mode, vector is
Have
Virtualization Yes Taken from Yes
Extensions Hyp mode
? ?
No No
HCR.IMO Hyp mode,

Yes
?
No Non-secure IRQ mode,
SCTLR.VE No
?
Yes Non-secure IRQ mode, vector is
Figure B1-8 The mode the IRQ exception is taken to
The mode to which the Virtual IRQ exception is taken

The Virtual IRQ exception is supported only as part of the Virtualization Extensions. A Virtual IRQ exception is
taken from a Non-secure PL1 or PL0 mode, and is taken to Non-secure IRQ mode, using a vector offset of 0x18 from
the Non-secure exception base address.
Determining the mode to which the FIQ exception is taken
Figure B1-8 shows how the implementation, state, and configuration options determine the mode to which an FIQ
exception is taken.
FIQ exception Have

Security SCTLR.VE FIQ mode,
No No
Extensions == 1 vector offset 0x1C
? ?
Yes Yes FIQ mode, vector is
SCR.FIQ Monitor mode,

Yes
?
No
State is Secure FIQ mode,

Yes SCTLR.VE No
Secure vector offset 0x1C
== 1
?
?
No Yes Secure FIQ mode, vector is
Have
Virtualization Yes Taken from Yes
Extensions Hyp mode
? ?
No No
HCR.FMO Hyp mode,

Yes
?
No Non-secure FIQ mode,
SCTLR.VE No
?
Yes Non-secure FIQ mode, vector is
Figure B1-9 The mode the FIQ exception is taken to
The mode to which the Virtual FIQ exception is taken
The Virtual FIQ exception is supported only as part of the Virtualization Extensions. A Virtual FIQ exception is
taken from a Non-secure PL1 or PL0 mode, and is taken to Non-secure FIQ mode, using a vector offset of 0x1C from
the Non-secure exception base address.
B1.8.5 Processor state on exception entry

The description of each exception includes a pseudocode description of entry to that exception, as Table B1-5 on
page B1-1170 shows. The following sections describe the processor state changes on entering an exception, for
different processor implementations and operating states. However, you must always see the exception entry
pseudocode for a full description of the state changes on exception entry:
• Instruction set state on exception entry.
• CPSR.E bit value on exception entry.
• CPSR.{A, I, F, M} values on exception entry.
Instruction set state on exception entry

Exception handlers always execute in either Thumb state or ARM state, as Table B1-8 shows. On exception entry,
CPSR.{T, J} are set to the values shown, with the CPSR.T value determined by SCTLR.TE or HSCTLR.TE,
depending on the mode the exception is taken to:
Table B1-8 CPSR.J and CPSR.T bit values on exception entry
Exception mode HSCTLR.TE SCTLR.TE CPSR.J CPSR.T Exception handler state
Secure or Non-secure PL1 x 0 0 0 ARM
1 0 1 Thumb
Hyp 0 x 0 0 ARM
1 x 0 1 Thumb
When an implementation includes the Security Extensions, SCTLR is Banked for Secure and Non-secure states, and
therefore the TE bit value might be different for Secure and Non-secure states. For an exception taken to a Secure
or Non-secure PL1 mode, the SCTLR.TE bit for the security state to which the exception is taken determines the
instruction set state for the exception handler. This means the PL1 exception handlers might run in different
instruction set states, depending on the security state.
CPSR.E bit value on exception entry

The CPSR.E bit controls the load and store endianness for data handling. On exception entry, this bit is set as
Table B1-9 shows:
Table B1-9 CPSR.E bit value on exception entry
Exception mode HSCTLR.EE SCTLR.EE Endianness for data loads and stores CPSR.E
Secure or Non-secure PL1 x 0 Little-endian 0
1 Big-endian 1
Hyp 0 x Little-endian 0
1 x Big-endian 1
For more information, see the bit description in Format of the CPSR and SPSRs on page B1-1148.
CPSR.{A, I, F, M} values on exception entry

On exception entry, CPSR.M is set to the value for the mode to which the exception is taken, as described in
Processor mode for taking exceptions on page B1-1172.
Table B1-10 shows the cases where CPSR.{A, I, F} bits are set to 1 on an exception entry, and how this depends on
the mode and security state to which an exception is taken. If the table entry for a particular mode and security state
does not define a value for a CPSR.{A, I, F} bit then that bit is unchanged by the exception entry. In this table:
• The Exception mode column is the mode to which the exception is taken.
• The Non-secure, no Virtualization Extensions column applies to exceptions taken to Non-secure state in an
implementation that includes the Security Extensions but not the Virtualization Extensions.
• The All others column applies to:

— Implementations that do not include the Security Extensions.
— Exceptions taken to Secure state.
— Exceptions taken to Non-secure state in an implementation that includes the Virtualization Extensions.
Table B1-10 CPSR.{A, I, F} values on exception entry
Security state and implementation

Exception mode
Non-secure, no Virtualization Extensions All others
Hyp - If SCR.EA==0 then CPSR.A is set to 1

If SCR.IRQ==0 then CPSR.I is set to 1
If SCR.FIQ==0 then CPSR.F is set to 1
Monitor - CPSR.A is set to 1

CPSR.I is set to 1
CPSR.F is set to 1
FIQ If SCR.AW==1 then CPSR.A is set to 1 CPSR.A is set to 1

CPSR.I is set to 1 CPSR.I is set to 1
If SCR.FW==1 then CPSR.F is set to 1 CPSR.F is set to 1
IRQ, Abort If SCR.AW==1 then CPSR.A is set to 1 CPSR.A is set to 1

CPSR.I is set to 1 CPSR.I is set to 1
Undefined, Supervisor CPSR.I is set to 1 CPSR.I is set to 1
Note
Compared to an implementation that includes only the Security Extensions, implementing the Virtualization
Extensions changes both the effects of the SCR.{AW, FW} bits and the interpretation of the CPSR.{A, F} bits.
Asynchronous exception masking on page B1-1183 summarizes the behavior for both of these implementation
options.
B1.8.6 Asynchronous exception masking

The CPSR.{A, I, F} bits can mask the corresponding exceptions, as follows:
• CPSR.A can mask asynchronous aborts.
• CPSR.I can mask IRQ exceptions.
• CPSR.F can mask FIQ exceptions.
In an ARMv7 implementation that does not include the Security Extensions, setting one of these bits to 1 masks the
corresponding exception, meaning the exception cannot be taken.
In an implementation that includes the Security Extensions, the SCR.{AW, FW} bits provide a mechanism to
prevent use of the CPSR.{A, F} mask bits by Non-secure software. In an implementation that includes the
Virtualization Extensions:
• HCR.{AMO, FMO} modify this mechanism.
• HCR.IMO can prevent the masking, by CPSR.I, of IRQs taken from Non-secure state.
This means the asynchronous exception masking mechanism is as follows:
Implementation that includes the Security Extensions but not the Virtualization Extensions
When an SCR.{AW, FW} bit is set to 0, Non-secure software cannot update the corresponding
CPSR bit. This means:
• When SCR.AW is set to 0, CPSR.A cannot be updated in Non-secure state.
• When SCR.FW is set to 0, CPSR.F cannot be updated in Non-secure state.
Note
There is no control of updates to CPSR.I. CPSR.I can be updated in either security state.
The CPSR.{A, I, F} bits mask the corresponding exceptions. This means:

• When CPSR.A is set to 1, asynchronous aborts are masked.
• When CPSR.I is set to 1, IRQs are masked.
• When CPSR.F is set to 1, FIQs are masked.
Implementation that includes the Security Extensions and the Virtualization Extensions
When an HCR.{AMO, IMO, FMO} mask override bit is set to 1, the value of the corresponding
CPSR.{A, I, F} bit is ignored when both of the following apply:
• The exception is taken from Non-secure state.
• Either:
— The corresponding SCR.{EA, IRQ, FIQ} bit routes the exception to Monitor mode.
— The exception is taken from a Non-secure mode other than Hyp mode.
In addition, when an SCR.{AW, FW} bit is set to 0, the value of the corresponding CPSR.{A, F}
bit is ignored when all of the following apply:
• The exception is taken from Non-secure state.
• The corresponding SCR.{EA, FIQ} bit routes the exception to Monitor mode.
• The corresponding HCR.{AMO, FMO} mask override bit is set to 0.
This means that the controls on each of the CPSR mask bits, and the effect of those bits, are as shown
in the following tables.
Table B1-11 shows the controls of the masking of asynchronous exceptions by CPSR.A.
Table B1-11 Control of masking by CPSR.A
Security state HCR.AMO SCR.EA SCR.AW Mode CPSR.A
Secure x x x x Masks asynchronous aborts, when set to 1
Non-secure 0 0 x x Masks asynchronous aborts, when set to 1
1 0 x Ignored
1 x Masks asynchronous aborts, when set to 1
1 x x Not Hyp Ignored
0 x Hyp Masks asynchronous aborts, when set to 1
1 x x Ignored
Table B1-12 shows the controls of the masking of FIQ exceptions by CPSR.F:
Table B1-12 Control of masking by CPSR.I
Security state HCR.IMO SCR.IRQ Mode CPSR.I
Secure x x x Masks IRQs, when set to 1
Non-secure 0 x x Masks IRQs, when set to 1
1 x Not Hyp Ignored
0 Hyp Masks IRQs, when set to 1
1 x Ignored
Table B1-13 shows the controls of the masking of FIQ exceptions by CPSR.F:
Table B1-13 Control of masking by CPSR.F
Security state HCR.FMO SCR.FIQ SCR.FW Mode CPSR.F
Secure x x x x Masks FIQs, when set to 1
Non-secure 0 0 x x Masks FIQs, when set to 1
1 0 x Ignored
1 x Masks FIQs, when set to 1
1 x x Not Hyp Ignored
0 x Hyp Masks FIQs, when set to 1
1 x x Ignored
The values of SCR.{AW, FW} do not affect whether CPSR.{A, F} can be updated in Non-secure
state.
Mask override bits in the Virtualization Extensions on page B1-1185 gives more information about
the HCR.{AMO, IMO, FMO} bits.
Mask override bits in the Virtualization Extensions

The Virtualization Extensions add a set of mask override bits to the HCR, that affect both:
• The masking of asynchronous exceptions taken from Non-secure state.
• The enabling of the corresponding virtual exceptions.
These mask bits and their effects are:

• HCR.AMO can affect the masking of asynchronous aborts, and the enabling of Virtual Abort exceptions.
• HCR.IMO can affect the masking of IRQ exceptions, and the enabling of Virtual IRQ exceptions.
• HCR.FMO can affect the masking of FIQ exceptions, and the enabling of Virtual FIQ exceptions.
These bits can also affect the routing of the corresponding physical exceptions, see Asynchronous exception routing
controls on page B1-1174.
The HCR mask override bits have no effect on exceptions taken to Secure state.
If an HCR mask override bit is set to 1, when the processor is in Non-secure state and not in Hyp mode:
• If the corresponding physical exception is not routed to Monitor mode, the physical exception is taken to Hyp
mode.
• When the corresponding CPSR mask bit is set to 1 it:

— Masks the corresponding virtual exception.
— Does not mask the corresponding physical exception.
• If the corresponding virtual exception bit in the HCR is set to 1, and the corresponding CPSR mask bit is not
set to 1, the virtual exception is signaled to the processor.
When the processor is in Hyp mode, if an HCR mask override bit is set to 1 the corresponding CPSR mask bit cannot
mask the corresponding physical exception if that exception is routed to Monitor mode.
Note
When the processor is in Hyp mode:
• Physical asynchronous exceptions that are not routed to Monitor mode are taken to Hyp mode.
• Virtual exceptions are not signaled to the processor.
B1.8.7 Summaries of asynchronous exception behavior

In an ARMv7 implementation that does not include the Security Extensions, the asynchronous exceptions behave
as follows:
• An asynchronous abort is taken to Abort mode.
• An IRQ exception is taken to IRQ mode.
• An FIQ exception is taken to FIQ mode.
The Security Extensions and Virtualization Extensions introduce controls that affect:
• The routing of these exceptions, see Asynchronous exception routing controls on page B1-1174.
• Masking of these exceptions in Non-secure state, see Asynchronous exception masking on page B1-1183.
This section summarizes the effect of these controls, for each of the asynchronous exceptions. Because the
Virtualization Extensions change the behavior of some of the Security Extensions controls, it gives separate
summaries for implementations that include and do not include the Virtualization Extensions.
Note
• In an implementation that includes the Security Extensions but does not include the Virtualization
Extensions, the following configurations permit the Non-secure state to deny service to the Secure state.
Therefore, ARM recommends that, wherever possible, these configurations are not used:
— Setting SCR.IRQ to 1. With this configuration, Non-secure PL1 software can set CPSR.I to 1, denying
the required routing of IRQs to Monitor mode.
— Setting SCR.FW to 1 when SCR.FIQ is set to 1. With this configuration, Non-secure PL1 software can
set CPSR.F to 1, denying the required routing of FIQs to Monitor mode.
The changes introduced by the Virtualization Extensions remove these possible denials of service.
• Interrupts driven by Secure peripherals are called Secure interrupts. When SCR.FW = 0 and SCR.FIQ = 1,
FIQ exceptions can be used as Secure interrupts. These enter Secure state in a deterministic way.
The following subsections summarize the behavior of asynchronous exceptions:

• Asynchronous exception behavior, Security Extensions only.
• Asynchronous exception behavior, with the Virtualization Extensions on page B1-1187.
Asynchronous exception behavior, Security Extensions only

The following subsections describe the behavior of each of the asynchronous exceptions, in an implementation that
includes the Security Extensions but not the Virtualization Extensions:
• Behavior of asynchronous aborts, Virtualization Extensions not implemented.
• Behavior of IRQ exceptions, Virtualization Extensions not implemented on page B1-1187.
• Behavior of FIQ exceptions, Virtualization Extensions not implemented on page B1-1187.
Behavior of asynchronous aborts, Virtualization Extensions not implemented
Table B1-14 shows how SCR.{AW, EA} control asynchronous abort behavior.
Table B1-14 Behavior of asynchronous aborts, Virtualization Extensions not implemented
SCR.EA SCR.AW Effect on asynchronous abort behavior
0 0 Asynchronous aborts are taken to Abort mode.

If CPSR.A is set to 1 it masks asynchronous aborts in all states and modes.
CPSR.A can be modified in Secure PL1 modes, but cannot be modified in Non-secure PL1 modes.
0 1 Asynchronous aborts are taken to Abort mode.

CPSR.A can be modified in Secure and Non-secure PL1 modes.
1 0 Asynchronous aborts are taken to Monitor mode.

CPSR.A can be modified in Secure PL1 modes, but cannot be modified in Non-secure PL1 modes.
1 1 Asynchronous aborts are taken to Monitor mode.

CPSR.A can be modified in Secure and Non-secure PL1 modes.
Note
The values of SCR.EA and CPSR.A have no effect on the behavior of asynchronous watchpoints.
Behavior of IRQ exceptions, Virtualization Extensions not implemented
Table B1-15 shows how SCR.IRQ controls IRQ exception behavior.
Table B1-15 Behavior of IRQ exceptions, Virtualization Extensions not implemented
SCR.IRQ Effect on IRQ exception behavior
0 IRQ exceptions are taken to IRQ mode.

If CPSR.I is set to 1 it masks IRQs in all states and modes.
1 IRQ exceptions are taken to Monitor mode.

Behavior of FIQ exceptions, Virtualization Extensions not implemented
Table B1-16 shows how SCR.{FIQ, FW} control FIQ exception behavior.
Table B1-16 Behavior of FIQ exceptions, Virtualization Extensions not implemented
SCR.FIQ SCR.FW Effect on FIQ exception behavior
0 0 FIQ exceptions are taken to FIQ mode.

If CPSR.F is set to 1 it masks FIQs in all states and modes.
CPSR.F can be modified in Secure PL1 modes, but cannot be modified in Non-secure PL1 modes.
0 1 FIQ exceptions are taken to FIQ mode.

CPSR.F can be modified in Secure and Non-secure PL1 modes.
1 0 FIQ exceptions are taken to Monitor mode.

CPSR.F can be modified in Secure PL1 modes, but cannot be modified in Non-secure PL1 modes.
1 1 FIQ exceptions are taken to Monitor mode.

CPSR.F can be modified in Secure and Non-secure PL1 modes.
Asynchronous exception behavior, with the Virtualization Extensions

The following subsections describe the behavior of each of the asynchronous exceptions, in an implementation that
includes both the Security Extensions and the Virtualization Extensions:
• Behavior of asynchronous aborts when an implementation includes the Virtualization Extensions on

page B1-1188.
• Behavior of IRQ exceptions when an implementation includes the Virtualization Extensions on

page B1-1189.
• Behavior of FIQ exceptions when an implementation includes the Virtualization Extensions on

page B1-1190.
These summaries include the behavior of the virtual exceptions. See Virtual exceptions in the Virtualization
Extensions on page B1-1196 for more information about these exceptions. To distinguish them from the virtual
exceptions, the asynchronous aborts defined for an ARMv7 implementation that does not include the Virtualization
Extensions are described as physical aborts. That is, they are described as physical asynchronous aborts, physical
IRQs, and physical FIQs.
Note
As stated in Vectored interrupt support on page B1-1167, the Virtualization Extensions do not support the vectoring
of IRQ or FIQ exceptions that are routed to Hyp mode. Therefore, if at least one of HCR.IMO and HCR.FMO is set
to 1, the processor behaves as if the Non-secure SCTLR.VE bit is set to 0, regardless of the actual value of that bit.
Behavior of asynchronous aborts when an implementation includes the Virtualization Extensions
Table B1-17 shows how SCR.{AW, EA} and HCR.AMO control asynchronous abort behavior in an
implementation that includes the Virtualization Extensions. In such an implementation, CPSR.A can be modified in
Secure and Non-secure PL1 modes and in Hyp mode, regardless of the value of SCR.AW.
Table B1-17 Behavior of asynchronous aborts, Virtualization Extensions implemented
SCR.EA SCR.AW HCR.AMO Effect on asynchronous abort behavior
0 x 0 Physical asynchronous aborts are taken to:

• Abort mode, if taken from a PL0 or PL1 mode.
• Hyp mode, if taken from Hyp mode.
HCR.VA, the Virtual asynchronous abort bit, has no effect, and Virtual asynchronous aborts
are masked.
If CPSR.A is set to 1 it masks physical asynchronous aborts in all states and modes.
0 x 1 Physical asynchronous aborts are taken to:

• Secure Abort mode if taken from a Secure mode.
• Hyp mode if taken from a Non-secure mode.
If HCR.VA is set to 1 and the processor is in a Non-secure PL1 or PL0 mode, a virtual
asynchronous abort is signaled to the processor.
If CPSR.A is set to 1:
• In Secure state or in Hyp mode, physical asynchronous aborts are masked
• In a Non-secure PL1 or PL0 mode:
— Virtual asynchronous aborts are masked.
— Physical asynchronous aborts are not masked.
1 0 0 Physical asynchronous aborts are taken to Monitor mode.

HCR.VA, the Virtual asynchronous abort bit, has no effect, and Virtual asynchronous aborts
are masked.
• In Secure state, physical asynchronous aborts are masked.
• In Non-secure state, physical asynchronous aborts are not masked.
1 x 1 Physical asynchronous aborts are taken to Monitor mode.

If HCR.VA is set to 1 and the processor is in a Non-secure PL1 or PL0 mode, a virtual
asynchronous abort is signaled to the processor.
• In Secure state, physical asynchronous aborts are masked.
• In Non-secure state:
— Physical asynchronous aborts are not masked.
— In PL1 and PL0 modes, virtual asynchronous aborts are masked.
1 1 0 Physical asynchronous aborts are taken to Monitor mode.

HCR.VA, the Virtual asynchronous abort bit, has no effect.
If CPSR.A is set to 1 it masks physical asynchronous aborts in all states and modes.
Behavior of IRQ exceptions when an implementation includes the Virtualization Extensions
Table B1-18 shows how SCR.IRQ and HCR.IMO control IRQ exception behavior, in an implementation that
includes the Virtualization Extensions.
Table B1-18 Behavior of IRQ exceptions, Virtualization Extensions implemented
SCR.IRQ HCR.IMO Effect on IRQ exception behavior
0 0 Physical IRQs are taken to:

• IRQ mode, if taken from a PL0 or PL1 mode.
HCR.VI, the Virtual IRQ bit, has no effect, and Virtual IRQs are masked.
0 1 Physical IRQs are taken to:

• Secure IRQ mode if taken from a Secure mode.
If HCR.VI is set to 1 and the processor is in a Non-secure PL1 or PL0 mode, a virtual IRQ is signaled to
the processor.
If CPSR.I is set to 1:
• In Secure state or in Hyp mode, physical IRQs are masked.
— Virtual IRQs are masked.
— Physical IRQs are not masked.
1 0 Physical IRQs are taken to Monitor mode.

HCR.VI, the Virtual IRQ bit, has no effect, and Virtual IRQs are masked.
If CPSR.I is set to 1 it masks physical IRQs in all states and modes.
1 1 Physical IRQs are taken to Monitor mode.

If HCR.VI is set to 1 and the processor is in a Non-secure PL1 or PL0 mode, a virtual IRQ is signaled to
the processor.
If CPSR.I is set to 1:
• In Secure state, physical IRQs are masked.
— Physical IRQs are not masked.
— In PL1 and PL0 modes, virtual IRQs are masked.
Behavior of FIQ exceptions when an implementation includes the Virtualization Extensions
Table B1-19 shows how SCR.{FIQ, FW} and HCR.FMO control FIQ exception behavior, in an implementation that
includes the Virtualization Extensions. In such an implementation, CPSR.F can be modified in Secure and
Non-secure PL1 modes and in Hyp mode, regardless of the value of SCR.FW.
Table B1-19 Behavior of FIQ exceptions, Virtualization Extensions implemented
SCR.FIQ SCR.FW HCR.FMO Effect on FIQ exception behavior
0 x 0 Physical FIQs are taken to:

• FIQ mode, if taken from a PL1 or PL0 mode.
HCR.VF, the Virtual FIQ bit, has no effect, and Virtual FIQs are masked.
0 x 1a Physical FIQs are taken to:

• Secure FIQ mode if taken from a Secure mode.
If HCR.VF is set to 1 and the processor is in a Non-secure PL1 or PL0 mode, a virtual FIQ
is signaled to the processor.
If CPSR.F is set to 1:
• In Secure state or in Hyp mode, physical FIQs are masked.
— Virtual FIQs are masked.
— Physical FIQs are not masked.
1 0 0 Physical FIQs are taken to Monitor mode.

HCR.VF, the Virtual FIQ bit, has no effect, and Virtual FIQs are masked.
• In Secure state, physical FIQs are masked.
• In Non-secure state, physical FIQs are not masked.
1 x 1a Physical FIQs are taken to Monitor mode.

If HCR.VF is set to 1 and the processor is in a Non-secure PL1 or PL0 mode, a virtual FIQ
is signaled to the processor.
• In Secure state, physical FIQs are masked.
— Physical FIQs are not masked.
— In PL1 and PL0 modes, virtual FIQs are masked.
1 1 0 Physical FIQs are taken to Monitor mode.

HCR.VF, the Virtual FIQ bit, has no effect.
If CPSR.F is set to 1 it masks physical FIQs in all states and modes.
a. Only if NSACR.RFR is set to 0. If NSACR.RFR is set to 1, the processor behaves as if HCR.FMO is set to 0.
B1.8.8 Routing general exceptions to Hyp mode
Note
The routing provided by setting HCR.TGE to 1 permits applications that run in User mode to run on a hypervisor,
in Hyp mode, without a Guest OS running in a Non-secure PL1 mode. Many UNPREDICTABLE definitions associated
with setting HCR.TGE to 1 are based on this usage model.
When HCR.TGE is set to 1, and the processor is in Non-secure User mode, the following exceptions are taken to
Hyp mode, instead of to the default Non-secure mode for handling the exception:
• Undefined Instruction exceptions.
• Supervisor Call exceptions.
• Synchronous External aborts.
• Any Alignment fault other than an alignment fault caused by the memory type when SCTLR.M is 1.
Note
If SCTLR.M and HCR.TGE are both 1 then behavior is UNPREDICTABLE.
The following sections give more information about the behavior when each of these exceptions is routed in this
way:
• Undefined Instruction exception, when HCR.TGE is set to 1.
• Supervisor Call exception, when HCR.TGE is set to 1.
• Synchronous external abort, when HCR.TGE is set to 1 on page B1-1192.
• Alignment fault, when HCR.TGE is set to 1 on page B1-1192.
The effect of executing in any of the following states with HCR.TGE set to 1 is UNPREDICTABLE:
• In a Non-secure PL1 mode.
• In Non-secure User mode if either:
— SCTLR.M is set to 1.
— One or more of HDCR.{TDE, TDA, TDRA, TDOSA} is set to 0.
Undefined Instruction exception, when HCR.TGE is set to 1

When HCR.TGE is set to 1, if the processor is executing in Non-secure User mode and attempts to execute an
UNDEFINED instruction, it takes the Hyp Trap exception, instead of an Undefined Instruction exception. On taking
the Hyp Trap exception, the HSR reports an unknown reason for the exception, using the EC value 0x00. For more
information see Use of the HSR on page B3-1421.
Supervisor Call exception, when HCR.TGE is set to 1

When HCR.TGE is set to 1, if the processor executes an SVC instruction in Non-secure User mode, the Supervisor
Call exception generated by the instruction is taken to Hyp mode.
The HSR reports that entry to Hyp mode was because of a Supervisor Call exception, and:
• If the SVC is unconditional, takes for the imm16 value in the HSR:
— A zero-extended 8-bit immediate value for the Thumb SVC instruction.
Note
The only Thumb encoding for SVC is a 16-bit instruction encoding.
— The bottom16 bits of the immediate value for the ARM SVC instruction.
• If the SVC is conditional, the imm16 value in the HSR is UNKNOWN.
If the SVC is conditional, the processor takes the exception only if it passes its condition code check.
The HSR reports the exception as a Supervisor Call exception taken to Hyp mode, using the EC value 0x11. For
more information, see Use of the HSR on page B3-1421.
Note
The effect of setting HCR.TGE to 1 is to route the Supervisor Call exception to Hyp mode, not to trap the execution
of the SVC instruction. This means that the preferred return address for the exception, when routed to Hyp mode in
this way, is the instruction after the SVC instruction.
Synchronous external abort, when HCR.TGE is set to 1

When HCR.TGE is set to 1, and SCR.EA is set to 0, if the processor is executing in Non-secure User mode and
attempts to execute an instruction that causes a synchronous external abort, it takes the Hyp Trap exception, instead
of a Data Abort or Prefetch Abort exception. On taking the Hyp Trap exception, the HSR indicates whether a Data
Abort exception or a Prefetch Abort exception caused the Hyp Trap exception entry, and presents a valid syndrome
in the HSR.
Note
When SCR.EA is set to 1, external aborts are routed to Secure Monitor mode, and this takes priority over the
HCR.TGE routing. For more information, see Asynchronous exception routing controls on page B1-1174. The
SCR.EA control described in that section applies to both synchronous and asynchronous external aborts.
If an instruction that causes this exception is conditional, the processor takes the exception only if the instruction
passes its condition code check.
The HSR reports the exception either:

• As a Prefetch Abort exception routed to Hyp mode, using the EC value 0x20.
• As a Data Abort exception routed to Hyp mode, using the EC value 0x24.
For more information about the exception reporting, see Use of the HSR on page B3-1421.
Alignment fault, when HCR.TGE is set to 1

When HCR.TGE is set to 1, if the processor is executing in Non-secure User mode, this control applies to an attempt
to execute an instruction that causes an Alignment fault because one or more of the following applies:
• SCTLR.A is set to 1.
• The instruction supports only aligned accesses, and is accessing an unaligned address.
• HCR.DC is set to 0 and SCTLR.M is set to 0, so all memory accesses are Strongly-Ordered, and unaligned
accesses to strongly-ordered memory cause alignment faults.
Unaligned data access on page A3-106 summarizes the Alignment faults that are trapped.
In these cases, the attempted execution generates a Hyp Trap exception, instead of a Data Abort exception. When
the Hyp Trap exception is taken, the HSR reports that a Data Abort caused the Hyp Trap exception entry, and
presents a valid syndrome.
When the Non-secure SCTLR.M bit is set to 1, enabling the Non-secure PL1&0 stage 1 MMU, an
otherwise-permitted unaligned access to Device or Strongly-ordered memory generates an Alignment fault.
However, having HCR.TGE set to 1 when SCTLR.M is set to 1 is generally UNPREDICTABLE.
If an instruction that causes this exception is conditional, the processor takes the exception only if the instruction
The HSR reports the exception as a Data Abort routed to Hyp mode, using the EC value 0x24, see Use of the HSR
on page B3-1421.
B1.8.9 Routing Debug exceptions to Hyp mode

When HDCR.TDE is set to 1, if the processor is executing in a Non-secure mode other than Hyp mode, any Debug
exception is routed to Hyp mode. This means it generates a Hyp Trap exception. This applies to:
• Debug exceptions associated with instruction fetch, that would otherwise generate a Prefetch Abort
exception. These are exceptions generated by the Breakpoint, BKPT instruction, and Vector catch debug
events, see Debug exception on BKPT instruction, Breakpoint, or Vector catch debug events on
page C4-2076.
• Debug exceptions associated with data accesses, that would otherwise generate a Data Abort exception.
These are exceptions generated by the Watchpoint debug event, see Debug exception on Watchpoint debug
event on page C4-2077.
When HDCR.TDE is set to 1, the HDCR.{TDRA, TDOSA, TDA} bits must all be set to 1, otherwise behavior is
UNPREDICTABLE.
See also Permitted combinations of HDCR.{TDRA, TDOSA, TDA, TDE} bits on page B1-1259.
Note
• A debug event generates a debug exception only when invasive debug is enabled and Monitor debug-mode
is selected, see About debug exceptions on page C4-2076. When Halting debug-mode is selected, a debug
event causes Debug state entry and cannot be trapped to Hyp mode.
• When HDCR.TDE is set to 1, the Hyp Trap exception is generated instead of the Prefetch Abort exception
or Data Abort exception that is otherwise generated by the Debug exception.
• Debug exceptions, other than the exception on the BKPT instruction, are not permitted in Hyp mode.
When a Hyp Trap exception is generated because HDCR.TDE is set to 1, The HSR reports the exception either:
• As a Prefetch Abort exception routed to Hyp mode, using the EC value 0x20.
• As a Data Abort exception routed to Hyp mode, using the EC value 0x24.
For more information see Use of the HSR on page B3-1421.
B1.8.10 Exception return

In the ARM architecture, exception return requires the simultaneous restoration of the PC and CPSR to values that
are consistent with the desired state of execution on returning from the exception. Typically, exception return
involves returning to one of:
• The instruction after the instruction boundary at which an asynchronous exception was taken.
• The instruction following an SVC, SMC, or HMC instruction, for an exception generated by one of those
instructions.
• The instruction that caused the exception, after the reason for the exception has been removed.
• The subsequent instruction, if the instruction that caused the exception has been emulated in the exception
handler.
The ARM architecture defines a preferred return address for each exception other than Reset, see Link values saved
on exception entry on page B1-1171. The values of the SPSR.IT[7:0] bits generated on exception entry are always
correct for this preferred return address, but might require adjustment by the exception handler if returning
elsewhere.
In some cases, to calculate the appropriate preferred return address, a subtraction must be performed on the link
value saved on taking the exception. The description of each exception includes any value that must be subtracted
from the link value, and other information about the required exception return.
On an exception return, the CPSR takes either:
• The value loaded by the RFE instruction.
• If the exception return is not performed by executing an RFE instruction, the value of the current SPSR at the
time of the exception return
Where the exception return is UNPREDICTABLE, the implementation can adjust the value loaded into the CPSR, to
avoid a security hole, or other undesirable behavior. For example:
• In an implementation that includes the Security Extensions, if the processor is in a Non-secure PL1 mode,
and one of the following applies:
— The restored CPSR.M value is 0b10110, the value for Monitor mode.
— NSACR.RFR is set to 1, and the restored CPSR.M value is 0b10001, the value for FIQ mode.
Note
When NSACR.RFR is set to 1, FIQ mode is reserved for Secure operation.
— If the implementation includes the Virtualization Extensions, and the restored CPSR.M value is
0b11010, the value for Hyp mode.
In this case, CPSR.M takes an UNKNOWN value that does not correspond to any of:
— Hyp mode.
— Monitor mode.
— If NSACR.RFR is set to 1, FIQ mode.
• In an implementation that includes the Virtualization Extensions, if the processor is in the Non-secure PL2
mode and one of the following applies:
— The restored CPSR.M value is 0b10110, the value for Monitor mode.
— NSACR.RFR is set to 1 and the restored CPSR.M value is 0b10001, the value for FIQ mode.
In this case, CPSR.M takes an UNKNOWN value that does not correspond to either:
— Monitor mode.
— If NSACR.RFR is set to 1, FIQ mode.
• In an implementation that includes the Virtualization Extensions, if SCR.NS is set to 0 and the restored
CPSR.M value is 0b11010, the value for Hyp mode.
In this case, CPSR.M takes an UNKNOWN value that does not correspond to Hyp mode.
• If the new CPSR.{J, T} bits correspond to an unsupported instruction set, including an instruction set that is
not supported in the mode of operation that applies immediately after the exception return, the CPSR.{J, T}
bits might be set to values that correspond to a supported instruction set. For more information see Exception
return to an unimplemented instruction set state on page B1-1196.
An example of where this might happen is a return to Hyp mode with CPSR.{J, T} set to {1, 1}, the values
for ThumbEE.
• If the new CPSR.IT bits correspond to a reserved value then CPSR.IT might be set to a permitted UNKNOWN
value. For more information see IT block state register, ITSTATE on page A2-51.
Exception return instructions

The instructions that an exception handler can use to return from an exception depend on whether the exception was
taken to a PL1 mode, or in a PL2 mode, see:
• Return from an exception taken to a PL1 mode on page B1-1195.
• Return from an exception taken to a PL2 mode on page B1-1195.
Note
The Thumb exception return instructions are all UNPREDICTABLE if executed in ThumbEE state.
Return from an exception taken to a PL1 mode
For an exception taken to a PL1 mode, the ARM architecture provides the following exception return instructions:
• Data-processing instructions with the S bit set and the PC as a destination, see SUBS PC, LR (Thumb) on
page B9-1996 and SUBS PC, LR and related instructions (ARM) on page B9-1998.
Typically:
— A return where no subtraction is required uses SUBS with an operand of 0, or the equivalent MOVS
instruction.
— A return requiring subtraction uses SUBS with a nonzero operand.
• From ARMv6, the RFE instruction, see RFE on page B9-1986. If a subtraction is required, typically it is
performed before saving the LR value to memory.
• In ARM state, a form of the LDM instruction, see LDM (exception return) on page B9-1972. If a subtraction is
required, typically it is performed before saving the LR value to memory.
Return from an exception taken to a PL2 mode

For an exception taken to a PL2 mode, the ARM architecture provides the ERET instruction, see ERET on
page B9-1968. An exception handler executing in a PL2 mode must return using the ERET instruction.
Hyp mode is the only PL2 mode. Both Hyp mode and the ERET instruction are implemented only as part of the
Virtualization Extensions.
Alignment of exception returns

The {J, T} bits of the value transferred to the CPSR by an exception return control the target instruction set of that
return. The behavior of the hardware for exception returns for different values of the {J, T} bits is as follows:
{J, T} == 00 The target instruction set state is ARM state. Bits[1:0] of the address transferred to the PC are
ignored by the hardware.
{J, T} == 01 The target instruction set state is Thumb state:

• Bit[0] of the address transferred to the PC is ignored by the hardware.
• Bit[1] of the address transferred to the PC is part of the instruction address.
{J, T} == 10 The target instruction set state is Jazelle state. In a non-trivial implementation of the Jazelle
extension, bits[1:0] of the address transferred to the PC are part of the instruction address. For the
behavior in a trivial implementation of the Jazelle extension, see Exception return to an
unimplemented instruction set state on page B1-1196. For details of the trivial implementation see
Trivial implementation of the Jazelle extension on page B1-1244.
{J, T} == 11 The target instruction set state is ThumbEE state:

• Bit[0] of the address transferred to the PC is ignored by the hardware.
• Bit[1] of the address transferred to the PC is part of the instruction address.
ARM deprecates any dependence on the requirements that the hardware ignores bits of the address. ARM
recommends that the address transferred to the PC for an exception return is correctly aligned for the target
instruction set.
After an exception entry other than Reset, the LR value has the correct alignment for the instruction set indicated
by the SPSR.{J, T} bits. This means that if exception return instructions are used with the LR and SPSR values
produced by such an exception entry, the only precaution software needs to take to ensure correct alignment is that
any subtraction is of a multiple of four if returning to ARM state, or a multiple of two if returning to Thumb state
or to ThumbEE state.
Exception return to an unimplemented instruction set state

An implementation that does not support one or both of Jazelle and ThumbEE states does not normally get into an
unimplemented instruction set state, because:
• On a trivial Jazelle implementation, the BXJ instruction acts as a BX instruction.
• On an implementation that does not include ThumbEE support, the ENTERX instruction is UNDEFINED.
• Normal exception entry and return preserves the instruction set state.
However, on some implementations, an exception return instruction might set CPSR.{J. T} to the values
corresponding to an unimplemented instruction set state, see Unimplemented instruction sets on page B1-1155. This
is most likely to happen because a faulty exception handler restores the wrong value to the CPSR.
If the processor attempts to execute an instruction while the CPSR.{J, T} bits indicate an unimplemented instruction
set state, an Undefined Instruction exception is taken. This happens if either:
• CPSR.J == 1 and CPSR.T == 1, and the processor does not support ThumbEE state.
• CPSR.J == 1 and CPSR.T == 0, and the processor does not support Jazelle state.
The Undefined Instruction exception handler can detect the cause of this exception because on entry to the handler
the SPSR.{J, T} bits indicate the unimplemented instruction set state. If the Undefined Instruction exception handler
wants to return to a valid instruction set state it can change the values its exception return instruction writes to the
CPSR.{J, T} bits.
If an exception return writes CPSR.{J, T} values that correspond to an unimplemented instruction set state, and also
writes the address of an aborting memory location to the PC, it is IMPLEMENTATION DEFINED whether:
• The instruction fetch is attempted, and a Prefetch Abort exception is taken because the memory access aborts.
• An Undefined Instruction exception is taken, without the instruction being fetched.
If an exception return writes CPSR.{J, T} values that correspond to an unimplemented instruction set, the width of
the instruction fetch is an IMPLEMENTATION DEFINED value that is 1, 2 or 4 bytes.
An implementation that supports neither of the Jazelle and ThumbEE states can implement the J bits of the PSRs as
RAZ/WI. On such an implementation, a return to an unimplemented instruction set state cannot occur.
B1.8.11 Virtual exceptions in the Virtualization Extensions

The Virtualization Extensions introduce three virtual exceptions, that correspond to the physical asynchronous
exceptions:
• Virtual Abort, that corresponds to a physical external asynchronous abort.
• Virtual IRQ, that corresponds to a physical IRQ.
• Virtual FIQ, that corresponds to a physical FIQ.
When the corresponding HCR.{AMO, IMO, FMO} bit is set to 1, a virtual exception is generated either:
• By setting a virtual interrupt pending, HCR.{VA, VI, VF}, to 1.
• For a Virtual IRQ or Virtual FIQ, by an IMPLEMENTATION DEFINED mechanism. This might be a signal from
an interrupt controller, for example, as defined by the ARM Generic Interrupt Controller Architecture
Specification.
A virtual exception is taken only from a Non-secure PL1 or PL0 mode. In any other mode, if the exception is
generated it is not taken.
A virtual exception is taken to Non-secure state in the default mode for the corresponding physical exception. This
means:
• A Virtual Abort is taken to Non-secure Abort mode.
• A Virtual IRQ is taken to Non-secure IRQ mode.
• A Virtual FIQ is taken to Non-secure FIQ mode.
Table B1-20 summarizes the HCR bits that route asynchronous exceptions to Hyp mode, and the bits that generate
the virtual exceptions.
Table B1-20 HCR bits controlling asynchronous exceptions
Exception Routing the physical exception to Hyp mode Generating the virtual exception
Asynchronous abort HCR.AMO HCR.VA
IRQ HCR.IMO HCR.VI
FIQ HCR.FMO HCR.VF
The HCR.{AMO, IMO, FMO} bits route the corresponding physical exception to Hyp mode only if the physical
exception is not routed to Monitor mode by the SCR.{EA, IRQ, FIQ} bit. Similarly, the HCR.{VA, VI, VF} bits
generate a virtual exception only if set to 1 when the corresponding HCR.{AMO, IMO, FMO} is set to 1. For more
information, see Asynchronous exception behavior, with the Virtualization Extensions on page B1-1187.
When an HCR.{AMO, IMO, FMO} control bit is set to 1, the corresponding mask bit in the CPSR:
• Does not mask the physical exception.
• Masks the virtual exception, if the processor is executing in a Non-secure PL1 or PL0 mode.
Taking a Virtual Abort exception clears HCR.VA to zero. Taking a Virtual IRQ exception or a Virtual FIQ exception
does not affect the value of HCR.VI or HCR.VF.
Note
This means that the exception handler for a Virtual IRQ exception or a Virtual FIQ exception must cause software
executing in Hyp mode, or in Monitor mode, to update the HCR to clear the appropriate virtual exception bit to 0.
See WFE wake-up events on page B1-1200 and Wait For Interrupt on page B1-1202 for information about how
virtual exceptions affect wake up from power-saving states.
Note
A hypervisor can use virtual exceptions to signal exceptions to the current Guest OS. The Guest OS takes a virtual
exception exactly as it would take the corresponding physical exception, and is unaware of any distinction between
virtual exceptions and the corresponding physical exceptions.
B1.8.12 Low interrupt latency configuration

Setting SCTLR.FI to 1 enables the low interrupt latency configuration of an implementation. This configuration can
reduce the interrupt latency of the processor. The mechanisms implemented to achieve low interrupt latency are
IMPLEMENTATION DEFINED. For the description of the SCTLR see either:
In an implementation that includes the Virtualization Extensions, the HSCTLR.FI bit is a RO bit that indicates the
current value of SCTLR.FI.
To ensure that a change between normal and low interrupt latency configurations is synchronized correctly, the
SCTLR.FI bit must be changed only in IMPLEMENTATION DEFINED circumstances. The FI bit can be changed shortly
after reset, with interrupts disabled, and before enabling any MMU, MPU, or cache, using the following sequence:
DSB
ISB
MCR p15, 0, Rx, c1, c0, c0 ; change FI bit in the SCTLR
DSB
ISB
An implementation can define other sequences and circumstances that permit the SCTLR.FI bit to be changed.
Note
• Examples of methods that might be implemented to reduce interrupt latency are:
— Disabling Hit-Under-Miss functionality in a processor.
— The abandoning of restartable external accesses.
These choices permit the processor to react to a pending interrupt faster than would otherwise be the case.
• Reducing interrupt latency can result in reduced performance overall.
A low interrupt latency configuration might permit interrupts and asynchronous aborts to be taken during a sequence
of memory transactions generated by a single load or store instruction. For details of what these sequences are and
the consequences of taking interrupts and asynchronous aborts in this way see Single-copy atomicity on
page A3-125. If the implementation permits interrupts to be taken during an LDM or STM instruction in this way, those
instructions are described as being restartable.
ARM deprecates any software reliance on the behavior that an interrupt or asynchronous abort cannot occur in a
sequence of memory transactions generated by a single load or store instruction that accesses Normal memory.
Note
A particular case that has shown this reliance is load multiples that load the stack pointer from memory. In an
implementation where an interrupt is taken during the LDM, this can corrupt the stack pointer.
B1.8.13 Wait For Event and Send Event

ARMv7 and ARMv6K provide a mechanism, the Wait For Event mechanism, that permits a processor in a
multiprocessor system to request entry to a low-power state, and, if the request succeeds, to remain in that state until
it receives an event generated by a Send Event operation on another processor in the system. Example B1-1
describes how a spinlock implementation might use this mechanism to save energy.
Example B1-1 Spinlock as an example of using Wait For Event and Send Event
A multiprocessor operating system requires locking mechanisms to protect data structures from being accessed
simultaneously by multiple processors. These mechanisms prevent the data structures becoming inconsistent or
corrupted if different processors try to make conflicting changes. If a lock is busy, because a data structure is being
used by one processor, it might not be practical for another processor to do anything except wait for the lock to be
released. For example, if a processor is handling an interrupt from a device it might need to add data received from
the device to a queue. If another processor is removing data from the queue, it will have locked the memory area
that holds the queue. The first processor cannot add the new data until the queue is in a consistent state and the lock
has been released. It cannot return from the interrupt handler until the data has been added to the queue, so it must
wait.
Typically, a spin-lock mechanism is used in these circumstances:
• A processor requiring access to the protected data attempts to obtain the lock using single-copy atomic
synchronization primitives such as the Load-Exclusive and Store-Exclusive operations described in
Synchronization and semaphores on page A3-112.
• If the processor obtains the lock it performs its memory operation and releases the lock.
• If the processor cannot obtain the lock, it reads the lock value repeatedly in a tight loop until the lock becomes
available. At this point it again attempts to obtain the lock.
A spin-lock mechanism is not ideal for all situations:
• In a low-power system the tight read loop is undesirable because it uses energy to no effect.
• In a multi-threaded processor the execution of spin-locks by waiting threads can significantly degrade overall
performance.
Using the Wait For Event and Send Event mechanism can improve the energy efficiency of a spinlock. In this
situation, a processor that fails to obtain a lock can execute a Wait For Event instruction, WFE, to request entry to a
low-power state. When a processor releases a lock, it must execute a Send Event instruction, SEV, causing any
waiting processors to wake up. Then, these processors can attempt to gain the lock again.
The Virtualization Extensions provide a bit that traps to Hyp mode any attempt to enter a low-power state from a
Non-secure PL1 or PL0 mode. For more information see Trapping use of the WFI and WFE instructions on
page B1-1253.
The architecture does not define the exact nature of the low power state, but the execution of a WFE instruction must
not cause a loss of memory coherency.
Note
Although a complex operating system can contain thousands of distinct locks, the event sent by this mechanism does
not indicate which lock has been released. If the event relates to a different lock, or if another processor acquires the
lock more quickly, the processor fails to acquire the lock and can re-enter the low-power state waiting for the next
event.
The Wait For Event system relies on hardware and software working together to achieve energy saving:
• The hardware provides the mechanism to enter the Wait For Event low-power state.
• The operating system software is responsible for issuing:

— A Wait For Event instruction, to request entry to the low-power state, used in the example when
waiting for a spin-lock.
— A Send Event instruction, required in the example when releasing a spin-lock.
The mechanism depends on the interaction of:

• WFE wake-up events, see WFE wake-up events.
• The Event Register, see The Event Register.
• The Send Event instruction, see The Send Event instruction on page B1-1201.
• The Wait For Event instruction, see The Wait For Event instruction on page B1-1201.
WFE wake-up events

The following events are WFE wake-up events:
• The execution of an SEV instruction on any processor in the multiprocessor system.
• A physical IRQ interrupt, unless masked by the CPSR.I bit.
• A physical FIQ interrupt, unless masked by the CPSR.F bit.
• A physical asynchronous abort, unless masked by the CPSR.A bit.
• In Non-secure state in any mode other than Hyp mode:
— When HCR.IMO is set to 1, a virtual IRQ interrupt, unless masked by the CPSR.I bit.
— When HCR.FMO is set to 1, a virtual FIQ interrupt, unless masked by the CPSR.F bit.
— When HCR.AMO is set to 1, a virtual asynchronous abort, unless masked by the CPSR.A bit.
• An asynchronous debug event, if invasive debug is enabled and the debug event is permitted.
• An event sent by the timer event stream, see Event streams on page B8-1950.
• An event sent by some IMPLEMENTATION DEFINED mechanism.
In addition to the possible masking of WFE wake-up events shown in this list, when invasive debug is enabled and
DBGDSCR[15:14] is not set to 0b00, DBGDSCR.INTdis can mask interrupts, including masking them acting as
WFE wake-up events. For more information, see DBGDSCR, Debug Status and Control Register on
page C11-2229.
As shown in the list of wake-up events, an implementation can include IMPLEMENTATION DEFINED hardware
mechanisms to generate wake-up events.
Note
For more information about CPSR masking see Asynchronous exception masking on page B1-1183. If the
configuration of the masking controls provided by the Security Extensions, or Virtualization Extensions, mean that
a CPSR mask bit cannot mask the corresponding exception, then the physical exception is a WFE wake-up event,
regardless of the value of the CPSR mask bit.
The Event Register

The Event Register is a single bit register for each processor. When set, an event register indicates that an event has
occurred, since the register was last cleared, that might require some action by the processor. Therefore, the
processor must not suspend operation on issuing a WFE instruction.
The reset value of the Event Register is UNKNOWN.
The Event Register is set by:

• An SEV instruction.
• An event sent by some IMPLEMENTATION DEFINED mechanism.
• A debug event that causes entry into Debug state.
• An exception return.
As shown in this list, the Event Register might be set by IMPLEMENTATION DEFINED mechanisms.
The Event Register is cleared only by a Wait For Event instruction.
Software cannot read or write the value of the Event Register directly.
The Send Event instruction

The Send Event instruction, SEV, causes an event to be signaled to all processors in the multiprocessor system. The
mechanism that signals the event to the processors is IMPLEMENTATION DEFINED. Hardware does not guarantee the
ordering of this event with respect to the completion of memory accesses by instructions before the SEV instruction.
Therefore, ARM recommends that software includes a DSB instruction before an SEV instruction.
Note
A DSB instruction ensures that no instruction, including any SEV instruction, that appears in program order after the
DSB instruction, can execute until the DSB instruction has completed. For more information, see Data Synchronization
Barrier (DSB) on page A3-150.
Execution of the Send Event instruction sets the Event Register.
The Send Event instruction is available at all privilege levels, see SEV on page A8-607.
An implementation can merge two or more events sent by two or more instances of SEV execution into a single
write to the event register and a single WFE wake-up event for a processor.
The Wait For Event instruction

The action of the Wait For Event instruction depends on the state of the Event Register:
• If the Event Register is set, the instruction clears the register and completes immediately. Normally, if this
happens the software makes another attempt to claim the lock.
• If the Event Register is clear the processor can suspend execution and enter a low-power state. It can remain
in that state until the processor detects a WFE wake-up event or a reset. When the processor detects a WFE
wake-up event, or earlier if the implementation chooses, the WFE instruction completes.
The Wait For Event instruction, WFE, is available at all privilege levels, see WFE on page A8-1105.
Software using the Wait For Event mechanism must tolerate spurious wake-up events, including multiple wake ups.
page B1-1253.
Pseudocode details of the Wait For Event lock mechanism

This section defines pseudocode functions that describe the operation of the Wait For Event mechanism.
The ClearEventRegister() pseudocode procedure clears the Event Register of the current processor.
The EventRegistered() pseudocode function returns TRUE if the Event Register of the current processor is set and
FALSE if it is clear:
boolean EventRegistered()
The WaitForEvent() pseudocode procedure optionally suspends execution until a WFE wake-up event or reset
occurs, or until some earlier time if the implementation chooses. It is IMPLEMENTATION DEFINED whether restarting
execution after the period of suspension causes a ClearEventRegister() to occur.
The SendEvent() pseudocode procedure sets the Event Register of every processor in the multiprocessor system.
The SendEventLocal() pseudocode procedure sets the Event Register of the processor that executes the
SendEventLocal() procedure.
B1.8.14 Wait For Interrupt

ARMv7 supports Wait For Interrupt through an instruction, WFI, that is provided in the ARM and Thumb instruction
sets. For more information, see WFI on page A8-1107.
Note
ARMv7 redefines the CP15 c7 encoding previously used for WFI as UNPREDICTABLE, see Retired operations on
page B3-1494 and Retired operations on page B5-1796.
When a processor issues a WFI instruction it can suspend execution and enter a low-power state.
page B1-1253.
The processor can remain in the WFI low-power state until it is reset, or it detects one of the following WFI wake-up
events:
• A physical IRQ interrupt, regardless of the value of the CPSR.I bit.
• A physical FIQ interrupt, regardless of the value of the CPSR.F bit.
• A physical asynchronous abort, regardless of the value of the CPSR.A bit.
• In Non-secure state in any mode other than Hyp mode:
— When HCR.IMO is set to 1, a virtual IRQ interrupt, regardless of the value of the CPSR.I bit.
— When HCR.FMO is set to 1, a virtual FIQ interrupt, regardless of the value of the CPSR.F bit.
— When HCR.AMO is set to 1, a virtual asynchronous abort, regardless of the value of the CPSR.A bit.
• An asynchronous debug event, when invasive debug is enabled and the debug event is permitted.
An implementation can include other IMPLEMENTATION DEFINED hardware mechanisms to generate WFI wake-up
events.
When the hardware detects a WFI wake-up event, or earlier if the implementation chooses, the WFI instruction
completes.
WFI wake-up events cannot be masked by the mask bits in the CPSR.
The architecture does not define the exact nature of the low power state, but the execution of a WFI instruction must
not cause a loss of memory coherency.
Note
• Because debug events are WFI wake-up events, ARM strongly recommends that Wait For Interrupt is used
as part of an idle loop rather than waiting for a single specific interrupt event to occur and then moving
forward. This ensures the intervention of debug while waiting does not significantly change the function of
the program being debugged.
• In some previous implementations of Wait For Interrupt, the idle loop is followed by exit functions that must
be executed before taking the interrupt. The operation of Wait For Interrupt remains consistent with this
model, and therefore differs from the operation of Wait For Event.
• Some implementations of Wait For Interrupt drain down any pending memory activity before suspending
execution. This increases the power saving, by increasing the area over which clocks can be stopped. The
ARM architecture does not require this operation, and software must not rely on Wait For Interrupt operating
in this way.
Using WFI to indicate an idle state on bus interfaces

A common implementation practice is to complete any entry into powerdown routines with a WFI instruction.
Typically, the WFI instruction:
1. Forces the suspension of execution, and of all associated bus activity.
2. Suspends the execution of instructions by the processor.
The control logic required to do this tracks the activity of the bus interfaces of the processor. This means it can signal
to an external power controller that there is no ongoing bus activity.
However, the processor must continue to process memory-mapped and external debug interface accesses to debug
registers when in the WFI state. The indication of idle state to the system normally only applies to the functional
interfaces of the processor, not the debug interfaces.
On an implementation that includes v7.1 Debug, when DBGPRSR.DLK, the OS Double Lock status bit, is set to 1,
the processor must not signal this idle state to the processor unless it can guarantee, also, that the debug interface is
idle. For more information about OS Double Lock, see Permissions in relation to locks on page C6-2106.
Note
In a processor that implements separate core and debug power domains, the debug interface referred to in this
section is the interface between the core and debug power domains, since the signal to the power controller indicates
that the core power domain is idle. For more information about the power domains see Power domains and debug
on page C7-2137.
The exact nature of this interface is IMPLEMENTATION DEFINED, but the use of Wait For Interrupt as the only
architecturally-defined mechanism that completely suspends execution makes it very suitable as the preferred
powerdown entry mechanism.
Pseudocode details of Wait For Interrupt

The WaitForInterrupt() pseudocode procedure optionally suspends execution until a WFI wake-up event or reset
occurs, or until some earlier time if the implementation chooses.
B1.9 Exception descriptions

Exception handling on page B1-1164 gives general information about exception handling. This section describes
each of the exceptions, in the following subsections:
• Reset.
• Undefined Instruction exception on page B1-1205.
• Hyp Trap exception on page B1-1208.
• Supervisor Call (SVC) exception on page B1-1209.
• Secure Monitor Call (SMC) exception on page B1-1210.
• Hypervisor Call (HVC) exception on page B1-1211.
• Prefetch Abort exception on page B1-1212.
• Data Abort exception on page B1-1214.
• Virtual Abort exception on page B1-1217.
• IRQ exception on page B1-1218.
• Virtual IRQ exception on page B1-1220.
• FIQ exception on page B1-1220.
• Virtual FIQ exception on page B1-1222.
Additional pseudocode functions for exception handling on page B1-1223 gives additional pseudocode that is used
in the pseudocode descriptions of a number of the exceptions.
B1.9.1 Reset
On an ARM processor, when the Reset input is asserted the processor stops execution. When Reset is deasserted,
the processor then starts executing instructions:
• In Secure state, if it implements the Security Extensions.
• In Supervisor mode, with interrupts disabled.
Reset returns some processor state to architecturally-defined or IMPLEMENTATION DEFINED values, and makes other
state UNKNOWN. For more information see:
• For a VMSAv7 implementation:
— Behavior of the caches at reset on page B2-1267.
— Enabling MMUs on page B3-1314.
— TLB behavior at reset on page B3-1375.
— Reset behavior of CP14 and CP15 registers on page B3-1446.
• For a PMSAv7 implementation:
— Behavior of the caches at reset on page B2-1267.
— Enabling and disabling the MPU on page B5-1750.
— Reset behavior of CP14 and CP15 registers on page B5-1770.
When reset is deasserted, execution starts either:
• From the low or high reset vector address, 0x00000000 or 0xFFFF0000, as determined by the reset value of the
SCTLR.V bit. This reset value can be determined by an IMPLEMENTATION DEFINED configuration input
signal.
• From an IMPLEMENTATION DEFINED address.
When executions starts, system behavior depends on the reset value of the CPSR, as defined by the TakeReset()
pseudocode function that is defined later in this section. See also The Current Program Status Register (CPSR) on
page B1-1147.
The ARM architecture does not define any way of returning to a previous execution state from a reset.
Note
• A Reset exception does not reset the value of all of the debug registers. For more information see Reset and
debug on page C7-2148.
• The ARM architecture does not distinguish between multiple levels of reset. A system can provide multiple
distinct levels of reset that reset different parts of the system. These all correspond to this single reset
exception.
Pseudocode description of taking the Reset exception

The TakeReset() pseudocode procedure describes how the processor takes the exception:
// TakeReset()
// ===========
TakeReset()
// Enter Supervisor mode and (if relevant) Secure state, and reset CP15. This affects
// the Banked versions and values of various registers accessed later in the code.
// Also reset other system components.
CPSR.M = '10011'; // Supervisor mode
if HaveSecurityExt() then SCR.NS = '0';
ResetControlRegisters();
if HaveAdvSIMDorVFP() then FPEXC.EN = '0'; SUBARCHITECTURE_DEFINED further resetting;
if HaveThumbEE() then TEECR.XED = '0';
if HaveJazelle() then JMCR.JE = '0'; SUBARCHITECTURE_DEFINED further resetting;
// Further CPSR changes: all interrupts disabled, IT state reset, instruction set
// and endianness according to the SCTLR values produced by the above call to
// ResetControlRegisters().
CPSR.I = '1'; CPSR.F = '1'; CPSR.A = '1';
CPSR.IT = '00000000';
CPSR.J = '0'; CPSR.T = SCTLR.TE; // TE=0: ARM, TE=1: Thumb
CPSR.E = SCTLR.EE; // EE=0: little-endian, EE=1: big-endian
// All registers, bits and fields not reset by the above pseudocode or by the
// BranchTo() call below are UNKNOWN bitstrings after reset. In particular, the
// return information registers R14_svc and SPSR_svc have UNKNOWN values, so that
// it is impossible to return from a reset in an architecturally defined way.
// Branch to Reset vector.

ResetVector[31:1] = if HasIMPDEFResetVactor() then Bits[31:1] IMPLEMENTATION DEFINED else
ExecVectorBase()[31:1];
ResetVector[0] = '0';
BranchTo(ResetVector);
The HasIMPDEFResetVector() pseudocode function returns TRUE if the implementation has an IMPLEMENTATION
DEFINED reset vector.
B1.9.2 Undefined Instruction exception

An Undefined Instruction exception might be caused by:
• A coprocessor instruction that is not accessible because of the settings in one or more of:
— The CPACR, see CPACR, Coprocessor Access Control Register, VMSA on page B4-1547, or CPACR,
Coprocessor Access Control Register, PMSA on page B6-1823.
— In an implementation that includes the Security Extensions, the NSACR.
— In an implementation that includes the Virtualization Extensions, when the processor is in Hyp mode,
the HCPTR.
• A coprocessor instruction that is not implemented.
• A coprocessor instruction that causes an exception during execution, for example a trapped floating-point
exception on a floating-point instruction, see Floating-point exceptions on page A2-69.
• An instruction that is UNDEFINED.
• An attempt to execute an instruction in an unimplemented instruction set state, see Exception return to an
unimplemented instruction set state on page B1-1196.
• Division by zero in an SDIV or UDIV instruction, in an ARMv7-R implementation when the SCTLR.DZ bit is
set to 1.
Note
In an ARMv7-A implementation that includes the SDIV and UDIV instructions, division by zero always returns
a result of zero, see ARMv7 implementation requirements and options for the divide instructions on
page A4-170.
By default, an Undefined Instruction exception is taken to Undefined mode, but an Undefined Instruction exception
can be taken to Hyp mode, see Determining the mode to which the Undefined Instruction exception is taken on
page B1-1175.
The Undefined Instruction exception can provide:

• Signaling of:
— An illegal instruction execution.
— Division by zero errors, in the ARMv7-R profile.
• Software emulation of a coprocessor in a system that does not have the physical coprocessor hardware.
• Lazy context switching of coprocessor registers.
• General-purpose instruction set extension by software emulation.
In some coprocessor designs, an internal exceptional condition caused by one coprocessor instruction is signaled
asynchronously by refusing to respond to a later coprocessor instruction that belongs to the same coprocessor. In
these circumstances, the Undefined Instruction exception handler must take whatever action is needed to clear the
exceptional condition, and then return to the second coprocessor instruction.
Note
The only mechanism to determine the cause of an Undefined Instruction exception that is taken to Undefined mode
is analysis of the instruction indicated by the return link in the LR on exception entry. Therefore it is important that
a coprocessor only reports exceptional conditions by generating Undefined Instruction exceptions on its own
coprocessor instructions.
The preferred return address for an Undefined Instruction exception is the address of the instruction that generated
the exception. This return is performed as follows:
• If returning from Secure or Non-secure Undefined mode, the exception return uses the SPSR and LR_und
values generated by the exception entry, as follows:
— If SPSR.{J, T} are both 0, indicating that the exception occurred in ARM state, the return uses an
exception return instruction with a subtraction of 4.
— If SPSR.T is 1, indicating that the exception occurred in Thumb state or ThumbEE state, the return
uses an exception return instruction with a subtraction of 2
— If SPSR.J is 1 and SPSR.T is 0, indicating that the exception occurred in Jazelle state, then exception
return is not possible. For more information see Undefined Instruction exception in Jazelle state on
page B1-1207.
• If returning from Hyp mode, the exception return is performed by an ERET instruction, using the SPSR and
ELR_hyp values generated by the exception entry.
Note
If handling the Undefined Instruction exception requires instruction emulation, followed by return to the next
instruction after the instruction that caused the exception, the instruction emulator must use the instruction length
to calculate the correct return address, and to calculate the updated values of the IT bits if necessary.
Pseudocode description of taking the Undefined Instruction exception

The TakeUndefInstrException() pseudocode procedure describes how the processor takes the exception:
// TakeUndefInstrException()
// =========================
TakeUndefInstrException()
// Determine return information. SPSR is to be the current CPSR, and LR is to be the
// current PC minus 2 for Thumb or 4 for ARM, to change the PC offsets of 4 or 8
// respectively from the address of the current instruction into the required return
// address offsets of 2 or 4 respectively.
new_lr_value = if CPSR.T == '1' then PC-2 else PC-4;
new_spsr_value = CPSR;
vect_offset = 4;
// Check whether to take exception to Hyp mode

// if in Hyp mode then stay in Hyp mode
take_to_hyp = HaveVirtExt() && HaveSecurityExt() && SCR.NS == '1' && CPSR.M == '11010';
// if HCR.TGE is set, take to Hyp mode through Hyp Trap vector
route_to_hyp = (HaveVirtExt() && HaveSecurityExt() && !IsSecure() && HCR.TGE == '1'
&& CPSR.M == '10000'); // User mode
// if HCR.TGE == '1' and in a Non-secure PL1 mode, the effect is UNPREDICTABLE
return_offset = if CPSR.T == '1' then 2 else 4;

preferred_exceptn_return = new_lr_value - return_offset;
if take_to_hyp then
// Note that whatever called TakeUndefInstrException() will have set the HSR
EnterHypMode(new_spsr_value, preferred_exceptn_return, vect_offset);
elsif route_to_hyp then
// Note that whatever called TakeUndefInstrException() will have set the HSR
EnterHypMode(new_spsr_value, preferred_exceptn_return, 20);
else
// Enter Undefined ('11011') mode, and ensure Secure state if initially in Monitor
// ('10110') mode. This affects the Banked versions of various registers accessed later
// in the code.
if CPSR.M == '10110' then SCR.NS = '0';
CPSR.M = '11011';
// Write return information to registers, and make further CPSR changes:

// IRQs disabled, IT state reset, instruction set and endianness set to
// SCTLR-configured values.
SPSR[] = new_spsr_value;
R[14] = new_lr_value;
CPSR.I = '1';
CPSR.IT = '00000000';
// Branch to Undefined Instruction vector.

BranchTo(ExcVectorBase() + vect_offset);
Additional pseudocode functions for exception handling on page B1-1223 defines the EnterHypMode() pseudocode
procedure.
Undefined Instruction exception in Jazelle state

The architecture does not define any behavior that requires a processor to take an Undefined Instruction exception
when it is operating in Jazelle state. However, on some implementations the processor might take an Undefined
Instruction exception as a result of UNPREDICTABLE behavior, for example attempting instruction execution in
Jazelle state on a possible trivial implementation of the Jazelle extension, see Exception return to an unimplemented
instruction set state on page B1-1196. If the processor takes such an Undefined Instruction exception in Jazelle
state, exception entry sets the LR to an UNKNOWN value.
Conditional execution of undefined instructions

The conditional execution rules described in Conditional execution on page A8-286 apply to all instructions. This
includes undefined instructions and other instructions that would cause entry to the Undefined Instruction
exception.
If such an instruction fails its condition check, the behavior depends on the architecture profile and the potential
cause of entry to the Undefined Instruction exception, as follows:
• In the ARMv7-A profile:

— If the potential cause is the execution of the instruction itself and depends on data values used by the
instruction, the instruction executes as a NOP and does not cause an Undefined Instruction exception.
— If the potential cause is the execution of an earlier coprocessor instruction, or the execution of the
instruction itself without dependence on the data values used by the instruction, it is IMPLEMENTATION
DEFINED whether the instruction executes as a NOP or causes an Undefined Instruction exception.
An implementation must handle all such cases in the same way.
• In the ARMv7-R profile, the instruction executes as a NOP and does not cause an Undefined Instruction
exception.
Note
Before ARMv7, all implementations executed any instruction that failed its condition check as a NOP, even if it
would otherwise have caused an Undefined Instruction exception. An Undefined Instruction handler written for
these implementations might assume without checking that the undefined instruction passed its condition check.
Such an Undefined Instruction handler is likely to need rewriting, to check the condition is passed, before it
functions correctly on all ARMv7-A implementations.
Interaction of UNPREDICTABLE and UNDEFINED instruction behavior

If this manual describes an instruction as both UNPREDICTABLE and UNDEFINED then the instruction is
UNPREDICTABLE.
Note
An example of this is where both:
• An instruction, or instruction class, is made UNDEFINED by some general principle, or by a configuration
field.
• A particular encoding of that instruction or instruction class is specified as UNPREDICTABLE.
B1.9.3 Hyp Trap exception

The Hyp Trap exception is implemented only as part of the Virtualization Extensions.
A Hyp Trap exception is generated if the processor is running in a Non-secure mode other than Hyp mode, and
commits for execution an instruction that is trapped to Hyp mode. Instruction traps are enabled by setting bits to 1
in the HCR, HCPTR, HDCR, or HSTR. For more information see Traps to the hypervisor on page B1-1246.
A Hyp Trap exception is taken to Hyp mode.
The preferred return address for a Hyp Trap exception is the address of the trapped instruction. The exception return
is performed by an ERET instruction, using the SPSR and ELR_hyp values generated by the exception entry.
Note
The SPSR and ELR_hyp values generated on exception entry can be used, without modification, for an exception
return to re-execute the trapped instruction. If the exception handler emulates the trapped instruction, and must
return to the following instruction, the emulation of the instruction must include modifying ELR_hyp, and possibly
updating SPSR_hyp.
For related information, see General information about traps to the hypervisor on page B1-1247.
Pseudocode description of taking the Hyp Trap exception

The TakeHypTrapException() pseudocode procedure describes how the processor takes the exception:
// TakeHypTrapException()
// ======================
TakeHypTrapException()
// A Hyp Trap exception is caused by executing an instruction that is trapped to Hyp mode as
// a result of a trap set by a bit in the HCR, HCPTR, HSTR or HDCR. By definition, it can
// only be generated in a Non-secure mode other than Hyp mode.
// Note that, when a Supervisor Call exception is taken to Hyp mode because HCR.TGE==1, this
// is not a trap of the SVC instruction. See the TakeSVCException() pseudocode for this case.
preferred_exceptn_return = if CPSR.T == '1' then PC-4 else PC-8;
procedure.
B1.9.4 Supervisor Call (SVC) exception

The Supervisor Call instruction, SVC, requests a supervisor function, causing the processor to enter Supervisor mode.
Typically, the SVC instruction is executed to request an operating system function. For more information, see SVC
(previously SWI) on page A8-721.
Note
• In previous versions of the ARM architecture, the SVC instruction was called SWI, Software Interrupt.
• In an implementation that includes the Virtualization Extensions:

— When an SVC instruction is executed in Hyp mode, the Supervisor Call exception is taken to Hyp mode.
For more information see SVC (previously SWI) on page A8-721.
— When the HCR.TGE bit is set to 1, the Supervisor Call exception generated by execution of an SVC
instruction in Non-secure User mode is routed to Hyp mode. For more information, see Supervisor
Call exception, when HCR.TGE is set to 1 on page B1-1191.
By default, a Supervisor Call exception is taken to Supervisor mode, but a Supervisor Call exception can be taken
to Hyp mode, see Determining the mode to which the Supervisor Call exception is taken on page B1-1175.
The preferred return address for a Supervisor Call exception is the address of the next instruction after the SVC
instruction. This return is performed as follows:
• If returning from Secure or Non-secure Supervisor mode, the exception return uses the SPSR and LR_svc
values generated by the exception entry, in an exception return instruction without subtraction.
• If returning from Hyp mode, the exception return is performed by an ERET instruction, using the SPSR and
ELR_hyp values generated by the exception entry.
Pseudocode description of taking the Supervisor Call exception

The TakeSVCException() pseudocode procedure describes how the processor takes the exception:
// TakeSVCException()
// ==================
TakeSVCException()
// Determine return information. SPSR is to be the current CPSR, after changing the IT[]
// bits to give them the correct values for the following instruction, and LR is to be
// the current PC minus 2 for Thumb or 4 for ARM, to change the PC offsets of 4 or 8
// respectively from the address of the current instruction into the required address of
// the next instruction, the SVC instruction having size 2bytes for Thumb or 4 bytes for ARM.
ITAdvance();
new_lr_value = if CPSR.T == '1' then PC-2 else PC-4;
vect_offset = 8;

take_to_hyp = (HaveVirtExt() && HaveSecurityExt() && SCR.NS == '1' && CPSR.M == '11010');
// if HCR.TGE is set to 1, take to Hyp mode through Hyp Trap vector
route_to_hyp = (HaveVirtExt() && HaveSecurityExt() && !IsSecure() && HCR.TGE == '1'
&& CPSR.M == '10000'); // User mode
preferred_exceptn_return = new_lr_value;
if take_to_hyp then
else
// Enter Supervisor ('10011') mode, and ensure Secure state if initially in Monitor
// ('10110') mode. This affects the Banked versions of various registers accessed later
// in the code.
CPSR.M = '10011';
// Write return information to registers, and make further CPSR changes: IRQs disabled,
// IT state reset, instruction set and endianness set to SCTLR-configured values.
CPSR.I = '1';
CPSR.IT = '00000000';
// Branch to SVC vector.

procedure.
B1.9.5 Secure Monitor Call (SMC) exception

The Secure Monitor Call exception is implemented only as part of the Security Extensions.
The Secure Monitor Call instruction, SMC, requests a Secure Monitor function, causing the processor to enter
Monitor mode. For more information, see SMC (previously SMI) on page B9-1988.
Note
• In previous versions of the ARM architecture, the SMC instruction was called SMI, Software Monitor Interrupt.
• In an implementation that includes the Virtualization Extensions, when the HCR.TSC bit is set to 1, execution
of an SMC instruction in a Non-secure PL1 mode is trapped to Hyp mode, and therefore generates a Hyp Trap
Exception. For more information see Trapping use of the SMC instruction on page B1-1253.
A Secure Monitor Call exception is taken to Monitor mode.
The preferred return address for a Secure Monitor Call exception is the address of the next instruction after the SMC
instruction. This return is performed using the SPSR and LR_mon values generated by the exception entry, using
an exception return instruction without a subtraction.
Note
The exception handler can return to the SMC instruction itself by returning using a subtraction of 4, without any
adjustment to the SPSR.IT[7:0] bits. If it does this, the return occurs, then interrupts or external aborts might occur
and be handled, then the SMC instruction is re-executed and another Secure Monitor Call exception occurs.
This relies on:
• The SMC instruction being used correctly, either outside an IT block or as the last instruction in an IT block,
so that the SPSR.IT[7:0] bits indicate unconditional execution.
• The Secure Monitor Call handler not changing the result of the original conditional execution test for the SMC
instruction.
Pseudocode description of taking the Secure Monitor Call exception

The TakeSMCException() pseudocode procedure describes how the processor takes the exception:
// TakeSMCException()
// ==================
TakeSMCException()
// the next instruction (with the SMC instruction always being 4 bytes in length).
ITAdvance();
new_lr_value = if CPSR.T == '1' then PC else PC-4;
vect_offset = 8;
// Ensure Secure state if initially in Monitor mode.

// This affects the Banked versions of various registers accessed later in the code.
EnterMonitorMode(new_spsr_value, new_lr_value, vect_offset);
Additional pseudocode functions for exception handling on page B1-1223 defines the EnterMonitorMode()
pseudocode procedure.
B1.9.6 Hypervisor Call (HVC) exception

The Hypervisor Call exception is implemented only as part of the Virtualization Extensions.
The Hypervisor Call instruction, HVC, requests a hypervisor function, causing the processor to enter Hyp mode. For
more information, see HVC on page B9-1970. The instruction generates a Hypervisor Call exception that is taken
to Hyp mode.
The preferred return address for a Hypervisor Call exception is the address of the next instruction after the HVC
instruction. The exception return is performed by an ERET instruction, using the SPSR and ELR_hyp values
generated by the exception entry.
Executing an HVC instruction transfers the immediate argument of the instruction to the HSR. The exception handler
retrieves the argument from the HSR, and therefore does not have to access the original HVC instruction. For more
information see Use of the HSR on page B3-1421.
Pseudocode description of taking the Hypervisor Call exception

The TakeHVCException() pseudocode procedure describes how the processor takes the exception:
// TakeHVCException()
// ==================
TakeHVCException()
// the next instruction (with the HVC instruction always being 4 bytes in length).
ITAdvance();
preferred_exceptn_return = if CPSR.T == '1' then PC else PC-4;
// Enter Hyp mode. HVC pseudocode has checked that use of HVC is valid.
// Required vector offset depends on whether current mode is Hyp mode.
if CPSR.M == '11010' then
else
procedure.
B1.9.7 Prefetch Abort exception

A Prefetch Abort exception can be generated by:
• A synchronous memory abort on an instruction fetch.
Note
Asynchronous aborts on instruction fetches are reported using the Data Abort exception, see Data Abort
Prefetch Abort exception entry is synchronous to the instruction whose fetch aborted.
For more information about memory aborts see:
— VMSA memory aborts on page B3-1392.
— PMSA memory aborts on page B5-1757.
• A Breakpoint, Vector catch or BKPT instruction debug event, see Debug exception on BKPT instruction,
Breakpoint, or Vector catch debug events on page C4-2076.
Note
If an implementation fetches instructions speculatively, it must handle a synchronous abort on such an instruction
fetch by:
• Generating a Prefetch Abort exception only if the instruction would be executed in a simple sequential
execution of the program.
• Ignoring the abort if the instruction would not be executed in a simple sequential execution of the program.
By default, a Prefetch Abort exception is taken to Abort mode, but a Prefetch Abort exception can be taken to
Monitor mode, or Hyp mode. For more information, see Determining the mode to which the Prefetch Abort
exception is taken on page B1-1177.
The preferred return address for a Prefetch Abort exception is the address of the aborted instruction. This return is
performed as follows:
• If returning from a PL1 mode, using the SPSR and LR values generated by the exception entry, using an
exception return instruction with a subtraction of 4. This means using:
— SPSR_abt and LR_abt if returning from Abort mode.
— SPSR_mon and LR_mon if returning from Monitor mode.
• If returning from Hyp mode, using the SPSR_hyp and ELR_hyp values generated by the exception entry,
using an ERET instruction.
Pseudocode description of taking the Prefetch Abort exception

The TakePrefetchAbortException() pseudocode procedure describes how the processor takes the exception:
// TakePrefetchAbortException()
// ============================
TakePrefetchAbortException()
// respectively from the address of the current instruction into the required address
// of the current instruction plus 4.
vect_offset = 12;
preferred_exceptn_return = new_lr_value - 4;
// Determine whether this is an external abort to be routed to Monitor mode.

route_to_monitor = HaveSecurityExt() && SCR.EA == '1' && IsExternalAbort();

// otherwise, check whether to take to Hyp mode through Hyp Trap vector
route_to_hyp = (HaveVirtExt() && HaveSecurityExt() && !IsSecure() &&
(SecondStageAbort() ||
(DebugException() && HDCR.TDE == '1' && CPSR.M != '11010') ||
(IsExternalAbort() && !IsAsyncAbort() && HCR.TGE == '1'
&& CPSR.M == '10000'))); // User mode
if route_to_monitor then
// Ensure Secure state if initially in Monitor ('10110') mode. This affects
// the Banked versions of various registers accessed later in the code.
elsif take_to_hyp then
// Note that whatever called TakePrefetchAbortException() will have set the HSR
// Note that whatever called TakePrefetchAbortException() will have set the HSR
else
// Handle in Abort mode. Ensure Secure state if initially in Monitor mode. This
// affects the Banked versions of various registers accessed later in the code.
if HaveSecurityExt() && CPSR.M == '10110' then SCR.NS = '0';
CPSR.M = '10111'; // Abort mode

// IRQs disabled, other interrupts disabled if appropriate, IT state reset,
// instruction set and endianness set to SCTLR-configured values.
CPSR.I = '1';
if !HaveSecurityExt() || HaveVirtExt() || SCR.NS == '0' || SCR.AW == '1' then
CPSR.A = '1';
CPSR.IT = '00000000';
Additional pseudocode functions for exception handling on page B1-1223 defines the EnterMonitorMode() and
EnterHypMode() pseudocode procedures.
B1.9.8 Data Abort exception

A Data Abort exception can be generated by:
• A synchronous abort on a data read or write memory access. Exception entry is synchronous to the instruction
that generated the memory access.
• An asynchronous abort. The memory access that caused the abort can be any of:
— a data read or write access
— an instruction fetch
— in a VMSA memory system, a translation table access.
Exception entry occurs asynchronously, and is similar to an interrupt.
As described in Asynchronous exception masking on page B1-1183, asynchronous aborts can be masked.
When this happens, a generated asynchronous abort is not taken until it is not masked.
Note
There are no asynchronous internal aborts in ARMv7 and earlier architecture versions, so asynchronous
aborts are always asynchronous external aborts.
• A Watchpoint debug event, see Debug exception on Watchpoint debug event on page C4-2077.
Note
Data Abort exceptions generated by Watchpoint debug events can be either asynchronous or synchronous.
However, the CPSR.A bit has no effect on the taking of such an exception, regardless of whether it is
asynchronous.
By default, a Data Abort exception is taken to Abort mode, but a Data Abort exception can be taken to Monitor
mode, or to Hyp mode. For more information see Determining the mode to which the Data Abort exception is taken
on page B1-1177.
For more information about memory aborts see:

• VMSA memory aborts on page B3-1392.
• PMSA memory aborts on page B5-1757.
The preferred return address for a Data Abort exception is the address of the instruction that generated the aborting
memory access, or the address of the instruction following the instruction boundary at which an asynchronous Data
Abort exception was taken. This return is performed as follows:
— SPSR_abt and LR_abt if returning from Abort mode.
Pseudocode description of taking the Data Abort exception

The TakeDataAbortException() pseudocode procedure describes how the processor takes the exception:
// TakeDataAbortException()
// ========================
TakeDataAbortException()

// current PC plus 4 for Thumb or 0 for ARM, to change the PC offsets of 4 or 8
// of the current instruction plus 8. For an asynchronous abort, the PC and CPSR are
// considered to have already moved on to their values for the instruction following
// the instruction boundary at which the exception occurred.
new_lr_value = if CPSR.T == '1' then PC+4 else PC;

vect_offset = 16;
// Determine whether this is an external abort to be routed to Monitor mode.

route_to_monitor = HaveSecurityExt() && SCR.EA == '1' && IsExternalAbort();

// otherwise, check whether to take to Hyp mode through Hyp Trap vector
route_to_hyp = (HaveVirtExt() && HaveSecurityExt() && !IsSecure() &&
(SecondStageAbort() || (CPSR.M != '11010' &&
(IsExternalAbort() && IsAsyncAbort() && HCR.AMO == '1') ||
(DebugException() && HDCR.TDE == '1')) ||
(CPSR.M == '10000' && HCR.TGE == '1' &&
(IsAlignmentFault() || (IsExternalAbort() && !IsAsyncAbort())))));
// Ensure Secure state if initially in Monitor mode. This affects the Banked
// versions of various registers accessed later in the code
elsif take_to_hyp then
else
// Handle in Abort mode. Ensure Secure state if initially in Monitor mode. This
// affects the Banked versions of various registers accessed later in the code
if HaveSecurityExt() && CPSR.M == '10110' then SCR.NS = '0';

// IRQs disabled, other interrupts disabled if appropriate,
CPSR.I = '1';
CPSR.A = '1';
CPSR.IT = '00000000';
Effects of data-aborted instructions

An instruction that accesses data memory can modify memory by storing one or more values. If the execution of
such an instruction generates a Data Abort exception, or causes Debug state entry because of a watchpoint set on
the instruction, the value of each memory location that the instruction stores to is:
• unchanged for any location for which one of the following applies:
— An MMU fault is generated.
— A Watchpoint is generated.
— An external abort is generated, if that external abort is taken synchronously.
• UNKNOWN for any location for which no exception and no debug event is generated.
If the access to a memory location generates an external abort that is taken asynchronously, it is outside the scope
of the architecture to define the effect of the store on that memory location, because this depends on the
system-specific nature of the external abort. However, in general, ARM recommends that such locations are
unchanged.
For external aborts and Watchpoints, where in principle faulting could be identified at byte or halfword granularity,
the size of a location in this definition is the size for which a memory access is single-copy atomic.
Instructions that access data memory can modify registers in the following ways:
• By loading values into one or more of the ARM core registers. The registers loaded 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 support base register writeback have UNPREDICTABLE results
if base register writeback is specified with the PC as the base register. Only ARM core registers other than
the PC can be modified reliably in this way.
• By changing the value of one or more coprocessor registers either directly or indirectly, for example:
— Executing an LDC instruction loads a coprocessor register directly from memory.
— Executing an STC instruction that accesses DBGDTRRXint can have a side effect of changing
DBGDSCR.RXfull. This means the STC instruction changes the value of DBGDSCR indirectly.
• By modifying the CPSR.
If the execution of such an instruction generates a synchronous Data Abort exception, the following rules determine
the values left in these registers:
• On entry to the Data Abort exception handler:

— The PC value is the Data Abort vector address, see Exception vectors and the exception base address
on page B1-1164.
— The LR_abt value is determined from the address of the aborted instruction.
Neither value is affected by the results of any load specified by the instruction.
• The base register is restored to its original value if either:

— The aborted instruction is a load and the list of registers to be loaded includes the base register.
— The base register is being written back.
• If the instruction only loads one ARM core register, the value in that register is unchanged.
• If the instruction loads more than one ARM core register, UNKNOWN values are left in destination registers
other than the PC and the base register of the instruction.
• If the instruction affects any coprocessor registers, UNKNOWN values are left in the coprocessor registers that
are affected.
• CPSR bits that are not defined as updated on exception entry retain their current value.
• If the instruction is a STREX, STREXB, STREXH, or STREXD, <Rd> is not updated.
After taking a Data Abort exception, the state of the exclusive monitors is UNKNOWN. Therefore, ARM strongly
recommends that the abort handler performs a CLREX instruction, or a dummy STREX instruction, to clear the exclusive
monitor state.
The ARM abort model

The abort model used by an ARM processor implementation is described as a Base Restored Abort Model. This
means that if a synchronous Data Abort exception is generated by executing an instruction that specifies base
register writeback, the value in the base register is unchanged.
Note
In versions of the ARM architecture before ARMv6, it is IMPLEMENTATION DEFINED whether the abort model used
is the Base Restored Abort Model or the Base Updated Abort Model. For more information, see The ARM abort
model on page D15-2588.
The abort model applies uniformly across all instructions.
B1.9.9 Virtual Abort exception

The Virtual Abort exception is implemented only as part of the Virtualization Extensions.
A Virtual Abort exception is generated if all of the following apply:

• The processor is in a Non-secure mode other than Hyp mode.
• HCR.AMO is set to 1.
• HCR.VA is set to 1.
• CPSR.A is set to 0.
The conditions for generating a Virtual Abort exception mean the exception is always:
• Taken to Non-secure Abort mode.
Note
Because the Virtual Abort exception is always taken to Non-secure Abort mode, on exception entry the preferred
return address is always saved to LR_abt.
The preferred return address for a Virtual Abort exception is the address of the instruction immediately after the
instruction boundary where the exception was taken. This return is performed using the SPSR and LR_abt values
generated by the exception entry, using an exception return instruction without subtraction.
Pseudocode description of taking the Virtual Abort exception

The TakeVirtualAbortException() pseudocode procedure describes how the processor takes the exception:
// TakeVirtualAbortException()
// ===========================
TakeVirtualAbortException()
// current PC plus 4 for Thumb or 0 for ARM, to change the PC offsets of 4 or 8
// of the current instruction plus 8. For an asynchronous abort, the PC and CPSR are
// considered to have already moved on to their values for the instruction following
// the instruction boundary at which the exception occurred.
new_lr_value = if CPSR.T == '1' then PC+4 else PC;
vect_offset = 16;

// IRQs disabled, other interrupts disabled if appropriate,
HCR.VA = '0';
CPSR.I = '1';
CPSR.A = '1';
CPSR.IT = '00000000';
B1.9.10 IRQ exception

The IRQ exception is generated by IMPLEMENTATION DEFINED means. Typically this is by asserting an IRQ interrupt
request input to the processor.
How an IRQ exception is taken depends on SCTLR.FI:
• If SCTLR.FI == 0, IRQ exception entry is precise to an instruction boundary.
• If SCTLR.FI == 1, IRQ exception entry is precise to an instruction boundary, except that some of the effects
of the instruction that follows that boundary might have occurred. These effects are restricted to those that
can be repeated idempotently and without breaking the rules in Single-copy atomicity on page A3-125.
Examples of such effects are:
— Changing the value of a register that the instruction writes to but does not read.
— Performing an access to Normal memory.
Note
This relaxation of the normal definition of a precise asynchronous exception permits interrupts to occur
during the execution of instructions that change register or memory values, while only requiring the
implementation to restore those register values that are needed to correctly re-execute the instruction after a
return to the preferred return address. LDM and STM are examples of such instructions.
As described in Asynchronous exception masking on page B1-1183, IRQ exceptions can be masked. When this
happens, a generated IRQ exception is not taken until it is not masked.
By default, an IRQ exception is taken to IRQ mode, but an IRQ exception can be taken to Monitor mode, or Hyp
mode. For more information, see Determining the mode to which the IRQ exception is taken on page B1-1179.
The preferred return address for an IRQ exception is the address of the instruction following the instruction
boundary at which the exception was taken. This return is performed as follows:
— SPSR_irq and LR_irq if returning from IRQ mode.
Pseudocode description of taking the IRQ exception

The TakePhysicalIRQException() pseudocode procedure describes how the processor takes the exception:
// TakePhysicalIRQException()
// ==========================
TakePhysicalIRQException()
// of the instruction boundary at which the interrupt occurred plus 4. For this
// purpose, the PC and CPSR are considered to have already moved on to their values
// for the instruction following that boundary.
vect_offset = 24;
// Determine whether IRQs are routed to Monitor mode.

route_to_monitor = HaveSecurityExt() && SCR.IRQ == '1';
// Determine whether IRQs are routed to Hyp mode.

route_to_hyp = (HaveVirtExt() && HaveSecurityExt() && SCR.IRQ == '0' && HCR.IMO == '1'
&& !IsSecure()) || CPSR.M == '11010';
HSR = bits(32) UNKNOWN;
else
// Handle in IRQ mode. Ensure Secure state if initially in Monitor mode. This
CPSR.M = '10010'; // IRQ mode

CPSR.I = '1';
CPSR.A = '1';
CPSR.IT = '00000000';
// Branch to correct IRQ vector.

if SCTLR.VE == '1' then
IMPLEMENTATION_DEFINED branch to an IRQ vector;
else
B1.9.11 Virtual IRQ exception

The Virtual IRQ exception is implemented only as part of the Virtualization Extensions.
A Virtual IRQ exception is generated if all of the following apply:

• HCR.IMO is set to 1.
• CPSR.I is set to 0.
• Either:
— HCR.VI is set to 1.
— A Virtual IRQ exception is generated by an IMPLEMENTATION DEFINED mechanism.
The conditions for generating a Virtual IRQ exception mean the exception is always:
• Taken to Non-secure IRQ mode.
For more information see Virtual exceptions in the Virtualization Extensions on page B1-1196
The preferred return address for a Virtual IRQ exception is the address of the instruction immediately after the
instruction boundary where the exception was taken. This return is performed using the SPSR and LR_irq values
generated by the exception entry, using an exception return instruction with a subtraction of 4.
Pseudocode description of taking the Virtual IRQ exception

The TakeVirtualIRQException() pseudocode procedure describes how the processor takes the exception:
// TakeVirtualIRQException()
// =========================
TakeVirtualIRQException()
vect_offset = 24;
CPSR.M = '10010'; // IRQ mode

CPSR.I = '1';
CPSR.A = '1';
CPSR.IT = '00000000';
// Branch to correct IRQ vector.

IMPLEMENTATION_DEFINED branch to an IRQ vector;
else
B1.9.12 FIQ exception

The FIQ exception is generated by IMPLEMENTATION DEFINED means. Typically this is by asserting an FIQ interrupt
request input to the processor.
How an FIQ exception is taken depends on SCTLR.FI:
• If SCTLR.FI == 0, FIQ exception entry is precise to an instruction boundary.
• If SCTLR.FI == 1, FIQ exception entry is precise to an instruction boundary, except that some of the effects
of the instruction that follows that boundary might have occurred. These effects are restricted to those that
can be repeated idempotently and without breaking the rules in Single-copy atomicity on page A3-125.
Examples of such effects are:
— Changing the value of a register that the instruction writes but does not read.
— Performing an access to Normal memory.
Note
This relaxation of the normal definition of a precise asynchronous exception permits interrupts to occur
during the execution of instructions that change register or memory values, while only requiring the
implementation to restore those register values that are needed to correctly re-execute the instruction after a
return to the preferred return address. LDM and STM are examples of such instructions.
As described in Asynchronous exception masking on page B1-1183, FIQ exceptions can be masked. When this
happens, a generated FIQ exception is not taken until it is not masked.
By default, an FIQ exception is taken to FIQ mode, but an FIQ exception can be taken to Monitor mode, or to Hyp
mode. For more information, see Determining the mode to which the FIQ exception is taken on page B1-1179.
The preferred return address for an FIQ exception is the address of the instruction following the instruction
boundary at which the exception was taken. This return is performed as follows:
— SPSR_fiq and LR_fiq if returning from FIQ mode.
Pseudocode description of taking the FIQ exception

The TakePhysicalFIQException() pseudocode procedure describes how the processor takes the exception:
// TakePhysicalFIQException()
// ==========================
TakePhysicalFIQException()
vect_offset = 28;
// Determine whether FIQs are routed to Monitor mode.

route_to_monitor = HaveSecurityExt() && SCR.FIQ == '1';
// Determine whether route FIQ to Hyp mode.

route_to_hyp = (HaveVirtExt() && HaveSecurityExt() && SCR.FIQ == '0' && HCR.FMO == '1'
&& !IsSecure()) || CPSR.M == '11010';

HSR = bits(32) UNKNOWN;
else
// Handle in FIQ mode. Ensure Secure state if initially in Monitor mode. This
CPSR.M = '10001'; // FIQ mode

CPSR.I = '1';
if !HaveSecurityExt() || HaveVirtExt() || SCR.NS == '0' || SCR.FW == '1' then
CPSR.F = '1';
CPSR.A = '1';
CPSR.IT = '00000000';
// Branch to correct FIQ vector.

IMPLEMENTATION_DEFINED branch to an FIQ vector;
else
B1.9.13 Virtual FIQ exception

The Virtual FIQ exception is implemented only as part of the Virtualization Extensions.
A Virtual FIQ exception is generated if all of the following apply:

• HCR.FMO is set to 1.
• CPSR.F is set to 0.
• Either:
— HCR.VF is set to 1.
— A Virtual FIQ exception is generated by an IMPLEMENTATION DEFINED mechanism.
The conditions for generating a Virtual FIQ exception mean the exception is always:
• Taken to Non-secure FIQ mode.
The preferred return address for a Virtual FIQ exception is the address of the instruction immediately after the
instruction boundary where the exception was taken. This return is performed using the SPSR and LR_irq values
generated by the exception entry, using an exception return instruction with a subtraction of 4.
Pseudocode description of taking the Virtual FIQ exception

The TakeVirtualFIQException() pseudocode procedure describes how the processor takes the exception:
// TakeVirtualFIQException()
// =========================
TakeVirtualFIQException()
vect_offset = 28;
CPSR.M = '10001'; // FIQ mode

CPSR.I = '1';
CPSR.F = '1';
CPSR.A = '1';
CPSR.IT = '00000000';
// Branch to correct FIQ vector.

IMPLEMENTATION_DEFINED branch to an FIQ vector;
else
B1.9.14 Additional pseudocode functions for exception handling

The EnterMonitorMode() pseudocode function changes the processor mode to Monitor mode, with the required state
changes:
// EnterMonitorMode()
// ==================
EnterMonitorMode(bits(32) new_spsr_value, bits(32) new_lr_value, integer vect_offset)

CPSR.M = '10110';
CPSR.J = '0';
CPSR.T = SCTLR.TE;
CPSR.E = SCTLR.EE;
CPSR.A = '1';
CPSR.F = '1';
CPSR.I = '1';
CPSR.IT = '00000000';
BranchTo(MVBAR + vect_offset);
The EnterHypMode() pseudocode function changes the processor mode to Hyp mode, with the required state changes:
// EnterHypMode()
// =============
EnterHypMode(bits(32) new_spsr_value, bits(32) preferred_exceptn_return, integer vect_offset)

CPSR.M = '11010';
ELR_hyp = preferred_exceptn_return;
CPSR.J = '0';
CPSR.T = HSCTLR.TE;
CPSR.E = HSCTLR.EE;
if SCR.EA == '0' then CPSR.A = '1';
if SCR.FIQ == '0' then CPSR.F = '1';

if SCR.IRQ == '0' then CPSR.I = '1';
CPSR.IT = '00000000';
BranchTo(HVBAR + vect_offset);
B1.10 Coprocessors and system control

The ARM architecture supports sixteen coprocessors, usually referred to as CP0 to CP15. Coprocessor support on
page A2-93 introduces these coprocessors. The architecture reserves two of these coprocessors, CP14 and CP15,
for configuration and control related to the architecture:
• CP14 is reserved for the configuration and control of:

— Debug features, see The CP14 debug register interface on page C6-2109.
— Trace features, see the Embedded Trace Macrocell Architecture Specification and the CoreSight
Program Flow Trace Architecture Specification.
— The Thumb Execution Environment, see Thumb Execution Environment on page B1-1239.
— Direct Java bytecode execution, see Jazelle direct bytecode execution on page B1-1240.
• CP15 is called the System Control coprocessor, and is reserved for the control and configuration of the ARM
processor system, including architecture and feature identification.
This section gives:

• An introduction to the CP14 and CP15 registers, see CP14 and CP15 system control registers.
• Information about access controls for coprocessors CP0 to CP13, see Access controls on CP0 to CP13 on
page B1-1226.
B1.10.1 CP14 and CP15 system control registers

The implementation of the CP15 registers depends heavily on whether the ARMv7 implementation is:
• An ARMv7-A implementation with a Virtual Memory System Architecture (VMSA).
• An ARMv7-R implementation with a Protected Memory System Architecture (PMSA).
The implementation of the CP14 registers is generally similar in ARMv7-A and ARMv7-R implementation.
However, CP14 provides both:
• The system control registers for ThumbEE and the Jazelle extension. These relate to the functionality
described in parts A and B of this manual.
• An interface to the debug and trace registers. These relate to the functionality described in part C of this
manual and in separate trace architecture specifications.
Therefore, part B of this manual provides separate register descriptions for VMSA and PMSA implementations.
Both descriptions include general information about CP14 register accesses, including accesses to the Debug
registers. In more detail:

— Chapter B3, starting at the section About the system control registers for VMSA on page B3-1440,
gives a general description of the system control registers, including the CP14 interface to the Debug
registers
— Chapter B4 System Control Registers in a VMSA implementation describes all of the non-debug
system control registers, in order of their register names.
• For a PMSA implementation:

— Chapter B5, starting at the section About the system control registers for PMSA on page B5-1766,
gives a general description of the system control registers, including the CP14 interface to the Debug
registers
— Chapter B6 System Control Registers in a PMSA implementation describes all of the non-debug
system control registers, in order of their register names.
• For all implementations:

— Chapter C6 Debug Register Interfaces gives more information about CP14 accesses to the debug
registers
— Chapter C11 The Debug Registers describes all of the debug registers, in order of their register names.
Registers that are common to VMSA and PMSA implementations are described in both Chapter B4 and Chapter B6.
Some registers are implemented differently in VMSA and PMSA implementations.
Access to CP14 and CP15 registers

Most CP14 and CP15 registers are accessible only from PL1 or higher. For possible accesses from PL0:
• The register descriptions in Chapter B4 System Control Registers in a VMSA implementation and Chapter B6
System Control Registers in a PMSA implementation indicate whether a register is accessible from PL0.
Note
These chapters provide all of the CP14 and CP15 register descriptions in this manual, except for the CP14
debug registers, that are described in Chapter C11 The Debug Registers.
• The descriptions of the CP14 interface in Chapter C6 Debug Register Interfaces include the permitted
accesses to the debug registers from PL0.
• The following sections summarize the permitted accesses to CP15 registers from PL0:
— For a VMSA implementation, PL0 views of the CP15 registers on page B3-1483.
— For a PMSA implementation, PL0 views of the CP15 registers on page B5-1789.
B1.10.2 Access controls on CP0 to CP13

Coprocessors CP0 to CP13 might be required for optional features of the ARMv7 implementation. In particular,
CP10 and CP11 support the floating-point instructions provided by the Floating-point and Advanced SIMD
Extensions to the architecture, see Advanced SIMD and floating-point support on page B1-1228.
Coprocessors CP0 to CP7 can provide IMPLEMENTATION DEFINED vendor-specific features.

The CPACR controls access to coprocessors CP0 to CP13 from software executing at PL1 or PL0, see either:
• CPACR, Coprocessor Access Control Register, VMSA on page B4-1547.
• CPACR, Coprocessor Access Control Register, PMSA on page B6-1823.
Initially on powerup or reset, access to coprocessors CP0 to CP13 is disabled.
Note
The CPACR has no effect on accesses from Hyp mode.
If an implementation includes the Security Extensions, the NSACR determines which of the CP0 to CP13
coprocessors can be accessed from the Non-secure state.
If an implementation includes the Virtualization Extensions, the HCPTR provides additional controls on
Non-secure accesses to coprocessors CP0 to CP13. For accesses that are otherwise permitted by the CPACR and
NSACR settings, setting HCPTR bits to 1:
• Traps otherwise-permitted accesses from PL1 or PL0 to Hyp mode.
• Makes accesses from Hyp mode UNDEFINED.
For more information, see Trapping accesses to coprocessors on page B1-1255.
Note
• When an implementation includes either or both of the Floating-point and Advanced SIMD Extensions, the
access settings for CP10 and CP11 must be identical. If these settings are not identical the behavior of the
extensions is UNPREDICTABLE.
• To check which coprocessors are implemented:

1. If required, read the Coprocessor Access Control Register and save the value.
2. Write the value 0x0FFFFFFF to the register, to write 0b11 to the access field for each of the coprocessors
CP13 to CP0.
3. Read the Coprocessor Access Control Register again and check the access field for each coprocessor:
• If the access field value is 0b00 the coprocessor is not implemented.
• If the access field value is 0b11 the coprocessor is implemented.
4. If required, write the value from stage 1 back to the register to restore the original value.
B1.11 Advanced SIMD and floating-point support

Advanced SIMD and Floating-point Extensions on page A2-54 introduces:
• The Floating-point (VFP) Extension, that adds scalar floating-point instructions to the ARM and Thumb
instruction sets.
• The Advanced SIMD Extension, that adds integer and floating-point vector instructions to the ARM and
Thumb instruction sets.
• The Advanced SIMD and Floating-point Extension registers D0 - D31 and their alternative views as S0 - S31
and Q0 - Q15.
• The Floating-Point Status and Control Register (FPSCR).
For more information about the system registers for the Advanced SIMD and Floating-point Extensions see
Advanced SIMD and Floating-point Extension system registers on page B1-1235.
Software can interrogate the registers summarized in Advanced SIMD and Floating-point Extension feature
identification registers on page B7-1944 to discover the implemented Advanced SIMD and floating-point support.
The following subsections give more information about the Advanced SIMD and Floating-point Extensions:
• Enabling Advanced SIMD and floating-point support.
• Advanced SIMD and Floating-point Extension system registers on page B1-1235.
• Context switching with the Advanced SIMD and Floating-point Extensions on page B1-1236.
• Floating-point support code on page B1-1236.
• VFP subarchitecture support on page B1-1238.
B1.11.1 Enabling Advanced SIMD and floating-point support

If an ARMv7 implementation includes support for any Advanced SIMD or Floating-point features then software
must ensure that the required access to these features is enabled:
• Any use of Advanced SIMD or floating-point features requires access to CP10 and CP11.
• Additional controls apply to the use of Advanced SIMD features, see Additional controls on Advanced SIMD
functionality on page B1-1232.
The controls of access to CP10 and CP11 are:
• CPACR.{cp10, cp11} control access from PL1 and PL0. The permitted values of these fields are:
0b00 No access. Any access to the Advanced SIMD and Floating-point Extension features is
UNDEFINED.
0b01 Accessible at PL1 only. Any access to the Advanced SIMD and Floating-point Extension features
from PL0 is UNDEFINED.
0b11 Accessible from PL0 and PL1. The meaning of this level of access is defined by the appropriate
coprocessor.
These fields reset to 0b00, no access.
• In an implementation that includes the Security Extensions, NSACR.{cp10, cp11} control access from
Non-secure state. The permitted values of these bits are:
0 Accessible from Secure state only. Any access to the Advanced SIMD and Floating-point
Extension features from Non-secure state is UNDEFINED.
1 Accessible from both security states, subject to any other access controls that apply. These
include:
• For all accesses from PL1 or PL0, the CPACR.{cp10, cp11} controls.
• If the implementation includes the Virtualization Extension, the HCPTR.{TCP10,
TCP11} control. This applies to accesses from PL2, PL1, and PL0.
• In an implementation that includes the Virtualization Extensions, when NSACR.{cp10, cp11} are set to 1, to
permit Non-secure accesses, HCPTR.{TCP10, TCP11} provide an additional control on those accesses. The
permitted values of these bits are:
0 Advanced SIMD and Floating-point Extension features are accessible from Non-secure state,
subject to any other access controls that apply. The CPACR.{cp10, cp11} controls:
• Apply to accesses from PL1 or PL0.
• Have no effect on accesses from PL2, Hyp mode.
1 Trap coprocessor accesses:
• Accesses from PL1 or PL0 that are permitted by other controls, including the
CPACR.{cp10, cp11} controls, generate an exception that is taken to Hyp mode.
• Any access to Advanced SIMD and Floating-point Extension features from PL2, Hyp
mode, is UNDEFINED.
When NSACR.{cp10, cp11} are set to 0, all accesses to Advanced SIMD and Floating-point Extension
features from Non-secure state are UNDEFINED.
Note
The HCPTR can also trap to Hyp mode otherwise-permitted Non-secure PL1 and PL0 accesses to Advanced
SIMD or Floating-point functionality. At reset, those traps are disabled.
In an implementation that includes at least one of the Advanced SIMD and Floating-point Extensions, access control
bits for CP10 and CP11 must be programmed with the same values, otherwise operation of the controlled Advanced
SIMD and Floating-point features is UNPREDICTABLE. This means that operation is UNPREDICTABLE:
• In any implementation, if the values of CPACR.cp10 and CPACR.cp11 are different.
• In an implementation that includes the Security Extensions, in Non-secure state, if the values of
NSACR.cp10 and NSACR.cp11 are different.
• In an implementation that includes the Virtualization Extensions, in Non-secure state, if the values of
HCPTR.TCP10 and HCPTR.TCP11 are different.
In addition, FPEXC.EN is an enable bit for most Advanced SIMD and Floating-point operations. When FPEXC.EN
is 0, all Advanced SIMD and Floating-point instructions are treated as UNDEFINED except for:
• A VMSR to the FPEXC or FPSID register.
• A VMRS from the FPEXC, FPSID, MVFR0, or MVFR1 register.
These instructions can be executed only at PL1 or higher.
Note
• Although FPSID is a read-only register, software can perform a VMSR to the FPSID to force Floating-point
serialization, as described in Asynchronous bounces, serialization, and Floating-point exception barriers on
page B1-1237.
• When FPEXC.EN is 0, these operations are treated as UNDEFINED:

— A VMSR to the FPSCR.
— A VMRS from the FPSCR.
• If a Floating-point implementation contains system registers additional to the FPSID, FPSCR, FPEXC,
MVFR0, and MVFR1 registers, the behavior of VMSR instructions to them and VMRS instructions from them is
SUBARCHITECTURE DEFINED.
These controls, summarized in Summary of general controls of CP10 and CP11 functionality on page B1-1230,
apply to all functionality that depends on access to CP10 and CP11. That is, they apply equally to all implemented
Advanced SIMD and floating-point functionality.
Additional controls apply to any implemented Advanced SIMD functionality, see Additional controls on Advanced
SIMD functionality on page B1-1232.
Pseudocode details of enabling the Advanced SIMD and Floating-point Extensions on page B1-1234 gives a
pseudocode description of both sets of controls.
Summary of general controls of CP10 and CP11 functionality

Table B1-21 summarizes the access controls for the implemented Advanced SIMD and floating-point functionality,
that are based on controlling access to coprocessors CP10 and CP11, and on the FPEXC.EN enable bit. The
following subsections give more information about the entries in this table:
• Information about the general controls of CP10 and CP11 functionality on page B1-1231.
• PL0 access to Advanced SIMD and floating-point functionality, and traps of PL0 functionality on
page B1-1231.
In this table, and in Table B1-23 on page B1-1233, an entry of:
• UND indicates that the Advanced SIMD or floating-point access generates an Undefined Instruction
exception. For an access made from Hyp mode this exception is taken to Hyp mode, otherwise it is taken to
Secure or Non-secure Undefined mode.
• Trapped indicates that accesses generate a Hyp Trap exception, that is taken to Hyp mode.
Table B1-21 Summary of access controls for all CP10 and CP11 functionality
Controls Secure Non-secure
CPACR.cpn a NSACR.cpn HCPTR.TCPn FPEXC.EN PL1 PL0 PL2 PL1 PL0
00 0 xb x UND UND UND UND UND
1 0 0 UND UND UND c UND UND
1 UND UND Enabled UND UND
1 x UND UND UND UND UND
01 0 xb 0 UND c UND UND UND UND
1 Enabled UND UND UND UND
1 0 0 UND c UND UND c UND c UND
1 Enabled UND Enabled Enabled UND
1 0 UND c UND UND UND d UND
1 Enabled UND UND Trapped UND
11 0 xb 0 UND c UND UND UND UND
1 Enabled Enabled UND UND UND
1 0 0 UND c UND UND c UND c UND
1 Enabled Enabled Enabled Enabled Enabled
1 0 UND c UND UND UND d UND
1 Enabled Enabled UND Trapped Trapped
a. When the corresponding NSACR bit is set to 0, for Non-secure accesses the CPACR field behaves as RAZ/WI. That is, when
NSACR.cp10 is set to 0, for Non-secure accesses CPACR.cp10 ignores writes, and reads as 0b00, regardless of its actual value.
b. When the NSACR control bits are set to 0, for Non-secure accesses the HCPTR control bits behave as RAO/WI.
c. Except for VMSR to the FPEXC or FPSID register, or a VMRS from the FPEXC, FPSID, MVFR0, or MVFR1 register.
d. Except for VMSR to the FPEXC or FPSID register, or a VMRS from the FPEXC, FPSID, MVFR0, or MVFR1 register, that are Trapped.
Note
In Table B1-21 on page B1-1230:
• the behavior of Secure accesses depends only on the CPACR and FPEXC control values
• the behavior of accesses from Hyp mode depends only on the NSACR, HCPTR, and FPEXC control values.
Information about the general controls of CP10 and CP11 functionality
In Table B1-21 on page B1-1230, the values for each of the registers shown in the Controls columns are:
CPACR The value of the CPACR.cp10 and CPACR.cp11 fields. These fields must be programmed to the
same value, otherwise behavior is UNPREDICTABLE. The table does not show the reserved value of
0b10.
In addition, when CP10 and CP11 functionality is otherwise enabled, if CPACR.D32DIS is set to 1,
any operation that uses registers D16-D31 of the Floating-point register file is UNDEFINED.
These controls are part of any implementation that includes at least one of the Advanced SIMD
Extension and the Floating-point Extension.
NSACR The value of the NSACR.cp10 and NSACR.cp11 bits. These bits must be programmed to the same
value, otherwise behavior is UNPREDICTABLE.
These controls are implemented only as part of the Security Extensions. For the access controls for
an implementation that does not include the Security Extensions, consider only:
• The Secure PL1 and PL0 columns.
• The rows for which NSACR is 0, and HCPTR is 0 or x.
HCPTR The value of the HCPTR.TCP10 and HCPTR.TCP11 bits. These bits must be programmed to the
same value, otherwise behavior is UNPREDICTABLE.
These controls are implemented only as part of the Virtualization Extensions. For the access controls
for an implementation that does not include the Virtualization Extensions:
• Ignore the Non-secure PL2 column.
• Consider only the rows for which HCPTR is 0 or x.
FPEXC.EN The value of FPEXC.EN. As indicated in this section, and in the table footnote, when this bit is set
to 0:
• Most Advanced SIMD and floating-point functionality is disabled.
• A limited number of register accesses are permitted at PL1 or higher.
When this bit is set to 1, Advanced SIMD and floating-point functionality is enabled, but subject to:
• The other access controls shown in the table.
• The restrictions described in PL0 access to Advanced SIMD and floating-point functionality,
and traps of PL0 functionality.
This control is part of any implementation that includes at least one of the Advanced SIMD
Extension and the Floating-point Extension.
PL0 access to Advanced SIMD and floating-point functionality, and traps of PL0 functionality
When Table B1-21 on page B1-1230 shows that PL0 access to the Advanced SIMD and floating-point functionality
is Enabled or Trapped, this applies only to the subset of functionality that is available at PL0.
In particular:
• The only Advanced SIMD and Floating-point Extension system register that is accessible at PL0 is the
FPSCR.
• The Advanced SIMD and floating-point instructions are available at PL0.
This means that when the CPACR, NSACR, and FPEXC controls permit Non-secure PL0 access to this Advanced
SIMD and floating point functionality, HCPTR.{TCP10, TCP11} determine whether those accesses are trapped to
Hyp mode.
Execution at PL0 corresponds to the application level view of the extensions, as described in Advanced SIMD and
Floating-point Extensions on page A2-54.
Additional controls on Advanced SIMD functionality

If the general controls summarized in Summary of general controls of CP10 and CP11 functionality on
page B1-1230 permit access to CP10 and CP11 functionality, additional controls apply to any implemented
Advanced SIMD functionality. The following controls apply to all Advanced SIMD instructions, that is, to all
instruction encodings in Alphabetical list of instructions on page A8-298 that are identified as Advanced SIMD
encodings and are not also Floating-point encodings:
• When CPACR.ASEDIS is set to 1, all Advanced SIMD instructions are UNDEFINED.
• In an implementation that includes the Security Extensions, when CPACR.ASEDIS is set to 0, if

NSACR.NSASEDIS is set to 1 and the processor is in Non-secure state, CPACR.ASEDIS appears as
RAO/WI and all Advanced SIMD instructions are UNDEFINED.
• In an implementation that includes the Virtualization Extensions, when the CPACR and NSACR settings
permit Non-secure use of the Advanced SIMD instructions, if HCPTR.TASE is set to 1 any use of an
Advanced SIMD instruction from:
— A Non-secure PL1 or PL0 mode is trapped to Hyp mode.
— Hyp mode generates an Undefined Instruction exception that is taken to Hyp mode.
Table B1-22 references the descriptions of the registers that control this functionality, and Summary of access
controls for Advanced SIMD functionality shows these controls.
Table B1-22 Registers that control access to Advanced SIMD and floating-point functionality
Description VMSA PMSA Note
Coprocessor Access Control Register CPACR CPACR -
Floating-Point Exception Control register FPEXC FPEXC -
Non-Secure Access Control Register NSACR - Security Extensions, therefore VMSA only
Hyp Coprocessor Trap Register HCPTR - Virtualization Extensions, therefore VMSA only
Summary of access controls for Advanced SIMD functionality
Table B1-23 on page B1-1233 summarizes the additional access controls for the use of Advanced SIMD
instructions.
• In this table, entries of UND and Enabled have the meanings defined in Summary of general controls of CP10
and CP11 functionality on page B1-1230
• The entries shown in this table must be combined with the information shown in Table B1-21 on
page B1-1230 as follows:
— If at least one table shows the access as UND then the access is UNDEFINED.
— Otherwise, if at least one table shows the access as Trapped then the access generates a Hyp Trap
exception.
— Otherwise, both tables show the access as Enabled, meaning the access is permitted.
Table B1-23 Summary of additional access controls for Advanced SIMD functionality
Controls Secure Non-secure
CPACR.ASEDIS NSACR.NSASEDIS HCPTR.TASE PL1 PL0 PL2 PL1 PL0
0a 0 0 Enabled Enabled Enabled Enabled Enabled
1 Enabled Enabled UND Trapped Trapped
1 xa Enabled Enabled UND UND UND
1 0 0 UND UND Enabled UND UND
1 UND UND UND UND UND
1 xa UND UND UND UND UND
a. When NSACR.NSASEDIS is set to 1, for Non-secure accesses:

– to CPACR, the ASEDIS bit behaves as RAO/WI
– to HCPTR, the TASE bit behaves as RAO/WI.
When interpreting Table B1-23:
• The NSACR is implemented only as part of the Security Extensions. For an implementation that does not
include the Security Extensions, use of the Advanced SIMD instructions:
— Is enabled when CPACR.ASEDIS is set to 0.
— Is disabled when CPACR.ASEDIS is set to 1.
• The HCPTR is implemented only as part of the Virtualization Extensions. For an implementation that does
not include the Virtualization Extensions, when the controls shown in Table B1-21 on page B1-1230 permit
Non-secure use of the CP10 and CP11 functionality, use of the Advanced SIMD instructions from
Non-secure state:
— Is enabled when CPACR.ASEDIS and NSACR.NSASEDIS are both set to 0.
— Is disabled otherwise.
Pseudocode details of enabling the Advanced SIMD and Floating-point Extensions

The following pseudocode takes appropriate action if an Advanced SIMD or Floating-point instruction is used when
the extensions are not enabled:
// CheckAdvSIMDOrVFPEnabled()
// ==========================
CheckAdvSIMDOrVFPEnabled(boolean include_fpexc_check, boolean advsimd)
// In Non-secure state, Non-secure view of CPACR and HCPTR determines behavior

// Copy register values
cpacr_cp10 = CPACR.cp10;
cpacr_cp11 = CPACR.cp11;
cpacr_asedis = CPACR.ASEDIS;
if HaveVirtExt() then
hcptr_cp10 = HCPTR.TCP10;
hcptr_cp11 = HCPTR.TCP11;
hcptr_tase = HCPTR.TASE;
if HaveSecurityExt() then
// Check Non-Secure Access Control Register for permission to use CP10/11.
if NSACR.cp10 != NSACR.cp11 then UNPREDICTABLE;
if !IsSecure() then
// Modify register values to the Non-secure view
if NSACR.cp10 == '0' then
cpacr_cp10 = '00';
cpacr_cp11 = '00';
hcptr_cp10 = '1';
hcptr_cp11 = '1';
if NSACR.NSASEDIS == '1' then
cpacr_asedis = '1';
hcptr_tase = '1';
// Check Coprocessor Access Control Register for permission to use CP10/11.

if !HaveVirtExt() || !CurrentModeIsHyp() then
if cpacr_cp10 != cpacr_cp11 then UNPREDICTABLE;
case cpacr_cp10 of
when '00' UNDEFINED;
when '01' if !CurrentModeIsNotUser() then UNDEFINED;
// else CPACR permits access
when '10' UNPREDICTABLE;
when '11' // CPACR permits access
// If the Advanced SIMD extension is specified, check whether it is disabled.

if advsimd && cpacr_asedis == '1' then UNDEFINED;
// If required, check FPEXC enabled bit.

if include_fpexc_check && FPEXC.EN == '0' then UNDEFINED;
if HaveSecurityExt() && HaveVirtExt() && !IsSecure() then

if hcptr_cp10 != hcptr_cp11 then UNPREDICTABLE;
if hcptr_cp10 == '1' || (advsimd && hcptr_tase == '1') then
if advsimd then
HSRString<5> = '1';
HSRString<3:0> = bits (4) UNKNOWN;
else
HSRString<5> = '0';
HSRString<3:0> = '1010';
WriteHSR('000111', HSRString);
if !CurrentModeIsHyp() then
else
UNDEFINED;
return;
// CheckAdvSIMDEnabled()
// =====================
CheckAdvSIMDEnabled()
CheckAdvSIMDOrVFPEnabled(TRUE, TRUE);
// Return from CheckAdvSIMDOrVFPEnabled() occurs only if Advanced SIMD access is permitted
// Make temporary copy of D registers

// _Dclone[] is used as input data for instruction pseudocode
for i = 0 to 31
_Dclone[i] = _D[i];
return;
// CheckVFPEnabled()
// =================
CheckVFPEnabled(boolean include_fpexc_check)
CheckAdvSIMDOrVFPEnabled(include_fpexc_check, FALSE);
// Return from CheckAdvSIMDOrVFPEnabled() occurs only if VFP access is permitted
return;
B1.11.2 Advanced SIMD and Floating-point Extension system registers

The Advanced SIMD and Floating-point Extensions share a common set of system registers. Any ARMv7
implementation that includes either or both of these extensions must implement these registers. This section gives
general information about this set of registers, and indicates where each register is described in detail. It contains
the following subsections:
• Register map of the Advanced SIMD and Floating-point Extension system registers.
• Accessing the Advanced SIMD and Floating-point Extension system registers on page B1-1236.
Register map of the Advanced SIMD and Floating-point Extension system registers
Table B1-24 shows the register map of the Advanced SIMD and Floating-point registers. Each register is 32 bits
wide. In an implementation that includes the Security Extensions, the Advanced SIMD and Floating-point registers
are common registers, see Common system control registers on page B3-1453.
Table B1-24 Advanced SIMD and Floating-point common register block
Name, VMSA a Name, PMSA a System register Width Type Description
FPSID FPSID 0b0000 32-bit RO Floating-point System ID Register
FPSCR FPSCR 0b0001 32-bit RW Floating-point Status and Control Register
- - 0b0010- 0b0101 32-bit - All accesses are UNPREDICTABLE
MVFR1 MVFR1 0b0110 32-bit RO Media and VFP Feature Register 1
MVFR0 MVFR0 0b0111 32-bit RO Media and VFP Feature Register 0
FPEXC FPEXC 0b1000 32-bit RW Floating-Point Exception Register
- - 0b1001-0b1111 32-bit SUBARCHITECTURE DEFINED
a. VMSA and PMSA definitions of the register fields are identical. These columns link to the descriptions in Chapter B4 and Chapter B6.
Note
Appendix D6 Common VFP Subarchitecture Specification includes examples of how a Floating-point
subarchitecture might define additional registers, in the SUBARCHITECTURE DEFINED register space using addresses
in the 0b1001 to 0b1111 range. Appendix D6 is not part of the ARMv7 architecture. It is included as an example of
how a Floating-point subarchitecture might be defined.
Accessing the Advanced SIMD and Floating-point Extension system registers

Software accesses the Advanced SIMD and Floating-point Extension system registers using the VMRS and VMSR
instructions, see:
• VMRS on page B9-2000.
• VMSR on page B9-2002.
For example:
VMRS <Rt>, FPSID ; Read Floating-Point System ID Register

VMRS <Rt>, MVFR1 ; Read Media and VFP Feature Register 1
VMSR FPSCR, <Rt> ; Write Floating-Point System Control Register
Software can access the Advanced SIMD and Floating-point Extension system registers only if the access controls
for the extensions permit the access, see Enabling Advanced SIMD and floating-point support on page B1-1228.
Note
All hardware ID information can be accessed only from PL1 or higher. This means:
The FPSID is accessible only from PL1 or higher.

This is a change introduced in VFPv3. In VFPv2 implementations the FPSID register can be
accessed in all modes.
The MVFR registers are accessible only from PL1 or higher.

Unprivileged software must issue a system call to determine what features are supported.
B1.11.3 Context switching with the Advanced SIMD and Floating-point Extensions
In an implementation that includes one or both of the Advanced SIMD and Floating-point Extensions, if the
Floating-point registers are used by only a subset of processes, the operating system might implement lazy context
switching of the extension registers and extension system registers.
In the simplest lazy context switch implementation, the primary context switch software disables the Advanced
SIMD and Floating-point Extensions, by disabling access to coprocessors CP10 and CP11 in the Coprocessor
Access Control Register, see Enabling Advanced SIMD and floating-point support on page B1-1228. Subsequently,
when a process or thread attempts to use an Advanced SIMD or Floating-point instruction, it triggers an Undefined
Instruction exception. The operating system responds by saving and restoring the extension registers and extension
system registers. Typically, it then re-executes the Advanced SIMD or Floating-point instruction that generated the
Undefined Instruction exception.
B1.11.4 Floating-point support code

A complete Floating-point implementation might require a software component, called the support code. For
example, if an implementation includes VFPv3U or VFPv4U, support code must handle the trapped floating-point
exceptions. The interface to the support code is called the VFP subarchitecture. ARM has defined a subarchitecture
that is suitable for use with implementations of the ARM Floating-point Extension, see Appendix D6 Common VFP
Subarchitecture Specification.
Note
The Common VFP Subarchitecture is not part of the ARMv7 architecture specification, see VFP subarchitecture
support on page B1-1238.
If the Floating-point Extension hardware does not respond to a Floating-point instruction, the support code is
entered through the ARM Undefined Instruction vector. This software entry is called a bounce.
When an implementation includes VFPv3U or VFPv4U, the bounce mechanism also supports trapped
floating-point exceptions. Trapped floating-point exceptions, called traps, are floating-point exceptions that an
implementation passes back to application software to resolve, see Floating-point exceptions on page A2-69. The
support code must catch a trapped exception and convert it into a trap handler call.
Support code can perform other tasks, as determined by the implementation. For example, it might be used for rare
conditions, such as operations that are difficult to implement in hardware, or operations that are gate-intensive in
hardware. However, in ARMv7, ARM:
• Deprecates any such use of support code.
• Strongly recommends that all floating-point functionality, except for short vector support, is fully
implemented in hardware.
The division of labor between the hardware and software components of an implementation, and details of the
interface between the support code and hardware are SUBARCHITECTURE DEFINED.
Asynchronous bounces, serialization, and Floating-point exception barriers
Note
Asynchronous bounces were commonly used in ARMv6 implementations. For ARMv7 implementations, ARM
strongly recommends that any bounces are synchronous.
A Floating-point implementation can produce an asynchronous bounce, in which a Floating-point instruction takes
the Undefined Instruction exception because support code processing is required for an earlier Floating-point
instruction. The mechanism by which the support code determines the nature of the required processing is
SUBARCHITECTURE DEFINED. Typically, it involves:
• Using the SUBARCHITECTURE DEFINED bits of the FPEXC.
• Using the SUBARCHITECTURE DEFINED extension system registers, see Advanced SIMD and Floating-point
Extension system registers on page B1-1235.
• Setting FPEXC.EX == 1, to indicate that the SUBARCHITECTURE DEFINED extension system registers must be
saved on a context switch.
An asynchronous bounce might not relate to the last Floating-point instruction executed before the one that
generated the Undefined Instruction exception. Another Floating-point instruction might have been issued and
retired before the asynchronous bounce occurs. This is possible only if this intervening instruction has no register
dependencies on the Floating-point instruction that requires support code processing. In addition. a subarchitecture
can proved SUBARCHITECTURE DEFINED mechanisms for handling an intervening Floating-point instruction that has
issued but not retired. The common VFP subarchitecture defined in Appendix D6 includes such mechanisms.
However, VMRS and VMSR instructions that access the FPSID, FPSCR, or FPEXC registers are serializing instructions.
This means that, before they perform any required register transfer, they ensure that any exceptional condition that
requires support code processing, from any preceding Floating-point instruction, has been detected and reflected in
the extension system registers. A VMSR instruction to the read-only FPSID register is a serializing NOP.
In addition:
• A VMRS or VMSR instruction that accesses the FPSCR acts as a Floating-point exception barrier. This means
that, before it performs the register transfer, it ensures that any outstanding exceptional conditions in
preceding Floating-point instructions have been detected and processed by the support code. If necessary, the
VMRS or VMSR instruction takes an asynchronous bounce to force the processing of any outstanding exceptional
conditions.
• VMRS and VMSR instructions that access the FPSID or FPEXC do not take asynchronous bounces.
In pseudocode, Floating-point serialization and the Floating-point exception barriers are described by the
SerializeVFP() and VFPExcBarrier() functions respectively.
B1.11.5 VFP subarchitecture support

In the ARMv7 specification of the Floating-point Extension, some features are identified as SUBARCHITECTURE
DEFINED. ARMv7 is compatible with the ARM Common VFP subarchitecture, that is used by several Floating-point
implementations. However, ARMv7 does not require or specifically recommend the use of the ARM Common VFP
subarchitecture.
Appendix D6 Common VFP Subarchitecture Specification is the specification of the ARM Common VFP
subarchitecture. The subarchitecture is not part of the ARMv7 architecture specification. For details of the status of
the subarchitecture specification see the Note on the cover page of Appendix D6.
B1.12 Thumb Execution Environment
B1.12 Thumb Execution Environment

Thumb Execution Environment on page A2-94 introduces the Thumb Execution Environment (ThumbEE), and
includes:
• An application level view of the execution environment.
• A summary of its system control registers.
Chapter A9 The ThumbEE Instruction Set describes the ThumbEE instruction set.
This section describes the system level programmers’ model for ThumbEE.
The ThumbEE Configuration Register can be read at PL0, but can be written only at PL1 or higher, see TEECR,
ThumbEE Configuration Register, VMSA on page B4-1709 or TEECR, ThumbEE Configuration Register, PMSA on
page B6-1928.
Access to the ThumbEE Handler Base Register depends on the value held in the TEECR and the current privilege
level, see TEEHBR, ThumbEE Handler Base Register, VMSA on page B4-1710 or TEEHBR, ThumbEE Handler
Base Register, PMSA on page B6-1929.
The processor executes ThumbEE instructions when it is in ThumbEE state.
The processor instruction set state is indicated by the CPSR.{J T} bits, see Program Status Registers (PSRs) on
page B1-1147. CPSR.{J, T} == 0b11 when the processor is in ThumbEE state.
During normal execution, not involving exception entries and returns:
• ThumbEE state can only be entered from Thumb state, using the ENTERX instruction
• exit from ThumbEE state always occurs using the LEAVEX instruction and returns execution to Thumb state.
For details of these instructions see ENTERX, LEAVEX on page A9-1116.
When an exception occurs in ThumbEE state, exception entry goes to either ARM state or Thumb state as usual,
depending on the value of SCTLR.TE. When the exception handler returns, the exception return instruction restores
CPSR.{J, T} as usual, causing a return to ThumbEE state.
In ThumbEE state, execution of the exception return instructions described in Exception return on page B1-1193 is
UNPREDICTABLE.
B1.12.1 ThumbEE and the Security Extensions and Virtualization Extensions

When an implementation that includes ThumbEE support also includes the Security Extensions, the ThumbEE
registers are common registers, see Common system control registers on page B3-1453.
When an implementation that includes ThumbEE support also includes the Virtualization Extensions, accesses to
the ThumbEE registers from Non-secure PL1 and PL0 modes can be trapped to Hyp mode, see Trapping accesses
to the ThumbEE configuration registers on page B1-1254.
B1.12.2 Aborts, exceptions, and checks

Aborts and exceptions are unchanged in ThumbEE. A null check takes priority over an abort or watchpoint on the
same memory access. For more information, see Null checking on page A9-1113.
The IT state bits in the CPSR are always cleared on entry to a NullCheck or IndexCheck handler. For more
information, see IT block and check handlers on page A9-1114.
B1.13 Jazelle direct bytecode execution

In Jazelle state the processor executes bytecode programs, as described in Jazelle state on page A2-97. The
CPSR.{J, T} bits indicate the processor instruction set state, see Program Status Registers (PSRs) on page B1-1147.
CPSR.{J, T} == 0b10 when the processor is in Jazelle state. Because the Virtualization Extensions require an
implementation to include only a trivial Jazelle implementation, an implementation that includes the Virtualization
Extensions cannot execute in Jazelle state.
For more information about entering and exiting Jazelle state see Jazelle state on page B1-1244.
B1.13.1 Extension of the PC to 32 bits

In a non-trivial Jazelle implementation, all 32 bits of the PC are defined. This means the PC can point to an arbitrary
bytecode instruction. In the PC, bit[0] always reads as zero when in ARM, Thumb, or ThumbEE state.
Note
The existence of bit[0] as a valid address bit in the PC is visible in ARM, Thumb, or ThumbEE states only when an
exception occurs in Jazelle state and the exception return address is odd-byte aligned.
B1.13.2 Exception handling in the Jazelle extension

Exception handling on page B1-1164 describes exception entry for an exception that occurs while the processor is
executing in Jazelle state. This section gives more information about how exceptions in Jazelle state are taken and
handled. Because an implementation that includes the Virtualization Extensions cannot include a non-trivial Jazelle
implementation, exceptions taken from Jazelle state are always taken to and handled in a PL1 mode.
IRQ and FIQ interrupts

To ensure the standard mechanism for handling interrupts works correctly, a Jazelle hardware implementation must
ensure that one of the following applies at the point where execution of a Java bytecode instruction might be
interrupted by an IRQ or FIQ:
• Execution has reached a bytecode instruction boundary. That is:

— All operations required to implement one bytecode instruction have completed.
— No operation required to implement the next bytecode instruction has completed.
The LR value on entry to the interrupt handler must be (address of the next bytecode instruction) + 4.
• The sequence of operations performed from the start of execution of the current bytecode instruction, up to
the point where the interrupt occurs, is idempotent. This means that the sequence can be repeated from its
start without changing the overall result of executing the bytecode instruction.
The LR value on entry to the interrupt handler must be (address of the current bytecode instruction) + 4.
• Corrective action is taken either:

— Directly by the Jazelle extension hardware.
— Indirectly, by calling a SUBARCHITECTURE DEFINED handler in the EJVM.
The corrective action must re-create a situation where the bytecode instruction can be re-executed from its
start.
The LR value on entry to the interrupt handler must be (address of the interrupted bytecode instruction) + 4.
In an implementation that includes the Virtualization Extensions, these options apply, also, to the point where
execution might be interrupted by a virtual IRQ or virtual FIQ:
Data Abort exceptions

The standard mechanism for handling a Data Abort exception is:
• Read the Fault Status and Fault Address registers.
• Fix the reason for the abort.
• Return using SUBS PC, LR, #8 or its equivalent.
The abort handler must be able to do this without looking at the instruction that caused the abort, and without
knowing the instruction set state it was executed in.
Note
• This assumes that the intention is to return to and retry the bytecode instruction that caused the Data Abort
exception. If the intention is instead to return to the bytecode instruction after the one that caused the abort,
then the return address must be modified by the length of the bytecode instruction that caused the abort.
• For details of the exception reporting, see:

— Exception reporting in a VMSA implementation on page B3-1406, for a VMSA implementation.
— Exception reporting in a PMSA implementation on page B5-1761, for a PMSA implementation.
To ensure the standard mechanism for handling Data Abort exceptions works correctly, a Jazelle hardware
implementation must ensure that one of the following applies at any point where a Java bytecode instruction can
generate a Data Abort exception:
• The sequence of operations performed from the start of execution of the bytecode instruction, up to the point
where the Data Abort exception is generated, is idempotent. This means that the sequence can be repeated
from its start without changing the overall result of executing the bytecode instruction.
• If the Data Abort exception is generated during execution of a bytecode instruction, corrective action is taken
either:
— Directly by the Jazelle extension hardware.
— Indirectly, by calling a SUBARCHITECTURE DEFINED handler in the EJVM.
The corrective action must re-create a situation where the bytecode instruction can be re-executed from its
start.
Note
From ARMv6, the ARM architecture does not support the Base Updated Abort Model. This removes a potential
obstacle to the first of these solutions. For information about the Base Updated Abort Model in earlier versions of
the ARM architecture see The ARM abort model on page D15-2588.
Prefetch Abort exceptions

On taking a Prefetch Abort exception, the Prefetch Abort exception handler can use the value saved in LR_abt to
locate the start of the instruction that caused the abort, without knowing the instruction set state in which its
execution was attempted. The start of this instruction is always at address (LR_abt – 4).
A multi-byte bytecode instruction can cross a page boundary. In this case the Prefetch Abort exception handler
cannot use LR_abt to determine which of the two pages caused the abort. Instead, in an ARMv7 implementation,
for any exception taken to a PL1 mode, the IFAR indicates the faulting address.
Supervisor Call and Secure Monitor Call exceptions

Supervisor Call and Secure Monitor Call exceptions cannot be generated during Jazelle state execution. To generate
one of these exceptions, a Jazelle implementation must exit to a software handler that executes an SVC or SMC
instruction.
Undefined Instruction exceptions

The Undefined Instruction exception cannot be taken during Jazelle state execution, except that on a trivial
implementation of the Jazelle extension, the UNPREDICTABLE behavior described in Exception return to an
unimplemented instruction set state on page B1-1196 might include taking the Undefined Instruction exception.
B1.13.3 Jazelle state configuration and control

For details of the configuration and control of Jazelle state from the application level, see Application level
configuration and control of the Jazelle extension on page A2-98. That section includes a summary of the Jazelle
extension registers. For descriptions of the registers see:
• For a VMSA implementation, JIDR, JMCR, and JOSCR.
• For a PMSA implementation, JIDR, JMCR, and JOSCR.
JIDR and JMCR can be accessed from PL0. JOSCR is accessible only from PL1 or higher.
Note
VMSA and PMSA implementations of the Jazelle registers are identical. The registers are described both in
Chapter B4 System Control Registers in a VMSA implementation and in Chapter B6 System Control Registers in a
PMSA implementation.
In an implementation that includes the Security Extensions, the Jazelle registers are Common registers, see Common
system control registers on page B3-1453. Each register has the same access permissions in both security states. For
more information, see the register descriptions.
Note
• Normally, an EJVM never accesses the JOSCR.
• An EJVM that runs in User mode must not attempt to access the JOSCR.
The JOSCR provides a control mechanism that is independent of the subarchitecture of the Jazelle extension. An
operating system can use this mechanism to control access to the Jazelle extension.The JOSCR.CV and JOSCR.CD
are both set to 0 on reset. This ensures that, subject to some conditions, an EJVM can operate under an OS that does
not support the Jazelle extension. The main condition required to ensure an EJVM can operate under an OS that
does not support the Jazelle extension is that the operating system never swaps between two EJVM processes that
require different settings of the Jazelle configuration registers.
Two examples of how this condition can be met in a system are:

• If there is only ever one process or thread using the EJVM.
• If all of the processes or threads that use the EJVM use the same static settings of the configuration registers.
Controlling entry to Jazelle state

The normal method of entering Jazelle state is using the BXJ instruction, see Jazelle state entry instruction, BXJ on
page A2-97. The operation of this instruction depends on the values of both JMCR.JE and JOSCR.CV.
When the JMCR.JE bit is 0, the JOSCR has no effect on the execution of BXJ instructions. They always execute as
BX instructions, and there is no attempt to enter Jazelle state.
When the JMCR.JE bit is 1, the JOSCR.CV bit controls the operation of BXJ instructions:
If CV == 1 The Jazelle extension hardware configuration is valid and enabled. A BXJ instruction causes the
processor to enter Jazelle state in SUBARCHITECTURE DEFINED circumstances, and execute bytecode
instructions as described in Executing BXJ with Jazelle extension enabled on page A2-97.
If CV == 0 The Jazelle extension hardware configuration is not valid and therefore entry to Jazelle state is
disabled.
In all SUBARCHITECTURE DEFINED circumstances where, if CV had been 1 the BXJ instruction would
have caused the Jazelle extension hardware to enter Jazelle state, it instead:
• Enters a Configuration Invalid handler.
• Sets CV to 1.
A Configuration Invalid handler is a sequence of instructions that:
• Includes MCR instructions to write the configuration required by the EJVM.
• Ends with a BXJ instruction to re-attempt execution of the required bytecode instruction.
The following are SUBARCHITECTURE DEFINED:

• How the address of the Configuration Invalid handler is determined.
• The entry and exit conditions of the Configuration Invalid handler.
In circumstances in which the Jazelle extension hardware would not have entered Jazelle state if CV
had been 1, it is IMPLEMENTATION DEFINED whether:
• The Configuration Invalid handler is entered.
• A SUBARCHITECTURE DEFINED handler is entered, as described in Executing BXJ with Jazelle
extension enabled on page A2-97.
In ARMv7, the JOSCVR.CV bit is set to 0 on exception entry for all implementations other than a trivial
implementation of the Jazelle extension.
The intended use of the JOSCR.CV bit is:
1. When a context switch occurs, JOSCR.CV is set to 0. This is done by the operating system or, in ARMv7, as
the result of an exception.
2. When the new process or thread performs a BXJ instruction to start executing bytecode instructions, the
Configuration Invalid handler is entered and JOSCR.CV is set to 1.
3. The Configuration Invalid handler:

• Writes the configuration required by the EJVM to the Jazelle configuration registers.
• Retries the BXJ instruction to execute the bytecode instruction.
This ensures that the Jazelle extension configuration registers are set up correctly for the EJVM concerned before
any bytecode instructions are executed. It successfully handles cases where a context switch occurs during
execution of the Configuration Invalid handler.
In an implementation that includes the Virtualization Exceptions, accesses to the Jazelle system control registers
from Non-secure PL1 and PL0 modes can be trapped to Hyp mode, see Trapping accesses to Jazelle functionality
on page B1-1254.
Monitoring and controlling User mode access to the Jazelle extension

The system can use the JOSCR.CD bit in different ways to monitor and control User mode access to the Jazelle
extension hardware. Possible uses include:
• An OS can set JOSCR.CD to 1 and JMCR.JE to 0, to prevent all User mode access to the Jazelle extension
hardware. With these settings any use of the BXJ instruction has the same result as a BX instruction, and any
attempt to configure the hardware, including any attempt to set the JMCR.JE bit to 1, results in an Undefined
Instruction exception.
• A simple mechanism for the OS to provide User mode access to the Jazelle extension hardware, while
protecting EJVMs from conflicting use of the hardware by other processes, is:
— Set the JOSCR.CD bit to 0.
— Preserve and restore the JMCR on context switches, initializing its value to 0 for new processes.
— The JOSCR.CV bit is set to 0 on each context switch, either by the operating system or, in ARMv7, as
the result of an exception. This ensures that EJVMs reconfigure the Jazelle extension hardware to
match their requirements when necessary.
The context switch mechanism is described in Controlling entry to Jazelle state on page B1-1242.
B1.13.4 EJVM operation

EJVM operation on page A2-99 described the architectural requirements for an EJVM at the Application level.
Because the EJVM is provided for use by applications, the system level description of the architecture does not
require significant additional information about the EJVM.
Initialization on page A2-99 stated that, if the EJVM is compatible with the subarchitecture, the EJVM must write
its required configuration to the JMCR and any other configuration registers. The EJVM must not omit this step on
the assumption that the JOSCR.CV bit is 0. In other words, the EJVM must not assume that JOSCR.CV is set to 0,
and that this will trigger entry to the Configuration Invalid handler before any bytecode instruction is executed by
the Jazelle extension hardware.
B1.13.5 Trivial implementation of the Jazelle extension

Jazelle direct bytecode execution support on page A2-96 introduced the possible trivial implementation of the
Jazelle extension, and summarized the application level requirements of a trivial implementation. This section gives
the system level description of a trivial implementation of the Jazelle extension.
A trivial implementation of the Jazelle extension must:
• Implement the JIDR with the implementer and subarchitecture fields set to zero. The register can be
implemented so that the whole register is RAZ.
• Implement the JMCR as RAZ/WI.
• Implement the JOSCR either:

— So that it can be read and written, but its effects are ignored.
— As RAZ/WI.
This ensures that operating systems that support an EJVM execute correctly.
• Implement the BXJ instruction to behave identically to the BX instruction in all circumstances, as required by
the fact that the JMCR.JE bit is always zero. This means that, with a trivial implementation of the Jazelle
extension, Jazelle state can never be entered normally.
Note
As described in Trapping accesses to Jazelle functionality on page B1-1254, if HSTR.TJDBX is set to 1, an
otherwise-valid execution of a BXJ instruction is trapped to Hyp mode, but execution of a BX instruction is not
trapped. In this respect only, BXJ and BX behave differently.
• Treat Jazelle state as an unimplemented instruction set state, as described in Exception return to an
unimplemented instruction set state on page B1-1196.
A trivial implementation does not have to extend the PC to 32 bits, that is, it can implement PC[0] as RAZ/WI. This
is because the only way that PC[0] is visible in ARM or Thumb state is as a result of a processor exception occurring
during Jazelle state execution, and Jazelle state execution cannot occur on a trivial implementation.
B1.13.6 Jazelle state

All processor state information that can be modified by Jazelle state execution is held in registers that are visible at
the application level, as described in ARM core registers on page B1-1143 and The Application Program Status
Register (APSR) on page A2-49. Configuration information can be kept either in these application level registers or
in Jazelle configuration registers that are accessible at the Application level, see Application level configuration and
control of the Jazelle extension on page A2-98. This might include configuration registers that are Jazelle
SUBARCHITECTURE DEFINED. This ensures that the processor configuration information is preserved and restored
correctly when processor exceptions and context switches occur. In this context, configuration information is
information that affects Jazelle state execution but is not modified by it.
An EJVM implementation must check whether the implemented Jazelle extension is compatible with its use of the
application level registers. If the implementation is compatible, the EJVM sets JMCR.JE to 1. If the implementation
is not compatible, the EJVM sets JMCR.JE to 0, and executes without hardware acceleration.
Jazelle state exit

The processor exits Jazelle state in IMPLEMENTATION DEFINED circumstances. Typically, this is due to attempted
execution of a bytecode instruction that the implementation cannot handle in hardware, or that generates one of the
Java exceptions described in The Java Virtual Machine Specification. On exit from Jazelle state, various processor
registers contain SUBARCHITECTURE DEFINED values, enabling the EJVM to resume software execution of the
bytecode program correctly.
The processor also exits Jazelle state if it takes an exception. In this case, the CPSR is copied to the Banked SPSR
for the mode to which the exception is taken, so the Banked SPSR contains J == 1 and T == 0. This means re-enters
Jazelle state on return from the exception, when the SPSR is copied back into the CPSR. With the restriction that
Jazelle state execution can modify only application level registers, this ensures that all registers are correctly
preserved and can be restored by the exception handlers. Configuration and control registers can be modified in the
exception handler itself as described in Jazelle state configuration and control on page B1-1242.
Specific considerations apply to the processor taking an exception from Jazelle state, see Exception handling in the
Jazelle extension on page B1-1240.
It is IMPLEMENTATION DEFINED whether Jazelle extension hardware contains state that is both:
• Modified during Jazelle state execution.
• Held outside the application level registers during Jazelle state execution.
If such state exists, the implementation must:
• Initialize the state from one or more of the application level registers whenever Jazelle state is entered,
whether as the result of:
— The execution of a BXJ instruction.
— The processor returning from taking an exception.
• Write the state into one or more of the application level registers whenever Jazelle state is exited, whether as
a result of the processor taking an exception, or of IMPLEMENTATION DEFINED circumstances.
• Ensure that the mechanism for writing the state into application level registers on the processor taking an
exception, and initializing the state from application level registers on returning from that exception, ensures
that the state is correctly preserved and restored over the exception.
Additional Jazelle state restrictions

Therefore a processor that implements the Virtualization Extensions cannot enter Jazelle state.
Execution in Jazelle state is UNPREDICTABLE in FIQ mode.

Otherwise, the Jazelle extension hardware must obey the following restrictions:
• It must not change processor mode other than by taking one of the processor exceptions described in
Exception descriptions on page B1-1204.
• It must not access Banked copies of registers other than the ones belonging to the processor mode in which
it is entered.
• It must not do anything that is illegal for an UNPREDICTABLE instruction, see UNPREDICTABLE.
As a result of these requirements, Jazelle state can be entered from PL0 without risking a breach of OS security.
B1.14 Traps to the hypervisor

This section describes the traps the Virtualization Extensions provide, that software executing at PL2 can use to trap
Non-secure operations performed at PL1 or PL0.
In a similar way, software executing at PL2 can route a number of exceptions to be taken to Hyp mode. Therefore,
the trapping and related mechanisms provided by the Virtualization Extensions include:
• Trapping attempted execution of certain instructions to Hyp mode, so a hypervisor can emulate the
instruction. This section describes these traps.
• Routing certain synchronous exceptions to Hyp mode, see:

— Routing general exceptions to Hyp mode on page B1-1190.
— Routing Debug exceptions to Hyp mode on page B1-1193.
Note
— These controls for routing synchronous exceptions to Hyp mode are similar to the controls for the traps
described in this section, and Summary of trap controls on page B1-1260 includes these trap controls.
— In addition, a hypervisor can route interrupts and asynchronous external aborts to itself. For more
information see Asynchronous exception routing controls on page B1-1174.
• Providing aliased versions of some system control registers, see Trapping ID mechanisms on page B1-1249.
Because of the wide range of usage models for virtualization, the Virtualization Extensions provide many trapping
options, support different levels of granularity of the trapping. The following sections describe these trapping
options:
• General information about traps to the hypervisor on page B1-1247.
• Trapping ID mechanisms on page B1-1249.
• Trapping accesses to lockdown, DMA, and TCM operations on page B1-1251.
• Trapping accesses to cache maintenance operations on page B1-1252.
• Trapping accesses to TLB maintenance operations on page B1-1252.
• Trapping accesses to the Auxiliary Control Register on page B1-1252.
• Trapping accesses to the Performance Monitors Extension on page B1-1253.
• Trapping use of the SMC instruction on page B1-1253.
• Trapping use of the WFI and WFE instructions on page B1-1253.
• Trapping accesses to Jazelle functionality on page B1-1254.
• Trapping accesses to the ThumbEE configuration registers on page B1-1254.
• Trapping accesses to coprocessors on page B1-1255.
• Trapping writes to virtual memory control registers on page B1-1256.
• Generic trapping of accesses to CP15 system control registers on page B1-1256.
• Trapping CP14 accesses to debug registers on page B1-1258.
• Trapping CP14 accesses to trace registers on page B1-1259.
• Summary of trap controls on page B1-1260.
Note
Many of these sections include a Note that indicates when or why a hypervisor might use the traps described in that
section. This information is not part of the architecture specification.
These sections include descriptions of trapping Debug configuration options that can generate traps when the
processor is in Non-debug state. The Virtualization Extensions do not provide any trapping in Debug state.
B1.14.1 General information about traps to the hypervisor

The Hyp Trap exception provides the standard mechanism for trapping Guest OS functions to the hypervisor. The
processor always takes a Hyp Trap exception to Hyp mode, and enters the exception handler using the vector at
offset 0x14 from the Hyp vector base address. For more information see Exception handling on page B1-1164.
When the processor enters the handler for a Hyp Trap exception, the HSR holds syndrome information for the
exception. For more information see Use of the HSR on page B3-1421.
A Hyp Trap exception can be generated only when all of the following apply:
• The processor is both:

— Not in Debug state.
— In a Non-secure PL1 or PL0 mode.
• The trapped instruction is not UNPREDICTABLE in the mode in which it is executed. UNPREDICTABLE
instructions can generate a Hyp Trap exception, but the architecture does not require them to do so, see
UNPREDICTABLE.
• The trapped instruction is not UNDEFINED in the mode in which it is executed, except for the following cases
in which an UNDEFINED instruction might cause a Hyp Trap exception:
— A trapped conditional UNDEFINED instruction that, if it was not trapped, would generate an Undefined
Instruction exception, see Hyp traps on instructions that fail their condition code check on
page B1-1248.
— A PL0 mode access to IMPLEMENTATION DEFINED CP15 features in primary CP15 register c9-c11, see
Trapping accesses to lockdown, DMA, and TCM operations on page B1-1251.
— A PL0 mode access to an IMPLEMENTATION DEFINED CP15 register for which there is a generic Hyp
trap, see Generic trapping of accesses to CP15 system control registers on page B1-1256.
— When HCR.TGE is set to 1, any instruction executed in a Non-secure PL1 or PL0 mode that generates
an Undefined Instruction exception, see Undefined Instruction exception, when HCR.TGE is set to 1
on page B1-1191.
Note
• These rules mean that, for traps on system control register accesses, unless the specific trap description states
otherwise:
— If the register description in this manual describes the register as not being accessible from User mode
in Non-secure state, the Virtualization Extensions do not change this behavior. User mode accesses to
the register cannot be trapped.
— If the register description in this manual describes the register as being accessible from User mode in
Non-secure state, when accesses to the register are trapped to Hyp mode the trap applies to accesses
from both Non-secure PL1 modes and from the Non-secure PL0 mode.
• Traps to Hyp mode never apply in Secure state, regardless of the value of the SCR.NS bit.
• Although a Hyp Trap exception cannot be generated when the processor is in Hyp mode, the HCPTR restricts
coprocessor accesses in Hyp mode, as well as in the Non-secure PL1 modes. If the HCPTR settings generate
an exception when the processor is in Hyp mode, that exception is taken using the Hyp mode Undefined
Instruction vector, not the Hyp Trap vector.
• PL0 mode is a synonym for User mode.
Many instructions that can be trapped by a Hyp trap are UNDEFINED in User mode. For these instructions, enabling
a Hyp trap on the instruction has no effect on operation in Non-secure User mode. A small number of traps also
apply to operations in Non-secure User mode. This means they trap operations at PL0 and at PL1.
Hyp traps on instructions that fail their condition code check

If the processor executes an instruction that has a Hyp trap set, and that instruction fails its condition code check,
unless the specific trap description states otherwise, it is IMPLEMENTATION DEFINED which of the following occurs:
• The instruction generates a Hyp Trap exception.
• The instruction executes as a NOP.
Note
The architecture requires that a Hyp trap on a conditional SMC instruction generates an exception only if the
instruction passes its condition code check, see Trapping use of the SMC instruction on page B1-1253.
This is consistent with the treatment of conditional undefined instructions, as described in Conditional execution of
undefined instructions on page B1-1208. Any implementation must be consistent in its handling of instructions that
fail their condition code check, meaning that whenever a Hyp trap it set on such an instruction it must either:
• Always generate a Hyp Trap exception.
• Always treat the instruction as a NOP.
This requirement that an implementation is consistent in its handling of instructions that fail their condition code
check also means that the IMPLEMENTATION DEFINED part of the requirements of Conditional execution of undefined
instructions on page B1-1208 must be consistent with the handling of Hyp traps on instructions that fail their
condition code check, as Table B1-25 shows:
Table B1-25 Consistent handling of instructions that fail their condition code check
Behavior of conditional UNDEFINED instruction a Hyp trap on instruction that fails its condition code check b
Executes as a NOP Executes as a NOP
Generates an Undefined Instruction exception Generates a Hyp Trap exception
a. As defined in Conditional execution of undefined instructions on page B1-1208. In Non-secure PL1 and PL0 modes, applies only if no
Hyp trap is set for the instruction, otherwise see the behavior in the other column of the table.
b. For a trapped instruction executed in a Non-secure PL1 or PL0 mode.
Hyp traps on instructions that are UNPREDICTABLE

For an instruction that is UNPREDICTABLE, but is in a class that has a Hyp trap, the behavior of the instruction when
the Hyp trap is enabled is UNPREDICTABLE. The architecture permits such an instruction to generate a Hyp Trap
exception, but does not require it to do so.
Note
UNPREDICTABLE behavior must not perform any function that cannot be performed at the current or lower level of
privilege using instructions that are not UNPREDICTABLE. This means that setting a Hyp trap on an instruction
changes the set of instructions that might be executed in Non-secure state at PL1 or PL0. This affects, indirectly, the
permitted behavior of UNPREDICTABLE instructions.
If no instructions are configured to generate Hyp traps, then the attempted execution of an UNPREDICTABLE
instruction in a Non-secure PL1 or PL0 mode cannot generate a Hyp Trap exception.
Hyp traps on instructions that are UNDEFINED

Except where explicitly stated in this manual, if an enabled Hyp trap is associated with an instruction that would
otherwise be UNDEFINED, attempting to execute that instruction from a Non-secure PL1 or PL0 mode generates an
Undefined Instruction exception, not a Hyp Trap exception.
Traps of register access instructions

When an attempt to execute an instruction is trapped to Hyp mode, the trap is taken before execution of the
instruction. This means that, if the trapped instruction is a register access instruction, before taking the Hyp Trap
exception:
• No register access is made.
• No side-effects normally associated with the register access occur.
B1.14.2 Trapping ID mechanisms
Note
The processor ID registers that can be accessed from Non-secure state can present a virtualization hole, since system
software can use them to determine information about the physical hardware that a hypervisor might want to
conceal. However, many uses of virtualization do not require the hypervisor to disguise the identity of the physical
processor.
For a small number of frequently-accessed ID registers, the Virtualization Extensions provide read/write aliases of
the registers, accessible only from Hyp mode, or from Secure state. A read of the original ID register from a
Non-secure PL1 mode actually returns the value of the read/write alias register. This register substitution is invisible
to the software reading the register.
Table B1-26 ID register substitution by the Virtualization Extensions
Physical ID register RW alias register
MIDR VPIDR
MPIDR VMPIDR
A reset sets VPIDR to the MIDR value, and VMPIDR to the MPIDR value.
Reads of MIDR or MPIDR from Hyp mode or from Secure state are unchanged by the Virtualization Extensions,
and access the physical registers. This also applies to accesses from Monitor mode with SCR.NS set to 1.
Note
A hypervisor often has to virtualize one or both of the MIDR and MPIDR because:
• The MIDR provides information about the implementer, the processor name, and revision information.
• In a multiprocessor implementation, the MPIDR defines the processor position within a cluster.
The Virtualization Extensions divide the remaining ID registers into a number of groups, and provide a bit for each
group in the HCR, to control trapping of accesses to that group of registers. Setting one of these HCR bits to 1 means
that any attempt to read a register in that group or, for the CSSELR register, attempts to write that register if it is in
that group from a Non-secure mode other than Hyp mode generates a Hyp Trap exception, unless the register
description indicates that the attempted access is UNDEFINED. This trap has no effect on writes to these registers other
than the case of the CSSELR.
Note
Most but not all of the ID registers are RO registers, and write accesses to these registers behave as described in
Read-only and write-only register encodings on page B3-1445. Each register description identifies whether the
register is RO.
Table B1-27 shows the HCR trap bits, and references the subsections that define the registers in each group. Each
group description also indicates how the trap is reported to the exception handler.
Table B1-27 ID register groups for Hyp Trap exceptions
Trap bit Register group definition
HCR.TID0 ID group 0, Primary device identification registers
HCR.TID1 ID group 1, Implementation identification registers
HCR.TID2 ID group 2, Cache identification registers
HCR.TID3 ID group 3, Detailed feature identification registers on page B1-1251
ID group 0, Primary device identification registers
Note
With MIDR and MPIDR, these registers provide the coarse-grained identification mechanisms that software is
likely to access.
The registers that are in ID group 0 for Hyp traps are the FPSID register and the JIDR.
When an exception is taken because HCR.TID0 is set to 1, the HSR reports the exception:
• Using EC value 0x05, trapped CP14 access, for a read of JIDR.
• Using EC value 0x08, trapped CP10 access, for a read of FPSID.
If the HCPTR traps accesses to CP10 and CP11, then for a read of FPSID that trap has priority over the ID group 0
trap. For more information, see Trapping accesses to coprocessors on page B1-1255.
ID group 1, Implementation identification registers
Note
In ARMv7, these registers often provide coarse-grained identification mechanisms for implementation-specific
features.
The registers that are in ID group 1 for Hyp traps are the TCMTR, TLBTR, REVIDR, and AIDR.
When an exception is taken because HCR.TID1 is set to 1, the HSR reports the exception as a trapped CP15 access,
using the EC value 0x03, see Use of the HSR on page B3-1421.
ID group 2, Cache identification registers
Note
These are the registers that describe and control the cache implementation.
The registers that are in ID group 2 for Hyp traps are the CTR, CCSIDR, CLIDR, and CSSELR.
When an exception is taken because HCR.TID2 is set to 1, the HSR reports the exception as a trapped CP15 access,
ID group 3, Detailed feature identification registers
Note
These are the CPUID registers, that provide detailed information about the features of the processor
implementation. In many implementations of virtualization the hypervisor will not trap accesses to registers in this
group. The architecture only requires this trap to apply to the registers listed in this section. There is no requirement
for the trap to apply to the registers that Chapter B7 The CPUID Identification Scheme defines as reserved.
The registers that are in ID group 3 for Hyp traps are the ID_PFR0, ID_PFR1, ID_DFR0, ID_AFR0, ID_MMFR0,
ID_MMFR1, ID_MMFR2, ID_MMFR3, ID_ISAR0, ID_ISAR1, ID_ISAR2, ID_ISAR3, ID_ISAR4, ID_ISAR5,
MVFR0, and MVFR1.
When an exception is taken because HCR.TID3 is set to 1, the HSR reports the exception:
• Using EC value 0x08, trapped CP10 access, for a read of MVFR0 or MVFR1.
• Using EC value 0x03, trapped CP15 access, for a read of any other register in the group.
If the HCPTR traps accesses to CP10 and CP11, then for reads of MVFR0 and MVFR1, that trap has priority over
the ID group 3 trap. For more information, see Trapping accesses to coprocessors on page B1-1255.
B1.14.3 Trapping accesses to lockdown, DMA, and TCM operations

The lockdown, DMA, and TCM features of the ARM architecture are IMPLEMENTATION DEFINED. However, the
architecture reserves the following CP 15 register encodings for control of these features:
• CRn==c9, opc1=={0-7}, CRm=={c0-c2, c5-c8}, opc2=={0-7}, see Cache and TCM lockdown registers,
VMSA on page B4-1745.
• CRn==c10, opc1=={0-7}, CRm=={c0, c1, c4, c8}, opc2=={0-7}, see VMSA CP15 c10 register summary,
memory remapping and TLB control registers on page B3-1473.
• CRn==c11, opc1=={0-7}, CRm=={c0-c8, c15}, opc2=={0-7}, see VMSA CP15 c11 register summary,
reserved for TCM DMA registers on page B3-1473.
Setting HCR.TIDCP to 1 means:
• Any attempt to use an MCR or MRC instruction with one of these encodings from a Non-secure PL1 mode
generates a Hyp Trap exception.
• On an attempt to use an MCR or MRC instruction with one of these encodings from Non-secure PL0 mode, it is
IMPLEMENTATION DEFINED which of the following occurs:
— The processor takes the Hyp Trap exception.

— The processor treats the instruction as UNDEFINED, and takes the Undefined Instruction exception to
Non-secure Undefined mode.
• Any lockdown fault in the memory system caused by the use of these operations in Non-secure state
generates a Data Abort exception that is taken to Hyp mode.
An implementation can include IMPLEMENTATION DEFINED registers that provide additional controls, to give
finer-grained control of the trapping of IMPLEMENTATION DEFINED features.
When an exception is taken because HCR.TIDCP is set to 1, the HSR reports the exception as a trapped CP15
access, using the EC value 0x03, see Use of the HSR on page B3-1421.
Note
• ARM expects the trapping of Non-secure User mode access to these functions to Hyp mode to be unusual,
and used only when the hypervisor is virtualizing User mode operation. ARM strongly recommends that,
unless the hypervisor must virtualize User mode operation, a Non-secure User mode access to any of these
functions generates an Undefined Instruction exception, as it would if the implementation did not include the
Virtualization Extensions. The processor then takes this exception to Non-secure Undefined mode.
• The trapping of all attempted accesses to these registers from Non-secure PL1 modes overrides the general
behavior described in Hyp traps on instructions that are UNDEFINED on page B1-1248.
B1.14.4 Trapping accesses to cache maintenance operations
Note
Virtualizing a uniprocessor system within an MP system, permitting a virtual machine to move between different
physical processors, makes cache maintenance by set/way difficult. This is because a set/way operation might be
interrupted part way through its operation, and therefore the hypervisor must reproduce the effect of the
maintenance on both physical processors
Table B1-28 shows the HCR trap bits that trap cache maintenance operations to the hypervisor. When one of these
bits is set to 1, any attempt to access one of the corresponding CP15 c7 operations from a Non-secure PL1 mode
generates a Hyp Trap exception.
Table B1-28 Control of Hyp traps for cache maintenance operations
Trap bit Traps Trapped operations
HCR.TSW Data cache maintenance by set/way DCISW, DCCSW, DCCISW
HCR.TPC Data cache maintenance to point of coherency DCIMVAC, DCCIMVAC, DCCMVAC
HCR.TPU Cache maintenance to point of unification ICIMVAU, ICIALLU, ICIALLUIS, DCCMVAU
For any of these traps, when the exception is taken, the HSR reports the exception as a trapped CP15 access, using
the EC value 0x03, see Use of the HSR on page B3-1421.
For more information about these operations, see Cache and branch predictor maintenance operations, VMSA on
page B4-1735.
B1.14.5 Trapping accesses to TLB maintenance operations

Setting HCR.TTLB to 1 means that any attempt to access one of the CP15 c8 maintenance operations from a
Non-secure PL1 mode generates a Hyp Trap exception. The trapped operations are TLBIALLIS, TLBIMVAIS,
TLBIASIDIS, TLBIMVAAIS, DTLBIALL, ITLBIALL, TLBIALL, DTLBIMVA, ITLBIMVA, TLBIMVA,
DTLBIASID, ITLBIASID, TLBIASID, TLBIMVAA.
When an exception is taken because HCR.TTLB is set to 1, the HSR reports the exception as a trapped CP15 access,
For more information about these operations, see TLB maintenance operations, not in Hyp mode on page B4-1738.
B1.14.6 Trapping accesses to the Auxiliary Control Register
Note
The ACTLR is an IMPLEMENTATION DEFINED register that might implement global control bits for the processor.
An attempt by a Guest OS to access the ACTLR is a potential virtualization problem. Trapping these accesses to the
hypervisor means the hypervisor can react, typically by emulating the required function or signaling a virtualization
error.
Setting HCR.TAC to 1 means that any attempt to access the ACTLR from Non-secure PL1 generates a Hyp Trap
exception.
When an exception is taken because HCR.TAC is set to 1, the HSR reports the exception as a trapped CP15 access,
B1.14.7 Trapping accesses to the Performance Monitors Extension
Note
A hypervisor might assign Performance Monitors functionality to a particular Guest OS, or might virtualize
performance monitoring. The Virtualization Extensions provide a trap bit that, when set to 1, traps all CP15 accesses
to the Performance Monitors to the Hyp Trap exception. A hypervisor might use this as part of a lazy context switch
that assigns the Performance Monitors to a particular Guest OS, or might use it as part of a virtualization approach.
A second trap bit traps accesses to the PMCR. The hypervisor can use this in emulating the Performance Monitors
identification bits.
The Performance Monitors Extension is an OPTIONAL extension to an ARMv7 implementation. The processor
accesses the Performance Monitors Extension registers through the CP15 c9 registers with opc1 == {0-7},
CRm == {c12-c15}, opc2 == {0-7}.
In an implementation that includes the Performance Monitors Extension:
• Setting HDCR.TPM to 1 traps accesses to the Performance Monitors Extension registers to Hyp mode. When
this bit is set to 1, any attempt to access these registers from a Non-secure PL1 or PL0 mode generates a Hyp
Trap exception, unless the register description in Performance Monitors registers on page C12-2314
indicates that the attempted access is UNDEFINED.
• Setting HDCR.TPMCR to 1 traps CP15 accesses to the PMCR to Hyp mode. The conditions for this trap are
identical to those for the trap controlled by HDCR.TPM.
For either of these traps, when the exception is taken, the HSR reports the exception as a trapped CP15 access, using
the EC value 0x03, see Use of the HSR on page B3-1421.
B1.14.8 Trapping use of the SMC instruction
Note
Typically, a hypervisor determines whether a Guest OS can access Secure state directly. If the hypervisor does not
permit a particular Guest OS to access Secure state directly, and that Guest OS attempts to change to Secure state,
then the hypervisor must either report a virtualization error or emulate the required Secure state operation. To
support this, the HCR includes a bit that traps use of the SMC instruction to the Hyp Trap exception.
When HCR.TSC is set to 1, an attempt to execute an SMC instruction from a Non-secure PL1 mode generates a Hyp
Trap exception, regardless of the value of SCR.SCD.
Note
When HCR.TSC is set to 0, SCR.SCD controls whether SMC instructions can be executed from Non-secure state:
• When SCR.SCD is set to 0, the SMC instruction executes normally in Non-secure state.
• When SCR.SCD is set to 1, the SMC instruction is UNDEFINED in Non-secure state.
The HCR.TSC trap mechanism traps the attempted execution of a conditional SMC instruction only if the instruction
When an exception is taken because HCR.TSC is set to 1, the HSR reports the exception as a trapped SMC instruction,
B1.14.9 Trapping use of the WFI and WFE instructions
Note
An operating system can use the WFI mechanism to signal to the processor that it can suspend operation until it
receives an interrupt. In a virtualized system, the hypervisor might use this signal as an indication that it can switch
to another Guest OS. Therefore, the HCR includes a bit that traps attempted execution of a WFI instruction to the
Hyp Trap exception.
Software can use the WFE mechanism to signal to the processor that it can suspend execution during polling of a
variable, such as a spinlock. In a virtualized system, WFE might indicate an opportunity for the hypervisor to
reschedule. However, WFE generally requires a shorter wait than WFI, and therefore there might be situations
where rescheduling on WFE is not appropriate.
For this reason, the HCR includes separate bits for trapping WFI and WFE to the Hyp Trap exception.
When HCR.TWI is set to 1, and the processor is in a Non-secure mode other than Hyp mode, execution of a WFI
instruction generates a Hyp Trap exception if, ignoring the value of the HCR.TWI bit, conditions permit the
processor to suspend execution. For more information about when a WFI instruction can cause the processor to
suspend execution, see Wait For Interrupt on page B1-1202.
When HCR.TWE is set to 1, and the processor is in a Non-secure mode other than Hyp mode, execution of a WFE
instruction generates a Hyp Trap exception if, ignoring the value of the HCR.TWE bit, conditions permit the
processor to suspend execution. For more information about when a WFE instruction can cause the processor to
suspend execution, see Wait For Event and Send Event on page B1-1199.
For either of these traps, when the exception is taken, the HSR reports the exception as a trapped WFI or WFE
instruction, using the EC value 0x01, see Use of the HSR on page B3-1421.
B1.14.10 Trapping accesses to Jazelle functionality

Setting HSTR.TJDBX to 1 means that, when the processor is in a Non-secure mode other than Hyp mode, the
following generate a Hyp Trap exception:
• Any access to the JOSCR, JMCR, or a Jazelle SUBARCHITECTURE DEFINED configuration register, that this
reference manual or the Jazelle subarchitecture description does not describe as UNDEFINED.
• Any attempt to execute a BXJ instruction.
Note
• An implementation that includes the Virtualization Extensions must include only a trivial Jazelle
implementation. These traps apply to the trivial Jazelle implementation.
• The HSTR.TJDBX trap does not trap accesses to the JIDR. See, instead, ID group 0, Primary device
identification registers on page B1-1250.
When an exception is taken because HSTR.TJDBX is set to 1, the HSR reports the exception as:
• A trapped CP14 access, using EC value 0x05, for an access to a Jazelle register.
• A trapped BXJ instruction, using EC value 0x0A, for execution of a BXJ instruction.
B1.14.11 Trapping accesses to the ThumbEE configuration registers

Setting HSTR.TTEE to 1 means that, when the processor is in a Non-secure mode other than Hyp mode, any access
to the ThumbEE configuration registers TEECR and TEEHBR that this reference manual does not describe as
UNDEFINED, generates a Hyp Trap exception.
When an exception is taken because HSTR.TTEE is set to 1, the HSR reports the exception as a trapped CP14
B1.14.12 Trapping accesses to coprocessors
Note
• A hypervisor might use the coprocessor access trapping mechanism as part of an implementation of lazy
switching of Guest OSs.
• One function of the CPACR is as an ID register that identifies what coprocessor functionality is implemented.
A hypervisor can trap CPACR accesses, to emulate this ID mechanism.
The HCPTR provides bits that trap coprocessor operations, to coprocessors other than CP14 and CP15, to Hyp
mode. The traps controlled by the HCPTR apply regardless of whether the processor is in Debug state.
As described in Access controls on CP0 to CP13 on page B1-1226, the HCPTR traps are secondary to the controls
provided by the CPACR and NSACR. Only if those controls permit a Non-secure access to a coprocessor can the
HCPTR setting trap that access to Hyp mode.
If the NSACR.cpn control bit is set to 1, prohibiting Non-secure accesses to coprocessor n, then:
• Non-secure accesses to the coprocessor behave as if HCPTR.TCPn is set to1, regardless of the value of that
bit.
• Non-secure writes to the corresponding HCPTR.TCPn bit are ignored.
• Non-secure reads of HCPTR.TCPn return 1, regardless of the actual value of that bit.
In addition, for the HCPTR traps on coprocessor accesses, and on the use of Advanced SIMD functionality, if a trap
bit is set to 1, an attempt to access the trapped functionality from Hyp mode generates an Undefined Instruction
exception, that is taken to Hyp mode.
The following subsections give more information about the HCPTR traps:
• Trapping of Advanced SIMD functionality.
• General trapping of coprocessor accesses on page B1-1256.
• Trapping CPACR accesses on page B1-1256.
Trapping CP14 accesses to trace registers on page B1-1259 describes an additional HCPTR trap.
Trapping of Advanced SIMD functionality

When the settings in the CPACR and NSACR permit Non-secure accesses to Advanced SIMD functionality, and
HCPTR.{TCP10, TCP11} are set to 0, if HCPTR.TASE is set to 1, execution of any Advanced SIMD instruction:
• From a Non-secure mode other than Hyp mode generates a Hyp Trap exception.
Note
If the CPACR.ASEDIS is set to 1, the CPACR.ASEDIS setting takes priority. This means any execution of
an Advanced SIMD instruction by Non-secure software executing at PL1 or PL0 generates an Undefined
Instruction exception, taken to Non-secure Undefined mode, and is not trapped to Hyp mode.
• From Hyp mode generates an Undefined Instruction exception, taken to Hyp mode, with the HSR holding a
syndrome for the instruction.
Note
When HCPTR.TASE is set to 0, if the NSACR settings permit Non-secure use of the Advanced SIMD
functionality then Hyp mode can access that functionality, regardless of any settings in the CPACR.
When an exception is taken because HCPTR.TASE is set to 1, the HSR reports the exception as a HCPTR-trapped
coprocessor access, using the EC value 0x07, see Use of the HSR on page B3-1421.
General trapping of coprocessor accesses

The HCPTR defines a set of trap bits, TCP0 to TCP13, for trapping accesses to coprocessors CP0 to CP13. Setting
HCPTR.TCPn to1 means that an access to coprocessor CPn that is otherwise permitted:
• From a Non-secure mode other than Hyp mode, generates a Hyp Trap exception.
Note
If the CPACR.cpn field does not permit the PL1 or PL0 access, then the CPACR.cpn setting takes priority.
This means the access generates an Undefined Instruction exception, taken to Non-secure Undefined mode,
and is not trapped to Hyp mode.
• From Hyp mode, generates an Undefined Instruction exception, taken to Hyp mode, with the HSR holding a
syndrome for the instruction.
Note
When HCPTR.TCPn is set to 0, if the NSACR settings permit Non-secure use of coprocessor CPn then Hyp
mode can access that coprocessor, regardless of any settings in the CPACR.
When an exception is taken because an HCPTR.TCPn bit is set to 1, the HSR reports the exception as a
HCPTR-trapped coprocessor access, using the EC value 0x07, see Use of the HSR on page B3-1421.
Trapping CPACR accesses

When HCPTR.TCPAC is set to 1, any access to CPACR from a Non-secure PL1 mode generates a Hyp Trap
exception.
When an exception is taken because HCPTR.TCPAC is set to 1, the HSR reports the exception as a trapped CP15
B1.14.13 Trapping writes to virtual memory control registers
Note
The Virtualization Extensions provide a second stage of address translation, that a hypervisor can use to remap the
address map defined by a Guest OS. In addition, a hypervisor can trap attempts by the Guest OS to write to the
registers that control the Non-secure memory system. A hypervisor might use this trap as part of its virtualization
of memory management.
Setting HCR.TVM to 1 means that any attempt, to write to a Non-secure memory control register from a Non-secure
PL1 or PL0 mode, that this reference manual does not describe as UNDEFINED, generates a Hyp Trap exception. This
trap applies to accesses to the SCTLR, TTBR0, TTBR1, TTBCR, DACR, DFSR, IFSR, DFAR, IFAR, AxFSRs,
PRRR, NMRR, MAIRs, and the CONTEXTIDR.
When an exception is taken because HCR.TVM is set to 1, the HSR reports the exception:
• As a trapped MCR or MRC CP15 access, using the EC value 0x03, if the access is to a 32-bit register.
• As a trapped MCRR or MRRC CP15 access, using the EC value 0x04, if the access is to a 64-bit register.
B1.14.14 Generic trapping of accesses to CP15 system control registers
Note
• Many of the hypervisor traps described in the section Traps to the hypervisor on page B1-1246 trap specific
CP15 system control register operations to Hyp mode. However, because of the large number of possible
usage models for virtualization, the traps on specific functions might not meet all possible requirements.
Therefore, the Virtualization Extensions also provide a set of generic traps for trapping CP15 accesses to Hyp
mode, as described in this subsection.
• ARM expects that trapping of Non-secure User mode accesses to CP15 to Hyp mode will be unusual, and
used only when the hypervisor must virtualize User mode operation. ARM recommends that, whenever
possible, Non-secure User mode accesses to CP15 behave as they would if the processor did not implement
the Virtualization Extensions, generating an Undefined Instruction exception taken to Non-secure Undefined
mode if the architecture does not support the User mode access.
The HSTR provides trap bits {T0-T3, T5-T13, T15}, for trapping accesses to each implemented primary CP15
register, {c0-c3, c5-c13, c15}. When a trap bit is set to 0, it has no effect on accesses to the CP15 registers. When a
trap bit is set to 1, the trap applies as follows:
• In MCR and MRC instructions, CRn specifies the primary CP15 register. The trap applies if the value of CRn
corresponds to the trapped primary CP15 register.
• In MCRR and MRRC instructions, CRm specifies the primary CP15 register. The trap applies if the value of CRm
corresponds to the trapped primary CP15 register.
For a trapped primary CP15 register:
• Any MCR, MRC, MCRR, or MRRC access from a Non-secure PL1 mode, generates a Hyp Trap exception.
• Any MCR, MRC, MCRR, or MRRC access from Non-secure User mode:
— Generates a Hyp Trap exception if the access would not be UNDEFINED if the corresponding trap bit
was set to 0.
— Otherwise, generates an Undefined Instruction exception, taken to Non-secure Undefined mode.
If it is IMPLEMENTATION DEFINED whether, when the corresponding trap bit is set to 0, an access from
Non-secure User mode is UNDEFINED, then, when the corresponding trap bit is set to 1, it is IMPLEMENTATION
DEFINED whether an access from Non-secure User mode generates:
— A Hyp trap exception.
— An Undefined Instruction exception, taken to Non-secure Undefined mode.
This behavior is an exception to the general trapping behavior described in Hyp traps on instructions that are
UNDEFINED on page B1-1248.
Note
• The definition of this trap means that, when HSTR.Tx is set to 1, the trap applies to accesses from Non-secure
PL1 or PL0 modes:
— Using an MCR or MRC instruction with CRn set to x.
— Using an MCRR or MRRC instruction with CRm set to x.
• An implementation might provide additional controls, in IMPLEMENTATION DEFINED registers, to provide

finer-grained control of control of trapping of IMPLEMENTATION DEFINED features.
• HSTR bit[14] is reserved, UNK/SBZP regardless of whether the implementation includes the Generic Timer,
that has its control registers in CP15 c14. The HSTR does not provide a trap on accesses to the Generic Timer
CP15 registers.
For example, when HSTR.T7 is set to 1:
• Any 32-bit CP15 access from a Non-secure PL1 mode, using an MRC or MCR instruction with CRn set to c7, is
trapped to Hyp mode.
• Any 64-bit CP15 access from a Non-secure PL1 mode, using an MRRC or MCRR instructions with CRm set to c7,
is trapped to Hyp mode.
When an exception is taken because an HSTR.Tn bit is set to 1, the HSR reports the exception:
• As a trapped MCR or MRC CP15 access, using the EC value 0x03, if the access uses an MCR or MRC instruction.
• As a trapped MCRR or MRRC CP15 access, using the EC value 0x04, if the access uses an MCRR or MRRC instruction.
B1.14.15 Trapping CP14 accesses to debug registers

Bits in HDCR control the trapping of Non-secure CP14 accesses to Hyp mode. When a HDCR control bit is set to 1,
and the processor is executing in a Non-secure mode other than Hyp mode and is in Non-debug state, any access to
an associated debug register through the CP14 interface generates a Hyp Trap exception.
CP14 register accesses can have side-effects. When a CP14 register access is trapped to Hyp mode, no side-effects
occur before the exception is taken, see Traps of register access instructions on page B1-1249.
For more information about the reporting of the exceptions see Use of the HSR on page B3-1421.
The following sections summarize the HDCR control bits, the associated debug registers, and the HSR reporting of
the Hyp Trap exception:
• Trapping CP14 accesses to Debug ROM registers.
• Trapping CP14 accesses to OS-related debug registers.
• Trapping general CP14 accesses to debug registers.
• Permitted combinations of HDCR.{TDRA, TDOSA, TDA, TDE} bits on page B1-1259.
Trapping CP14 accesses to Debug ROM registers

When HDCR.TDRA is set to 1, if the processor is executing in a Non-secure mode other than Hyp mode, and is in
Non-debug state, any CP14 access to DBGDRAR or DBGDSAR generates a Hyp Trap exception.
If HDCR.TDE is set to 1, or HDCR.TDA is set to 1, HDCR.TDRA must be set to 1, otherwise behavior is

UNPREDICTABLE. For more information about HDCR.TDE, see Routing Debug exceptions to Hyp mode on
page B1-1193.
The HSR reports the exception as a trapped MCR or MRC access to CP14, using the EC value 0x05.
Trapping CP14 accesses to OS-related debug registers

When HDCR.TDOSA is set to 1, if the processor is executing in a Non-secure mode other than Hyp mode, and is
in Non-debug state, any CP14 access to an OS-related debug register generates a Hyp Trap exception.
If HDCR.TDE is set to 1, or HDCR.TDA is set to 1, HDCR.TDOSA must be set to 1, otherwise behavior is

UNPREDICTABLE. For more information about HDCR.TDE, see Routing Debug exceptions to Hyp mode on
page B1-1193.
The OS-related debug registers are:
• DBGOSLSR, DBGOSLAR, DBGOSDLR, and DBGPRCR.
• Any IMPLEMENTATION DEFINED integration registers, including DBGITCTRL.
• Any IMPLEMENTATION DEFINED register with similar functionality, that the implementation specifies is
trapped by HDCR.TDOSA.
Depending on the instruction used for the attempted register access, the HSR reports the exception:
• For an access to a 32-bit CP14 register, as a trapped MCR or MRC access to CP14, using the EC value 0x05.
• For an access to a 64-bit register, as a trapped MRRC access to CP14, using the EC value 0x0C.
Trapping general CP14 accesses to debug registers

When HDCR.TDA is set to 1, if the processor is executing in a Non-secure mode other than Hyp mode, and is in
Non-debug state, any CP14 access to a Debug register generates a Hyp Trap exception, except for:
• Any access that this reference manual describes as UNPREDICTABLE or as causing an Undefined Instruction
exception. Accesses described as UNPREDICTABLE can generate a Hyp Trap exception, but the architecture
does not require them to do so, see UNPREDICTABLE.
• Any access to DBGDRAR or DBGDSAR. For more information about trapping accesses to these registers
see Trapping CP14 accesses to Debug ROM registers.
• Any access to an OS-related debug register. For a list of these registers, and more information about trapping
accesses to them, see Trapping CP14 accesses to OS-related debug registers on page B1-1258.
Accesses trapped to Hyp mode by setting HDCR.TDA to 1 include STC accesses to DBGDTRRXint, and LDC
accesses to DBGDTRTXint.
When HDCR.TDA is set to 1, both of HDCR.{TDRA, TDOSA} must be set to 1, otherwise behavior is
UNPREDICTABLE.
If HDCR.TDE is set to 1, HDCR.TDA must be set to 1, otherwise behavior is UNPREDICTABLE. For more
information about HDCR.TDE, see Routing Debug exceptions to Hyp mode on page B1-1193.
Depending on the instruction used for the attempted register access, the HSR reports the exception:
• As a trapped MCR or MRC access to CP14, using the EC value 0x05.
• As a trapped LDC or STC access to CP14, using the EC value 0x06.
Permitted combinations of HDCR.{TDRA, TDOSA, TDA, TDE} bits

The permitted values of the HDCR.{TDRA, TDOSA, TDA, TDE} bits are 0b0000, 0b0100, 0b1000, 0b1100, 0b1110,
and 0b1111. If these bits are set to any other values, behavior is UNPREDICTABLE.
B1.14.16 Trapping CP14 accesses to trace registers

When HCPTR.TTA is set to 1, any access to a CP14 Trace register through the CP14 interface, except for accesses
that the appropriate Trace Architecture Specification describes as UNPREDICTABLE or as causing an Undefined
Instruction exception:
• If made from a Non-secure PL1 or PL0 mode, generates a Hyp Trap exception.
• If made from Hyp mode, generates an Undefined Instruction exception, taken to Hyp mode, with the HSR
holding a syndrome for the instruction.
Note
Accesses described as UNPREDICTABLE can generate a Hyp Trap or Undefined Instruction exception, but the
architecture does not require them to do so. See UNPREDICTABLE.
CP14 register accesses can have side-effects. When a CP14 register access is trapped to Hyp mode, or generates an
Undefined Instruction exception, because of the value of HCPTR.TTA, no side-effects occur before the exception
is taken, see Traps of register access instructions on page B1-1249.
When the processor is in Debug state, these register accesses do not generate Hyp Trap exceptions, regardless of the
value of HCPTR.TTA.
Trapping accesses to coprocessors on page B1-1255 describes other traps controlled by HCPTR.
When a Hyp Trap exception is generated because HCPTR.TTA is set to 1, the HSR reports the exception as a
trapped MCR or MRC access to CP14, using the EC value 0x05. For more information see Use of the HSR on
page B3-1421.
B1.14.17 Summary of trap controls

Table B1-29 summarizes the hypervisor trap controls, and the associated trap bits. To provide a single summary of
all the controls that can cause entry to Hyp mode, it also includes the exception routing controls described in Routing
general exceptions to Hyp mode on page B1-1190 and Routing Debug exceptions to Hyp mode on page B1-1193.
Table B1-29 Summary of Hyp trap controls
Trap description Controlled by
Trapping ID mechanisms on page B1-1249 HCR.{TID0, TID1, TID2, TID3}
Trapping accesses to lockdown, DMA, and TCM operations on page B1-1251 HCR.TIDCP
Trapping accesses to cache maintenance operations on page B1-1252 HCR.{TSW, TPC, TPU}
Trapping accesses to TLB maintenance operations on page B1-1252 HCR.TTLB
Trapping accesses to the Auxiliary Control Register on page B1-1252 HCR.TAC
Trapping accesses to the Performance Monitors Extension on page B1-1253 HDCR.{TPM, TPMCR}
Trapping use of the SMC instruction on page B1-1253 HCR.TSC
Trapping use of the WFI and WFE instructions on page B1-1253 HCR.{TWI, TWE}
Trapping accesses to Jazelle functionality on page B1-1254 HSTR.TJDBX
Trapping accesses to the ThumbEE configuration registers on page B1-1254 HSTR.TTEE
Trapping of Advanced SIMD functionality on page B1-1255 HCPTR.TASE
General trapping of coprocessor accesses on page B1-1256 HCPTR.{TCP0-TCP13}
Trapping CPACR accesses on page B1-1256 HCPTR.TCPAC
Trapping writes to virtual memory control registers on page B1-1256 HCR.TVM
Generic trapping of accesses to CP15 system control registers on page B1-1256 HSTR.{T0-T3, T5-T13, T15}
Trapping CP14 accesses to Debug ROM registers on page B1-1258 HDCR.TDRA
Trapping CP14 accesses to OS-related debug registers on page B1-1258 HDCR.TDOSA
Trapping general CP14 accesses to debug registers on page B1-1258 HDCR.TDA
Trapping CP14 accesses to trace registers on page B1-1259 HCPTR.TTA
Routing general exceptions to Hyp mode on page B1-1190 HCR.TGE
Routing Debug exceptions to Hyp mode on page B1-1193 HDCR.TDE
Chapter B2
Common Memory System Architecture Features
This chapter provides a system level view of the general features of the memory system. It contains the following
sections:
• About the memory system architecture on page B2-1262.
• Caches and branch predictors on page B2-1264.
• IMPLEMENTATION DEFINED memory system features on page B2-1290.
• Pseudocode details of general memory system operations on page B2-1291.
B2 Common Memory System Architecture Features
B2.1 About the memory system architecture

The ARM architecture supports different implementation choices for the memory system microarchitecture and
memory hierarchy, depending on the requirements of the system being implemented. In this respect, the memory
system architecture describes a design space in which an implementation is made. The architecture does not
prescribe a particular form for the memory systems. Key concepts are abstracted in a way that permits
implementation choices to be made while enabling the development of common software routines that do not have
to be specific to a particular microarchitectural form of the memory system. For more information about the concept
of a hierarchical memory system, see Memory hierarchy on page A3-153.
B2.1.1 Form of the memory system architecture

ARMv7 supports different forms of the memory system architecture, that map onto the different architecture
profiles. Two of these are described in this manual:
• ARMv7-A, the A profile, requires the inclusion of a Virtual Memory System Architecture (VMSA), as
described in Chapter B3 Virtual Memory System Architecture (VMSA).
• ARMv7-R, the R profile, requires the inclusion of a Protected Memory System Architecture (PMSA), as
described in Chapter B5 Protected Memory System Architecture (PMSA).
Both of these memory system architectures provide mechanisms to split memory into different regions. Each region
has specific memory types and attributes. The two memory system architectures have different capabilities and
programmers’ models.
The memory system architecture model required by ARMv7-M, the M profile, is outside the scope of this manual.
It is described in the ARMv7-M Architecture Reference Manual.
B2.1.2 Memory attributes

Summary of ARMv7 memory attributes on page A3-124 summarizes the memory attributes, including how different
memory types have different attributes. Each region of memory has a set of memory attributes:
• In a VMSA implementation, the translation tables define the virtual memory regions, and the attributes for
each region.
Note
Depending on its translation regime, an access is subject to one or two stages of translation. For an access
that requires two stages of translation, the attributes from each stage of translation are combined to obtain the
final region attribute. About the VMSA on page B3-1306 defines the translation regimes.
For more information, see Translation tables on page B3-1316.
• In a PMSA implementation the attributes are part of each MPU memory region definition, see Memory region
Cacheability and cache allocation hint attributes

As described in Summary of ARMv7 memory attributes on page A3-124, the ARMv7 memory attributes include
cacheability and cache allocation hint attributes. In most implementations, these are combined into a single attribute,
that is one of:
• Non-cacheable.
• Write-Through Cacheable.
• Write-Back Write-Allocate Cacheable.
• Write-Back no Write-Allocate Cacheable.
The exception to this is an ARMv7-A implementation that includes the Large Physical Address Extension and is
using the Long-descriptor translation table format. In this case, the translation table entry for any Cacheable region
assigns that region both a Read-Allocate and a Write-Allocate hint. Each hint is either Allocate or Do not allocate.
For more information, see Long-descriptor format memory region attributes on page B3-1368.
Note
A Cacheable region with both no Read-Allocate and no Write-Allocate hints is not the same as a Non-cacheable
region. A Non-cacheable region has coherency guarantees for observers outside its Shareability domains, that do
not apply for a region that is Cacheable, no Read-Allocate, no Write-Allocate.
The architecture does not require an implementation to make any use of cache allocation hints. This means an
implementation might not make any distinction between memory regions with attributes that differ only in their
cache allocation hint.
B2.1.3 Levels of cache

In ARMv7, the architecturally-defined cache control mechanism covers multiple levels of cache, as described in
Caches and branch predictors on page B2-1264. Also, it permits levels of cache beyond the scope of these cache
control mechanisms, see System level caches on page B2-1288.
Note
Before ARMv7, the architecturally-defined cache control mechanism covers only a single level of cache, and any
support for other levels of cache is IMPLEMENTATION DEFINED.
B2.2 Caches and branch predictors

The concept of caches is described in Caches and memory hierarchy on page A3-153. This section describes the
ARMv7 cache identification and control mechanisms, and the cache maintenance operations, in the following
sections:
• Cache identification.
• Cache behavior on page B2-1265.
• Cache enabling and disabling on page B2-1268.
• Branch predictors on page B2-1270.
• Multiprocessor considerations for cache and similar maintenance operations on page B2-1271.
• About ARMv7 cache and branch predictor maintenance functionality on page B2-1272.
• Cache and branch predictor maintenance operations on page B2-1276.
• The interaction of cache lockdown with cache maintenance operations on page B2-1286.
• Ordering of cache and branch predictor maintenance operations on page B2-1287.
• System level caches on page B2-1288.
Note
• Branch predictors typically use a form of cache to hold branch target data. Therefore, they are included in
this section.
• The following sections describe the cache identification and control mechanisms in previous versions of the
ARM architecture:
— Cache support on page D12-2504, for ARMv6.
— Cache support on page D15-2590, for the ARMv4 and ARMv5 architectures.
B2.2.1 Cache identification

The ARMv7 cache identification consists of a set of registers that describe the implemented caches that are under
the control of the processor:
• A single Cache Type Register defines:

— The minimum line length of any of the instruction caches.
— The minimum line length of any of the data or unified caches.
— The cache indexing and tagging policy of the Level 1 instruction cache.
— CTR, Cache Type Register, VMSA on page B4-1552, for a VMSA implementation.
— CTR, Cache Type Register, PMSA on page B6-1827, for a PMSA implementation.
• A single Cache Level ID Register defines:

— The type of cache implemented at a each cache level, up to the maximum of seven levels.
— The Level of Coherence (LoC) for the caches.
— The Level of Unification (LoU) for the caches.
— CLIDR, Cache Level ID Register, VMSA on page B4-1526, for a VMSA implementation.
— CLIDR, Cache Level ID Register, PMSA on page B6-1808, for a PMSA implementation.
• A single Cache Size Selection Register selects the cache level and cache type of the current Cache Size
Identification Register, see:
— CSSELR, Cache Size Selection Register, VMSA on page B4-1551, for a VMSA implementation.
— CSSELR, Cache Size Selection Register, PMSA on page B6-1826, for a PMSA implementation.
• For each implemented cache, across all the levels of caching, a Cache Size Identification Register defines:
— Whether the cache supports Write-Through, Write-Back, Read-Allocate and Write-Allocate.
— The number of sets, associativity, and line length of the cache.

— CCSIDR, Cache Size ID Registers, VMSA on page B4-1524, for a VMSA implementation.
— CCSIDR, Cache Size ID Registers, PMSA on page B6-1806, for a PMSA implementation.
Identifying the cache resources in ARMv7

In ARMv7, the architecture defines support for multiple levels of cache, up to a maximum of seven levels. This
complicates the process of identifying the cache resources available to an ARMv7 processor. To obtain this
information, software must:
1. Read the Cache Type Register to find the indexing and tagging policy used for the Level 1 instruction cache.
This register also provides the size of the smallest cache lines used for the instruction caches, and for the data
and unified caches. These values are used in cache maintenance operations.
2. Read the Cache Level ID Register to find what caches are implemented. The register includes seven Cache
type fields, for cache levels 1 to 7. Scanning these fields, starting from Level 1, identifies the instruction, data
or unified caches implemented at each level. This scan ends when it reaches a level at which no caches are
defined. The Cache Level ID Register also provides the Level of Unification (LoU) and the Level of
Coherence (LoC) for the cache implementation.
3. For each cache identified at stage 2:

• Write to the Cache Size Selection Register to select the required cache. A cache is identified by its
level, and whether it is:
— An instruction cache.
— A data or unified cache.
• Read the Cache Size ID Register to find details of the cache.
Note
In ARMv6, only the Level 1 caches are architecturally defined, and the Cache Type Register holds details of the
caches. For more information, see Cache support on page D12-2504.
B2.2.2 Cache behavior

The following subsections summarize the behavior of caches in an ARMv7 implementation:
• General behavior of the caches.
• Behavior of the caches at reset on page B2-1267.
• Behavior of Preload Data (PLD, PLDW) and Preload Instruction (PLI) with caches on page B2-1267.
General behavior of the caches

When a memory location is marked with a Normal Cacheable memory attribute, determining whether a copy of the
memory location is held in a cache still depends on many aspects of the implementation. The following
non-exhaustive list of factors might be involved:
• The size, line length, and associativity of the cache.
• The cache allocation algorithm.
• Activity by other elements of the system that can access the memory.
• Speculative instruction fetching algorithms.
• Speculative data fetching algorithms.
• Interrupt behaviors.
Given this range of factors, and the large variety of cache systems that might be implemented, the architecture
cannot guarantee whether:
• A memory location present in the cache remains in the cache.
• A memory location not present in the cache is brought into the cache.
Instead, the following principles apply to the behavior of caches:
• The architecture has a concept of an entry locked down in the cache. How lockdown is achieved is
IMPLEMENTATION DEFINED, and lockdown might not be supported by:
— A particular implementation.
— Some memory attributes.
• An unlocked entry in the cache cannot be relied upon to remain in the cache. If an unlocked entry does remain
in the cache, it cannot be relied upon to remain incoherent with the rest of memory. In other words, software
must not assume that an unlocked item that remains in the cache remains dirty.
• A locked entry in the cache can be relied upon to remain in the cache. A locked entry in the cache cannot be
relied upon to remain incoherent with the rest of memory, that is, it cannot be relied on to remain dirty.
Note
For more information, see The interaction of cache lockdown with cache maintenance operations on
page B2-1286.
• There is no mechanism that can guarantee that the memory location cannot be allocated to an enabled cache
at any time if a memory location both:
— Has permissions that mean it can be accessed, either by reads or by writes, for the translation scheme
at either the current level of privilege or at a higher level of privilege.
— Is marked as Cacheable for that translation regime.
Any application must assume that any memory location with such access permissions and cacheability
attributes can be allocated to any enabled cache at any time.
• If the cache is disabled, it is guaranteed that no new allocation of memory locations into the cache occurs.
• If the cache is enabled, it is guaranteed that no memory location that does not have a Cacheable attribute is
allocated into the cache.
• If the cache is enabled, it is guaranteed that no memory location is allocated to the cache if the access
permissions for that location are such that the location cannot be accessed by reads and cannot be accessed
by writes in both:
— The translation regime at the current level of privilege.
— The translation regime at a higher level of privilege.
• For data accesses, any memory location that is marked as Normal Shareable is guaranteed to be coherent with
all masters in that shareability domain.
• Any memory location is not guaranteed to remain incoherent with the rest of memory.
• The eviction of a cache entry from a cache level can overwrite memory that has been written by another
observer only if the entry contains a memory location that has been written to by an observer in the
shareability domain of that memory location. The maximum size of the memory that can be overwritten is
called the Cache Write-back Granule. In some implementations the CTR identifies the Cache Write-back
Granule, see:
— CTR, Cache Type Register, VMSA on page B4-1552 for a VMSA implementation.
— CTR, Cache Type Register, PMSA on page B6-1827 for a PMSA implementation.
• The allocation of a memory location into a cache cannot cause the most recent value of that memory location
to become invisible to an observer, if it had previously been visible to that observer.
For the purpose of these principles, a cache entry covers at least 16 bytes and no more than 2KB of contiguous
address space, aligned to its size.
In ARMv7, in the following situations it is UNPREDICTABLE whether the location is returned from cache or from
memory:
• The location is not marked as Cacheable but is contained in the cache. This situation can occur if a location
is marked as Non-cacheable after it has been allocated into the cache.
• The location is marked as Cacheable and might be contained in the cache, but the cache is disabled.
Behavior of the caches at reset

In ARMv7:
• All caches are disabled at reset.
• An implementation can require the use of a specific cache initialization routine to invalidate its storage array
before it is enabled. The exact form of any required initialization routine is IMPLEMENTATION DEFINED, and
the routine must be documented clearly as part of the documentation of the device.
• It is IMPLEMENTATION DEFINED whether an access can generate a cache hit when the cache is disabled. If an
implementation permits cache hits when the cache is disabled the cache initialization routine must:
— Provide a mechanism to ensure the correct initialization of the caches.
— Be documented clearly as part of the documentation of the device.
In particular, if an implementation permits cache hits when the cache is disabled and the cache contents are
not invalidated at reset, the initialization routine must avoid any possibility of running from an uninitialized
cache. It is acceptable for an initialization routine to require a fixed instruction sequence to be placed in a
restricted range of memory.
• ARM recommends that whenever an invalidation routine is required, it is based on the ARMv7 cache
maintenance operations.
When it is enabled, the state of a cache is UNPREDICTABLE if the appropriate initialization routine has not been
performed.
Similar rules apply:

• To branch predictor behavior, see Behavior of the branch predictors at reset on page B2-1271.
• On an ARMv7-A implementation, to TLB behavior, see TLB behavior at reset on page B3-1375.
Note
Before ARMv7, caches are invalidated by the assertion of reset, see Cache behavior at reset on page D12-2505.
Behavior of Preload Data (PLD, PLDW) and Preload Instruction (PLI) with caches
The PLD and PLI instructions provide Preload Data and Preload Instruction operations. These instructions are
implemented in the ARM and Thumb instruction sets. The Multiprocessing Extensions add the PLDW instruction.
These instructions are memory system hints, and the effect of each instruction is IMPLEMENTATION DEFINED, see
Preloading caches on page A3-155.
Because they are hints to the memory system, the operation of a PLD, PLDW, or PLI instruction does not cause a
synchronous abort to occur. However, a memory operation performed as a result of one of these memory system
hints might trigger an asynchronous event, so influencing the execution of the processor. Examples of the
asynchronous events that might be triggered are asynchronous aborts and interrupts.
Any location that can be allocated into a cache at any time as described in the General behavior of the caches on
page B2-1265 can be allocated as a result of a PLD, PLDW, or PLI instructions.
A memory location can be accessed as a result of a PLD, PLDW, or PLI instruction if:
• In a VMSA implementation, the location both:

— Has permissions that mean it can be accessed, either by reads or by writes, for the translation regime
at either the current level of privilege or at a higher level of privilege.
— Is marked as Normal memory for that translation regime in which it can be accessed.
• In a PMSA implementation, both:

— The location is in a memory region with permissions, defined by the PMSA, that means it can be
accessed, either by reads or by writes at either the current level of privilege or at a higher level of
privilege.
— That memory region is marked as Normal memory.
A PLI instruction must not perform any access that cannot be performed by a speculative instruction fetch by the
processor. Therefore:
• If a location is marked as Execute Never and Device, for the VMSA translation regime or PMSA memory
region at the current level of privilege and at any higher level of privilege a PLI instruction cannot cause an
access to that location.
• In a VMSA implementation, if all associated MMUs are disabled, a PLI instruction cannot access any
memory location that cannot be accessed by instruction fetches.
Note
In ARMv6, a speculative instruction fetch is provided by the optional Prefetch instruction cache line operation in
CP15 c7, with encoding <opc1> == 0, <CRm> == c13, <opc2> == 1, see CP15 c7, Cache and branch predictor
operations on page D12-2518.
Cache lockdown
Cache lockdown requirements can conflict with the management of hardware coherency. For this reason, ARMv7
introduces significant changes in this area, compared to previous versions of the ARM architecture. These changes
recognize that, in many systems, cache lockdown is inappropriate.
For an ARMv7 implementation:
• There is no requirement to support cache lockdown.
• If cache lockdown is supported, the lockdown mechanism is IMPLEMENTATION DEFINED. However key
properties of the interaction of lockdown with the architecture must be described in the implementation
documentation.
• The Cache Type Register does not hold information about lockdown. This is a change from ARMv6.
However some CP15 c9 encodings are available for IMPLEMENTATION DEFINED cache lockdown features, see
IMPLEMENTATION DEFINED memory system features on page B2-1290.
Note
For details of cache lockdown in ARMv6 see CP15 c9, Cache lockdown support on page D12-2523.
B2.2.3 Cache enabling and disabling

Levels of cache on page B2-1263 indicates that:
• In ARMv7, the architecture defines the control of multiple levels of cache.
• Before ARMv7, the architecture defines the control of only one level of cache.
This means the mechanism for cache enabling and disabling caches changes in ARMv7. In ARMv6, and in earlier
versions of the architecture, SCTLR.C and SCTLR.I control enabling and disabling of caches, see:
• SCTLR, System Control Register, VMSA on page B4-1700, for a VMSA implementation.
• SCTLR, System Control Register, PMSA on page B6-1921, for a PMSA implementation.
In ARMv7:
• SCTLR.C enables or disables all data and unified caches for data accesses, across all levels of cache visible
to the processor. It is IMPLEMENTATION DEFINED whether it also enables or disables the use of unified caches
for instruction accesses.
• SCTLR.I enables or disables all instruction caches, across all levels of cache visible to the processor.
• If an implementation requires finer-grained control of cache enabling, it can implement control bits in the
Auxiliary Control Register for this purpose. For example, an implementation might define control bits to
enable and disable the caches at a particular level. For more information about the Auxiliary Control Register,
see:
— ACTLR, IMPLEMENTATION DEFINED Auxiliary Control Register, VMSA on page B4-1518, for a
VMSA implementation.
— ACTLR, IMPLEMENTATION DEFINED Auxiliary Control Register, PMSA on page B6-1802, for a
PMSA implementation.
Note
In ARMv6, the SCTLR I, C, and W bits provide separate enables for the level 1 instruction cache, if implemented,
the level 1 data or unified cache, and write buffering.
When a cache is disabled for a type of access, for a particular translation regime:
• It is IMPLEMENTATION DEFINED whether a cache hit occurs if a location that is held in the cache is accessed
by that type of access.
• Any location that is not held in the cache is not brought into the cache as a result of a memory access of that
type.
Note
When interpreting this requirement for a PMSA implementation, all memory accesses belong to a single translation
regime that provides a flat mapping from input address to output address.
It is IMPLEMENTATION DEFINED whether the following bits affect the memory attributes generated by an enabled
MMU or MPU:
• For execution in Hyp mode, HSCTLR.{C, I}.
• For execution in any other mode, SCTLR.{C, I}.
In an implementation where the {C, I} bits can affect the generated memory attributes:
• If the implementation is a VMSAv7 implementation that includes the Virtualization Extensions, HCR.DC is
set to 1, and SCTLR.M is set to 0, then for execution using a PL1&0 translation regime the {C, I} bits have
no effect on cacheability.
• Otherwise:
— When a C bit is set to 0, disabling the data or unified cache for the corresponding translation regime,
data accesses, and translation table walks from that translation regime to any Normal memory region
behave as Non-cacheable for all levels of data or unified cache.
Note
Setting a C bit to 0 has no effect on the behavior of instruction accesses.
— When an I bit is set to 0, disabling the instruction cache for the corresponding translation regime,
instruction accesses from that translation regime to any Normal memory region behave as
Non-cacheable for all levels of instruction cache.
For implementations where the {C, I} bits can affect the generated memory attributes, this otherwise case
applies to all PMSA implementations, and to a VMSA implementation where any of the following applies:
— The implementation does not include the Virtualization Extensions.
— HCR.DC is set to 0, or SCTLR.M is set to 1.
— Execution is not using a PL1&0 translation regime.
Note
Regardless of whether the {C, I} bits affect the memory attributes, when a cache is disabled for a type of memory
access, a memory location that is not held in the cache is never brought into the cache as a result of a memory access
of that type.
If the MMU or MPU is disabled, the following sections describe the effects of SCTLR.{C, I} on the memory
attributes:
• The effects of disabling MMUs on VMSA behavior on page B3-1312 for the MMU.
• Behavior when the MPU is disabled on page B5-1750 for the MPU.
B2.2.4 Branch predictors

Branch predictor hardware typically uses a form of cache to hold branch information. The ARM architecture
permits this branch predictor hardware to be visible to software, and so the branch predictor is not architecturally
invisible. This means that under some circumstances software must perform branch predictor maintenance to avoid
incorrect execution caused by out-of-date entries in the branch predictor. For example, to ensure correct operation
it might be necessary to invalidate branch predictor entries on a change to instruction memory, or a change of
instruction address mapping. For more information, see Requirements for branch predictor maintenance
operations.
An invalidate all operation on the branch predictor ensures that any location held in the branch predictor has no
functional effect on execution. An invalidate branch predictor by MVA operation operates on the address of the
branch instruction, but can affect other branch predictor entries.
Note
The architecture does not make visible the range of addresses in a branch predictor to which the invalidate operation
applies. This means the address used in the invalidate by MVA operation must be the address of the branch to be
invalidated.
If branch prediction is architecturally visible, an instruction cache invalidate all operation also invalidates all branch
predictors.
Requirements for branch predictor maintenance operations

If, for a given translation regime and a given ASID and VMID as appropriate, the instructions at any virtual address
change, then branch predictor maintenance operations must be performed to invalidate entries in the branch
predictor, to ensure that the change is visible to subsequent execution. This maintenance is required when writing
new values to instruction locations. It can also be required as a result of any of the following situations that change
the translation of a virtual address to a physical address, if, as a result of the change to the translation, the instructions
at the virtual addresses change:
• Enabling or disabling the MMU.
• Writing new mappings to the translation tables.
• Any change to the TTBR0, TTBR1, or TTBCR registers, unless accompanied by a change to the ContextID,
or a change to the VMID
• Changes to the VTTBR or VTCR registers, unless accompanied by a change to the VMID.
Note
Invalidation is not required if the changes to the translations are such that the instructions associated with the
non-faulting translations of a virtual address, for a given translation regime and a given ASID and VMID, as
appropriate, remain unchanged throughout the sequence of changes to the translations. Examples of translation
changes to which this applies are:
• Changing a valid translation to a translation that generates an MMU fault.
• Changing a translation that generates an MMU fault to a valid translation.
Failure to invalidate entries might give UNPREDICTABLE results, caused by the execution of old branches. For more
information, see Ordering of cache and branch predictor maintenance operations on page B2-1287.
Note
• In ARMv7, there is no requirement to use the branch predictor maintenance operations to invalidate the
branch predictor after:
— Changing the ContextID or VMID, or changing the FCSE ProcessID in an implementation that
includes the FCSE.
— A cache operation that is identified as also flushing the branch predictors, see Cache and branch
predictor maintenance operations on page B2-1276.
• In ARMv6, the branch predictor must be invalidated after a change to the ContextID or FCSE ProcessID, see
CP15 c13, Context ID support on page D12-2530.
Behavior of the branch predictors at reset

In ARMv7:
• If branch predictors are not architecturally invisible, the branch prediction logic is disabled at reset.
• An implementation can require the use of a specific branch predictor initialization routine to invalidate the
branch predictor storage array before it is enabled. The exact form of any required initialization routine is
IMPLEMENTATION DEFINED, but the routine must be documented clearly as part of the documentation of the
device.
• ARM recommends that whenever an invalidation routine is required, it is based on the ARMv7 branch
predictor maintenance operations.
When it is enabled, the state of the branch predictor logic is UNPREDICTABLE if the appropriate initialization routine
has not been performed.

• To cache behavior, see Behavior of the caches at reset on page B2-1267.
• On an ARMv7-A implementation, to TLB behavior, see TLB behavior at reset on page B3-1375.
B2.2.5 Multiprocessor considerations for cache and similar maintenance operations

The ARMv7 architecture defines maintenance operations for:
• Caches.
• Branch predictors.
• On a VMSA implementation, TLBs.
For an implementation that does not include the Multiprocessing Extensions, the ARMv7 architecture defines these
operations as applying only to resources directly attached to the processor on which the operation is executed. This
means that there is no requirement for maintenance operations to influence other processors with which data can be
shared. If porting an architecturally-portable multiprocessor operating system to an implementation of the ARMv7
architecture that does not include the Multiprocessing Extensions, when a maintenance operation is performed, the
operating system must use Inter-Processor Interrupts (IPIs) to inform other processors in a multiprocessor
configuration that they must perform the equivalent operation.
The ARMv7 Multiprocessing Extensions provide enhanced support for multiprocessor implementations, including
extending the maintenance operations, so that some maintenance operations affect other processors in the system.
The Multiprocessing Extensions both:
• Change the effect of some existing maintenance operations.
• Add new maintenance operations.
The following sections include descriptions of the extensions to the maintenance operations:
• Cache and branch predictor maintenance operations on page B2-1276.
• TLB maintenance requirements on page B3-1377.
When a uniprocessor implementation with no hardware support for cache coherency includes the Multiprocessing
Extensions, the Inner Shareable and Outer Shareable domains apply only to the single processor, and all instructions
defined to apply to the Inner Shareable domain behave as aliases of the local operations.
B2.2.6 About ARMv7 cache and branch predictor maintenance functionality

This chapter describes cache and branch predictor maintenance for ARMv7. For details of maintenance operations
in previous versions of the ARM architecture, see:
• CP15 c7, Cache and branch predictor operations on page D12-2518 for ARMv6.
• CP15 c7, Cache and branch predictor operations on page D15-2613 for the ARMv4 and ARMv5
architectures.
The following sections give general information about the ARMv7 cache and branch prediction maintenance
functionality:
• Terms used in describing the maintenance operations.
• The ARMv7 abstraction of the cache hierarchy on page B2-1275.
Cache and branch predictor maintenance operations on page B2-1276 describes the maintenance operations.
Requirements for branch predictor maintenance operations on page B2-1270 describes cases that require software
to perform branch predictor maintenance.
Terms used in describing the maintenance operations

Cache maintenance operations are defined to act on particular memory locations. Operations can be defined:
• By the address of the memory location to be maintained, referred to as operating by MVA.
• By a mechanism that describes the location in the hardware of the cache, referred to as operating by set/way.
In addition, for instruction caches and branch predictors, there are operations that invalidate all entries.
The following subsections define the terms used in the descriptions of the cache operations:
• Terminology for operations by MVA.
• Terminology for operations by set/way on page B2-1273.
• Terminology for Clean, Invalidate, and Clean and Invalidate operations on page B2-1273.
Terminology for operations by MVA
The term Modified Virtual Address (MVA) relates to the Fast Context Switch Extension (FCSE) mechanism,
described in Appendix D10 Fast Context Switch Extension (FCSE). When the FCSE is absent or disabled, the MVA
and VA have the same value. However the term MVA is used throughout this section, and elsewhere in this manual,
for cache and TLB operations. This is consistent with previous issues of the ARM Architecture Reference Manual.
Note
From ARMv6, ARM deprecates any use of the FCSE. The FCSE is OPTIONAL and deprecated in an ARMv7
implementation that does not include the Multiprocessing Extensions, and is not supported by any implementation
that includes the Multiprocessing Extensions. That is, the Multiprocessing Extensions make the FCSE obsolete.
Virtual addresses only exist in systems with an MMU. When no MMU is implemented, or all applicable MMUs are
disabled, the MVA and VA are identical to the PA.
Note
For more information about memory system behavior when MMUs are disabled, see The effects of disabling MMUs
on VMSA behavior on page B3-1312.
Terminology for operations by set/way
Cache maintenance operations by set/way refer to the particular structures in a cache. Three parameters describe the
location in a cache hierarchy that an operation works on. These parameters are:
Level The cache level of the hierarchy. The number of levels of cache is IMPLEMENTATION DEFINED, and
can be determined from the Cache Level ID Register, see:
• CLIDR, Cache Level ID Register, VMSA on page B4-1526 for a VMSA implementation.
• CLIDR, Cache Level ID Register, PMSA on page B6-1808 for a PMSA implementation.
In the ARM architecture, the lower numbered levels are those closest to the processor, see Memory
hierarchy on page A3-153.
Set Each level of a cache is split up into a number of sets. Each set is a set of locations in a cache level
to which an address can be assigned. Usually, the set number is an IMPLEMENTATION DEFINED
function of an address.
In the ARM architecture, sets are numbered from 0.
Way The Associativity of a cache defines the number of locations in a set to which an address can be
assigned. The way number specifies a location in a set.
In the ARM architecture, ways are numbered from 0.
Terminology for Clean, Invalidate, and Clean and Invalidate operations
Caches introduce coherency problems in two possible directions:
1. An update to a memory location by a processor that accesses a cache might not be visible to other observers
that can access memory. This can occur because new updates are still in the cache and are not visible yet to
the other observers that do not access that cache.
2. Updates to memory locations by other observers that can access memory might not be visible to a processor
that accesses a cache. This can occur when the cache contains an old, or stale, copy of the memory location
that has been updated.
The Clean and Invalidate operations address these two issues. The definitions of these operations are:
Clean A cache clean operation ensures that updates made by an observer that controls the cache are made
visible to other observers that can access memory at the point to which the operation is performed.
Once the Clean has completed, the new memory values are guaranteed to be visible to the point to
which the operation is performed, for example to the point of unification.
The cleaning of a cache entry from a cache can overwrite memory that has been written by another
observer only if the entry contains a location that has been written to by an observer in the
shareability domain of that memory location.
Invalidate A cache invalidate operation ensures that updates made visible by observers that access memory at
the point to which the invalidate is defined are made visible to an observer that controls the cache.
This might result in the loss of updates to the locations affected by the invalidate operation that have
been written by observers that access the cache.
If the address of an entry on which the invalidate operates does not have a Normal Cacheable
attribute, or if the cache is disabled, then an invalidate operation also ensures that this address is not
present in the cache.
Note
Entries for addresses with a Normal Cacheable attribute can be allocated to an enabled cache at any
time, and so the cache invalidate operation cannot ensure that the address is not present in an
enabled cache.
Clean and Invalidate

A cache clean and invalidate operation behaves as the execution of a clean operation followed
immediately by an invalidate operation. Both operations are performed to the same location.
The points to which a cache maintenance operation can be defined differ depending on whether the operation is by
MVA or by set/way:
• For set/way operations, and for All (entire cache) operations, the point is defined to be to the next level of
caching.
• For MVA operations, two conceptual points are defined:

Point of coherency (PoC)
For a particular MVA, the PoC is the point at which all agents that can access memory are
guaranteed to see the same copy of a memory location. In many cases, this is effectively the main
system memory, although the architecture does not prohibit the implementation of caches beyond
the PoC that have no effect on the coherence between memory system agents.
Note
The presence of system caches can affect the definition of the point of coherency as described in
System level caches on page B2-1288.
Point of unification (PoU)

The PoU for a processor is the point by which the instruction and data caches and the translation
table walks of that processor are guaranteed to see the same copy of a memory location. In many
cases, the point of unification is the point in a uniprocessor memory system by which the
instruction and data caches and the translation table walks have merged.
The PoU for an Inner Shareable shareability domain is the point by which the instruction and data
caches and the translation table walks of all the processors in that Inner Shareable shareability
domain are guaranteed to see the same copy of a memory location. Defining this point permits
self-modifying software to ensure future instruction fetches are associated with the modified
version of the software by using the standard correctness policy of:
1. Clean data cache entry by address.
2. Invalidate instruction cache entry by address.
The PoU also permits a uniprocessor system that does not implement the Multiprocessing
Extensions to use the clean data cache entry operation to ensure that all writes to the translation
tables are visible to the translation table walk hardware.
The following fields in the CLIDR relate to these conceptual points:
LoC, Level of coherence
This field defines the last level of cache that must be cleaned or invalidated when cleaning or
invalidating to the point of coherency. The LoC value is a cache level, so, for example, if LoC
contains the value 3:
• A clean to the point of coherency operation requires the level 1, level 2 and level 3 caches
to be cleaned.
• Level 4 cache is the first level that does not have to be maintained.
If the LoC field value is 0x0, this means that no levels of cache need to cleaned or invalidated
when cleaning or invalidating to the point of coherency.
If the LoC field value is a nonzero value that corresponds to a level that is not implemented, this
indicates that all implemented caches are before the point of coherency.
LoUU, Level of unification, uniprocessor
This field defines the last level of cache that must be cleaned or invalidated when cleaning or
invalidating to the point of unification for the processor. As with LoC, the LoUU value is a cache
level.
If the LoUU field value is 0x0, this means that no levels of cache need to cleaned or invalidated
when cleaning or invalidating to the point of unification.
If the LoUU field value is a nonzero value that corresponds to a level that is not implemented,
this indicates that all implemented caches are before the point of unification.
LoUIS, Level of unification, Inner Shareable
This field is defined only as part of the Multiprocessing Extensions. If an implementation does
not include the Multiprocessing Extensions, then this field is RAZ.
In an implementation that includes the Multiprocessing Extensions:

• This field defines the last level of cache that must be cleaned or invalidated when cleaning
or invalidating to the point of unification for the Inner Shareable shareability domain. As
with LoC, the LoUIS value is a cache level.
• If the LoUIS field value is 0x0, this means that no levels of cache need to cleaned or
invalidated when cleaning or invalidating to the point of unification for the Inner
Shareable shareability domain.
• If the LoUIS field value is a nonzero value that corresponds to a level that is not
implemented, this indicates that all implemented caches are before the point of unification.
— CLIDR, Cache Level ID Register, VMSA on page B4-1526 for a VMSA implementation.
— CLIDR, Cache Level ID Register, PMSA on page B6-1808 for a PMSA implementation.
The ARMv7 abstraction of the cache hierarchy

The following subsections describe the ARMv7 abstraction of the cache hierarchy:
• Cache hierarchy abstraction for address-based operations.
• Cache hierarchy abstraction for set/way-based operations.
Performing cache maintenance operations on page B2-1284 gives more information about the cache maintenance
operations, including an example of cache maintenance code, that can be adapted for other cache operations.
Cache hierarchy abstraction for address-based operations
The addressed-based cache operations are described as operating by MVA. Each of these operations is always
qualified as being one of:
• Performed to the point of coherency.
• Performed to the point of unification.
See Terms used in describing the maintenance operations on page B2-1272 for definitions of point of coherency
and point of unification, and more information about possible meanings of MVA.
Summary of cache and branch predictor maintenance operations on page B2-1276 lists the address-based
maintenance operations.
The CTR holds minimum line length values for:

• The instruction caches.
• The data and unified caches.
These values support efficient invalidation of a range of addresses, because this value is the most efficient address
stride to use to apply a sequence of address-based maintenance operations to a range of addresses.
For the Invalidate data or unified cache line by MVA operation, the Cache Write-back Granule field of the CTR
defines the maximum granule that a single invalidate instruction can invalidate. This meaning of the Cache
Write-back Granule is in addition to its defining the maximum size that can be written back.
For details of the CTR, see:

• CTR, Cache Type Register, VMSA on page B4-1552 for a VMSA implementation.
• CTR, Cache Type Register, PMSA on page B6-1827 for a PMSA implementation.
Cache hierarchy abstraction for set/way-based operations
Summary of cache and branch predictor maintenance operations on page B2-1276 lists the set/way-based
maintenance operations. The CP15 c7 encodings of these operations include a required field that specifies the cache
level for the operation:
• A clean operation cleans from the level of cache specified through to at least the next level of cache, moving
further from the processor.
• An invalidate operation invalidates only at the level specified.
B2.2.7 Cache and branch predictor maintenance operations

Cache and branch predictor maintenance operations are performed using accesses to CP15 c7. The following
sections define the encodings for these operations:
• Cache and branch predictor maintenance operations, VMSA on page B4-1735, for a VMSA implementation.
• Cache and branch predictor maintenance operations, PMSA on page B6-1932, for a PMSA implementation.
The following sections describe the operations:

• Summary of cache and branch predictor maintenance operations.
• Requirements for cache and branch predictor maintenance operations on page B2-1278.
• Scope of cache and branch predictor maintenance operations on page B2-1279.
• Virtualization Extensions upgrading of maintenance operations on page B2-1284.
• Performing cache maintenance operations on page B2-1284.
Summary of cache and branch predictor maintenance operations

The following subsections summarize the required cache and branch predictor maintenance operations:
• Data cache and unified cache operations.
• Instruction cache operations on page B2-1277.
• Branch predictor operations on page B2-1278.
Note
Other cache maintenance operations specified in ARMv6 are not supported in ARMv7. Their associated encodings
in CP15 c7 are UNPREDICTABLE.
An ARMv7 implementation can add additional IMPLEMENTATION DEFINED cache maintenance functionality using
CP15 c15 operations, if this is required.
In a VMSA implementation, some maintenance operations that take an MVA as an argument can generate an MMU
fault. The fault descriptions in MMU faults on page B3-1400 identify these cases.
General requirements for the scope of maintenance operations on page B2-1279 gives information that applies to
all of these operations. Where appropriate, the operation summaries give cross-references to subsections that give
additional information that is relevant to that operation.
Data cache and unified cache operations
Any of these operations can be applied to any data cache, or to any unified cache. The supported operations, grouped
by the argument required for the operation, are:
Operations by MVA
The data and unified cache operations by MVA are:
DCIMVAC Invalidate, to point of coherency.
DCCMVAC Clean, to point of coherency.
DCCMVAU Clean, to point of unification.
DCCIMVAC Clean and invalidate, to point of coherency.
These operations invalidate, clean, or clean and invalidate a data or unified cache line based on the
address it contains. For more information, see:
• Requirements for operations by MVA on page B2-1278.
• For an implementation that includes the Multiprocessing Extensions:
— For the operations to the point of coherency, Effect of the Multiprocessing Extensions
on operations to the point of coherency on page B2-1279.
— For DCCMVAU, Effect of the Multiprocessing Extensions on operations not to the
point of coherency on page B2-1280.
For a data or unified cache maintenance operation by MVA, the operation cannot generate a Data
Abort exception for a Domain fault or a Permission fault, except for the Permission fault cases
described in:
• Virtualization Extensions upgrading of maintenance operations on page B2-1284.
• Stage 2 fault on a stage 1 translation table walk, Virtualization Extensions on page B3-1399.
For more information about these faults, see MMU faults on page B3-1400.
Operations by set/way
The data and unified cache operations by set/way are:
DCISW Invalidate.
DCCSW Clean.
DCCISW Clean and invalidate, to point of coherency.
These operations invalidate, clean, or clean and invalidate a data or unified cache line based on its
location in the cache hierarchy. For more information, see:
• Requirements for operations by set/way on page B2-1278.
• For an implementation that includes the Multiprocessing Extensions, Effect of the
Multiprocessing Extensions on All and set/way maintenance operations on page B2-1281.
Note
The possible presence of system caches, as described in System level caches on page B2-1288 means architecture
does not guarantee that all levels of the cache can be maintained using set/way instructions.
Instruction cache operations
The supported operations, grouped by the operation type, are:
Operation by MVA
ICIMVAU Invalidate, to point of unification.
This instruction invalidates an instruction cache line based on the address it contains. For more
information, see:
• Requirements for operations by MVA on page B2-1278.
Multiprocessing Extensions on operations not to the point of coherency on page B2-1280.
For an instruction cache maintenance operation by MVA:
• It is IMPLEMENTATION DEFINED whether the operation can generate a Data Abort exception
for a Translation fault or an Access flag fault.
• The operation cannot generate a Data Abort exception for a Domain fault or a Permission
fault, except for the Permission fault case described in Stage 2 fault on a stage 1 translation
table walk, Virtualization Extensions on page B3-1399.
Operations on all entries

The instruction cache operations that operate on all entries are:
ICIALLU Invalidate all, to point of unification.
ICIALLUIS Invalidate all, to point of unification, Inner Shareable.
These instructions invalidate the entire instruction cache or caches, and, if branch predictors are
architecturally-visible, all branch predictors. ICIALLUIS operates on all processors in the Inner
Shareable domain of the processor that performs the operation.
For more information about these instructions on an implementation that includes the
Multiprocessing Extensions, see Effect of the Multiprocessing Extensions on All and set/way
maintenance operations on page B2-1281.
Branch predictor operations
The supported operations, grouped by the operation type, are:
Operation by MVA
BPIMVA Invalidate.
Invalidates the branch predictor based on a branch address. For more information, see:
• Requirements for operations by MVA.
Multiprocessing Extensions on operations not to the point of coherency on page B2-1280.
For a branch predictor maintenance operation by MVA:
• It is IMPLEMENTATION DEFINED whether the operation can generate a Data Abort exception
for a Translation fault or an Access flag fault.
• The operation cannot generate a Data Abort exception for a Domain fault or a Permission
fault, except for the Permission fault case described in Stage 2 fault on a stage 1 translation
table walk, Virtualization Extensions on page B3-1399.
Operations on all entries

The instruction cache operations that operate on all entries are:
BPIALL Invalidate all.
BPIALLIS Invalidate all, Inner Shareable.
These instructions invalidate all branch predictors. BPIALLIS operates on all processors in the
Inner Shareable domain of the processor that performs the operation.
For more information about these instructions on an implementation that includes the
Multiprocessing Extensions, see Effect of the Multiprocessing Extensions on All and set/way
Requirements for cache and branch predictor maintenance operations

The following subsections give information about the requirements for the cache and branch predictor operations
that take arguments that define their target:
• Requirements for operations by MVA.
• Requirements for operations by set/way.
Requirements for operations by MVA
In the cache operations, any operation described as operating by MVA includes as part of any required MVA to PA
translation:
• For an operation performed at PL1, the current system Address Space Identifier (ASID).
• If the implementation includes the Security Extensions, the current security state.
• If the implementation includes the Virtualization Extensions:
— Whether the operation was performed from Hyp mode, or from a Non-secure PL1 mode.
— For an operation performed from a Non-secure PL1 mode, the virtual machine identifier (VMID).
Requirements for operations by set/way
Cache maintenance operations that work by set/way use the level, set and way values to determine the location acted
on by the operation. The address in memory that corresponds to this cache location is determined by the cache.
Note
Because the allocation of a memory address to a cache location is entirely IMPLEMENTATION DEFINED, ARM expects
that most portable software will use only the set/way operations as single steps in a routine to perform maintenance
on the entire cache.
Scope of cache and branch predictor maintenance operations

The following subsections describe the general architectural requirements for the scope of cache and branch
predictor maintenance operations, and how the Multiprocessing Extensions affect the scope of different operations:
• General requirements for the scope of maintenance operations.
• Effect of the Multiprocessing Extensions on operations to the point of coherency.
• Effect of the Multiprocessing Extensions on operations not to the point of coherency on page B2-1280.
• Effect of the Multiprocessing Extensions on All and set/way maintenance operations on page B2-1281.
• Effects of the Security and Virtualization Extensions on the maintenance operations on page B2-1282.
• Additional requirements of the Virtualization Extensions on page B2-1283.
General requirements for the scope of maintenance operations
The ARMv7 specification of the cache maintenance operations describes what each operation is guaranteed to do
in a system. It does not limit other behaviors that might occur, provided they are consistent with the requirements
described in Cache behavior on page B2-1265 and in Branch predictors on page B2-1270.
This means that:
• As a side-effect of a cache maintenance operation:

— Any location in the cache might be cleaned.
— Any unlocked location in the cache might be cleaned and invalidated.
• As a side-effect of a branch predictor maintenance operation, any entry in the branch predictor might be
invalidated.
Note
ARM recommends that, for best performance, such side-effects are kept to a minimum. In particular, in an
implementation that includes the Security Extensions, ARM strongly recommends that the side-effects of operations
performed in Non-secure state do not have a significant performance impact on execution in Secure state.
In addition, on a VMSAv7 implementation:
• If the implementation includes the Security Extensions, each security state has its own physical address
space, affecting the required and permitted scope of cache maintenance operations.
• The Virtualization Extensions add additional requirements for the cache maintenance operations.
Effects of the Security and Virtualization Extensions on the maintenance operations on page B2-1282 describes
these effects.
Effect of the Multiprocessing Extensions on operations to the point of coherency
The Multiprocessing Extensions add requirements for the scope of the following operations, that affect data and
unified caches to the point of coherency:
• Invalidate data, or unified, cache line by MVA to the point of coherency, DCIMVAC.
• Clean data, or unified, cache line by MVA to the point of coherency, DCCMVAC.
• Clean and invalidate data, or unified, cache line by MVA to the point of coherency, DCCIMVAC.
For Normal memory that is not Inner Non-cacheable, Outer Non-cacheable, these instructions must affect the caches
of other processors in the shareability domain described by the shareability attributes of the MVA supplied with the
operation.
In the following cases, these operations must affect the caches of all processors in the Outer Shareable shareability
domain of the processor on which the operation is performed:
• For Strongly-ordered memory.
• In an implementation that includes the Large Physical Address Extension, for Device memory. When using
the Short-descriptor translation table format this requirement applies regardless of any shareability attribute
applied to the region. This means that any PRRR.NOS bit that applies to the Device memory region has no
effect on the scope of the operation.
On an implementation that does not include the Large Physical Address Extension, for Device memory it is
IMPLEMENTATION DEFINED which of the following applies:
• These operations affect the caches of other processors in the Outer Shareable shareability domain.
• These operations affect the caches of other processors in the shareability domain defined by the shareability
attributes of the MVA passed with the instruction.
On an implementation that includes the Large Physical Address Extension and is using the Short-descriptor
translation table format, for Normal memory that is Inner Non-cacheable, Outer Non-cacheable, it is
IMPLEMENTATION DEFINED which of the following applies:
• These operations affect the caches of other processors in the Outer Shareable shareability domain.
• These operations affect the caches of other processors in the shareability domain defined by the shareability
attributes of the MVA passed with the instruction.
In all cases, for any affected processor, these operations affect all data and unified caches to the point of coherency.
For the cases where the shareability attribute of the MVA supplied with the operation determines the scope of the
operation, Table B2-1 shows how this attribute determines the minimum set of processors affected, and the point to
which the operation must be effective.
Table B2-1 Processors affected by Data and Unified cache operations
Shareability Processors affected Effective to
Non-shareable The processor performing the operation Point of coherency of the entire system
Inner Shareable All processors in the same Inner Shareable shareability domain as the Point of coherency of the entire system
processor performing the operation
Outer Shareable All processors in the same Outer Shareable shareability domain as the Point of coherency of the entire system
processor performing the operation
Effect of the Multiprocessing Extensions on operations not to the point of coherency
The Multiprocessing Extensions add requirements for the scope of the following operations, that operate by MVA
but not to the point of coherency:
• Clean data, or unified, cache line by MVA to the point of unification, DCCMVAU.
• Invalidate instruction cache line by MVA to point of unification, ICIMVAU.
• Invalidate MVA from branch predictors, BPIMVA.
On an implementation that includes the Large Physical Address Extension:
• For an MVA in a Strongly-ordered or Device memory region, these operations apply to all processors in the
Inner Shareable shareability domain.
Note
For Device memory, this requirement applies regardless of the current translation table format. When using
the Short-descriptor format, the shareability attribute of a Device memory region has no effect on the scope
of these operations. This means that any PRRR.NOS bit that applies to the Device memory region has no
effect on the scope of the operation.
• When the implementation is using the Short-descriptor translation table format, for Normal memory that is
Inner Non-cacheable, Outer Non-cacheable, it is IMPLEMENTATION DEFINED which of the following applies:
— These operations affect the caches of other processors in the Inner Shareable shareability domain.
— These operations affect the caches of other processors in the shareability domain defined by the
shareability attributes of the MVA passed with the instruction.
Otherwise, for these operations:
• Table B2-2 shows how, for an MVA in a Normal or Device memory region, the shareability attribute of the
MVA determines the minimum set of processors affected, and the point to which the operation must be
effective.
• The scope of an operation using an MVA in a Strongly-Ordered memory region is the same as that shown, in
Table B2-2, for an address with an Inner Shareable or Outer Shareable attribute.
Table B2-2 Processors affected by Address-based cache maintenance operations
Shareability Processors affected Effective to
Non-shareable The processor performing the Point of unification of instruction cache fills, data cache fills and write-backs,
operation and translation table walks, on the processor performing the operation
Inner Shareable or All processors in the same Inner To the point of unification of instruction cache fills, data cache fills and
Outer Shareable Shareable shareability domain write-backs, and translation table walks, of all processors in the same Inner
as the processor performing the Shareable shareability domain as the processor performing the operation
operation
Note
The set of processors guaranteed to be affected is never greater than the processors in the Inner Shareable
shareability domain containing the processor performing the operation.
Effect of the Multiprocessing Extensions on All and set/way maintenance operations
For an implementation that includes the Multiprocessing Extension, this section describes the
architecturally-required effect of local and Inner Shareable instructions for cache and branch predictor maintenance
operations that operate on all entries, or operate by set/way:
Local instructions
The only architectural guarantee for the following instructions is that they apply to the caches or
branch predictors of the processor that performs the operation:
• Invalidate entire instruction cache, ICIALLU.
• Invalidate all branch predictors, BPIALL.
• Clean and Invalidate data or unified cache line by set/way, DCCISW.
• Clean data or unified cache line by set/way, DCCSW.
• Invalidate data or unified cache line by set/way, DCISW.
That is, these operations have an effect only on the processor that performs the operation.
If the branch predictors are architecturally-visible, ICIALLU also performs a BPIALL operation.
These operations are functionally unchanged from their operation in an ARMv7 implementation
that does not include the Multiprocessing Extensions.
Note
Since the set/way instructions are performed only locally, there is no guarantee of the atomicity of
cache maintenance between different processors, even if those different processors are each
performing the same cache maintenance instructions at the same time. Since any cacheable line can
be allocated into the cache at any time, it is possible for cache line to migrate from an entry in the
cache of one processor to the cache of a different processor in a manner that the cache line avoids
being affected by set/way based cache maintenance. Therefore, ARM strongly discourages the use
of set/way instructions to manage coherency in coherent systems.
Inner Shareable instructions

The following instructions can affect the caches or branch predictors of all processors in the same
Inner Shareable shareability domain as the processor that performs the operation:
• Invalidate all branch predictors Inner Shareable, BPIALLIS.
• Invalidate entire instruction cache Inner Shareable, ICIALLUIS.
If the branch predictors are architecturally-visible, ICIALLUIS also performs a BPIALLIS
operation.
These operations have an effect to the point of unification of instruction cache fills, data cache fills
and write-backs, and translation table walks, of all processors in the same Inner Shareable
shareability domain.
Effects of the Security and Virtualization Extensions on the maintenance operations
In an implementation that includes the Security Extensions, each Security state has its own physical address space,
and therefore cache and branch predictor entries are associated with a physical address space. In addition, in an
implementation that includes the Virtualization Extensions, cache and branch predictor maintenance operations
performed in Non-secure state have to take account of:
• Whether the operation was performed at PL1 or at PL2.
• For operations by MVA, the current VMID.
Table B2-3 shows the effect of the Security and Virtualization Extensions on these maintenance operations.
Table B2-3 Effect of the Security and Virtualization Extensions on the maintenance operations
Security
Cache operation Targeted entry
state
Data or unified cache operations
Invalidate, Clean, or Either All lines that hold the PA that, in the current security state, is mapped to by the
Clean and Invalidate by combination of all of a:
MVA: DCIMVAC, • The specified MVA.
DCCMVAC,
• The current ASID.
DCCMVAU,
DCCIMVAC • In an implementation that includes the Virtualization Extensions, for an
operation performed in a Non-secure PL1 mode, the current VMID b.
Invalidate, Clean, or Non-secure Line specified by set/way provided that the entry comes from the Non-secure PA
Clean and Invalidate by space. a
set/way: DCISW,
DCCSW, DCCISW Secure Line specified by set/way regardless of the PA space that the entry has come from.
Instruction cache operations
Invalidate by MVA: Either All lines that match the specified VA, come from the VA space of the current Security
ICIMVAU state, and for the PL1 translation regime match the current ASID. In an
implementation that includes the Virtualization Extensions, for an instruction
executed in Non-secure state, lines are invalidated only if they also match the current
privilege level, and for the PL1 translation regime, the current VMID b.
Table B2-3 Effect of the Security and Virtualization Extensions on the maintenance operations (continued)
Security
Cache operation Targeted entry
state
Invalidate All: ICIALLU, • Can invalidate any unlocked entry in the instruction cache.
ICIALLUIS • Are required to invalidate any entries relevant to the software component that executed it. The
Non-secure and Secure descriptions give more information.
Non- secure In an implementation that includes the Virtualization Extensions, an operation

performed at PL1 must apply to all instruction cache lines that contain entries
associated with the current virtual machine, meaning any entry with the current
VMID b.
Otherwise, an operation must apply to all instruction cache lines that contain entries
that can be accessed from Non-secure state.
Secure Must invalidate all instruction cache lines.
Branch predictor operations
Invalidate by MVA: Either All entries that match the specified MVA and the current ASID, and come from the
BPIMVA same VA space as the current Security state. In an implementation that includes the
Virtualization Extensions, for an operation performed in Non-secure state, entries are
invalidated only if they also match the current VMID b and security level, PL1 or PL2.
Invalidate all: BPIALL, • Can invalidate any unlocked entry in the instruction cache.
BPIALLIS • Are required to invalidate any entries relevant to the software component that executed it. The
Non-secure and Secure descriptions give more information.
Non-secure In an implementation that includes the Virtualization Extensions, an operation

performed at PL1 must apply to all entries associated with the current virtual
machine, meaning any entry with the current VMID b.
Otherwise, an operation must apply to all entries that can be accessed from
Non-secure state.
Secure Must invalidate all entries.

a. See also Additional requirements of the Virtualization Extensions.
b. Dependencies on the VMID apply even when HCR.VM is set to 0. However, VTTBR.VMID resets to zero, meaning there is a valid VMID
from reset.
For locked entries and entries that might be locked, the behavior of cache maintenance operations described in The
interaction of cache lockdown with cache maintenance operations on page B2-1286 applies. This behavior is not
affected by either the Security Extensions or the Virtualization Extensions.
With an implementation that generates aborts if entries are locked or might be locked in the cache, when the use of
lockdown aborts is enabled, these aborts can occur on any cache maintenance operation regardless of the Security
Extensions.
For more information about the cache maintenance operations, see About ARMv7 cache and branch predictor
maintenance functionality on page B2-1272 and Cache and branch predictor maintenance operations, VMSA on
page B4-1735.
Additional requirements of the Virtualization Extensions
An implementation that includes the Virtualization Extensions has the following additional requirements for cache
maintenance:
• The architecture does not require cache cleaning when switching between virtual machines. Cache
invalidation by set/way must not present an opportunity for one virtual machine to corrupt state associated
with a second virtual machine. To ensure this requirement is met, Non-secure clean by set/way operations
can be upgraded to clean and invalidate by set/way.
• A data or unified clean by MVA operation performed in a Non-secure PL1 mode must not cause a change to
a data location for which the stage 2 translation properties do not permit write access.
For more information about these cases, see Virtualization Extensions upgrading of maintenance operations.
Virtualization Extensions upgrading of maintenance operations

• When HCR.FB is set to 1, for maintenance operations performed in a Non-secure PL1 mode:
— An ICIALLU is broadcast across the Inner Shareable domain. This means it is upgraded to
ICIALLUIS.
— A BPIALL is broadcast across the Inner Shareable domain. This means it is upgraded to BPIALLIS.
• When HCR.SWIO is set to 1, an invalidate by set/way performed in a Non-secure PL1 mode is treated as a
clean and invalidate by set/way. This means DCISW is upgraded to DCCISW.
As indicated in Additional requirements of the Virtualization Extensions on page B2-1283, a Data or unified cache
invalidation by MVA operation performed in a Non-secure PL1 mode must not cause a change to data in a location
for which the stage 2 translation permissions do not permit write access. Where such a permission violation occurs,
it is IMPLEMENTATION DEFINED whether:
• A stage 2 Permission fault is generated for the DCIMVAC operation.
• The DCIMVAC operation is upgraded to DCCIMVAC.
Note
Functionally, upgrading DCIMVAC to DCCIMVAC is acceptable for any data invalidate by MVA executed in a
Non-secure PL1 mode. Therefore, the implementation documentation might not specify the exact conditions in
which this upgrade occurs. Possible approaches are to upgrade DCIMVAC to DCCIMVAC:
• For any Non-secure PL1 operation when the stage 2 MMU is enabled.
• Only if a stage 2 Permission fault is detected.
Performing cache maintenance operations

To ensure all cache lines in a block of address space are maintained through all levels of cache, ARM strongly
recommends that software:
• For data or unified cache maintenance, uses the CTR.DMINLINE value to determine the loop increment size
for a loop of data cache maintenance by MVA operations.
• For instruction cache maintenance, uses the CTR.IMINLINE value to determine the loop increment size for
a loop of instruction cache maintenance by MVA operations.
Example code for cache maintenance operations
The code sequence given in this subsection illustrates a generic mechanism for cleaning the entire data or unified
cache to the point of coherency.
Note
In a multiprocessor implementation where multiple processors share a cache before the point of coherency, running
this sequence on multiple processors results in the operations being repeated on the shared cache.
MRC p15, 1, R0, c0, c0, 1 ; Read CLIDR into R0

ANDS R3, R0, #0x07000000
MOV R3, R3, LSR #23 ; Cache level value (naturally aligned)
BEQ Finished
MOV R10, #0
Loop1
ADD R2, R10, R10, LSR #1 ; Work out 3 x cachelevel
MOV R1, R0, LSR R2 ; bottom 3 bits are the Cache type for this level
AND R1, R1, #7 ; get those 3 bits alone

CMP R1, #2
BLT Skip ; no cache or only instruction cache at this level
MCR p15, 2, R10, c0, c0, 0 ; write CSSELR from R10
ISB ; ISB to sync the change to the CCSIDR
MRC p15, 1, R1, c0, c0, 0 ; read current CCSIDR to R1
AND R2, R1, #7 ; extract the line length field
ADD R2, R2, #4 ; add 4 for the line length offset (log2 16 bytes)
LDR R4, =0x3FF
ANDS R4, R4, R1, LSR #3 ; R4 is the max number on the way size (right aligned)
CLZ R5, R4 ; R5 is the bit position of the way size increment
MOV R9, R4 ; R9 working copy of the max way size (right aligned)
Loop2
LDR R7, =0x00007FFF
ANDS R7, R7, R1, LSR #13 ; R7 is the max number of the index size (right aligned)
Loop3
ORR R11, R10, R9, LSL R5 ; factor in the way number and cache number into R11
ORR R11, R11, R7, LSL R2 ; factor in the index number
MCR p15, 0, R11, c7, c10, 2 ; DCCSW, clean by set/way
SUBS R7, R7, #1 ; decrement the index
BGE Loop3
SUBS R9, R9, #1 ; decrement the way number
BGE Loop2
Skip
ADD R10, R10, #2 ; increment the cache number
CMP R3, R10
BGT Loop1
DSB
Finished
Similar approaches can be used for all cache maintenance operations.
Note
Cache maintenance by set/way does not happen on multiple processors, and cannot be made to happen atomically
for each address on each processor. Therefore, in multiprocessor systems, the use of cache maintenance to clean, or
clean and invalidate, the entire cache for coherency management with very large buffers or with buffers with
unknown address can fail to provide the expected coherency results because of speculation by other processors. The
only way that these instructions can be used in this way is to first ensure that all processors that might cause
speculative accesses to caches that need to be maintained are not capable of generating speculative accesses. This
can be achieved by ensuring that those processors have no memory locations marked as cacheable. Such an
approach can have very large system performance effects, and ARM advises implementers to use hardware
coherency mechanisms in systems where this will be an issue.
Boundary conditions for cache maintenance operations
Cache maintenance operations operate on the caches when the caches are enabled or when they are disabled.
For the address-based cache maintenance operations, the operations operate on the caches regardless of the memory
type and cacheability attributes marked for the memory address in the VMSA translation table entries or in the
PMSA section attributes. This means that the cache operations can apply regardless of:
• Whether the address accessed:
— Is Strongly-ordered, Device, or Normal memory.
— Has a Cacheable attribute, or the Non-cacheable attribute.
• Any applicable domain control of the address accessed.
• The access permissions for the address accessed, other than the effect of the stage 2 write permissions on
cache invalidation operations on a data or unified cache, as described in Virtualization Extensions upgrading
of maintenance operations on page B2-1284.
B2.2.8 The interaction of cache lockdown with cache maintenance operations

The interaction of cache lockdown and cache maintenance operations is IMPLEMENTATION DEFINED. However, an
architecturally-defined cache maintenance operation on a locked cache line must comply with the following general
rules:
• The effect of the following operations on locked cache entries is IMPLEMENTATION DEFINED:
— Cache clean by set/way, DCCSW.
— Cache invalidate by set/way, DCISW.
— Cache clean and invalidate by set/way, DCCISW.
— Instruction cache invalidate all, ICIALLU and ICIALLUIS.
However, one of the following approaches must be adopted in all these cases:
1. If the operation specified an invalidation, a locked entry is not invalidated from the cache. If the
operation specified a clean it is IMPLEMENTATION DEFINED whether locked entries are cleaned.
2. If an entry is locked down, or could be locked down, an IMPLEMENTATION DEFINED Data Abort
exception is generated, using the fault status code defined for this purpose in CP15 c5, see either:
• Exception reporting in a VMSA implementation on page B3-1406.
• Exception reporting in a PMSA implementation on page B5-1761.
This permits a usage model for cache invalidate routines to operate on a large range of addresses by
performing the required operation on the entire cache, without having to consider whether any cache entries
are locked. The operation performed is either an invalidate, or a clean and invalidate.
• The effect of the following operations is IMPLEMENTATION DEFINED:

— Cache clean by MVA, DCCMVAC and DCCMVAU.
— Cache invalidate by MVA, DCIMVAC.
— Cache clean and invalidate by MVA, DCCIMVAC.
However, one of the following approaches must be adopted in all these cases:
1. If the operation specified an invalidation, a locked entry is invalidated from the cache. For the clean
and invalidate operation, the entry must be cleaned before it is invalidated.
2. If the operation specified an invalidation, a locked entry is not invalidated from the cache. If the
operation specified a clean it is IMPLEMENTATION DEFINED whether locked entries are cleaned.
3. If an entry is locked down, or could be locked down, an IMPLEMENTATION DEFINED Data Abort
exception is generated, using the fault status code defined for this purpose in CP15 c5, see either:
• Exception reporting in a PMSA implementation on page B5-1761.
In an implementation that includes the Virtualization Extensions, if HCR.TIDCP is set to 1, any such
exception taken from a Non-secure PL1 mode is routed to Hyp mode, see Trapping accesses to
lockdown, DMA, and TCM operations on page B1-1251.
Note
An implementation that uses an abort mechanism for entries that can be locked down but are not actually locked
down must:
• Document the IMPLEMENTATION DEFINED instruction sequences that perform the required operations on
entries that are not locked down.
• Implement one of the other permitted alternatives for the locked entries.
ARM recommends that, when possible, such IMPLEMENTATION DEFINED instruction sequences use
architecturally-defined operations. This minimizes the number of customized operations required.
In addition, an implementation that uses an abort mechanism for handling cache maintenance operations on entries
that can be locked down but are not actually locked down, must provide a mechanism that ensures that no cache
entries are locked. The reset setting of the cache must be that no cache entries are locked.
On an ARMv7-A implementation, similar rules apply to TLB lockdown, see The interaction of TLB lockdown with
TLB maintenance operations on page B3-1379.
Additional cache functions for the implementation of lockdown

An implementation can add additional cache maintenance functions for the handling of lockdown in the
IMPLEMENTATION DEFINED spaces reserved for Cache Lockdown. Examples of possible functions are:
• Operations that unlock all cache entries.
• Operations that preload into specific levels of cache. These operations might be provided for instruction
caches, data caches, or both.
An implementation can add other functions as required.
B2.2.9 Ordering of cache and branch predictor maintenance operations

The following rules describe the effect of the memory order model on the cache and branch predictor maintenance
operations:
• All cache and branch predictor maintenance operations that do not specify an address execute, relative to
each other, in program order.
All cache and branch predictor operations that specify an address:
— Execute in program order relative to all cache and branch predictor operations that do not specify an
address.
— Execute in program order relative to all cache and branch predictor operations that specify the same
address.
— Can execute in any order relative to cache and branch predictor operations that specify a different
address.
• On an ARMv7-A implementation:
— Where a cache or branch predictor maintenance operation appears in program order before a change
to the translation tables, the architecture guarantees that the cache or branch predictor maintenance
operation uses the translations that were visible before the change to the translation tables.
— Where a change of the translation tables appears in program order before a cache or branch predictor
maintenance operation, software must execute the sequence outlined in TLB maintenance operations
and the memory order model on page B3-1379 before performing the cache or branch predictor
maintenance operation, to ensure that the maintenance operation uses the new translations.
• A DMB instruction causes the effect of all data or unified cache maintenance operations appearing in program
order before the DMB to be visible to all explicit load and store operations appearing in program order after the
DMB.
Also, a DMB instruction ensures that the effects of any data or unified cache maintenance operations appearing
in program order before the DMB are observable by any observer in the same required shareability domain
before any data or unified cache maintenance or explicit memory operations appearing in program order after
the DMB are observed by the same observer. Completion of the DMB does not guarantee the visibility of all data
to other observers. For example, all data might not be visible to a translation table walk, or to instruction
fetches.
• A DSB is required to guarantee the completion of all cache maintenance operations that appear in program
order before the DSB instruction.
• A context synchronization operation is required to guarantee the effects of any branch predictor maintenance
operation. This means that a context synchronization operation causes the effect of all completed branch
predictor maintenance operations appearing in program order before the context synchronization operation
to be visible to all instructions after the context synchronization operation.
Note
See Context synchronization operation in the Glossary for the definition of this term.
This means that, if a branch instruction appears after an invalidate branch predictor operation and before any
context synchronization operation, it is UNPREDICTABLE whether the branch instruction is affected by the
invalidate. Software must avoid this ordering of instructions, because it might cause UNPREDICTABLE
behavior.
• Any data or unified cache maintenance operation by MVA must be executed in program order relative to any
explicit load or store on the same processor to an address covered by the MVA of the cache operation if that
load or store is to Normal Cacheable memory. The order of memory accesses that result from the cache
maintenance operation, relative to any other memory accesses to Normal Cacheable memory, are subject to
the memory ordering rules. For more information, see Ordering requirements for memory accesses on
page A3-146.
Any data or unified cache maintenance operation by MVA can be executed in any order relative to any
explicit load or store on the same processor to an address covered by the MVA of the cache operation if that
load or store is not to Normal Cacheable memory.
• There is no restriction on the ordering of data or unified cache maintenance operations by MVA relative to
any explicit load or store on the same processor where the address of the explicit load or store is not covered
by the MVA of the cache operation. Where the ordering must be restricted, a DMB instruction must be inserted
to enforce ordering.
• There is no restriction on the ordering of a data or unified cache maintenance operation by set/way relative
to any explicit load or store on the same processor. Where the ordering must be restricted, a DMB instruction
must be inserted to enforce ordering.
• Software must execute a context synchronization operation after the completion of an instruction cache
maintenance operation, to guarantee that the effect of the maintenance operation is visible to any instruction
fetch.
In a VMSAv7 implementation, the scope of instruction cache maintenance depends on the type of the instruction
cache. For more information, see Instruction caches on page B3-1389.
Example B2-1 Cache cleaning operations for self-modifying code
The sequence of cache cleaning operations for a line of self-modifying code on a uniprocessor system is:
; Enter this code with <Rx> containing the new 32-bit instruction. Use STRH in the first
; line instead of STR for a 16-bit instruction.
STR <Rx>, [instruction location]
DCCMVAU [instruction location] ; Clean data cache by MVA to point of unification
DSB ; Ensure visibility of the data cleaned from the cache
ICIMVAU [instruction location] ; Invalidate instruction cache by MVA to PoU
BPIMVAU [instruction location] ; Invalidate branch predictor by MVA to PoU
DSB ; Ensure completion of the invalidations
ISB ; Synchronize fetched instruction stream
B2.2.10 System level caches

The system level architecture might define further aspects of the software view of caches and the memory model
that are not defined by the ARMv7 processor architecture. These aspects of the system level architecture can affect
the requirements for software management of caches and coherency. For example, a system design might introduce
additional levels of caching that cannot be managed using the CP15 maintenance operations defined by the ARMv7
architecture. Such caches are referred to as system caches.
Conceptually, three classes of system cache can be envisaged:
1. System caches which lie before the point of coherency and cannot be managed by any CP15 Cache
maintenance instructions. Such systems fundamentally undermine the concept of cache maintenance
instructions operating to the point of coherency, as they imply the use of non-architecture mechanisms to
manage coherency. ARM deprecates the use of such systems.
2. System caches which lie before the point of coherency and can be managed by CP15 Cache maintenance by
Address that imply to the point of coherency, but cannot be managed by CP15 Cache maintenance by set/way
instructions. Where maintenance of the entirety of such a cache must be performed, as is the case for power
management, it must be performed using non-architectural mechanisms.
3. System caches which lie beyond the point of coherency and so are invisible to software. The management of
such caches is outside the scope of architecture.
ARM also strongly recommends:
• For the maintenance of any such system cache:

— Physical, rather than virtual, addresses are used for address-based cache maintenance operations.
— Any IMPLEMENTATION DEFINED system cache maintenance operations include at least the set of
functions defined by Cache and branch predictor maintenance operations on page B2-1276, with the
number of levels of system cache operated on by these cache maintenance operations being
• Wherever possible, all caches that require maintenance to ensure coherency are included in the caches
affected by the architecturally-defined CP15 cache maintenance operations, so that the
architecturally-defined software sequences for managing the memory model and coherency are sufficient for
managing all caches in the system.
B2.3 IMPLEMENTATION DEFINED memory system features
B2.3 IMPLEMENTATION DEFINED memory system features

ARMv7 reserves space in the SCTLR for use with IMPLEMENTATION DEFINED features of the cache, and other
IMPLEMENTATION DEFINED features of the memory system architecture.
In particular, in ARMv7 the following memory system features are IMPLEMENTATION DEFINED:
• Cache lockdown, see Cache lockdown on page B2-1268.
• In VMSAv7, TLB lockdown, see TLB lockdown on page B3-1375.
• Tightly Coupled Memory (TCM) support, including any associated DMA scheme. The TCM Type Register,
TCMTR is required in all implementations, and if no TCMs are implemented this must be indicated by the
value of this register.
Note
For details of the optional TCMs and associated DMA scheme in ARMv6, see TCM support on
page D12-2505.
B2.3.1 ARMv7 CP15 register support for IMPLEMENTATION DEFINED features

The ARMv7 CP15 registers implementation includes the following support for IMPLEMENTATION DEFINED features
of the memory system:
• The TCM Type Register, TCMTR, in CP15 c0, must be implemented. The following conditions apply to this
register:
— If no TCMs are implemented, the TCMTR indicates zero-size TCMs. For more information see
TCMTR, TCM Type Register, VMSA on page B4-1708 or TCMTR, TCM Type Register, PMSA on
page B6-1927.
— If bits[31:29] are 0b100, the format of the rest of the register format is IMPLEMENTATION DEFINED. This
value indicates that the implementation includes TCMs that do not follow the ARMv6 usage model.
Other fields in the register might give more information about the TCMs.
• The CP15 c9 encoding space with <CRm> = {0-2, 5-7} is IMPLEMENTATION DEFINED for all values of <opc2>
and <opc1>. This space is reserved for branch predictor, cache and TCM functionality, for example
maintenance, override behaviors and lockdown. It permits:
— ARMv6 backwards compatible schemes.
— Alternative schemes.
— Cache and TCM lockdown registers, VMSA on page B4-1745, for a VMSA implementation.
— Cache and TCM lockdown registers, PMSA on page B6-1935, for a PMSA implementation.
• In a VMSAv7 implementation, part of the CP15 c10 encoding space is IMPLEMENTATION DEFINED and
reserved for TLB functionality, see TLB lockdown on page B3-1375.
• The CP15 c11 encoding space with <CRm> = {0-8, 15} is IMPLEMENTATION DEFINED for all values of <opc2>
and <opc1>. This space is reserved for DMA operations to and from the TCMs. It permits:
— An ARMv6 backwards compatible scheme.
— An alternative scheme.
— VMSA CP15 c11 register summary, reserved for TCM DMA registers on page B3-1473, for a VMSA
implementation.
— PMSA CP15 c11 register summary, reserved for TCM DMA registers on page B5-1784, for a PMSA
implementation.
B2.4 Pseudocode details of general memory system operations

This section contains pseudocode describing general memory operations, in the subsections:
• Memory data type definitions.
• Basic memory accesses on page B2-1292.
• Interfaces to memory system specific pseudocode on page B2-1292.
• Aligned memory accesses on page B2-1293.
• Unaligned memory accesses on page B2-1294.
• Reverse endianness on page B2-1295.
• Exclusive monitors operations on page B2-1296.
• Access permission checking on page B2-1297.
• Default memory access decode on page B2-1298.
• Data Abort exception on page B2-1300.
The pseudocode in this section applies to both VMSA and PMSA implementations. Additional pseudocode for
memory operations is given in:
• Pseudocode details of VMSA memory system operations on page B3-1498.
• Pseudocode details of PMSA memory system operations on page B5-1798.
B2.4.1 Memory data type definitions

The following data type definitions are used by the memory system pseudocode functions:
// Types of memory
enumeration MemType {MemType_Normal, MemType_Device, MemType_StronglyOrdered};
// Memory attributes descriptor
type MemoryAttributes is (
MemType type,
bits(2) innerattrs, // The possible encodings for each attributes field are as follows:
bits(2) outerattrs, // '00' = Non-cacheable; '10' = Write-Through
// '11' = Write-Back; '01' = RESERVED
bits(2) innerhints, // the possible encodings for the hints are as follows
bits(2) outerhints, // '00' = No-Allocate; '01' = Write-Allocate
// '10' = Read-Allocate; ;'11' = Read-Allocate and Write-Allocate
boolean innertransient,
boolean outertransient,
boolean shareable,
boolean outershareable
)
// Physical address type, with extra bits used by some VMSA features
type FullAddress is (
bits(40) physicaladdress,
bit NS // '0' = Secure, '1' = Non-secure
)
// Descriptor used to access the underlying memory array
type AddressDescriptor is (
MemoryAttributes memattrs,
FullAddress paddress
)
// Access permissions descriptor
type Permissions is (
bits(3) ap, // Access permission bits
bit xn, // Execute-never bit

bit pxn // Privileged execute-never bit
)
B2.4.2 Basic memory accesses

The _Mem[] function performs single-copy atomic, aligned, little-endian memory accesses to the underlying physical
memory array of bytes:
bits(8*size) _Mem[AddressDescriptor memaddrdesc, integer size]

assert size == 1 || size == 2 || size == 4 || size == 8;
_Mem[AddressDescriptor memaddrdesc, integer size] = bits(8*size) value

assert size == 1 || size == 2 || size == 4 || size == 8;
This function addresses the array using memaddrdesc.paddress, that supplies:
• A 32-bit physical address.
• An 8-bit physical address extension, that is treated as additional high-order bits of the physical address. This
extension is always 0b00000000 in the PMSA.
• A single NS bit to select between Secure and Non-secure parts of the array. This bit is always 0 if the Security
Extensions are not implemented.
The actual implemented array of memory might be smaller than the 241 bytes implied. In this case, the scheme for
aliasing is IMPLEMENTATION DEFINED, or some parts of the address space might give rise to external aborts. For
more information, see:
• External aborts on page B3-1402 for a VMSA implementation.
• External aborts on page B5-1759 for a PMSA implementation.
Implementations might generate synchronous or asynchronous external aborts as a result of memory accesses, for
a variety of IMPLEMENTATION DEFINED reasons. The handling and reporting of these aborts is outside the scope of
the pseudocode.
The attributes in memaddrdesc.memattrs are used by the memory system to determine caching and ordering behaviors
as described in Memory types and attributes and the memory order model on page A3-123.
B2.4.3 Interfaces to memory system specific pseudocode

The following functions call the VMSA-specific or PMSA-specific functions to handle Alignment faults and
perform address translation.
// AlignmentFault()
// ================
AlignmentFault(bits(32) address, boolean iswrite)

case MemorySystemArchitecture() of
when MemArch_VMSA
taketohypmode = CurrentModeIsHyp() || HCR.TGE == '1';
secondstageabort = FALSE;
AlignmentFaultV(address, iswrite, taketohypmode, secondstageabort)
when MemArch_PMSA
AlignmentFaultP(address, iswrite);
// TranslateAddress()
// ==================
AddressDescriptor TranslateAddress(bits(32) VA, boolean ispriv, boolean iswrite,

integer size, boolean wasaligned)
case MemorySystemArchitecture() of
when MemArch_VMSA return TranslateAddressV(VA, ispriv, iswrite, size, wasaligned);
when MemArch_PMSA return TranslateAddressP(VA, ispriv, iswrite, wasaligned);
B2.4.4 Aligned memory accesses

The MemA[] function performs a memory access at the current privilege level, and the MemA_unpriv[] function
performs an access that is always unprivileged. In both cases, the architecture requires the access to be aligned, and
in ARMv7 the function generates an Alignment fault if it is not.
Note
In versions of the architecture before ARMv7, if the SCTLR.A and SCTLR.U bits are both 0, an unaligned access
is forced to be aligned by replacing the low-order address bits with zeros.
// MemA[]
// ======
bits(8*size) MemA[bits(32) address, integer size]

return MemA_with_priv[address, size, CurrentModeIsNotUser(), TRUE];
MemA[bits(32) address, integer size] = bits(8*size) value

MemA_with_priv[address, size, CurrentModeIsNotUser(), TRUE] = value;
return;
// MemA_unpriv[]
// =============
bits(8*size) MemA_unpriv[bits(32) address, integer size]

return MemA_with_priv[address, size, FALSE, TRUE];
MemA_unpriv[bits(32) address, integer size] = bits(8*size) value

MemA_with_priv[address, size, FALSE, TRUE] = value;
return;
// MemA_with_priv[]
// ================
// Non-assignment form
bits(8*size) MemA_with_priv[bits(32) address, integer size, boolean privileged, boolean wasaligned]
// Sort out alignment

if address == Align(address, size) then
VA = address;
elsif ArchVersion() >= 7 || SCTLR.A == '1' || SCTLR.U == '1' then
// Unaligned access always faults in ARMv7, SCTLR.U is RAO.
AlignmentFault(address, FALSE);
else
// Legacy non alignment-checking configuration, SCTLR.{A, U} == {'0', '0'}
VA = Align(address, size);
// MMU or MPU
memaddrdesc = TranslateAddress(VA, privileged, FALSE, size, wasaligned);
// Memory array access, and sort out endianness

value = _Mem[memaddrdesc, size];
if CPSR.E == '1' then
value = BigEndianReverse(value, size);
return value;
// Assignment form
MemA_with_priv[bits(32) address, integer size, boolean privileged,
boolean wasaligned] = bits(8*size) value
// Sort out alignment

VA = address;
elsif ArchVersion() >= 7 || SCTLR.A == '1' || SCTLR.U == '1' then
// Unaligned access always faults in ARMv7, SCTLR.U is RAO.
AlignmentFault(address, TRUE);
else
// Legacy non alignment-checking configuration, SCTLR.{A, U} == {'0', '0'}
VA = Align(address, size);
// MMU or MPU
memaddrdesc = TranslateAddress(VA, privileged, TRUE, size, wasaligned);
// Effect on exclusives
if memaddrdesc.memattrs.shareable then
ClearExclusiveByAddress(memaddrdesc.paddress, ProcessorID(), size);
// Sort out endianness, then memory array access

_Mem[memaddrdesc,size] = value;
return;
B2.4.5 Unaligned memory accesses

The MemU[] function performs a memory access at the current privilege level, and the MemU_unpriv[] function
performs an access that is always unprivileged.
In both cases:
• For an access from Hyp mode:

— If the HSCTLR.A bit is 0, unaligned accesses are supported.
— If the HSCTLR.A bit is 1, unaligned accesses generate Alignment faults.
• For an access from any other mode:

— If the SCTLR.A bit is 0, unaligned accesses are supported.
— If the SCTLR.A bit is 1, unaligned accesses produce Alignment faults.
Note
In versions of the architecture before ARMv7, if the SCTLR.A and SCTLR.U bits are both 0, an unaligned access
is forced to be aligned by replacing the low-order address bits with zeros.
// MemU[]
// ======
bits(8*size) MemU[bits(32) address, integer size]

return MemU_with_priv[address, size, CurrentModeIsNotUser()];
MemU[bits(32) address, integer size] = bits(8*size) value

MemU_with_priv[address, size, CurrentModeIsNotUser()] = value;
return;
// MemU_unpriv[]
// =============
bits(8*size) MemU_unpriv[bits(32) address, integer size]

return MemU_with_priv[address, size, FALSE];
MemU_unpriv[bits(32) address, integer size] = bits(8*size) value

MemU_with_priv[address, size, FALSE] = value;
return;
// MemU_with_priv[]
// ================
//
// Due to single-copy atomicity constraints, the aligned accesses are distinguished from
// the unaligned accesses:
// * aligned accesses are performed at their size
// * unaligned accesses are expressed as a set of byte accesses.
// Non-assignment form
bits(8*size) MemU_with_priv[bits(32) address, integer size, boolean privileged]

bits(8*size) value;
// Legacy non alignment-checking configuration forces access to be aligned

if ArchVersion() < 7 && SCTLR.A == '0' && SCTLR.U == '0' then
address = Align(address, size);
// Do aligned access, take alignment fault, or do sequence of bytes

value = MemA_with_priv[address, size, privileged, TRUE];
elsif HaveVirtExt() && !IsSecure() && CurrentModeIsHyp() && HSCTLR.A == '1' then
// Access from Hyp mode faults if HSCTLR.A == '1'
elsif !CurrentModeIsHyp() && SCTLR.A == '1' then

// Access from mode other than Hyp faults if SCTLR.A == '1'
else
// Permitted unaligned access. For ARMv7 this is either:
// HSCTLR.A == '0', for an access from Hyp mode.
// SCTLR.A == '0', for an access from a mode other than Hyp mode.
for i = 0 to size-1
value<8*i+7:8*i> = MemA_with_priv[address+i, 1, privileged, FALSE];
return value;
// Assignment form
MemU_with_priv[bits(32) address, integer size, boolean privileged] = bits(8*size) value
// Legacy non alignment-checking configuration forces access to be aligned

if ArchVersion() < 7 && SCTLR.A == '0' && SCTLR.U == '0' then
address = Align(address, size);
// Do aligned access, take alignment fault, or do sequence of bytes

MemA_with_priv[address, size, privileged, TRUE] = value;
elsif HaveVirtExt() && !IsSecure() && CurrentModeIsHyp() && HSCTLR.A == '1' then
// Access from Hyp mode faults if HSCTLR.A == '1'
elsif !CurrentModeIsHyp() && SCTLR.A == '1' then

// Access from mode other than Hyp faults if SCTLR.A == '1'
else
// Permitted unaligned access. For ARMv7 this is either:
// HSCTLR.A == '0', for an access from Hyp mode.
// SCTLR.A == '0', for an access from a mode other than Hyp mode.
for i = 0 to size-1
MemA_with_priv[address+i, 1, privileged, FALSE] = value<8*i+7:8*i>;
return;
B2.4.6 Reverse endianness

The following pseudocode describes the operation to reverse endianness:
// BigEndianReverse()
// ==================
bits(8*N) BigEndianReverse (bits(8*N) value, integer N)

assert N == 1 || N == 2 || N == 4 || N == 8;
bits(8*N) result;
case N of
when 1
result<7:0> = value<7:0>;
when 2
when 4
result<23:16> = value<15:8>;
result<15:8> = value<23:16>;
when 8
result<55:48> = value<15:8>;
result<47:40> = value<23:16>;
result<39:32> = value<31:24>;
result<31:24> = value<39:32>;
result<23:16> = value<47:40>;
result<15:8> = value<55:48>;
return result;
B2.4.7 Exclusive monitors operations

The SetExclusiveMonitors() function sets the exclusive monitors for a Load-Exclusive instruction. The
ExclusiveMonitorsPass() function checks whether a Store-Exclusive instruction still has possession of the exclusive
monitors and therefore completes successfully.
// SetExclusiveMonitors()
// ======================
SetExclusiveMonitors(bits(32) address, integer size)

memaddrdesc = TranslateAddress(address, CurrentModeIsNotUser(), FALSE, size, TRUE);
MarkExclusiveGlobal(memaddrdesc.paddress, ProcessorID(), size);
MarkExclusiveLocal(memaddrdesc.paddress, ProcessorID(), size);
// ExclusiveMonitorsPass()
// =======================
boolean ExclusiveMonitorsPass(bits(32) address, integer size)

// It is IMPLEMENTATION DEFINED whether the detection of memory aborts happens
// before or after the check on the local Exclusive Monitor. As a result a failure
// of the local monitor can occur on some implementations even if the memory
// access would give an memory abort.
if address != Align(address, size) then

else
memaddrdesc = TranslateAddress(address, CurrentModeIsNotUser(), TRUE, size, TRUE);
passed = IsExclusiveLocal(memaddrdesc.paddress, ProcessorID(), size);
if passsed then
ClearExclusiveLocal(ProcessorID());
passed = passed && IsExclusiveGlobal(memaddrdesc.paddress, ProcessorID(), size);
return passed;
The MarkExclusiveGlobal() procedure takes as arguments a FullAddress, paddress, the processor identifier
processorid and the size of the transfer. The procedure records that processor processorid has requested exclusive
access covering at least size bytes from address paddress. The size of region marked as exclusive is
IMPLEMENTATION DEFINED, up to a limit of 2KB, and no smaller than two words, and aligned in the address space
to the size of the region. It is UNPREDICTABLE whether this causes any previous request for exclusive access to any
other address by the same processor to be cleared.
MarkExclusiveGlobal(FullAddress paddress, integer processorid, integer size)
The MarkExclusiveLocal() procedure takes as arguments a FullAddress paddress, the processor identifier
processorid and the size of the transfer. The procedure records in a local record that processor processorid has
requested exclusive access to an address covering at least size bytes from address paddress. The size of the region
marked as exclusive is IMPLEMENTATION DEFINED, and can at its largest cover the whole of memory, but is no
smaller than two words, and is aligned in the address space to the size of the region. It is IMPLEMENTATION DEFINED
whether this procedure also performs a MarkExclusiveGlobal() using the same parameters.
MarkExclusiveLocal(FullAddress paddress, integer processorid, integer size)
The IsExclusiveGlobal() function takes as arguments a FullAddress paddress, the processor identifier processorid
and the size of the transfer. The function returns TRUE if the processor processorid has marked in a global record
an address range as exclusive access requested that covers at least the size bytes from address paddress. It is
IMPLEMENTATION DEFINED whether it returns TRUE or FALSE if a global record has marked a different address as
exclusive access requested. If no address is marked in a global record as exclusive access, IsExclusiveGlobal()
returns FALSE.
boolean IsExclusiveGlobal(FullAddress paddress, integer processorid, integer size)
The IsExclusiveLocal() function takes as arguments a FullAddress paddress, the processor identifier processorid
and the size of the transfer. The function returns TRUE if the processor processorid has marked an address range
as exclusive access requested that covers at least the size bytes from address paddress. It is IMPLEMENTATION
DEFINED whether this function returns TRUE or FALSE if the address marked as exclusive access requested does
not cover all of the size bytes from address paddress. If no address is marked as exclusive access requested, then
this function returns FALSE. It is IMPLEMENTATION DEFINED whether this result is ANDed with the result of
IsExclusiveGlobal() with the same parameters.
boolean IsExclusiveLocal(FullAddress paddress, integer processorid, integer size)
The ClearExclusiveByAddress() procedure takes as arguments a FullAddress paddress, the processor identifier
processorid, and the size of the transfer. The procedure clears the global records of all processors, other than
processorid, for which an address region including any of the size bytes starting from paddress has had a request
for an exclusive access. It is IMPLEMENTATION DEFINED whether the equivalent global record of the processor
processorid is also cleared if any of the size bytes starting from paddress has had a request for an exclusive access,
or if any other address has had a request for an exclusive access.
ClearExclusiveByAddress(FullAddress paddress, integer processorid, integer size)
The ClearExclusiveLocal() procedure takes as arguments the processor identifier processorid. The procedure clears
the local record of processor processorid for which an address has had a request for an exclusive access. It is
IMPLEMENTATION DEFINED whether this operation also clears the global record of processor processorid that an
address has had a request for an exclusive access.
ClearExclusiveLocal(integer processorid)
B2.4.8 Access permission checking

The function CheckPermission() is used by both the VMSA and PMSA architectures to perform access permission
checking based on attributes derived from the translation tables or region descriptors. The domain and
sectionnotpage arguments are only relevant for the VMSA architecture.
The interpretation of the access permissions is shown in:

• Access permissions on page B3-1352, for a VMSA implementation.
• Access permissions on page B5-1753, for a PMSA implementation.
The following pseudocode describes the checking of the access permission:
// CheckPermission()
// =================
// Function used for permission checking at stage 1 of the translation process
// for the:
// VMSA Long-descriptor format
// VMSA Short-descriptor format
// PMSA format.
CheckPermission(Permissions perms, bits(32) mva, integer level, bits(4) domain, boolean iswrite,
boolean ispriv, boolean taketohypmode, boolean LDFSRformat)
// variable for the DataAbort function with fixed values
ipavalid = FALSE;
s2fs1walk = FALSE;
ipa = bits(40) UNKNOWN;
if SCTLR.AFE == '1' then

perms.ap<0> = '1';
case perms.ap of
when '000' abort = TRUE;
when '001' abort = !ispriv;
when '010' abort = !ispriv && iswrite;
when '011' abort = FALSE;
when '101' abort = !ispriv || iswrite;
when '110' abort = iswrite;
when '111'
if MemorySystemArchitecture() == MemArch_VMSA then
abort = iswrite;
else
UNPREDICTABLE;
if abort then
DataAbort(mva, ipa, domain, level, iswrite, DAbort_Permission, taketohypmode,
secondstageabort, ipavalid, LDFSRformat, s2fs1walk);
return;
B2.4.9 Default memory access decode

The function DefaultTEXDecode() is used by both the VMSA and PMSA architectures to decode the texcb and S
attributes derived from the translation tables or region descriptors.
The following sections show the interpretation of the arguments:

• For a VMSA implementation, Short-descriptor format memory region attributes, without TEX remap on
page B3-1363.
• For a PMSA implementation, C, B, and TEX[2:0] encodings on page B5-1754.
The following pseudocode describes the default memory access decoding for a PMSA implementation, and for a
VMSA implementation when TEX remap is not enabled:
// DefaultTEXDecode()
// ==================
MemoryAttributes DefaultTEXDecode(bits(5) texcb, bit S)
MemoryAttributes memattrs;
case texcb of
when '00000' // Strongly-ordered
memattrs.type = MemType_StronglyOrdered;
memattrs.innerattrs = bits(2) UNKNOWN;
memattrs.innerhints = bits(2) UNKNOWN;
memattrs.outerattrs = bits(2) UNKNOWN;
memattrs.outerhints = bits(2) UNKNOWN;
memattrs.shareable = TRUE;
when '00001' // Shareable Device
memattrs.type = MemType_Device;
when '00010' // Outer and Inner Write-Through, no Write-Allocate
memattrs.type = MemType_Normal;
memattrs.innerattrs = '10';
memattrs.innerhints = '10';
memattrs.outerattrs = '10';
memattrs.outerhints = '10';
memattrs.shareable = (S == '1');
when '00011' // Outer and Inner Write-Back, no Write-Allocate
when '00100' // Outer and Inner Non-cacheable
when '00110'
IMPLEMENTATION_DEFINED setting of memattrs;
when '00111' // Outer and Inner Write-Back, Write-Allocate
when '01000' // Non-shareable Device
when "1xxxx" // Cacheable, <3:2> = Outer attrs, <1:0> = Inner attrs
hintsattrs = ConvertAttrsHints(texcb<1:0>);
memattrs.innerattrs = hintsattrs<1:0>;
memattrs.innerhints = hintsattrs<3:2>;
hintsattrs = ConvertAttrsHints(texcb<3:2>);
memattrs.outerattrs = hintsattrs<1:0>;
memattrs.outerhints = hintsattrs<3:2>;
otherwise
UNPREDICTABLE;
memattrs.outershareable = memattrs.shareable;
return memattrs;
B2.4.10 Data Abort exception

The DataAbort() function generates a Data Abort exception, and is used by both the VMSA and PMSA architectures
to set the fault-reporting registers to indicate:
• The type of the abort, including the distinction between section and page on a VMSA implementation.
• On a VMSA implementation that is using the Short-descriptor translation table format, the domain, if
appropriate.
• Whether the access was a read or write.
For a synchronous abort, it also sets the DFAR to the MVA of the abort.
For details of the fault encoding values, see:
— PL1 fault reporting with the Short-descriptor translation table format on page B3-1411.
— Fault reporting with the Long-descriptor translation table format on page B3-1413.
• For a PMSA implementation, Fault Status Register encodings for the PMSA on page B5-1763.
An implementation might also set any IMPLEMENTATION DEFINED auxiliary fault reporting registers.
// Data Abort types.
enumeration DAbort {DAbort_AccessFlag,

DAbort_Alignment,
DAbort_Background,
DAbort_Domain,
DAbort_Permission,
DAbort_Translation,
DAbort_SyncExternal,
DAbort_SyncExternalonWalk,
DAbort_SyncParity,
DAbort_SyncParityonWalk,
DAbort_AsyncParity,
DAbort_AsyncExternal,
DAbort_SyncWatchpoint,
DAbort_AsyncWatchpoint,
DAbort_TLBConflict,
DAbort_Lockdown,
DAbort_Coproc,
DAbort_ICacheMaint};
// DataAbort()
// ===========
DataAbort(bits(32) vaddress, bits(40) ipaddress, bits(4) domain, integer level, boolean iswrite,
DAbort type, boolean taketohypmode, boolean secondstageabort, boolean ipavalid,
boolean LDFSRformat, boolean s2fs1walk)
// Data Abort handling for Memory Management generated aborts
if MemorySystemArchitecture() == MemArch_VMSA then

if !taketohypmode then
bits(14) DFSRString = Zeros(14);
if type IN {DAbort_AsyncParity,DAbort_AsyncExternal,DAbort_AsyncWatchpoint} ||
(type == DAbort_SyncWatchpoint && UInt(DBGDIDR.Version) <= 4) then
DFAR = bits(32) UNKNOWN;
else
DFAR = vaddress;
if LDFSRformat then
// new format
DFSRString<13> = if TLBLookupCameFromCacheMaintenance() then '1' else '0';
if type IN {DAbort_AsyncExternal,DAbort_SyncExternal} then
DFSRString<12> = IMPLEMENTATION_DEFINED;
else
DFSRString<12> = '0';
if type IN {DAbort_SyncWatchpoint,DAbort_AsyncWatchpoint} then
DFSRString<11> = bit UNKNOWN;
else
DFSRString<11> = if iswrite then '1' else '0';

DFSRString<8:6> = bits(3) UNKNOWN;
DFSRString<5:0> = EncodeLDFSR(type, level);
else
if HaveLPAE() then
DFSRString<13> = if TLBLookupCameFromCacheMaintenance() then '1' else '0';
else
else
domain_valid = (type == DAbort_Domain ||
(level == 2 &&
type IN {DAbort_Translation,DAbort_AccessFlag,
DAbort_SyncExternalonWalk,DAbort_SyncParityonWalk}) ||
(!HaveLPAE() && type == DAbort_Permission));
if domain_valid then
DFSRString<7:4> = domain;
else
DFSRString<7:4> = bits(4) UNKNOWN;
DFSRString<10,3:0> = EncodeSDFSR(type, level);
DFSR<13:0> = DFSRString;
else
bits(25) HSRString = Zeros(25);
bits(6) ec;
HDFAR = vaddress;
if ipavalid then
HPFAR<31:4> = ipaddress<39:12>;
if secondstageabort then
ec = '100100';
HSRString<24:16> = LSInstructionSyndrome();
else
ec = '100101';
HSRString<24> = '0'; // Instruction syndrome not valid
HSRString<9> = IMPLEMENTATION_DEFINED;
else
HSRString<9> = '0';
HSRString<8> = if TLBLookupCameFromCacheMaintenance() then '1' else '0';
HSRString<7> = if s2fs1walk then '1' else '0';
HSRString<6> = if iswrite then '1' else '0';
HSRString<5:0> = EncodeLDFSR(type, level);
WriteHSR(ec, HSRString);
else
// PMSA
bits(14) DFSRString = Zeros(14);
if type IN {DAbort_AsyncParity,DAbort_AsyncExternal,DAbort_AsyncWatchpoint} ||
(type == DAbort_SyncWatchpoint && UInt(DBGDIDR.Version) <= 4) then
DFAR = bits(32) UNKNOWN;
elseif type == DAbort_SyncParity then
DFAR = IMPLEMENTATION_DEFINED vaddress or unchanged;
else
DFAR = vaddress;
else
else

DFSRString<10,3:0> = EncodePMSAFSR(type);
DFSR<13:0> = DFSRString;
TakeDataAbortException();
return;
For a VMSA implementation, the EncodeSDFSR() pseudocode function returns the required fault code for a fault
status register that is reporting a Data Abort when using the Short-descriptor translation table format:
// EncodeSDFSR()
// =============
// Function that gives the Short-descriptor FSR code for
// different types of Data Abort
bits(5) EncodeSDFSR(DAbort type, integer level)
bits(5) result;
case type of
when DAbort_AccessFlag
if level == 1 then
result<4:0> = '00011';
else
result<4:0> = '00110';
when DAbort_Alignment
result<4:0> = '00001';
when DAbort_Permission
result<4:2> = '011';
result<0> = '1';
result<1> = level<1>;
when DAbort_Domain
result<4:2> = '010';
result<0> = '1';
when DAbort_Translation
result<4:2> = '001';
result<0> = '1';
when DAbort_SyncExternal
result<4:0> = '01000';
when DAbort_SyncExternalonWalk
result<4:2> = '011';
result<0> = '0';
when DAbort_SyncParity
result<4:0> = '11001';
when DAbort_SyncParityonWalk
result<4:2> = '111';
result<0> = '0';
when DAbort_AsyncParity
result<4:0> = '11000';
when DAbort_AsyncExternal
result<4:0> = '10110';
when DAbort_SyncWatchpoint, DAbort_AsyncWatchpoint
result<4:0> = '00010';
when DAbort_TLBConflict
result<4:0> = '10000';
when DAbort_Lockdown
result<4:0> = '10100';
when DAbort_Coproc
result<4:0> = '11010';
when DAbort_ICacheMaint
result<4:0> = '00100';
otherwise
result<4:0> = bits(5) UNKNOWN;
return result;
For a VMSA implementation, the EncodeLDFSR() pseudocode function returns the required fault code for a fault
status register that is reporting a Data Abort when using the Long-descriptor translation table format:
// EncodeLDFSR()
// =============
// Function that gives the Long-descriptor FSR code for
bits(6) EncodeLDFSR(DAbort type, integer level)
bits(6) result;
case type of
when DAbort_AccessFlag
result<5:2> = '0010';
result<1:0> = level<1:0>;
result<5:0> = '100001';
result<5:2> = '0011';
when DAbort_Translation
result<5:2> = '0001';
result<5:0> = '010000';
when DAbort_SyncExternalonWalk
result<5:2> = '0101';
result<5:0> = '011000';
when DAbort_SyncParityonWalk
result<5:2> = '0111';
result<5:0> = '011001';
result<5:0> = '010001';
result<5:0> = '100010';
when DAbort_TLBConflict
result<5:0> = '110000';
result<5:0> = '110100';
when DAbort_Coproc
result<5:0> = '111010';
otherwise
return result;
For a PMSA implementation, the EncodePMSAFSR() pseudocode function returns the required fault code for a fault
status register that is reporting a Data Abort:
// EncodePMSAFSR()
// ===============
// Function that gives the PMSA FSR code for
bits(5) EncodePMSAFSR(DAbort type)
bits(5) result;
case type of
result<4:0> = '00001';
result<4:0> = '01101';
result<4:0> = '01000';
result<4:0> = '11001';
result<4:0> = '11000';
result<4:0> = '10110';
result<4:0> = '00010';
when DAbort_Background
result<4:0> = '00000';
result<4:0> = '10100';
when DAbort_Coproc
result<4:0> = '11010';
otherwise
return result;
Chapter B3
Virtual Memory System Architecture (VMSA)
This chapter provides a system level view of the Virtual Memory System Architecture (VMSA), the memory system
architecture of an ARMv7-A implementation. It contains the following sections:
• About the VMSA on page B3-1306.
• The effects of disabling MMUs on VMSA behavior on page B3-1312.
• Translation tables on page B3-1316.
• Secure and Non-secure address spaces on page B3-1320.
• Short-descriptor translation table format on page B3-1321.
• Long-descriptor translation table format on page B3-1334.
• Memory access control on page B3-1352.
• Memory region attributes on page B3-1362.
• Translation Lookaside Buffers (TLBs) on page B3-1374.
• Caches in a VMSA implementation on page B3-1389.
• Virtual Address to Physical Address translation operations on page B3-1434.
• About the system control registers for VMSA on page B3-1440.
• Organization of the CP14 registers in a VMSA implementation on page B3-1464.
• Functional grouping of VMSAv7 system control registers on page B3-1486.
• Pseudocode details of VMSA memory system operations on page B3-1498.
Note
For an ARMv7-A implementation, this chapter must be read with Chapter B2 Common Memory System
Architecture Features.
B3 Virtual Memory System Architecture (VMSA)
B3.1 About the VMSA
B3.1 About the VMSA

Note
• This chapter describes the ARMv7 VMSA, including the Security Extensions, the Multiprocessing
Extensions, the Large Physical Address Extension (LPAE), and the Virtualization Extensions. This is referred
to as the Extended VMSAv7. This chapter also describes the differences in VMSAv7 implementations that
do not include some or all of these extensions.
• For details of the VMSA differences in previous versions of the ARM architecture, see:
— VMSA support on page D12-2506 for ARMv6.
— Virtual memory support on page D15-2590 for the ARMv4 and ARMv5 architectures.
In VMSAv7, a Memory Management Unit (MMU) controls address translation, access permissions, and memory
attribute determination and checking, for memory accesses made by the processor. The MMU is controlled by
system control registers, that can also disable the MMU. This chapter includes a definition the behavior of the
memory system when the MMU is disabled.
The Extended VMSAv7 provides multiple stages of memory system control, as follows:
• For operation in Secure state, a single stage of memory system control.
• For operation in Non-secure state, up to two stages of memory system control:
— When executing at PL2, a single stage of memory system control.
— When executing at PL1 or PL0, two stages of memory system control.
Each supported stage of memory system control is provided by an MMU, with its own independent set of controls.
Therefore, the Extended VMSAv7 provides the following MMUs:
• Secure PL1&0 stage 1 MMU.
• Non-secure PL2 stage 1 MMU.
• Non-secure PL1&0 stage 1 MMU.
• Non-secure PL1&0 stage 2 MMU.
Note
The model of having a separate MMU for each stage of memory control is an architectural abstraction. It does not
indicate any specific hardware requirements for an Extended VMSAv7 processor implementation. The architecture
requires only that the behavior of any VMSAv7 processor matches the behavior described in this manual.
These features mean the Extended VMSAv7 can support a hierarchy of software supervision, for example an
Operating System and a hypervisor.
Each MMU uses a set of address translations and associated memory properties held in memory mapped tables
called translation tables.
If an implementation does not include the Security Extensions, it has only a single Security state, with a single MMU
with controls equivalent to the Secure state MMU controls.
If an implementation does not include the Virtualization Extensions, then:

• It does not support execution at PL2.
• It Non-secure state, it provides only the Non-secure PL1&0 stage 1 MMU.
For an MMU, the translation tables define the following properties:
Access to the Secure or Non-secure address map

If an implementation includes the Security Extensions, the translation table entries determine
whether an access from Secure state accesses the Secure or the Non-secure address map. Any access
from Non-secure state accesses the Non-secure address map.
B3.1 About the VMSA
Memory access permission control

This controls whether a program is permitted to access a memory region. For instruction and data
access, the possible settings are:
• No access.
• Read-only.
• Write-only.
• Read/write.
For instruction accesses, additional controls determine whether instructions can be fetched and
executed from the memory region.
If a processor attempts an access that is not permitted, a memory fault is signaled to the processor.
Memory region attributes

These describe the properties of a memory region. The top-level attribute, the Memory type, is one
of Strongly-ordered, Device, or Normal. Device and Normal memory regions can have additional
attributes, see Summary of ARMv7 memory attributes on page A3-124.
Address translation mappings

An address translation maps an input address to an output address.
A stage 1 translation takes the address of an explicit data access or instruction fetch, a virtual
address (VA), as the input address, and translates it to a different output address:
• If only one stage of translation is provided, this output address is the physical address (PA).
• If two stages of address translation are provided, the output address of the stage 1 translation
is an intermediate physical address (IPA).
Note
In the ARMv7 architecture, a software agent, such as an Operating System, that uses or defines stage
1 memory translations, might be unaware of the distinction between IPA and PA.
A stage 2 translation translates the IPA to a PA.

The possible Security states and privilege levels of memory accesses define a set of translation
regimes. Figure B3-1 shows the VMSA translation regimes, and their associated translation stages
and MMUs.
Translation regime
Secure PL1&0 stage 1 MMU
Secure PL1&0 VA PA, Secure or Non-secure
Non-secure PL2 stage 1 MMU

Non-secure PL2 VA PA, Non-secure only
Non-secure PL1&0 VA Non-secure PL1&0 IPA Non-secure PL1&0 PA, Non-secure only
stage 1 MMU stage 2 MMU
Figure B3-1 VMSA translation regimes, and associated MMUs
Note
Conceptually, a translation regime that has only a stage 1 MMU is equivalent to a regime with a fixed, flat stage 2
mapping from IPA to PA.
System Control coprocessor (CP15) registers control the VMSA, including defining the location of the translation
tables, and enabling and configuring the MMUs. Also, they report any faults that occur on a memory access. For
more information, see Functional grouping of VMSAv7 system control registers on page B3-1486.
The following sections give an overview of the VMSA, and of the implementation options for VMSAv7:
• Address types used in a VMSA description on page B3-1308.
• Address spaces in a VMSA implementation on page B3-1308.
• About address translation on page B3-1309.
B3.1 About the VMSA
The remainder of the chapter fully describes the VMSA, including the different implementation options, as
summarized in Organization of this chapter on page B3-1311.
B3.1.1 Address types used in a VMSA description

A description of VMSAv7 refers to the following address types.
Note
These descriptions relate to a VMSAv7 description and therefore sometimes differ from the generic definitions
given in the Glossary.
Virtual Address (VA)

An address used in an instruction, as a data or instruction address, is a Virtual Address (VA).
An address held in the PC, LR, or SP, is a VA.
The VA map runs from zero to the size of the VA space. For ARMv7, the maximum VA space is
4GB, giving a maximum VA range of 0x00000000-0xFFFFFFFF.
Modified Virtual Address (MVA)

On an implementation that implements and uses the FCSE, the FCSE takes a VA and transforms it
to an MVA. This is a preliminary address translation, performed before the address translation
described in this chapter.
Otherwise, MVA is a synonym for VA.
Note
Appendix D10 Fast Context Switch Extension (FCSE) describes the FCSE. From ARMv6, ARM
deprecates any use of the FCSE. The FCSE is:
• OPTIONAL and deprecated in an ARMv7 implementation that does not include the
Multiprocessing Extensions.
• Obsolete from the introduction of the Multiprocessing Extensions.
Intermediate Physical Address (IPA)

In a translation regime that provides two stages of address translation, the IPA is the address after
the stage 1 translation, and is the input address for the stage 2 translation.
In a translation regime that provides only one stage of address translation, the IPA is identical to the
PA.
In ARM VMSA implementations, only one stage of address translation is provided:
• If the implementation does not include the Virtualization Extensions.
• When executing in Secure state.
• When executing in Hyp mode.
Physical Address (PA)

The address of a location in the Secure or Non-secure memory map. That is, an output address from
the processor to the memory system.
B3.1.2 Address spaces in a VMSA implementation

The ARMv7 architecture supports:
• A VA address space of up to 32 bits. The actual width is IMPLEMENTATION DEFINED.
• An IPA address space of up to 40 bits. The translation tables and associated system control registers define
the width of the implemented address space.
B3.1 About the VMSA
Note
The Large Physical Address Extension defines two translation table formats. The Long-descriptor format gives
access to the full 40-bit IPA or PA address space at a granularity of 4KB. The Short-descriptor format:
• Gives access to a 32-bit PA address space at 4KB granularity.
• Optionally, gives access to a 40-bit PA address space, but only at 16MB granularity.
If an implementation includes the Security Extensions, the address maps are defined independently for Secure and
Non-secure operation, providing two independent 40-bit address spaces, where:
• A VA accessed from Non-secure state can only be translated to the Non-secure address map.
• A VA accessed from Secure state can be translated to either the Secure or the Non-secure address map.
B3.1.3 About address translation

Address translation is the process of mapping one address type to another, for example, mapping VAs to IPAs, or
mapping VAs to PAs. A translation table defines the mapping from one address type to another, and a Translation
table base register indicates the start of a translation table. Each implemented MMU shown in VMSA translation
regimes, and associated MMUs on page B3-1307 requires its own set of translation tables.
For PL1&0 stage 1 translations, the mapping can be split between two tables, one controlling the lower part of the
VA space, and the other controlling the upper part of the VA space. This can be used, for example, so that:
• One table defines the mapping for operating system and I/O addresses, that do not change on a context switch.
• A second table defines the mapping for application-specific addresses, and therefore might require updating
on a context switch.
The VMSAv7 implementation options determine the supported MMUs, and therefore the supported address
translations:
VMSAv7 without the Security Extensions

Supports only a single PL1&0 stage 1 MMU. Operation of this MMU can be split between two sets
of translation tables, which are defined by TTBR0 and TTBR1, and controlled by TTBCR.
VMSAv7 with the Security Extensions but without the Virtualization Extensions
Supports only the Secure PL1&0 stage 1 MMU and the Non-secure PL1&0 stage 1 MMU.
Operation of each of these MMUs can be split between two sets of translation tables, which are
defined by the Secure and Non-secure copies of TTBR0 and TTBR1, and controlled by the Secure
and Non-secure copies of TTBCR.
VMSAv7 with Virtualization Extensions

The implementation supports all of the MMUs, as follows:
Secure PL1&0 stage 1 MMU
Operation of this MMU can be split between two sets of translation tables, which are
defined by the Secure copies of TTBR0 and TTBR1, and controlled by the Secure copy
of TTBCR.
Non-secure PL2 stage 1 MMU
The HTTBR defines the translation table for this MMU, controlled by HTCR.
Non-secure PL1&0 stage 1 MMU
Operation of this MMU can be split between two sets of translation tables, which are
defined by the Non-secure copies of TTBR0 and TTBR1 and controlled by the
Non-secure copy of TTBCR.
Non-secure PL1&0 stage 2 control
The VTTBR defines the translation table for this MMU, controlled by VTCR.
Figure B3-2 on page B3-1310 shows the possible memory translations in a VMSAv7 implementation that includes
the Virtualization Extensions, and indicates the required privilege level to define each set of translation tables:
B3.1 About the VMSA
Translation regime
Secure PL1&0 stage 1 MMU PA,
Secure PL1&0 VA
Secure TTBR0‡, TTBR1‡, and TTBCR‡ Secure or Non-secure
Non-secure PL2 stage 1 MMU PA,

Non-secure PL2 VA
HTTBR§ and HTCR§ Non-secure only
Non-secure PL1&0 stage 1 MMU Non-secure PL1&0 stage 2 MMU PA,

Non-secure PL1&0 VA IPA
Non-secure TTBR0†, TTBR1†, VTTBR§ and VTCR§ Non-secure only
and TTBCR†
‡ Configured at Secure PL1
Translation table base address
† Configured at Non-secure PL1
and control registers
§ Configured at Non-secure PL2
Figure B3-2 Memory translation summary, with Virtualization Extensions
In general:
• The translation from VA to PA can require multiple stages of address translation, as Figure B3-2 shows.
• A single stage of address translation takes an input address and translates it to an output address.
A full translation table lookup is called a translation table walk. It is performed automatically by hardware, and can
have a significant cost in execution time. To support fine granularity of the VA to PA mapping, a single input address
to output address translation can require multiple accesses to the translation tables, with each access giving finer
granularity. Each access is described as a level of address lookup. The final level of the lookup defines:
• The required output address.
• The attributes and access permissions of the addressed memory.
Translation Lookaside Buffers (TLBs) reduce the average cost of a memory access by caching the results of
translation table walks. TLBs behave as caches of the translation table information, and the VMSA provides TLB
maintenance operations for the management of TLB contents.
Note
The ARM architecture permits TLBs to hold any translation table entry that does not directly cause a Translation
fault or an Access flag fault.
To reduce the software overhead of TLB maintenance, the VMSA distinguishes between Global pages and
Process-specific pages. The Address Space Identifier (ASID) identifies pages associated with a specific process and
provides a mechanism for changing process-specific tables without having to maintain the TLB structures.
If an implementation includes the Virtualization Extensions, the virtual machine identifier (VMID) identifies the
current virtual machine, with its own independent ASID space. The TLB entries include this VMID information,
meaning TLBs do not require explicit invalidation when changing from one virtual machine to another, if the virtual
machines have different VMIDs. For stage 2 translations, all translations are associated with the current VMID, and
there is no concept of global entries.
B3.1 About the VMSA
B3.1.4 Organization of this chapter

The remainder of this chapter is organized as follows.
The first part of the chapter describes address translation and the associated memory properties held in the
translation table entries, in the following sections:
• The effects of disabling MMUs on VMSA behavior on page B3-1312.
• Translation tables on page B3-1316.
• Secure and Non-secure address spaces on page B3-1320.
• Memory access control on page B3-1352.
• Memory region attributes on page B3-1362.
• Translation Lookaside Buffers (TLBs) on page B3-1374.
Caches in a VMSA implementation on page B3-1389 describes VMSA-specific cache requirements.
The following sections describe aborts on VMSA memory accesses, and how these and other faults are reported in
a VMSA implementation:
Virtual Address to Physical Address translation operations on page B3-1434 describes these operations, and how
they relate to address translation.
A number of sections then describe the control registers in a VMSA implementation. The following sections give
general information about the control registers, and the organization of the registers in the two coprocessors, CP14
and CP15, that provide the interface to these registers:
• About the system control registers for VMSA on page B3-1440.
• Functional grouping of VMSAv7 system control registers on page B3-1486.
The following sections then describe each of the functional groups of CP15 registers, including a full description of
each register in the group:
• Identification registers, functional group on page B3-1487.
• Virtual memory control registers, functional group on page B3-1488.
• PL1 Fault handling registers, functional group on page B3-1489.
• Other system control registers, functional group on page B3-1489.
• Lockdown, DMA, and TCM features, functional group, VMSA on page B3-1490.
• Cache maintenance operations, functional group, VMSA on page B3-1491.
• TLB maintenance operations, functional group on page B3-1492.
• Address translation operations, functional group on page B3-1493.
• Miscellaneous operations, functional group on page B3-1494.
• Performance Monitors, functional group on page B3-1495.
• Security Extensions registers, functional group on page B3-1495.
• Virtualization Extensions registers, functional group on page B3-1496.
• IMPLEMENTATION DEFINED registers, functional group on page B3-1497.
Pseudocode details of VMSA memory system operations on page B3-1498 then describes many features of VMSA
operation.
B3.2 The effects of disabling MMUs on VMSA behavior

About the VMSA on page B3-1306 defines the translation regimes and the associated MMUs. The VMSA includes
an enable bit for each MMU, as follows:
• SCTLR.M, in the Secure copy of the register, controls Secure PL1&0 stage 1 MMU.
• SCTLR.M, in the Non-secure copy of the register, controls Non-secure PL1&0 stage 1 MMU.
• HCR.VM controls Non-secure PL1&0 stage 2 MMU.
• HSCTLR.M controls Non-secure PL2 stage 1 MMU.
The following sections describe the effect on VMSAv7 behavior of disabling each stage of translation:
• VMSA behavior when a stage 1 MMU is disabled.
• VMSA behavior when the stage 2 MMU is disabled on page B3-1314.
• Behavior of instruction fetches when all associated MMUs are disabled on page B3-1314.
Enabling MMUs on page B3-1314 gives information about enabling MMUs, in particular after a reset on an
implementation that includes the Security Extensions.
B3.2.1 VMSA behavior when a stage 1 MMU is disabled

When a stage 1 MMU is disabled, memory accesses that would otherwise be translated by that MMU are treated as
follows:
Non-secure PL1 and PL0 accesses when HCR.DC is set to 1, Virtualization Extensions
In an implementation that includes the Virtualization Extensions, for an access from a Non-secure
PL1 or PL0 mode when HCR.DC is set to 1, the stage 1 translation assigns the Normal
Non-shareable, Inner Write-Back Write-Allocate, Outer Write-Back Write-Allocate memory
attributes.
All other accesses

For all other accesses, when a stage 1 MMU is disabled, the assigned attributes depend on whether
the access is a data access or an instruction access, as follows:
Data access
The stage 1 translation assigns the Strongly-Ordered memory type.
Note
This means the access is Non-cacheable. Unexpected data cache hit behavior is
Instruction access
The stage 1 translation assigns Normal memory attribute, with the cacheability and
shareability attributes determined by the value of:
• The Secure copy of SCTLR.I for the Secure PL1&0 translation regime.
• The Non-secure copy of SCTLR.I for the Non-secure PL1&0 translation regime.
• HSCTLR.I for the Non-secure PL2 translation regime.
In these cases, the meaning of the I bit is as follows:
When I is set to 0
The stage 1 translation assigns the Non-cacheable attribute. If the
implementation includes the Large Physical Address Extension, the Outer
Shareable attribute is assigned, otherwise the shareability attribute is
When I is set to 1
The stage 1 translation assigns the Cacheable, Inner Write-Through no
Write-Allocate, Outer Write-Through no Write-Allocate attribute.
Note
• An implementation that includes the Virtualization Extensions must include the
Large Physical Address Extension, and therefore if the stage 1 MMU is disabled
and HSCTLR.I is set to 0, the Outer Shareable attribute is assigned.
• On some implementations, if the SCTLR.TRE bit is set to 0 then this behavior
can be changed by the remap settings in the memory remap registers, see VMSA
CP15 c10 register summary, memory remapping and TLB control registers on
page B3-1473. The details of TEX remap when SCTLR.TRE is set to 0 are
IMPLEMENTATION DEFINED, see SCTLR.TRE, SCTLR.M, and the effect of the
TEX remap registers on page B3-1367.
These rules apply in the following cases:

• The implementation does not include the Virtualization Extensions.
• The implementation includes the Virtualization Extensions and any of the
following applies:
— The access is from Secure state.
— The access is from Hyp mode.
— The access is from a Non-secure PL1 or PL0 mode and HCR.DC is set to
0.
For this stage of translation, no memory access permission checks are performed, and therefore no MMU faults
relating to this stage of translation can be generated.
Note
Alignment checking is performed, and therefore Alignment faults can occur.
For every access, the output address of the stage 1 translation is equal to the input address. This is called a flat
address mapping. If the implementation supports output addresses of more than 32 bits then the output address bits
above bit[31] are zero. For example, for a VA to PA translation on an implementation that supports 40-bit PAs,
PA[39:32] is 0x00.
If stage 1 translation is disabled for a Secure translation regime, every access in Secure state using that translation
regime is made to the Secure physical address space.
If stage 1 translation is disabled for a Non-secure translation regime, every access in Non-secure state using that
translation regime is made to the Non-secure physical address space.
For a Non-secure PL1 or PL0 access, if the PL1&0 stage 2 MMU is enabled, the stage 1 memory attribute
assignments and output address can be modified by the stage 2 translation.
The effect of executing in a Non-secure PL1 or PL0 mode with HCR.DC set to 1 is UNPREDICTABLE if one or more
of the following applies:
• The Non-secure SCTLR.M bit is set to 1, enabling the Non-secure PL1&0 stage 1 MMU.
• The HCR.VM bit is set to 0, disabling the Non-secure PL1&0 stage 2 MMU.
The effect of HCR.DC might be held in TLB entries associated with a particular VMID. Therefore, if software
executing at PL2 changes the HCR.DC value without also changing the current VMID, it must also invalidate all
TLB entries associated with the current VMID. Otherwise, the behavior of Non-secure software executing at PL1
or PL0 is UNPREDICTABLE.
See also Behavior of instruction fetches when all associated MMUs are disabled on page B3-1314.
Effect of disabling the MMU on maintenance and address translation operations

CP15 cache maintenance operations act on the target cache whether the MMU is enabled or not, and regardless of
the values of the memory attributes. However, if the MMU is disabled, they use the flat address mapping, and all
mappings are considered global.
CP15 TLB invalidate operations act on the target TLB whether the MMU is enabled or not.
When the Non-secure PL1&0 stage 1 MMU is disabled, any ATS1C** or ATS12NSO** address translation
operation that accesses the Non-secure state translation reflects the effect of the HCR.DC bit. For more information
about these operations, see Virtual Address to Physical Address translation operations on page B3-1434.
B3.2.2 VMSA behavior when the stage 2 MMU is disabled

When the stage 2 MMU is disabled:
• The IPA output from the stage 1 translation maps flat to the PA.
• The memory attributes and permissions from the stage 1 translation apply to the PA.
If the stage 1 MMU and the stage 2 MMU are both disabled, see Behavior of instruction fetches when all associated
MMUs are disabled.
B3.2.3 Behavior of instruction fetches when all associated MMUs are disabled
The information in this section applies to memory accesses:
• From Secure PL1 and PL0 modes, when the Secure PL1&0 stage 1 MMU is disabled.
• From the Non-secure PL2 mode, when the Non-secure PL2 stage 1 MMU is disabled.
• From Non-secure PL1 and PL0 modes, when all of the following apply:
— The Non-secure PL1&0 stage 1 MMU is disabled.
— The Non-secure PL1&0 stage 2 MMU is disabled.
— HCR.DC is set to 0.
In these cases, a memory location might be accessed as a result of an instruction fetch if one of the following
conditions is met:
• The memory location is in the same 4KB block of memory (aligned to 4KB) as an instruction that a simple
sequential execution of the program requires to be fetched, or is in the 4KB block of memory immediately
following such a block.
• The memory location is in the same 4KB block of memory (aligned to 4KB) from which a simple sequential
execution of the program with all associated MMUs disabled has previously required an instruction to be
fetched, or is in the 4KB block immediately following such a block.
These accesses can be caused by speculative instruction fetches, regardless of whether the prefetched instruction is
committed for execution.
Note
To ensure architectural compliance, software must ensure that both of the following apply:
• Instructions that will be executed when an MMU is disabled are located in 4KB blocks of the address space
that contain only memory that is tolerant to speculative accesses.
• Each 4KB block of the address space that immediately follows a 4KB block that holds instructions that will
be executed when an MMU is disabled also contains only memory which is tolerant to speculative accesses.
B3.2.4 Enabling MMUs

An implementation that does not include the Security Extensions has a single MMU, controlled by SCTLR.M. On
startup or reset, SCTLR.M bit resets to 0, meaning the MMU is disabled.
• The PL1&0 stage 1 MMU enable bit, SCTLR.M, is Banked, meaning there are separate enables for operation
in Secure and Non-secure state.
• On startup or reset, only the Secure copy of the SCTLR.M bit resets to 0, disabling the Secure state PL1&0
stage 1 MMU. The reset value of the Non-secure copy of SCTLR.M is UNKNOWN.
In an implementation that includes the Virtualization Extensions, on startup or reset, the HSCTLR.M bit, that
controls the Non-secure PL2 stage 1 MMU, is UNKNOWN.
Note
If the PA of the software that enables or disables an MMU differs from its VA, speculative instruction fetching can
cause complications. ARM strongly recommends that the PA and VA of any software that enables or disables an
MMU are identical if that MMU controls address translations that apply to the software currently being executed.
B3.3 Translation tables

VMSAv7 defines two alternative translation table formats:
Short-descriptor format
This is the original format defined in issue A of this Architecture Reference Manual, and is the only
format supported on implementations that do not include the Large Physical Address Extension. It
uses 32-bit descriptor entries in the translation tables, and provides:
• Up to two levels of address lookup.
• 32-bit input addresses.
• Output addresses of up to 40 bits.
• Support for PAs of more than 32 bits by use of supersections, with 16MB granularity.
• Support for No access, Client, and Manager domains.
• 32-bit table entries.
Long-descriptor format
The Large Physical Address Extension adds support for this format. It uses 64-bit descriptor entries
in the translation tables, and provides:
• Up to three levels of address lookup.
• Input addresses of up to 40 bits, when used for stage 2 translations.
• Output addresses of up to 40 bits.
• 4KB assignment granularity across the entire PA range.
• No support for domains, all memory regions are treated as in a Client domain.
• 64-bit table entries.
• Fixed 4KB table size, unless truncated by the size of the input address space.
Note
Translation with a 40-bit input address range requires two concatenated 4KB top-level tables,
aligned to 8KB.
The Large Physical Address Extension is an OPTIONAL extension, but an implementation that includes the
Virtualization Extensions must also include the Large Physical Address Extension.
In an implementation that includes the Large Physical Address Extension, but not the Virtualization Extensions, the
TTBCR.EAE bit indicates the current translation table format.
In an implementation that includes the Virtualization Extensions, of the possible address translations shown in
Figure B3-2 on page B3-1310:
• The translation tables for the Secure PL1&0 stage 1 translations, and for the Non-secure PL1&0 stage 1
translations, can use either translation table format, and the TTBCR.EAE bit indicates the current translation
table format.
• The translation tables for the Non-secure PL2 stage 1 translations, and for the Non-secure PL1&0 stage 2
translations, must use the Long-descriptor translation table format.
Many aspects of performing a translation table walk depend on the current translation table format. Therefore, the
following sections describe the two formats, including how the MMU performs a translation table walk for each
format:
The following subsections describe aspects of the translation tables and translation table walks that are independent
of the translation table format:
• Translation table walks on page B3-1317.
• Information returned by a translation table lookup on page B3-1318.
• Determining the translation table base address on page B3-1318.
• Security Extensions control of translation table walks on page B3-1319.
• Access to the Secure or Non-secure physical address map on page B3-1319.
See also TLB maintenance requirements on page B3-1377.
B3.3.1 Translation table walks

A translation table walk occurs as the result of a TLB miss, and starts with a read of the appropriate starting-level
translation table. The result of that read determines whether additional translation table reads are required, for this
stage of translation, as described in either:
• Translation table walks, when using the Short-descriptor translation table format on page B3-1328.
• Translation table walks, when using the Long-descriptor translation table format on page B3-1345.
Note
When using the Short-descriptor translation table format, the starting level for a translation table walk is always a
first-level lookup. However, with the Long-descriptor translation table format, the starting-level can be either a
first-level or a second-level lookup.
For the PL1&0 stage 1 translations, SCTLR.EE determines the endianness of the translation table lookups. In an
implementation that includes the Security Extensions, SCTLR is Banked, and therefore the endianness is
determined independently for the Secure and Non-secure PL1&0 stage 1 translations.
If an implementation includes the Virtualization Extensions, HSCTLR.EE defines the endianness for the
Non-secure PL2 stage 1 and Non-secure PL1&0 stage 2 translations.
Note
Dynamically changing translation table endianness
Because any change to SCTLR.EE or HSCTLR.EE requires synchronization before it is visible to
subsequent operations, ARM strongly recommends that:
• SCTLR.EE is changed only when either:
— Executing in a mode that does not use the translation tables affected by SCTLR.EE.
— Executing with SCTLR.M set to 0.
• HSCTLR.EE is changed only when either:
— Executing in a mode that does not use the translation tables affected by HSCTLR.EE.
— Executing with HSCTLR.M set to 0.
The physical address of the base of the starting-level translation table is determined from the appropriate Translation
table base register, see Determining the translation table base address on page B3-1318.
In an ARMv7 implementation that does not include the Multiprocessing Extensions, and in implementations of
architecture versions before ARMv7, it is IMPLEMENTATION DEFINED whether a hardware translation table walk can
cause a read from the L1 unified or data cache. If an implementation does not support translation table accesses from
L1 cache, then software must ensure coherency between translation table walks and data updates. This involves one
of:
• Storing translation tables in Normal memory that is Write-Through Cacheable for all cacheability regions to
the PoU.
• Storing translation tables in Inner Write-Back Cacheable Normal memory and ensuring the appropriate cache
entries are cleaned after modification.
• Storing translation tables in Non-cacheable memory.
For more information, see TLB maintenance operations and the memory order model on page B3-1379.
If an implementation includes the Multiprocessing Extensions, translation table walks must access data or unified
caches, or data and unified caches, of other agents participating in the coherency protocol, according to the
shareability attributes described in the TTBR. These shareability attributes must be consistent with the shareability
attributes for the translation tables themselves.
B3.3.2 Information returned by a translation table lookup

In a VMSA implementation, when an associated MMU is enabled, a memory access requires one or more
translation table lookups. If the required translation table descriptor is not held in a TLB, a translation table walk is
performed to obtain the descriptor. A lookup, whether from the TLB or as the result of a translation table walk,
returns both:
• An output address that corresponds to the input address for the lookup.
• A set of properties that correspond to that output address.
The returned properties are classified as providing address map control, access controls, or region attributes. This
classification determines how the descriptions of the properties are grouped. The classification is based on the
following model:
Address map control

Memory accesses from Secure state can access either the Secure or the Non-secure address map, as
summarized in Access to the Secure or Non-secure physical address map on page B3-1319.
Memory accesses from Non-secure state can only access the Non-secure address map.
Access controls
Determine whether the processor, in its current state, can access the output address that corresponds
to the given input address. If not, an MMU fault is generated and there is no memory access.
Memory access control on page B3-1352 describes the properties in this group.
Attributes Are valid only for an output address that the processor, in its current state, can access. The attributes
define aspects of the required behavior of accesses to the target memory region.
Memory region attributes on page B3-1362 describes the properties in this group.
B3.3.3 Determining the translation table base address

On a TLB miss, the VMSA must perform a translation table walk, and therefore must find the base address of the
translation table to use for its lookup. A TTBR holds this address. As Figure B3-2 on page B3-1310 shows:
• For a Non-secure PL2 stage 1 translation, the HTTBR holds the required base address. The HTCR is the
control register for these translations.
• For a Non-secure PL1&0 stage 2 translation, the VTTBR holds the required base address. The VTCR is the
control register for these translations.
• For a Non-secure PL1&0 stage 1 translation, or for a Secure PL1&0 stage 1 translation, either TTBR0 or
TTBR1 holds the required base address. The TTBCR is the control register for these translations.
The Non-secure copies of TTBR0, TTBR1, and TTBCR, relate to the Non-secure PL1&0 stage 1 translation.
The Secure copies of TTBR0, TTBR1, and TTBCR, relate to the Secure PL1&0 stage 1 translation.
For Secure or Non-secure PL1&0 translation table walks:
• TTBR0 can be configured to describe the translation of VAs in the entire address map, or to describe only the
translation of VAs in the lower part of the address map.
• If TTBR0 is configured to describe the translation of VAs in the lower part of the address map, TTBR1 is
configured to describe the translation of VAs in the upper part of the address map.
The contents of the appropriate copy of the TTBCR determine whether the address map is separated into two parts,
and where the separation occurs. The details of the separation depend on the current translation table format, see:
• Selecting between TTBR0 and TTBR1, Short-descriptor translation table format on page B3-1327.
• Selecting between TTBR0 and TTBR1, Long-descriptor translation table format on page B3-1341.
Example B3-1 Example use of TTBR0 and TTBR1
An example of using the two TTBRs is:
TTBR0 Used for process-specific addresses.

Each process maintains a separate first-level translation table. On a context switch:
• TTBR0 is updated to point to the first-level translation table for the new context.
• TTBCR is updated if this change changes the size of the translation table.
• The CONTEXTIDR is updated.
TTBCR can be programmed so that all translations use TTBR0 in a manner compatible with
architecture versions before ARMv6.
TTBR1 Used for operating system and I/O addresses, that do not change on a context switch.
B3.3.4 Security Extensions control of translation table walks

When an implementation includes the Security Extensions, two bits in the TTBCR for the current security state
control whether a translation table walk is performed on a TLB miss. These two bits are the:
• PD0 and PD1 bits, on a processor using the Short-descriptor translation table format.
• EPD0 and EPD1 bits, on a processor using the Long-descriptor translation table format.
Note
The different bit names are because the bits are in different positions in TTBCR, depending on the translation table
format.
The effect of these bits is:
{E}PDx == 0 If a TLB miss occurs based on TTBRx, a translation table walk is performed. The current security
state determines whether the memory access is Secure or Non-secure.
{E}PDx == 1 If a TLB miss occurs based on TTBRx, a First level Translation fault is returned, and no translation
table walk is performed.
B3.3.5 Access to the Secure or Non-secure physical address map

As stated in Address spaces in a VMSA implementation on page B3-1308, a processor that implements the Security
Extensions implements independent Secure and Non-secure address maps. These are defined by the translation
tables identified by the Secure TTBR0 and TTBR1. In both translation table formats:
• In the Secure translation tables, the NS bit in a descriptor indicates whether the descriptor refers to the Secure
or the Non-secure address map:
NS == 0 Access the Secure physical address space.
NS == 1 Access the Non-secure physical address space.
• In the Non-secure translation tables, the corresponding bit is SBZ. Non-secure accesses always access the
Non-secure physical address space, regardless of the value of this bit.
The Long-descriptor translation table format extends this control, adding an NSTable bit to the Secure translation
tables, as described in Hierarchical control of Secure or Non-secure memory accesses, Long-descriptor format on
page B3-1340. In the Non-secure translation tables, the corresponding bit is SBZ, and Non-secure accesses ignore
the value of this bit.
The following sections describe the address map controls in the two implementations:
• Control of Secure or Non-secure memory access, Short-descriptor format on page B3-1326.
• Control of Secure or Non-secure memory access, Long-descriptor format on page B3-1340.
For more information, see Secure and Non-secure address spaces on page B3-1320.
B3.4 Secure and Non-secure address spaces
B3.4 Secure and Non-secure address spaces

When implemented, the Security Extensions provide two physical address spaces, a Secure physical address space
and a Non-secure physical address space.
As described in Access to the Secure or Non-secure physical address map on page B3-1319, for Secure and
Non-secure PL1&0 stage 1 translations, the Translation table base registers, TTBR0, TTBR1, and TTBCR are
Banked between Secure and Non-secure versions, and the Security state of the processor when it performs a
memory access selects the corresponding version of the registers. This means there are independent Secure and
Non-secure versions of these translation tables, and translation table walks are made to the physical address space
corresponding to the Security state of the translation tables used.
For a translation table walk caused by a memory access from Non-secure state, all memory accesses are to the
Non-secure address space.
For a translation table walk caused by a memory access from Secure state:
• In an implementation that includes the Large Physical Address Extension, when address translation is using
the Long-descriptor translation table format:
— The first lookup performed must access the Secure address space.
— If a table descriptor read from the Secure address space has the NSTable bit set to 0, then the next level
of lookup is from the Secure address space.
— If a table descriptor read from the Secure address space has the NSTable bit set to 1, then the next level
of lookup, and any subsequent level of lookup, is from the Non-secure address space.
For more information, see Control of Secure or Non-secure memory access, Long-descriptor format on
page B3-1340.
• Otherwise, all memory accesses are to the Secure address space.
Note
• An ARMv7 implementation that includes the Virtualization Extensions, when executing in Non-secure state,
supports additional translations:
— Non-secure PL2 stage 1 translation.
— Non-secure PL1&0 stage 2 translation.
These translations can access only the Non-secure address space.
• A system implementation can alias parts of the Secure physical address space to the Non-secure physical
address space in an implementation-specific way. As with any other aliasing of physical memory, the use of
aliases in this way can require the use of cache maintenance operations to ensure that changes to memory
made using one alias of the physical memory are visible to accesses to the other alias of the physical memory.
B3.5 Short-descriptor translation table format

The Short-descriptor translation table format supports a memory map based on memory sections or pages:
Supersections Consist of 16MB blocks of memory. Support for Supersections is optional, except that an
implementation that includes the Large Physical Address Extension and supports more that 32 bits
of Physical Address must also support Supersections to provide access to the entire Physical
Address space.
Sections Consist of 1MB blocks of memory.
Large pages Consist of 64KB blocks of memory.
Small pages Consist of 4KB blocks of memory.
Supersections, Sections and Large pages map large regions of memory using only a single TLB entry.
Note
Whether a VMSAv7 implementation of the Short-descriptor format translation tables supports supersections is
When using the Short-descriptor translation table format, two levels of translation tables are held in memory:
First-level table
Holds first-level descriptors that contain the base address and
• Translation properties for a Section and Supersection.
• Translation properties and pointers to a second-level table for a Large page or a Small page.
Second-level tables
Hold second-level descriptors that contain the base address and translation properties for a Small
page or a Large page. With the Short-descriptor format, second-level tables can be referred to as
Page tables.
A second-level table requires 1KByte of memory.
In the translation tables, in general, a descriptor is one of:

• An invalid or fault entry.
• A page table entry, that points to a next-level translation table.
• A page or section entry, that defines the memory properties for the access.
• A reserved format.
Bits[1:0] of the descriptor give the primary indication of the descriptor type.
Figure B3-3 on page B3-1322 gives a general view of address translation when using the Short-descriptor
translation table format.
First-level table
TTBR0 or TTBR1
Second-level table
1MB
Section memory
region 64KB
Large page memory
Page table page
Repeated
16 times†
16MB Large page
Indexed by
Supersection memory
VA[31-N:20]‡ Indexed by
Repeated region
VA[19:12]
16 times†
Supersection 4KB
Small page memory
page
‡ When using TTBR1, N is 0. When using TTBR0, 0 ≤ N < 8.

See text for more information.
† Repeated entries required because of descriptor field overlaps.
Figure B3-3 General view of address translation using Short-descriptor format translation tables
Additional requirements for Short-descriptor format translation tables on page B3-1325 describes why, when using
the Short-descriptor format, Supersection and Large page entries must be repeated 16 times, as shown in
Figure B3-3.
Short-descriptor translation table format descriptors, Memory attributes in the Short-descriptor translation table
format descriptors on page B3-1325, and Control of Secure or Non-secure memory access, Short-descriptor format
on page B3-1326 describe the format of the descriptors in the Short-descriptor format translation tables.
The following sections then describe the use of this translation table format:
• Selecting between TTBR0 and TTBR1, Short-descriptor translation table format on page B3-1327.
• Translation table walks, when using the Short-descriptor translation table format on page B3-1328.
B3.5.1 Short-descriptor translation table format descriptors

The following sections describe the formats of the entries in the Short-descriptor translation tables:
• Short-descriptor translation table first-level descriptor formats.
• Short-descriptor translation table second-level descriptor formats on page B3-1324.
For more information about second-level translation tables, see Additional requirements for Short-descriptor format
translation tables on page B3-1325.
Note
Previous versions of the ARM Architecture Reference Manual, and some other documentation, describes the AP[2]
bit in the translation table entries as the APX bit.
Information returned by a translation table lookup on page B3-1318 describes the classification of the non-address
fields in the descriptors as address map control, access control, or attribute fields.
Short-descriptor translation table first-level descriptor formats

Each entry in the first-level table describes the mapping of the associated 1MB MVA range.
Figure B3-4 on page B3-1323 shows the possible first-level descriptor formats.
31 2 1 0
Invalid IGNORED 0 0
31 10 9 8 5 4 3 2 1 0
Page table Page table base address, bits[31:10] Domain 0 1
IMPLEMENTATION DEFINED SBZ

NS
PXN†
31 20 19 18 17 16 15 14 12 11 10 9 8 5 4 3 2 1 0
Section Section base address, PA[31:20] 0 S Domain C B 1
NS nG XN PXN‡
AP[2]
TEX[2:0]
AP[1:0]
31 24 23 20 19 18 17 16 15 14 12 11 10 9 8 5 4 3 2 1 0
Supersection 1 S TEX[2:0] C B 1
Supersection base address, PA[31:24] NS nG XN PXN‡

Extended base address, PA[35:32] AP[2]
AP[1:0]
Extended base address, PA[39:36]
31 2 1 0
Reserved, when Large
Physical Address Extension Reserved, UNK/SBZP 1 1
not implemented
† If the implementation does not support the PXN attribute this bit is SBZ. An implementation that includes the Large Physical
‡ If the implementation does not support the PXN attribute these bits must be 0. Address Extension must support the PXN attribute.
Figure B3-4 Short-descriptor first-level descriptor formats
Inclusion of the PXN attribute in the Short-descriptor translation table formats is:
• OPTIONAL in an implementation that does not include the Large Physical Address Extension.
• Required in an implementation includes the Large Physical Address Extension.
Descriptor bits[1:0] identify the descriptor type. On an implementation that supports the PXN attribute, for the
Section and Supersection entries, bit[0] also defines the PXN value. The encoding of these bits is:
0b00, Invalid
The associated VA is unmapped, and any attempt to access it generates a Translation fault.
Software can use bits[31:2] of the descriptor for its own purposes, because the hardware ignores
these bits.
0b01, Page table

The descriptor gives the address of a second-level translation table, that specifies the mapping of the
associated 1MByte VA range.
0b10, Section or Supersection

The descriptor gives the base address of the Section or Supersection. Bit[18] determines whether
the entry describes a Section or a Supersection.
If the implementation supports the PXN attribute, this encoding also defines the PXN bit as 0.
0b11, Section or Supersection, if the implementation supports the PXN attribute

If an implementation supports the PXN attribute, this encoding is identical to 0b10, except that it
defines the PXN bit as 1.
0b11, Reserved, UNK/SBZP, if the implementation does not support the PXN attribute
An attempt to access the associated VA generates a Translation fault.
On an implementation that does not support the PXN attribute, this encoding must not be used.
Note
• Issues A and B of this manual did not include the OPTIONAL support of the PXN attribute. The addition of
support for this attribute is backwards-compatible with software written to use the original VMSAv7
definition of the Short-descriptor translation table formats.
• A VMSAv7 implementation that implements the Large Physical Address Extension can use the
Short-descriptor translation table format for the Secure or Non-secure PL1&0 stage 1 translations, by setting
TTBCR.EAE to 0.
The address information in the first-level descriptors is:

Page table Bits[31:10] of the descriptor are bits[31:10] of the address of a Page table.
Section Bits[31:20] of the descriptor are bits[31:20] of the address of the Section.
Supersection Bits[31:24] of the descriptor are bits[31:24] of the address of the Supersection.
Optionally, bits[8:5, 23:20] of the descriptor are bits[39:32] of the extended Supersection address.
On an implementation that includes the Virtualization Extensions, for the Non-secure translation tables, the address
in the descriptor is the IPA of the Page table, Section, or Supersection. Otherwise, the address is the PA of the Page
table, Section, or Supersection.
For descriptions of the other fields in the descriptors, see Memory attributes in the Short-descriptor translation table
format descriptors on page B3-1325.
Short-descriptor translation table second-level descriptor formats

Figure B3-5 shows the possible formats of a second-level descriptor.
31 2 1 0
Invalid IGNORED 0 0
31 16 15 14 12 11 10 9 8 6 5 4 3 2 1 0
Large page Large page base address, PA[31:16] TEX[2:0] S SBZ C B 0 1
XN nG AP[1:0]
AP[2]
31 12 11 10 9 8 6 5 4 3 2 1 0
Small page Small page base address, PA[31:12] S TEX[2:0] C B 1
nG AP[1:0] XN
AP[2]
Figure B3-5 Short-descriptor second-level descriptor formats
Descriptor bits[1:0] identify the descriptor type. The encoding of these bits is:
0b00, Invalid
The associated VA is unmapped, and attempting to access it generates a Translation fault.
Software can use bits[31:2] of the descriptor for its own purposes, because the hardware ignores
these bits.
0b01, Large page

The descriptor gives the base address and properties of the Large page.
0b1x, Small page

The descriptor gives the base address and properties of the Small page.
In this descriptor format, bit[0] of the descriptor is the XN bit.
The address information in the second-level descriptors is:

Large page Bits[31:16] of the descriptor are bits[31:16] of the address of the Large page.
Small page Bits[31:12] of the descriptor are bits[31:12] of the address of the Small page.
On an implementation that includes the Virtualization Extensions, for the Non-secure translation tables, the address
in the descriptor is the IPA of the Page table, Section, or Supersection. Otherwise, the address is the PA of the Page
table, Section, or Supersection.
For descriptions of the other fields in the descriptors, see Memory attributes in the Short-descriptor translation table
format descriptors.
Additional requirements for Short-descriptor format translation tables

When using Supersection or Large page descriptors in the Short-descriptor translation table format, the input
address field that defines the Supersection or Large page descriptor address overlaps the table address field. In each
case, the size of the overlap is 4 bits. The following diagrams show these overlaps:
• Figure B3-8 on page B3-1330 for the first-level translation table Supersection entry.
• Figure B3-10 on page B3-1332 for the second-level translation table Large page table entry.
Considering the case of using Large page table descriptors in a second-level translation table, this overlap means
that for any specific Large page, the bottom four bits of the second-level translation table entry might take any value
from 0b0000 to 0b1111. Therefore, each of these 16 index values must point to a separate copy of the same descriptor.
This means that each Large page or Supersection descriptor must:
• Occur first on a sixteen-word boundary.
• Be repeated in 16 consecutive memory locations.
B3.5.2 Memory attributes in the Short-descriptor translation table format descriptors

This section describes the descriptor fields other than the descriptor type field and the address field:
TEX[2:0], C, B
Memory region attribute bits, see Memory region attributes on page B3-1362.
These bits are not present in a Page table entry.
XN bit The Execute-never bit. Determines whether the processor can execute software from the addressed
region, see Execute-never restrictions on instruction fetching on page B3-1355.
This bit is not present in a Page table entry.
PXN bit, when supported

The Privileged execute-never bit:
• On an implementation that does not include the Large Physical Address Extension, support
for the PXN bit in the Short-descriptor translation table format is OPTIONAL.
• On an implementation that includes the Large Physical Address Extension, the
Short-descriptor translation table format must include the PXN bit.
When supported, the PXN bit determines whether the processor can execute software from the
region when executing at PL1, see Execute-never restrictions on instruction fetching on
page B3-1355.
Note
Memory accesses by software executing at PL2 always use the Long-descriptor translation table
format.
When this bit is set to 1 in the Page table descriptor, it indicates that all memory pages described in
the corresponding page table are Privileged execute-never.
NS bit Non-secure bit. If an implementation includes the Security Extensions, for memory accesses from
Secure state, this bit specifies whether the translated PA is in the Secure or Non-secure address map,
see Control of Secure or Non-secure memory access, Short-descriptor format.
This bit is not present in second-level descriptors. The value of the NS bit in the first level Page table
descriptor applies to all entries in the corresponding second-level translation table.
Domain Domain field, see Domains, Short-descriptor format only on page B3-1358.
This field is not present in a Supersection entry. Memory described by Supersections is in domain 0.
This bit is not present in second-level descriptors. The value of the Domain field in the first level
Page table descriptor applies to all entries in the corresponding second-level translation table.
An IMPLEMENTATION DEFINED bit

This bit is not present in second-level descriptors.
AP[2], AP[1:0]
Access Permissions bits, see Memory access control on page B3-1352.
AP[0] can be configured as the Access flag, see The Access flag on page B3-1358.
These bits are not present in a Page table entry.
S bit The Shareable bit. Determines whether the addressed region is Shareable memory, see Memory
region attributes on page B3-1362.
nG bit The not global bit. Determines how the translation is marked in the TLB, see Global and
process-specific translation table entries on page B3-1374.
Bit[18], when bits[1:0] indicate a Section or Supersection descriptor

0 Descriptor is for a Section.
1 Descriptor is for a Supersection.
B3.5.3 Control of Secure or Non-secure memory access, Short-descriptor format

Access to the Secure or Non-secure physical address map on page B3-1319 describes how the NS bit in the
translation table entries:
• For accesses from Secure state, determines whether the access is to Secure or Non-secure memory.
• Is ignored by accesses from Non-secure state.
In the Short-descriptor translation table format, the NS bit is defined only in the first-level translation tables. This
means that, in a first-level Page table descriptor, the NS bit defines the physical address space, Secure or
Non-secure, for all of the Large pages and Small pages of memory described by that table.
The NS bit of a first-level Page table descriptor has no effect on the physical address space in which that translation
table is held. As stated in Secure and Non-secure address spaces on page B3-1320, the physical address of that
translation table is in:
• The Secure address space if the translation table walk is in Secure state.
• The Non-secure address space if the translation table walk is in Non-secure state.
This means the granularity of the Secure and Non-secure memory spaces is 1MB. However, in these memory
spaces, table entries can define physical memory regions with a granularity of 4KB.
B3.5.4 Selecting between TTBR0 and TTBR1, Short-descriptor translation table format
As described in Determining the translation table base address on page B3-1318, two sets of translation tables can
be defined for each of the PL1&0 stage 1 translations, and TTBR0 and TTBR1 hold the base addresses for the two
sets of tables. When using the Short-descriptor translation table format, the value of TTBCR.N indicates the number
of most significant bits of the input VA that determine whether TTBR0 or TTBR1 holds the required translation
table base address, as follows:
• If N == 0 then use TTBR0. Setting TTBCR.N to zero disables use of a second set of translation tables.
• If N > 0 then:
— If bits[31:32-N] of the input VA are all zero, then use TTBR0.
— Otherwise use TTBR1.
Table B3-1 shows how the value of N determines the lowest address translated using TTBR1, and the size of the
first-level translation table addressed by TTBR0.
Table B3-1 Effect of TTBCR.N on address translation, Short-descriptor format
TTBR0 table
TTBCR.N First address translated with TTBR1
Size Index range
0b000 TTBR1 not used 16KB VA[31:20]
0b001 0x80000000 8KB VA[30:20]
0b010 0x40000000 4KB VA[29:20]
0b011 0x20000000 2KB VA[28:20]
0b100 0x10000000 1KB VA[27:20]
0b101 0x08000000 512 bytes VA[26:20]
0b110 0x04000000 256 bytes VA[25:20]
0b111 0x02000000 128 bytes VA[24:20]
Whenever TTBCR.N is nonzero, the size of the translation table addressed by TTBR1 is 16KB.
Figure B3-6 on page B3-1328 shows how the value of TTBCR.N controls the boundary between VAs that are
translated using TTBR0, and VAs that are translated using TTBR1.
0xFFFFFFFF
TTBR1 region
TTBR0 region
Effect of decreasing N
Boundary, when
0x02000000
TTBCR.N==0b111
TTBR0 region
0x00000000
TTBCR.N==0b000
Use of TTBR1 disabled
Figure B3-6 How TTBCR.N controls the boundary between the TTBRs, Short-descriptor format
In the selected TTBR. the following bits define the memory region attributes for the translation table walk:
• The RGN, S, and C bits, in an implementation that does not include the Multiprocessing Extensions.
• The RGN, S, and IRGN[1:0] bits, in an implementation that includes the Multiprocessing Extensions.
For more information, see TTBCR, Translation Table Base Control Register, VMSA on page B4-1716, TTBR0,
Translation Table Base Register 0, VMSA on page B4-1721 and TTBR1, Translation Table Base Register 1, VMSA
on page B4-1725.
Translation table walks, when using the Short-descriptor translation table format describes the translation.
B3.5.5 Translation table walks, when using the Short-descriptor translation table format
When using the Short-descriptor translation table format, and a memory access requires a translation table walk:
• A section-mapped access only requires a read of the first-level translation table.
• A page-mapped access also requires a read of the second-level translation table.
Reading a first-level translation table describes how either TTBR1 or TTBR0 is used, with the accessed VA, to
determine the address of the first-level descriptor.
Reading a first-level translation table shows the output address as A[39:0]:
• On an implementation that includes the Virtualization Extensions, for a Non-secure PL1&0 stage 1
translation, this is the IPA of the required descriptor. A Non-secure PL1&0 stage 2 translation of this address
is performed to obtain the PA of the descriptor.
• Otherwise, this address is the PA of the required descriptor.
The full translation flow for Sections, Supersections, Small pages and Large pages on page B3-1329 then shows the
complete translation flow for each valid memory access.
Reading a first-level translation table

When performing a fetch based on TTBR0:
• The address bits taken from TTBR0 vary between bits[31:14] and bits[31:7].
• The address bits taken from the VA, that is the input address for the translation, vary between bits[31:20] and
bits[24:20].
The width of the TTBR0 and VA fields depend on the value of TTBCR.N, as Figure B3-7 on page B3-1329 shows.
When performing a fetch based on TTBR1, Bits TTBR1[31:14] are concatenated with bits[31:20] of the VA. This
makes the fetch equivalent to that shown in Figure B3-7, with N==0.
Note
See The address and Properties fields shown in the translation flows on page B3-1330 for more information about
the Properties label used in this and other figures.
31 32-N 31-N 20 19 0
‡ Table index Input address
31 14-N 13-N 7 6 0
UNK/
Translation base Properties TTBR0
SBZP
31 14-N 13-N 2 1 0
A[31:0] of first-level descriptor
Translation base Table index 0 0 Descriptor address
A[39:32] = 0x00
‡ This field is absent if N is 0
N is the value of TTBCR.N
For details of the Properties field, see the register description
Figure B3-7 Accessing first-level translation table based on TTBR0, Short-descriptor format
Regardless of which register is used as the base for the fetch, the resulting output address selects a four-byte
translation table entry that is one of:
• A first-level descriptor for a Section or Supersection.
• A Page table descriptor that points to a second-level translation table. In this case:
— A second fetch is performed to retrieve a second-level descriptor.
— The descriptor also contains some attributes for the access, see Figure B3-4 on page B3-1323.
• A faulting entry.
The full translation flow for Sections, Supersections, Small pages and Large pages
In a translation table walk, only the first lookup uses the translation table base address from the appropriate
Translation table base register. Subsequent lookups use a combination of address information from:
• The table descriptor read in the previous lookup.
• The input address.
This section summarizes how each of the memory section and page options is described in the translation tables,
and has a subsection summarizing the full translation flow for each of the options.
As described in Short-descriptor translation table format descriptors on page B3-1322, the four options are:
Supersection A 16MB memory region, see Translation flow for a Supersection on page B3-1330.
Section A 1MB memory region, see Translation flow for a Section on page B3-1331.
Large page A 64KB memory region, described by the combination of:

• A first-level translation table entry that indicates a second-level Page table address.
• A second-level descriptor that indicates a Large page.
See Translation flow for a Large page on page B3-1331.
Small page A 4KB memory region, described by the combination of:

• A first-level translation table entry that indicates a second-level Page table address.
• A second-level descriptor that indicates a Small page.

See Translation flow for a Small page on page B3-1332.
The address and Properties fields shown in the translation flows
On an implementation that includes the Virtualization Extensions, for the Non-secure translation tables:
• Any descriptor address is the IPA of the required descriptor.
• The final output address is the IPA of the Section, Supersection, Large page, or Small page.
In these cases, a PL1&0 stage 2 translation is performed to translate the IPA to the required PA.
Otherwise, the address is the PA of the descriptor, Section, Supersection, Large page, or Small page.
Properties indicates register or translation table fields that return information, other than address information, about
the translation or the targeted memory region. For more information, see Information returned by a translation table
lookup on page B3-1318, and the description of the register or translation table descriptor.
For translations using the Short-descriptor translation table format, Short-descriptor translation table format
descriptors on page B3-1322 describes the descriptors formats.
Translation flow for a Supersection
Figure B3-8 shows the complete translation flow for a Supersection. For more information about the fields shown
in this figure, see The address and Properties fields shown in the translation flows.
Table index
Supersection index
31 32-N 31-N 24 23 20 19 0
‡ Input address
31 14-N 13-N 7 6 0
UNK/
Translation base Properties Translation Table Base Register
SBZP
39 32 31 14-N 13-N 2 1 0
0 0 0 0 0 0 0 0 Translation base Table index 0 0 First-level descriptor address
First-level lookup
31 24 23 2 1 0
First-level
Supersection BA Extended Supersection BA and Properties fields 1 x
Supersection descriptor
Bits[8:5,23:20]
39 32 31 24 23 0
Extended BA Supersection BA Supersection index Output address, A[39:0]

BA = Base address
For a translation based on TTBR0, N is the value of TTBCR.N
For a translation based on TTBR1, N is 0
For details of Properties fields, see the register or descriptor description
Figure B3-8 Supersection address translation
Note
Figure B3-8 on page B3-1330 shows how, when the input address, the VA, addresses a Supersection, the top four
bits of the Supersection index bits of the address overlap the bottom four bits of the Table index bits. For more
information, see Additional requirements for Short-descriptor format translation tables on page B3-1325.
Translation flow for a Section
Figure B3-9 shows the complete translation flow for a Section. For more information about the fields shown in this
figure, see The address and Properties fields shown in the translation flows on page B3-1330.
31 32-N 31-N 20 19 0
‡ Table index Section index Input address
31 14-N 13-N 7 6 0
UNK/
Translation base Properties Translation Table Base Register
SBZP
39 32 31 14-N 13-N 2 1 0
0 0 0 0 0 0 0 0 Translation base Table index 0 0 First-level descriptor address
First-level lookup
31 20 19 2 1 0
Section base address Properties 1 x First-level Section descriptor
39 32 31 20 19 0
0 0 0 0 0 0 0 0 Section base address Section index Output address, A[39:0]

For details of Properties fields, see the register or descriptor description.
Figure B3-9 Section address translation
Translation flow for a Large page
Figure B3-10 on page B3-1332 shows the complete translation flow for a Large page. For more information about
the fields shown in this figure, see The address and Properties fields shown in the translation flows on
page B3-1330.
L2 table index
Page index
31 32-N 31-N 20 19 16 15 12 11 0
‡ L1 table index Input address
31 14-N 13-N 7 6 0
UNK/ Translation Table
Translation base Properties
SBZP Base Register
39 32 31 14-N 13-N 2 1 0
First-level descriptor
0 0 0 0 0 0 0 0 Translation base L1 table index 0 0
address
First-level lookup
31 10 9 2 1 0
Page table base address Properties 0 1 First-level descriptor
39 32 31 10 9 2 1 0
Second-level descriptor
0 0 0 0 0 0 0 0 Page table base address L2 table index 0 0
address
Second-level lookup
31 16 15 2 1 0
Large page base address Properties 0 1 Second-level descriptor
39 32 31 16 15 0
0 0 0 0 0 0 0 0 Large page base address Page index Output address, A[39:0]
L1 = First-level, L2 = Second-level
For details of Properties fields, see the register or descriptor description
Figure B3-10 Large page address translation
Note
Figure B3-10 shows how, when the input address, the VA, addresses a Large page, the top four bits of the page index
bits of the address overlap the bottom four bits of the First-level table index bits. For more information, see
Additional requirements for Short-descriptor format translation tables on page B3-1325.
Translation flow for a Small page
Figure B3-11 shows the complete translation flow for a Small page. For more information about the fields shown
in this figure, see The address and Properties fields shown in the translation flows on page B3-1330.
31 32-N 31-N 20 19 12 11 0
‡ L1 table index L2 table index Page index Input address
31 14-N 13-N 7 6 0
UNK/ Translation Table
Translation base Properties
SBZP Base Register
39 32 31 14-N 13-N 2 1 0
First-level descriptor
0 0 0 0 0 0 0 0 Translation base L1 table index 0 0
address
First-level lookup
31 10 9 2 1 0
Page table base address Properties 0 1 First-level descriptor
39 32 31 10 9 2 1 0
Second-level descriptor
0 0 0 0 0 0 0 0 Page table base address L2 table index 0 0
address
Second-level lookup
31 12 11 2 1 0
Small page base address Properties 1 x Second-level descriptor
39 32 31 12 11 0
0 0 0 0 0 0 0 0 Small page base address Page index Output address, A[39:0]

L1 = First-level, L2 = Second-level
Figure B3-11 Small page address translation
B3.6 Long-descriptor translation table format

The Long-descriptor translation table format is implemented only as part of the Large Physical Address Extension.
It supports the assignment of memory attributes to memory Pages, at a granularity of 4KB, across the complete
input address range. It also supports the assignment of memory attributes to blocks of memory, where a block can
be 2MB or 1GB.
Note
• While the current implementation is limited to three levels of address lookup, its design and naming
conventions support extension to additional levels, to support a larger input address range.
• Similarly, while the current implementation limits the output address range to 40 bits, its design supports
extension to a larger output address range.
In a VMSAv7 implementation that does not include the Virtualization Extensions, the Long-descriptor translation
table format can be used for either or both the Secure and Non-secure address translations.
In an implementation that includes the Virtualization Extensions, Figure B3-2 on page B3-1310 shows the different
address translation stages, and the Long-descriptor translation table format:
• Is used for:
— The Non-secure PL2 stage 1 translation.
— The Non-secure PL1&0 stage 2 translation.
• Can be used for the Secure and Non-secure PL1&0 stage 1 translations.
When used for a stage 1 translation, the translation tables support an input address of up to 32 bits, corresponding
to the VA address range of the processor. Figure B3-12 gives a general view of stage 1 address translation when
using the Long-descriptor translation table format.
TTBR0, First-level table

TTBR1, or
1GB Second-level table
HTTBR
Block memory
Indexed by region
VA[31:30] Table 2MB Third-level table
Block memory
Indexed by region
VA[29:21]
Table
Indexed by 4KB
VA[20:12] Page memory
page
If a First-level table would contain only one entry, it is skipped, and the TTBR points
to the Second-level table. This happens if the VA address range is 30 bits or less.
Figure B3-12 General view of stage 1 address translation using Long-descriptor format
When used for a stage 2 translation, the translation tables support an input address range of up to 40 bits, to support
the translation from IPA to PA. If the input address for the stage 2 translation is a 32-bit address, then this address
is zero-extended to 40 bits.
Note
When the Short-descriptor translation table format is used for the Non-secure stage 1 translations, this generates
32-bit IPAs. These are zero-extended to 40 bits to provide the input address for the stage 2 translation.
Figure B3-13 on page B3-1335 gives a general view of stage 2 address translation. Stage 2 translation always uses
the Long-descriptor translation table format.
First-level tables
VTTBR
1GB
Block memory Second-level tables
Indexed by region 2MB
IPA[38:30] Table Block memory Third-level table
Indexed by region
IPA[29:21] Table 4KB
Indexed by Page memory
Block IPA[20:12] page
Table Block
Table
Up to two concatenated
First-level tables, so that
IPA[39] indexes the table.
If a First-level table would contain 16 entries or fewer, first-level lookup can be omited. If so, VTTBR
points to the start of a block of concatenated Second-level tables. See text for more information.
Figure B3-13 General view of stage 2 address translation, Long-descriptor translation table format
Use of concatenated translation tables for stage 2 translations on page B3-1344 describes how using concatenated
Second-level tables means lookup can start at the Second level, as referred to in Figure B3-13.
Long-descriptor translation table format descriptors, Memory attributes in the Long-descriptor translation table
format descriptors on page B3-1337, and Control of Secure or Non-secure memory access, Long-descriptor format
on page B3-1340 describe the format of the descriptors in the Long-descriptor format translation tables.
The following sections then describe the use of this translation table format:
• Selecting between TTBR0 and TTBR1, Long-descriptor translation table format on page B3-1341.
• Long-descriptor translation table format address lookup levels on page B3-1343.
• Translation table walks, when using the Long-descriptor translation table format on page B3-1345.
B3.6.1 Long-descriptor translation table format descriptors

As described in Long-descriptor translation table format address lookup levels on page B3-1343, the
Long-descriptor translation table format provides up to three levels of address lookup. A translation table walk starts
either at the first level or the second level of address lookup.
In general, a descriptor is one of:

• An invalid or fault entry.
• A table entry, that points to the next-level translation table.
• A block entry, that defines the memory properties for the access.
• A reserved format.
Bit[1] of the descriptor indicates the descriptor type, and bit[0] indicates whether the descriptor is valid.
The following sections describe the Long-descriptor translation table descriptor formats:
• Long-descriptor translation table first-level and second-level descriptor formats.
• Long-descriptor translation table third-level descriptor formats on page B3-1337.
Information returned by a translation table lookup on page B3-1318 describes the classification of the non-address
fields in the descriptors between address map control, access controls, and region attributes.
Long-descriptor translation table first-level and second-level descriptor formats

In the Long-descriptor translation tables, the formats of the first-level and second-level descriptors differ only in the
size of the block of memory addressed by the block descriptor. A block entry:
• In a first-level table describes the mapping of the associated 1GB input address range.
• In a second-level table describes the mapping of the associated 2MB input address range.
Figure B3-14 shows the Long-descriptor first-level and second-level descriptor formats:
63 1 0
Invalid IGNORED 0
63 52 51 40 39 n n-1 12 11 2 1 0
Block Upper block attributes UNK/SBZP Output address[39:n] UNK/SBZP Lower block attributes 0 1
For the first-level descriptor, n is 30. For the second-level descriptor, n is 21.
NSTable
APTable Stage 1 only,
XNTable SBZ at stage 2
PXNTable
63 62 61 60 59 58 52 51 40 39 12 11 2 1 0
Table IGNORED UNK/SBZP Next-level table address[39:12] IGNORED 1 1
The first-level descriptor returns the address of the second-level table.

The second-level descriptor returns the address of the third-level table.
Figure B3-14 Long-descriptor first-level and second-level descriptor formats
Descriptor encodings, Long-descriptor first-level and second-level formats
In the Long-descriptor translation tables, the formats of the first-level and second-level descriptors differ only in the
size of the block of memory addressed by the block descriptor.
Descriptor bit[0] identifies whether the descriptor is valid, and is 1 for a valid descriptor. If a lookup returns an
invalid descriptor, the associated input address is unmapped, and any attempt to access it generates a Translation
fault.
Descriptor bit[1] identifies the descriptor type, and is encoded as:
0, Block The descriptor gives the base address of a block of memory, and the attributes for that memory
region.
1, Table The descriptor gives the address of the next level of translation table, and for a stage 1 translation,
some attributes for that translation.
The other fields in the valid descriptors are:
Block descriptor
Gives the base address and attributes of a block of memory:
• For a first-level Block descriptor, bits[39:30] are bits[39:30] of the output address that
specifies a 1GB block of memory.
• For a second-level Block descriptor, bits[39:21] are bits[39:21] of the output address that
specifies a 2MB block of memory.
Bits[63:52, 11:2] provide attributes for the target memory block, see Memory attributes in the
Long-descriptor translation table format descriptors on page B3-1337. The position and contents
of these bits are identical in the second-level block descriptor and in the third-level page descriptor.
Table descriptor
Bits[39:12] are bits[39:12] of the address of the required next-level table. Bits[11:0] of the table
address are zero:
• For a first-level Table descriptor, this is the address of a second-level table.
• For a second-level Table descriptor, this is the address of a third-level table.
For a stage 1 translation only, bits[63:59] provide attributes for the next-level lookup, see Memory
attributes in the Long-descriptor translation table format descriptors.
If the implementation includes the Virtualization Extensions and the translation table defines the Non-secure PL1&0
stage 1 translations, then the output address in the descriptor is the IPA of the target block or table. Otherwise, it is
the PA of the target block or table.
Long-descriptor translation table third-level descriptor formats

Each entry in a third-level table describes the mapping of the associated 4KB input address range.
Figure B3-15 shows the Long-descriptor third-level descriptor formats.
63 1 0
Invalid IGNORED 0
63 2 1 0
Reserved Reserved, UNK/SBZP 0 1
63 52 51 40 39 12 11 2 1 0
Page Upper page attributes UNK/SBZP Output address[39:12] Lower page attributes 1 1
Figure B3-15 Long-descriptor third-level descriptor formats
Descriptor bit[0] identifies whether the descriptor is valid, and is 1 for a valid descriptor. If a lookup returns an
invalid descriptor, the associated input address is unmapped, and any attempt to access it generates a Translation
fault.
Descriptor bit[1] identifies the descriptor type, and is encoded as:
0, Reserved, invalid
Behaves identically to encodings with bit[0] set to 0.
This encoding must not be used in third-level translation tables.
1, Page Gives the address and attributes of a 4KB page of memory.
At this level, the only valid format is the Page descriptor. The other fields in the Page descriptor are:
Page descriptor
Bits[39:12] are bits[39:12] of the output address for a page of memory.
Bits[63:52, 11:2] provide attributes for the target memory page, see Memory attributes in the
Long-descriptor translation table format descriptors. The position and contents of these bits are
identical in the first-level block descriptor and in the second-level block descriptor.
If the implementation includes the Virtualization Extensions and the translation table defines the Non-secure PL1&0
stage 1 translations, then the output address in the descriptor is the IPA of the target page. Otherwise, it is the PA of
the target page.
B3.6.2 Memory attributes in the Long-descriptor translation table format descriptors

The memory attributes in the Long-descriptor translation tables are based on those in the Short-descriptor
translation table format, with some extensions. Memory region attributes on page B3-1362 describes these
attributes. In the Long-descriptor translation table format:
• Table entries for stage 1 translations define attributes for the next level of lookup, see Next-level attributes in
stage 1 Long-descriptor Table descriptors on page B3-1338.
• Block and page entries define memory attributes for the target block or page of memory. Stage 1 and stage 2
translations have some differences in these attributes, see:
— Attribute fields in stage 1 Long-descriptor Block and Page descriptors.
— Attribute fields in stage 2 Long-descriptor Block and Page descriptors on page B3-1339.
Next-level attributes in stage 1 Long-descriptor Table descriptors

In a Table descriptor for a stage 1 translation, bits[63:59] of the descriptor define the following attributes for the
next-level translation table access:
NSTable, bit[63] For memory accesses from Secure state, specifies the security level for subsequent levels of
lookup, see Hierarchical control of Secure or Non-secure memory accesses,
Long-descriptor format on page B3-1340.
For memory accesses from Non-secure state, this bit is ignored.
APTable, bits[62:61] Access permissions limit for subsequent levels of lookup, see Hierarchical control of access
permissions, Long-descriptor format on page B3-1353.
APTable[0] is reserved, SBZ, in the Non-secure PL2 stage 1 translation tables.
XNTable, bit[60] XN limit for subsequent levels of lookup, see Hierarchical control of instruction fetching,
PXNTable, bit[59] PXN limit for subsequent levels of lookup, see Hierarchical control of instruction fetching,
This bit is reserved, SBZ, in the Non-secure PL2 stage 1 translation tables.
Attribute fields in stage 1 Long-descriptor Block and Page descriptors

Block and Page descriptors split the memory attributes into an upper block and a lower block. Figure B3-16 shows
the memory attribute fields in these blocks, for a stage 1 translation:
Upper attributes Lower attributes

63 59 58 55 54 53 52 11 10 9 8 7 6 5 4 2
IGNORED IGNORED
Reserved for software use nG

XN AF
PXN SH[1:0]
Contiguous bit AP[2:1]
NS
AttrIndx[2:0]
Figure B3-16 Memory attribute fields in Long-descriptor stage 1 Block and Page descriptors
For a stage 1 descriptor, the attributes are:
XN, bit[54] The Execute-never bit. Determines whether the region is executable, see Execute-never restrictions
on instruction fetching on page B3-1355.
PXN, bit[53] The Privileged execute-never bit. Determines whether the region is executable at PL1, see
Execute-never restrictions on instruction fetching on page B3-1355.
Contiguous bit, bit[52]

A bit indicating that 16 adjacent translation table entries point to contiguous memory regions, see
Contiguous bit on page B3-1369.
nG, bit[11] The not global bit. Determines how the translation is marked in the TLB, see Global and
process-specific translation table entries on page B3-1374.
AF, bit[10] The Access flag, see The Access flag on page B3-1358.
SH, bits[9:8] Shareability field, see Memory region attributes on page B3-1362.
AP[2:1], bits[7:6]
Access Permissions bits, see Memory access control on page B3-1352.
Note
For consistency with the Short-descriptor translation table formats, the Long-descriptor format
defines AP[2:1] as the Access Permissions bits, and does not define an AP[0] bit.
AP[1] is reserved, SBO, in the Non-secure PL2 stage 1 translation tables.
NS, bit[5] Non-secure bit. For memory accesses from Secure state, specifies whether the output address is in
Secure or Non-secure memory, see Control of Secure or Non-secure memory access,
For memory accesses from Non-secure state, this bit is ignored.
AttrIndx[2:0], bits[4:2]
Stage 1 memory attributes index field, for the indicated Memory Attribute Indirection Register, see
Long-descriptor format memory region attributes on page B3-1368.
In the upper attributes block, the architecture guarantees that hardware does not alter the fields marked as IGNORED.
For more information, see Other fields in the Long-descriptor translation table format descriptors on
page B3-1369.
Attribute fields in stage 2 Long-descriptor Block and Page descriptors

Block and Page descriptors split the memory attributes into an upper block and a lower block. Figure B3-17 shows
the memory attribute fields in these blocks, for a stage 2 translation:
Upper attributes Lower attributes

63 60 59 58 55 54 53 52 11 10 9 8 7 6 5 2
IGNORED IGNORED (0) (0)
Reserved for System MMU AF
IGNORED SH[1:0]
Reserved for software use HAP[2:1]
XN MemAttr[3:0]
Contiguous bit
Figure B3-17 Memory attribute fields in Long-descriptor stage 2 Block and Page descriptors
For a stage 2 descriptor, the attributes are:
XN, bit[54] The Execute-never bit. Determines whether the region is executable, see Execute-never restrictions
on instruction fetching on page B3-1355.
Contiguous bit, bit[52]

A bit indicating that 16 adjacent translation table entries point to contiguous memory regions, see
Contiguous bit on page B3-1369.
AF, bit[10] The Access flag, see The Access flag on page B3-1358.
SH, bits[9:8] Shareability field, see PL2 control of Non-secure memory region attributes on page B3-1370.
HAP[2:1], bits[7:6]
Stage 2 Access Permissions bits, see PL2 control of Non-secure access permissions on
page B3-1360.
Note
For consistency with the AP[2:1] field, the Long-descriptor format defines HAP[2:1] as the Stage 2
Access Permissions bits, and does not define an HAP[0] bit.
MemAttr[3:0], bits[5:2]
Stage 2 memory attributes, see PL2 control of Non-secure memory region attributes on
page B3-1370.
In the upper attributes block, the architecture guarantees that hardware does not alter the fields marked as IGNORED.
For more information, see Other fields in the Long-descriptor translation table format descriptors on
page B3-1369.
B3.6.3 Control of Secure or Non-secure memory access, Long-descriptor format

Access to the Secure or Non-secure physical address map on page B3-1319 describes how the NS bit in the
translation table entries:
• For accesses from Secure state, determines whether the access is to Secure or Non-secure memory.
• Is ignored by accesses from Non-secure state.
In the Long-descriptor format:
• The NS bit relates only to the memory block or page at the output address defined by the descriptor.
• The descriptors also include an NSTable bit, see Hierarchical control of Secure or Non-secure memory
accesses, Long-descriptor format.
The NS and NSTable bits are valid only for memory accesses from Secure state. Memory accesses from Non-secure
state ignore the values of these bits.
Hierarchical control of Secure or Non-secure memory accesses, Long-descriptor

format
For Long-descriptor format table descriptors for stage 1 translations, the descriptor includes an NSTable bit, that
indicates whether the table identified in the descriptor is in Secure or Non-secure memory. For accesses from Secure
state, the meaning of the NSTable bit is:
NSTable == 0 The defined table address is in the Secure physical address space. In the descriptors in that
translation table, NS bits and NSTable bits have their defined meanings.
NSTable == 1 The defined table address is in the Non-secure physical address space. Because this table is fetched
from the Non-secure address space, the NS and NSTable bits in the descriptors in this table must be
ignored. This means that, for this table:
• The value of the NS bit in any block or page descriptor is ignored. The block or page address
is refers to Non-secure memory.
• The value of the NSTable bit in any table descriptor is ignored, and the table address refers
to Non-secure memory. When this table is accessed, the NS bit in any block or page
descriptor is ignored, and all descriptors in the table refer to Non-secure memory.
In addition, an entry fetched in Secure state is treated as non-global if either:

• NSTable is set to 1.
• The fetch ignores the values of NS and NSTable, because of a higher-level fetch with NSTable set to 1.
That is, these entries must be treated as if nG==1, regardless of the value of the nG bit. For more information about
the nG bit, see Global and process-specific translation table entries on page B3-1374.
Note
• When using the Long-descriptor format, table descriptors are defined only for the first level and second level
of lookup.
• Stage 2 translations are performed only for operations in Non-secure state, that can access only the
Non-secure address space. Therefore, the stage 2 descriptors do not include NS or NSTable bits.
B3.6.4 Selecting between TTBR0 and TTBR1, Long-descriptor translation table format
As described in Determining the translation table base address on page B3-1318, two sets of translation tables can
be defined for each of the PL1&0 stage 1 translations, and TTBR0 and TTBR1 hold the base addresses for the two
sets of tables. The Long-descriptor translation table format provides more flexibility in defining the boundary
between using TTBR0 and using TTBR1. When a PL1&0 stage 1 MMU is enabled, TTBR0 is always used. If
TTBR1 is also used then:
• TTBR1 is used for the top part of the input address range
• TTBR0 is used for the bottom part of the input address range.
The TTBCR.T0SZ and TTBCR.T1SZ size fields control the use of TTBR0 and TTBR1, as Table B3-2 shows.
Table B3-2 Use of TTBR0 and TTBR1, Long-descriptor format
TTBCR Input address range using:
T0SZ T1SZ TTBR0 TTBR1
0b000 0b000 All addresses Not used
Ma 0b000 Zero to (2(32-M)-1) 232-M to maximum input address
0b000 Na Zero to (232-2(32-N)-1) 232-2(32-N) to maximum input address
Ma Na Zero to (2(32-M)-1) 232-2(32-N) to maximum input address
a. M, N must be greater than 0.The maximum possible value for each of T0SZ and T1SZ is 7.
For stage 1 translations, the input address is always a VA, and the maximum possible VA is (232-1).
When address translation is using the Long-descriptor translation table format:
• Figure B3-18 shows how, when TTBCR.T1SZ is zero, the value of TTBCR.T0SZ controls the boundary
between VAs that are translated using TTBR0, and VAs that are translated using TTBR1.
TTBCR.T1SZ==0b000
0xFFFFFFFF
0x80000000 Boundary, when TTBCR.T0SZ==0b001
TTBR1 region
TTBR0 region Effect of increasing TTBCR.T0SZ

TTBR0 region
0x00000000
TTBCR.T0SZ==0b000
Use of TTBR1 disabled
Figure B3-18 Control of TTBR boundary, when TTBCR.T1SZ is zero
• Figure B3-19 on page B3-1342 shows how, when TTBCR.T1SZ is nonzero, the values of TTBCR.T0SZ and
TTBCR.T1SZ control the boundaries between VAs that are translated using TTBR0, and VAs that are
translated using TTBR1.
0xFFFFFFFF
Effect of
TTBR1 region increasing TTBR1 region Effect of increasing TTBCR.T1SZ
TTBCR.T1SZ
Boundary,
TTBCR.T1SZ==0b001 Accesses
generate a Effect of decreasing TTBCR.T0SZ
Translation fault
0x40000000 TTBR0 region Boundary, when TTBCR.T0SZ==0b010
TTBR0 region Effect of increasing TTBCR.T0SZ
0x00000000
TTBCR.T0SZ==0b000 TTBCR.T0SZ>0b000
Figure B3-19 Control of TTBR boundaries, when TTBCR.T1SZ is nonzero

When T0SZ and T1SZ are both nonzero:
— If both fields are set to 0b001, the boundary between the two regions is 0x80000000. This is identical to
having T0SZ set to 0b000 and T1SZ set to 0b001.
— Otherwise, the TTBR0 and TTBR1 regions are non-contiguous. In this case, any attempt to access an
address that is in that gap between the TTBR0 and TTBR1 regions generates a Translation fault.
When using the Long-descriptor translation table format:
• The TTBCR contains fields that define memory region attributes for the translation table walk, for each
TTBR. These are the SH0, ORGN0, IRGN0, SH1, ORGN1, and IRGN1 bits.
• Each TTBR contains an ASID field, and the TTBCR.A1 field selects which ASID to use.
For this translation table format, Long-descriptor translation table format address lookup levels on page B3-1343
summarizes the lookup levels, and Translation table walks, when using the Long-descriptor translation table format
on page B3-1345 describes the possible translations.
Possible translation table registers programming errors

In all the descriptions in this subsection, the size of the input address supported for a PL1&0 stage 1 translation
refers to the size specified by a TTBCR.TxSZ field.
Note
For a PL1&0 stage 1 translation, the input address range can be split so that the lower addresses are translated by
TTBR0 and the higher addresses are translated by TTBR1. In this case, each of input address sizes specified by
TTBCR.{T0SZ, T1SZ} is smaller than the total address size supported by the stage of translation.
The following are possible errors in the programming of TTBR0, TTBR1, and TTBCR. For the translation of a
particular address at a particular stage of translation, either:
• The block size being used to translate the address is larger than the size of the input address supported at a
stage of translation used in performing the required translation. This can occur only for the stage 1 translation
of the PL1&0 translation regime, and only when either TTBCR.T0SZ or TTBCR.T1SZ is zero, meaning
there is no gap between the address range translated by TTBR0 and the range translated by TTBR1. In this
case, this programming error occurs if a block translated from the region that has TxSZ set to zero straddles
the boundary between the two address ranges. Example B3-2 on page B3-1343 shows an example of this
mis-programming.
• The address range translated by a set of blocks marked as contiguous, by use of the contiguous bit, is larger
than the size of the input address supported at a stage of translation used in performing the required
translation.
Example B3-2 Translation table programming error
If TTBCR.T0SZ is programmed to 0 and TTBCR.T1SZ is programmed to 7, this means:

• TTBR0 translates addresses in the range 0x00000000-0xFDFFFFFF.
• TTBR1 translates addresses in the range 0xFE000000-0xFFFFFFFF.
The translation table indicated by TTBR0 might be programmed with a block entry for a 1GB region starting at
0xC0000000. This covers the address range 0xC0000000-0xFFFFFFFF, that overlaps the TTBR1 address range. This
means this block size is larger than the input address size supported for translations using TTBR0, and therefore this
is a programming error.
To understand why this must be a programming error, consider a memory access to address 0xFFFF0000. According
to the TTBCR.{T0SZ, T1SZ} values, this must be translated using TTBR1. However, the access matches a TLB
entry for the translation, using TTBR0, of the block at 0xC0000000. Hardware is not required to detect that the access
to 0xFFFF0000 is being translated incorrectly.
In these cases, an implementation might use one of the following approaches:
• Treat such a block, that might be a block within a contiguous set of blocks, as causing a Translation fault,
even though the block is valid, and the address accessed within that block is within the size of the input
address supported at a stage of translation.
• Treat such a block, that might be a block within a contiguous set of blocks, as not causing a Translation fault,
even though the address accessed within that block is outside the size of the input address supported at a stage
of translation, provided that both of the following apply:
— The block is valid.
— At least one address within the block, or contiguous set of blocks, is within the size of the input address
supported at a stage of translation.
B3.6.5 Long-descriptor translation table format address lookup levels

As stated at the start of this section, because the Long-descriptor translation table format is used for the PL1&0
stage 2 translations, the format must support input addresses of up to 40 bits.
Table B3-3 summarizes the properties of the three levels of address lookup when using this format.
Table B3-3 Properties of the three levels of address lookup with Long-descriptor translation tables
Input address Output address a

Level Number of entries
Size Address range b Size Address range
First Up to 512GB Up to Address[38:0] 1GB Address[39:30] Up to 512
Second Up to 1GB Up to Address[29:0] 2MB Address[39:21] Up to 512
Third 2MB Address[20:0] 4KB Address[39:12] 512

a. Output address when an entry addresses a block of memory or a memory page. If an entry addresses the next level of
address lookup it specifies Address[39:12] for the next-level translation table.
b. Input address range for the translation table. See Use of concatenated first-level translation tables on page B3-1345 for
details of support for a 40-bit input address range.
For first-level and second-level tables, reducing the input address range reduces the number of addresses in the table
and therefore reduces the table size.The appropriate Translation Table Control Register specifies the input address
range.
Stage 1 translations require an input address range of up to 32 bits, corresponding to VA[31:0]. For these
translations:
• For a memory access from a mode other than Hyp mode, the Secure or Non-secure TTBR0 or TTBR1 holds
the translation table base address, and the Secure or Non-secure TTBCR is the control register.
• For a memory access from Hyp mode, HTTBR holds the translation table base address, and HTCR is the
control register.
Note
For translations controlled by TTBR0 and TTBR1, if neither Translation table base register has an input address
range larger than 1GB, then translation starts at the second level. Together, TTBR0 and TTBR1 can still cover the
32-bit VA input address range.
Stage 2 translations require an input address range of up to 40 bits, corresponding to IPA[39:0], and the supported
input address size is configurable in the range 25-40 bits. Table B3-3 on page B3-1343 indicates a requirement for
the translation mechanism to support a 39-bit input address range, Address[38:0]. Use of concatenated translation
tables for stage 2 translations describes how a 40-bit IPA address range is supported. For stage 2 translations:
• VTTBR holds the translation table base address, and VTCR is the control register.
• If a supplied input address is larger than the configured input address size, a Translation fault is generated.
Use of concatenated translation tables for stage 2 translations

If a stage 2 translation requires 16 entries or fewer in its top-level translation table, it can instead:
• Require the corresponding number of concatenated translation tables at the next translation level, aligned to
the size of the block of concatenated translation tables.
• Start the translation at that next translation level.
Note
Stage 2 translations always use the Long-descriptor translation table format.
Use of this translation scheme is:
• Required when the stage 2 translation supports a 40-bit input address range, see Use of concatenated
first-level translation tables on page B3-1345.
• Supported for a stage 2 translation with an input address range of 31-34 bits, see Use of concatenated
second-level translation tables on page B3-1345.
Note
This translation scheme:
• Avoids the overhead of an additional level of translation.
• Requires the software that is defining the translation to:
— Define the concatenated translation tables with the required overall alignment.
— Program VTTBR to hold the address of the first of the concatenated translation tables.
— Program VTCR to indicate the required input address range and first lookup level.
Use of concatenated first-level translation tables
The Long-descriptor format translation tables provide 9 bits of address resolution at each level of lookup. However,
a 40-bit input address range with a translation granularity of 4KB requires a total of 28 bits of address resolution.
Therefore, a stage 2 translation that supports a 40-bit input address range requires two concatenated first-level
translation tables, together aligned to 8KB, where:
• The table at the address with PA[12:0]==0b0000000000000 defines the translations for input addresses with
bit[39]==0.
• The table at the address with PA[12:0]==0b1000000000000 defines the translations for input addresses with
bit[39]==1.
• The 8KB alignment requirement means that both table have the same value for PA[39:13].
Use of concatenated second-level translation tables
A stage 2 translation with an input address range of 31-34 bits can start the translation either:
• With a first-level lookup, accessing a first-level translation table with 2-16 entries.
• With a second-level lookup, accessing a set of concatenated second-level translation tables.
Table B3-4 shows these options, for each of the input address ranges that can use this scheme.
Note
Because these are stage 2 translations, the input address range is an IPA range.
Table B3-4 Possible uses of concatenated translation tables for second-level lookup
Input address range Lookup starts at first level Lookup starts at second level
IPA range Size Required first-level entries Number of concatenated tables Required alignment a
IPA[30:0] 231 bytes 2 2 8KB
IPA[31:0] 232 bytes 4 4 16KB
IPA[32:0] 233 bytes 8 8 32KB
IPA[33:0] 234 bytes 16 16 64KB
a. Required alignment of the set of concatenated second-level tables.
See also Determining the required first lookup level for stage 2 translations on page B3-1348.
B3.6.6 Translation table walks, when using the Long-descriptor translation table format
Figure B3-2 on page B3-1310 shows the possible address translations in an Large Physical Address Extension
implementation. These are:
Stage 1 translations
For all stage 1 translations:
• The input address range is up to 32 bits, as determined by either:
— TTBCR.T0SZ or TTBCR.T1SZ, for a PL1&0 stage 1 translation.
— HTCR.T0SZ, for a PL2 stage 1 translation.
• The output address range is 40 bits.
The stage 1 translations are:

Non-secure PL1&0 stage 1 translation
The stage 1 translation for memory accesses from Non-secure modes other than Hyp
mode. In an implementation that includes the Virtualization Extensions, this translates
a VA to an IPA, otherwise it translates a VA to a PA. For this translation:
• Non-secure TTBR0 or TTBR1 holds the translation table base address.
• Non-secure TTBCR determines which TTBR is used.
Non-secure PL2 stage 1 translation
The stage 1 translation for memory accesses from Hyp mode. Supported only if the
implementation includes the Virtualization Extensions, and translates a VA to a PA. For
this translation, HTTBR holds the translation table base address.
Secure PL1&0 stage 1 translation
The stage 1 translation for memory accesses from Secure modes, translates a VA to a
PA. For this translation:
• Secure TTBR0 or TTBR1 holds the translation table base address.
• Secure TTBCR determines which TTBR is used.
Stage 2 translation
Non-secure PL1&0 stage 2 translation
The stage 2 translation for memory accesses from Non-secure modes other than Hyp
mode. Supported only if the implementation includes the Virtualization Extensions, and
translates an IPA to a PA. For this translation:
• The input address range is 40 bits, as determined by VTCR.T0SZ.
• The output address range depends on the implemented memory system, and is up
to 40 bits.
• VTTBR holds the translation table base address.
• VTCR specifies the required input address range, and whether the first lookup is
at the first level or at the second level.
The Long-descriptor translation table format provides up to three levels of address lookup, as described in
Long-descriptor translation table format address lookup levels on page B3-1343, and the first lookup, in which the
MMU reads the translation table base address, is at either the first level or the second level. The following
determines the level of the first lookup:
• For a stage 1 translation, the required input address range. For more information see Determining the required
first lookup level for stage 1 translations on page B3-1348.
• For a stage 2 translation, the level specified by the VTCR.SL0 field. For more information see Determining
the required first lookup level for stage 2 translations on page B3-1348.
Note
For a stage 2 translation, the size of the required input address range constrains the VTCR.SL0 value.
Figure B3-20 on page B3-1347 shows how the descriptor address for the first lookup for a translation using the
Long-descriptor translation table format is determined from the input address and the Translation table base register
value. This figure shows the lookup for a translation that starts with a first-level lookup, that translates bits[39:30]
of the input address, zero extended if necessary.
n+27
n+26
39 30 29 0
‡ Input address
63 56 55 48 47 40 39 n n-1 0
Translation table
UNK/SBZP Register-defined UNK/SBZP Translation table base address[39:n] UNK/SBZP
base register
n-1
39 n 3 2 0
0 0 0 Descriptor address†
See text for more information about the translation table base register used, and the value of n.
‡ This field is absent if n is 13.
† For a Non-secure PL1&0 stage 1 translation, the IPA of the descriptor. Otherwise, the PA of the descriptor.
Figure B3-20 Long-descriptor first lookup, starting at first level
For a translation that starts with a first-level lookup, as shown in Figure B3-20:
For a stage 1 translation

n is in the range 4-5 and:
• For a memory access from Hyp mode:
— HTTBR is the Translation table base register.
— n=5-HTCR.T0SZ.
• For other accesses:
— The Secure or Non-secure copy of TTBR0 or TTBR1 is the Translation table base
register.
— n=5-TTBCR.TxSZ, where x is 0 when using TTBR0, and 1 when using TTBR1.

n is in the range 4-13 and:
• VTTBR is the Translation table base register.
• n=5-VTCR.T0SZ.
For a translation that starts with a second-level lookup, the descriptor address is obtained in the same way, except
that bits[(n+17):21] of the input address provide bits[(n-1):3] of the descriptor address, where:

n is in the range 7-12. As Determining the required first lookup level for stage 1 translations on
page B3-1348 shows, for a stage 1 translation to start with a second-level lookup, the corresponding
T0SZ or T1SZ field must be 2 or more. This means:
• For a memory access from Hyp mode, n=14-HTCR.T0SZ.
• For other memory accesses, n=14-TTBCR.TxSZ, where x is 0 when using TTBR0, and 1
when using TTBR1.

n is in the range 7-16. For a stage 2 translation to start with a second-level lookup, VTCR.SL0 is
0b00, and n=14-VTCR.T0SZ.
Determining the required first lookup level for stage 1 translations

For a stage 1 translation, the required input address range, indicated by a T0SZ or T1SZ field in a translation table
control register, determines the first lookup level. The size of this input address region is 2(32-TxSZ) bytes, and if this
size is:
• Less than or equal to 230 bytes, the required start is at the second level, and translation requires two levels of
table to map to 4KB pages. This corresponds to a TxSZ value of 2 or more.
• More than 230 bytes, the required start is at the first level, and translation requires three levels of table to map
to 4KB pages. This corresponds to a TxSZ value that is less than 2.
For translations not in Hyp mode, the TTBCR:
• Splits the 32-bit VA input address range between TTBR0 and TTBR1, see Selecting between TTBR0 and
TTBR1, Long-descriptor translation table format on page B3-1341.
• Holds the input address range sizes for TTBR0 and TTBR1, in the TTBCR.T0SZ and TTBCR.T1SZ fields.
For translations in Hyp mode, HTCR.T0SZ indicates the size of the required input address range. For example, if
this field is 0b000, it indicates a 32-bit VA input address range, and translation lookup must start at the first level.
Determining the required first lookup level for stage 2 translations

For a stage 2 translation, the output address range from the stage 1 translations determines the required input address
range for the stage 2 translation. The permitted values of VTCR.SL0 are:
0b00 Stage 2 translation lookup must start at the second level.
0b01 Stage 2 translation lookup must start at the first level.
VTCR.T0SZ must indicate the required input address range. The size of the input address region is 2(32-T0SZ) bytes.
Note
VTCR.T0SZ holds a four-bit signed integer value, meaning it supports values from -8 to 7. This is different from
the other translation control registers, where TnSZ holds a three-bit unsigned integer, supporting values from 0 to 7.
The programming of VTCR must follow the constraints shown in Table B3-5, otherwise behavior is
UNPREDICTABLE. The table also shows how the VTCR.SL0 and VTCR.T0SZ values determine the
VTTBR.BADDR field width.
Table B3-5 Input address range constraints on programming VTCR
VTCR.SL0 VTCR.T0SZ Input address range, R First lookup level BADDR[39:x] width a
0b00 2 to 7 R≤230 bytes Second [39:12] to [39:7]
0b00 -2 to 1 230 <R≤234 bytes Second [39:16] to [39:13]
0b01 -2 to 1 First [39:7] to [39:4]
0b01 -8 to -3 234 <R First [39:13] to [39:8]
a. The first range corresponds to the first T0SZ value, the second range to the second T0SZ value.
Where necessary, the first lookup level provides multiple concatenated translation tables, as described in Use of
concatenated second-level translation tables on page B3-1345. This section also gives more information about the
alternatives, shown in Table B3-5, when R is in the range 231 -234.
Full translation flows for Long-descriptor format translation tables

In a translation table walk, only the first lookup uses the translation table base address from the appropriate
Translation table base register. Subsequent lookups use a combination of address information from:
• The table descriptor read in the previous lookup.
• The input address.
The following sections describe full Long-descriptor format translation flows, down to an entry for a 4KB page:
• The address and Properties fields shown in the translation flows.
• Full translation flow, starting at first-level lookup.
• Full translation flow, starting at second-level lookup on page B3-1351.
The address and Properties fields shown in the translation flows
On an implementation that includes the Virtualization Extensions, for the Non-secure PL1&0 stage 1 translation:
• Any descriptor address is the IPA of the required descriptor.
• The final output address is the IPA of the block or page.
In these cases, a PL1&0 stage 2 translation is performed to translate the IPA to the required PA.
For all other translations, the final output address is the PA of the block or page, and any descriptor address is the
PA of the descriptor.
Properties indicates register or translation table fields that return information, other than address information, about
the translation or the targeted memory region. For more information see Information returned by a translation table
lookup on page B3-1318, and the description of the register or translation table descriptor.
For translations using the Long-descriptor translation table format, Long-descriptor translation table format
descriptors on page B3-1335 describes the descriptors formats.
Full translation flow, starting at first-level lookup
Figure B3-21 on page B3-1350 shows the complete translation flow for a stage 1 translation table walk that starts
at a first-level lookup. For more information about the fields shown in the figure see The address and Properties
fields shown in the translation flows.
n is {4, 5} n+27 n+26

39 30 29 21 20 12 11 0
Input address
63 56 55 48 47 40 39 n n-1 0
Translation table
UNK/SBZP Properties UNK/SBZP Translation table base address[39:n] UNK/SBZP
base register
n-1
39 n 3 2 0
Descriptor
0 0 0
address
First-level lookup
63 59 58 52 51 40 39 12 11 2 1 0
First-level
Properties IGNORED SBZ Second-level table address[39:12] IGNORED 1 1 table descriptor
39 12 11 3 2 0
Descriptor
0 0 0
address
Second-level lookup
63 59 58 52 51 40 39 12 11 2 1 0
Second-level
Properties IGNORED SBZ Third-level table address[39:12] IGNORED 1 1
table descriptor
39 12 11 3 2 0
Descriptor
0 0 0
address
Third-level lookup
63 52 51 40 39 12 11 2 1 0
Third-level
Properties SBZ Output address[39:12] Properties 1 1
page descriptor
Figure B3-21 Complete Long-descriptor format stage 1 translation, starting at first level
If the first-level lookup or second-level lookup returns a block descriptor then the translation table walk completes
at that level.
A stage 2 translation that starts at a first-level lookup differs from the translation shown in Figure B3-21 only as
follows:
• The possible values of n are 4-13, to support an input address of between 31 and 40 bits.
• A descriptor and output addresses are always the PAs.
Full translation flow, starting at second-level lookup
Figure B3-22 shows the complete translation flow for a stage 1 translation table walk that starts at a second-level
lookup. For more information about the fields shown in the figure see The address and Properties fields shown in
the translation flows on page B3-1349.
n is {7, …, 12} n+18 n+17

39 32 31 21 20 12 11 0
Input address
63 56 55 48 47 40 39 n n-1 0
Translation table
UNK/SBZP Properties UNK/SBZP Translation table base address[39:n] UNK/SBZP
base register
39 n n-1 3 2 0
Descriptor
0 0 0
address
Second-level lookup
63 59 58 52 51 40 39 12 11 2 1 0
Second-level
Properties IGNORED SBZ Third-level table address[39:12] IGNORED 1 1
table descriptor
39 12 11 3 2 0
Descriptor
0 0 0
address
Third-level lookup
63 52 51 40 39 12 11 2 1 0
Third-level
Properties SBZ Output address[39:12] Properties 1 1
page descriptor
Figure B3-22 Complete Long-descriptor format stage 1 translation, starting at second level
If the second-level lookup returns a block descriptor then the translation table walk completes at that level.
A stage 2 translation that starts at a second-level lookup differs from the translation shown in Figure B3-22 only as
follows:
• The possible values of n are 7-16, to support an input address of up to 34 bits.
• The descriptor and output addresses are always PAs.
B3.7 Memory access control

In addition to an output address, a translation table entry that refers to page or region of memory includes fields that
define properties of the target memory region. Information returned by a translation table lookup on page B3-1318
describes the classification of those fields as address map control, access control, and memory attribute fields. The
access control fields, described in this section, determine whether the processor, in its current state, is permitted to
perform the required access to the output address given in the translation table descriptor. If a translation stage does
not permit the access then an MMU fault is generated for that translation stage, and no memory access is performed.
The following sections describe the memory access controls:

• Access permissions.
• Execute-never restrictions on instruction fetching on page B3-1355.
• Domains, Short-descriptor format only on page B3-1358.
• The Access flag on page B3-1358.
• PL2 control of Non-secure access permissions on page B3-1360.
B3.7.1 Access permissions
Note
This section gives a general description of memory access permissions. In an implementation that includes the
Virtualization Extensions, software executing at PL1 in Non-secure state can see only the access permissions
defined by the Non-secure PL1&0 stage 1 translations. However, software executing at PL2 can modify these
permissions, as described in PL2 control of Non-secure access permissions on page B3-1360. This modification is
invisible to Non-secure software executing at PL1 or PL0.
Access permission bits in a translation table descriptor control access to the corresponding memory region. The
Short-descriptor translation table format supports two options for defining the access permissions:
• Three bits, AP[2:0], define the access permissions.
• Two bits, AP[2:1], define the access permissions, and AP[0] can be used as an Access flag.
SCTLR.AFE selects the access permissions option. Setting this bit to 1, to enable the Access flag, also selects use
of AP[2:1] to define access permissions.
The Long-descriptor translation table format uses only AP[2:1] to control the access permissions, and provides an
AF bit for use as an Access flag. This means the VMSA behaves as if SCTLR.AFE is set to 1, regardless of the value
that software has written to this bit.
Note
When use of the Long-descriptor format is enabled, SCTLR.AFE is UNK/SBOP.
From the introduction of the Large Physical Address Extension, ARM deprecates any use of the AP[2:0] scheme
for defining access permissions, see Deprecations relating to using the AP[2:0] scheme for defining MMU access
permissions on page D9-2464.
The Access flag on page B3-1358 describes the Access flag, for both translation table formats.
The XN and PXN bits provide additional access controls for instruction fetches, see Execute-never restrictions on
instruction fetching on page B3-1355.
An attempt to perform a memory access that the translation table access permission bits do not permit generates a
Permission fault, for the corresponding stage of translation. However, when using the Short-descriptor translation
table format, it generates the fault only if the access is to memory in the Client domain, see Domains,
Short-descriptor format only on page B3-1358.
Note
In an implementation that includes the Virtualization Extensions, memory accesses made in Non-secure state at PL1
or PL0 are subject to two stages of translation. Each stage of translation has its own, independent, fault checking.
Fault handling is different for the two stages, see Exception reporting in a VMSA implementation on page B3-1406.
The following sections describe the two access permissions models:
• AP[2:1] access permissions model.
• AP[2:0] access permissions control, Short-descriptor format only on page B3-1354. This section includes
some information on access permission control in earlier versions of the ARM VMSA.
AP[2:1] access permissions model
Note
Some documentation describes this as the simplified access permissions model.
This access permissions model is used if the translation is either:

• Using the Long-descriptor translation table format.
• Using Short-descriptor translation table format, and the SCTLR.AFE bit is set to 1.
In this model:
• One bit, AP[2], selects between read-only and read/write access.
• A second bit, AP[1], selects between Application level (PL0) and System level (PL1) control.
For the Non-secure PL2 stage 1 translations, AP[1] is SBO.
In the ARM architecture, this model permits four access combinations:

• Read-only at all privilege levels.
• Read/write at all privilege levels.
• Read-only at PL1, no access by software executing at PL0.
• Read/write at PL1, no access by software executing at PL0.
Table B3-6 shows this access control model.
Table B3-6 VMSAv7 AP[2:1] access permissions model
AP[2], disable write access AP[1], enable unprivileged access Access
0 0a Read/write, only at PL1
0 1 Read/write, at any privilege level
1 0a Read-only, only at PL1
1 1 Read-only, at any privilege level
a. Not valid for Non-secure PL2 stage 1 translation tables. AP[1] is SBO in these tables.
Hierarchical control of access permissions, Long-descriptor format
The Long-descriptor translation table format introduces a mechanism that entries at one level of translation table
lookup can use to set limits on the permitted entries at subsequent levels of lookup. This applies to the access
permissions, and also to the restrictions on instruction fetching described in Hierarchical control of instruction
fetching, Long-descriptor format on page B3-1356.
The restrictions apply only to subsequent levels of lookup at the same stage of translation. The APTable[1:0] field
restricts the access permissions, as Table B3-7 on page B3-1354 shows.
As stated in the table footnote, for the Non-secure PL2 stage 1 translation tables, APTable[0] is reserved, SBZ.
Table B3-7 Effect of APTable[1:0] on subsequent levels of lookup
APTable[1:0] Effect
00 No effect on permissions in subsequent levels of lookup.
01 a Access at PL0 not permitted, regardless of permissions in subsequent levels of lookup.
10 Write access not permitted, at any privilege level, regardless of permissions in subsequent levels of lookup.
11 a Regardless of permissions in subsequent levels of lookup:

• Write access not permitted, at any privilege level.
• Read access not permitted at PL0.
a. Not valid for the Non-secure PL2 stage 1 translation tables. In those tables, APTable[0] is SBZ.
Note
The APTable[1:0] settings are combined with the translation table access permissions in the translation tables
descriptors accessed in subsequent levels of lookup. They do not restrict or change the values entered in those
descriptors.
The Long-descriptor format provides APTable[1:0] control only for the stage 1 translations. The corresponding bits
are SBZ in the stage 2 translation table descriptors.
When APTable[1:0] is not set to 0b00, its effects might be held in one or more TLB entries. Therefore, a change to
APTable[1:0] might require coarse-grained invalidation of the TLB to ensure that the effect of the change is visible
to subsequent memory transactions.
AP[2:0] access permissions control, Short-descriptor format only

This access permissions model applies when using the Short-descriptor translation tables format, and the
SCTLR.AFE bit is set to 0. Table B3-8 shows this access permissions model.
When SCTLR.AFE is set to 0, ensuring that the AP[0] bit is always set to 1 effectively changes the access model to
the simpler model described in AP[2:1] access permissions model on page B3-1353.
Table B3-8 shows the full AP[2:0] access permissions model:
Table B3-8 VMSAv7 MMU access permissions
AP[2] AP[1:0] PL1 access Unprivileged access Description
0 00 No access No access All accesses generate Permission faults
01 Read/write No access Access only at PL1
10 Read/write Read-only Writes at PL0 generate Permission faults
11 Read/write Read/write Full access
1 00 - - Reserved
01 Read-only No access Read-only, only at PL1
10 Read-only Read-only Read-only at any privilege level, deprecated a
11 Read-only Read-only Read-only at any privilege level b
a. From VMSAv7, ARM strongly recommends use of the 0b11 encoding for Read-only at any privilege level.
b. This mapping is introduced in VMSAv7, and is reserved in VMSAv6.
Note
• Before VMSAv7, the SCTLR.S and SCTLR.R bits also affect the access permissions. For more information,
see Translation attributes on page D15-2591.
• VMSAv7 supports the full set of access permissions shown in Table B3-8 on page B3-1354 only when
SCTLR.AFE is set to 0. When SCTLR.AFE is set to 1, the only supported access permissions are those
described in AP[2:1] access permissions model on page B3-1353.
• Some documentation describes the AP[2] bit in the translation table entries as the APX bit.
B3.7.2 Execute-never restrictions on instruction fetching

Execute-never (XN) controls provide an additional level of control on memory accesses permitted by the access
permissions settings. These controls are:
XN, Execute-never
When the XN bit is 1, a Permission fault is generated if the processor attempts to execute an
instruction fetched from the corresponding memory region. However, when using the
Short-descriptor translation table format, the fault is generated only if the access is to memory in the
Client domain, see Domains, Short-descriptor format only on page B3-1358. A processor can
execute instructions from a memory region only if the access permissions for its current state permit
read access, and the XN bit is set to 0.
PXN, Privileged execute-never

When the PXN bit is 1, a Permission fault is generated if the processor is executing at PL1 and
attempts to execute an instruction fetched from the corresponding memory region. As with the XN
bit, when using the Short-descriptor translation table format, the fault is generated only if the access
is to memory in the Client domain.
In both the Short-descriptor format and the Long-descriptor format translation tables, all descriptors for memory
blocks and pages always include an XN bit.
Support for the PXN bit is as follows:
• The Long-descriptor translation table formats always include the PXN bit.
• An implementation that includes the Large Physical Address Extension must:

— Support the use of the PXN bit.
— Use the Short-descriptor translation table formats that include the PXN bit.
• On an implementation that does not include the Large Physical Address Extension, support for use of the
PXN bit is OPTIONAL, and:
— If use of the PXN bit is supported, the Short-descriptor translation table formats include the PXN bit.
— Otherwise, the Short-descriptor translation table formats do not include the PXN bit.
Short-descriptor translation table first-level descriptor formats on page B3-1322 describes how support for
the PXN bit affects the Short-descriptor translation table formats.
Note
An implementation that does not include the Large Physical Address Extension always uses the Short-descriptor
translation table formats.
In the Non-secure PL2 stage 1 translation tables, the PXN bit is reserved, SBZ.
In addition, the Virtualization Extensions provide controls that enforce execute-never restrictions, regardless of the
settings in the translation tables. Execute-never controls provided by the Virtualization Extensions on page B3-1357
describes these controls.
The execute-never controls apply also to speculative instruction fetching. This means a speculative instruction fetch
from a memory region that is execute-never at the current level of privilege is prohibited.
The XN control means that, when the MMU is enabled, the processor can fetch, or speculatively fetch, an instruction
from a memory location only if all of the following apply:
• If using the Short-descriptor translation table format, the translation table descriptor for the location does not
indicate that it is in a No access domain.
• If using the Long-descriptor translation table format, or using the Short descriptor format and the descriptor
indicates that the location is in a Client domain, in the descriptor for the location the following apply:
— XN is set to 0.
— The access permissions permit a read access from the current processor mode.
• No other Prefetch Abort condition exists.
Note
• The PXN control applies to the processor privilege when it attempts to execute the instruction. In an
implementation that fetches instructions speculatively, this might not be the privilege when the instruction
was prefetched. Therefore, the architecture does not require the PXN control to prevent instruction fetching.
• Although the execute-never controls apply to speculative fetching, on a speculative instruction fetch from an
execute-never location, no Permission fault is generated unless the processor attempts to execute the
instruction fetched from that location. This means that, if a speculative fetch from an execute-never location
is attempted, but there is no attempt to execute the corresponding instruction, a Permission fault is not
generated.
• The software that defines a translation table must mark any region of memory that is read-sensitive as
execute-never, to avoid the possibility of a speculative fetch accessing the memory region. For example, it
must mark any memory region that corresponds to a read-sensitive peripheral as Execute-never.
• When using the Short-descriptor translation table format, the XN attribute is not checked for domains marked
as Manager. Therefore, the system must not include read-sensitive memory in domains marked as Manager,
because the XN bit does not prevent speculative fetches from a Manager domain.
When no MMU for the translation regime is enabled, memory regions cannot have XN or PXN attributes assigned.
Behavior of instruction fetches when all associated MMUs are disabled on page B3-1314 describes how disabling
all MMUs affects instruction fetching.
Hierarchical control of instruction fetching, Long-descriptor format

The Long-descriptor translation table format introduces a mechanism that entries at one level of translation tables
lookup can use to set limits on the permitted entries at subsequent levels of lookup. This applies to the restrictions
on instruction fetching, and also to the access permissions described in Hierarchical control of access permissions,
The restrictions apply only to subsequent levels of lookup at the same stage of translation, and:
• XNTable restricts the XN control:

— When XNTable is set to 1, the XN bit is treated as 1 in all subsequent levels of lookup, regardless of
the actual value of the bit.
— When XNTable is set to 0 it has no effect.
• PXNTable restricts the PXN control:

— When PXNTable is set to 1, the PXN bit is treated as 1 in all subsequent levels of lookup, regardless
of the actual value of the bit.
— When PXNTable is set to 0 it has no effect.
Note
The XNTable and PXNTable settings are combined with the XN and PXN bits in the translation table descriptors
accessed at subsequent levels of lookup. They do not restrict or change the values entered in those descriptors.
The XNTable and PXNTable controls are provided only in the Long-descriptor translation table format, and only
for stage 1 translations. The corresponding bits are SBZ in the stage 2 translation table descriptors.
When XNTable, or PXNTable, is set to 1, its effects might be held in one or more TLB entries. Therefore, a change
to XNTable or PXNTable might require coarse-grained invalidation of the TLB to ensure that the effect of the
change is visible to subsequent memory transactions.
Execute-never controls provided by the Virtualization Extensions

The Virtualization Extensions provide additional controls that force memory regions to be treated as execute-never,
regardless of the settings in the appropriate translation table descriptors. The following subsections describe these
controls:
• Restriction on Secure instruction fetch.
• Preventing execution from writable locations.
Restriction on Secure instruction fetch
The Virtualization Extensions add a Secure instruction fetch bit, SCR.SIF. When this bit is set to 1, any attempt in
Secure state to execute an instruction fetched from Non-secure physical memory causes a Permission fault. As with
all Permission fault checking, when using the Short-descriptor format translation tables the check applies only to
Client domains, see Access permissions on page B3-1352.
ARM expects SCR.SIF to be static during normal operation. In particular, whether the TLB holds the effect of the
SIF bit is IMPLEMENTATION DEFINED. The generic sequence to ensure visibility of a change to the SIF bit is:
Change the SCR.SIF bit

ISB ; This ensures synchronization of the change
Invalidate entire TLB
DSB ; This completes the TLB Invalidation
ISB ; This ensures instruction synchronization
Preventing execution from writable locations
The Virtualization Extensions add control bits that, when the corresponding stage 1 MMU is enabled, force writable
memory to be treated as XN, regardless of the setting of the XN bit:
• For Secure and Non-secure PL1&0 stage 1 translations, when SCTLR.WXN is set to 1, all regions that are
writable at stage 1 of the address translation are treated as XN.
• For Non-secure PL2 stage 1 translations, when HSCTLR.WXN is set to 1, all regions that are writable at
stage 1 of the address translation are treated as XN.
• For Secure and Non-secure PL1&0 stage 1 translations, when SCTLR.UWXN is set to 1, an instruction fetch
is treated as accessing a PXN region if it accesses a region that software executing at PL0 can write to.
For more information about the control bits see SCTLR, System Control Register, VMSA on page B4-1700 and
HSCTLR, Hyp System Control Register, Virtualization Extensions on page B4-1587.
Note
Setting a WXN or UWXN bit to 1 changes the interpretation of the translation table entry, overriding a zero value
of an XN or PXN field. It does not cause any change to the translation table entry.
For any given virtual machine, ARM expects WXN and UWXN to remain static in normal operation. In particular,
it is IMPLEMENTATION DEFINED whether TLB entries associated with a particular VMID reflect the effect of the
values of these bits. A generic sequence to ensure synchronization of a change to these bits, when that change is
made without a corresponding change of VMID, is:
Change the WXN or UWXN bit

ISB ; This ensures synchronization of the change
Invalidate entire TLB of associated entries
DSB ; This completes the TLB Invalidation
ISB ; This ensures instruction synchronization
As with all Permission fault checking, if the stage 1 translation is using the Short-descriptor translation table format,
the permission checks are performed only for Client domains. For more information see Access permissions on
page B3-1352.
For more information about address translation see About address translation on page B3-1309.
B3.7.3 Domains, Short-descriptor format only

A domain is a collection of memory regions. The Short-descriptor translation table format supports 16 domains, and
requires the software that defines a translation table to assign each VMSA memory region to a domain. When using
the Short-descriptor format:
• First-level translation table entries for Page tables and Sections include a domain field.
• Translation table entries for Supersections do not include a domain field. The Short-descriptor format defines
Supersections as being in domain 0.
• Second-level translation table entries inherit a domain setting from the parent first-level Page table entry.
• Each TLB entry includes a domain field.
The domain field specifies which of the 16 domains the entry is in, and a two-bit field in the DACR defines the
permitted access for each domain. The possible settings for each domain are:
No access Any access using the translation table descriptor generates a Domain fault.
Clients On an access using the translation table descriptor, the access permission attributes are checked.
Therefore, the access might generate a Permission fault.
Managers On an access using the translation table descriptor, the access permission attributes are not checked.
Therefore, the access cannot generate a Permission fault.
See The MMU fault-checking sequence on page B3-1395 for more information about how, when using the
Short-descriptor translation table format, the Domain attribute affects the checking of the other attributes in the
translation table descriptor.
Note
A single program might:
• Be a Client of some domains.
• Be a Manager of some other domains.
• Have no access to the remaining domains.
The Long-descriptor translation table format does not support domains. When a stage of translation is using this
format, all memory is treated as being in a Client domain, and the settings in the DACR are ignored.
B3.7.4 The Access flag

The Access flag indicates when a page or section of memory is accessed for the first time since the Access flag in
the corresponding translation table descriptor was set to 0:
• If address translation is using the Short-descriptor translation table format, it must set SCTLR.AFE to 1 to
enable use of the Access flag, see SCTLR, System Control Register, VMSA on page B4-1700. Setting this bit
to 1 redefines the AP[0] bit in the translation table descriptors as an Access flag, and limits the access
permissions information in the translation table descriptors to AP[2:1], as described in AP[2:1] access
permissions model on page B3-1353.
Note
ARMv6K introduces the Access flag mechanism. In earlier versions of the architecture, the SCTLR.AFE bit
is RAZ/WI. For more information see CP15 c1, System Control Register, SCTLR on page D12-2515.
• The Long-descriptor format always supports an Access flag bit in the translation table descriptors, and
address translation using this format behaves as if SCTLR.AFE is set to 1, regardless of the value of that bit.
The Access flag can be managed by software or by hardware. However, support for hardware management of the
Access flag is OPTIONAL and deprecated. The following subsections describe the management options:
• Software management of the Access flag.
• Hardware management of the Access flag.
Software management of the Access flag

An implementation that requires software to manage the Access flag generates an Access flag fault whenever a
translation table entry with the Access flag set to 0 is read into the TLB
Note
When using the Short-descriptor translation table format, Access flag faults are generated only if SCTLR.AFE is
set to 1, to enable use of a translation table descriptor bit as an Access flag.
The Access flag mechanism expects that, when an Access flag fault occurs, software resets the Access flag to 1 in
the translation table entry that caused the fault. This prevents the fault occurring the next time that memory location
is accessed. Entries with the Access flag set to 0 are never held in the TLB, meaning software does not have to flush
the entry from the TLB after setting the flag.
Hardware management of the Access flag

For the Secure and Non-secure PL1&0 stage 1 translations, an implementation can provide hardware management
of the Access flag. In this case, if a translation table entry with the Access flag set to 0 is read into the TLB, the
hardware writes 1 to the Access flag bit of the translation table entry in memory.
An implementation that provides hardware management of the Access flag for the Secure and Non-secure PL1&0
stage 1 translations:
• Uses the HW Access flag field, ID_MMFR2[31:28], to indicate this implementation choice.
• Implements the SCTLR.HA bit. This bit must be set to 1 to enable hardware management of the Access flag.
Note
When using the Short-descriptor translation table format, hardware management of the Access flag is performed
only if both:
• SCTLR.AFE is set to 1, to enable use of an Access flag.
• SCTLR.HA is set to 1, to enable hardware management of the Access flag.
The Banking of SCTLR means that these bits are defined independently for the Secure and Non-secure address
translations.
When hardware management of the Access flag, is enabled for a stage of address translation, no Access flag faults
are generated for the corresponding translations.
Any implementation of hardware management of the Access flag must ensure that any software changes to the
translation table are not overwritten. The architecture does not require software that changes translation table entries
to use interlocked operations. The hardware management mechanisms for the Access flag must prevent any loss of
data written to translation table entries that might occur when, for example, a write by another processor occurs
between the read and write phases of a translation table walk that updates the Access flag.
Architecturally, an operating system that uses the Access flag must support the software faulting option that
generates Access flag faults. This provides compatibility between systems that include a hardware implementation
of the Access flag and those systems that do not implement this feature.
ARM deprecates any use of the SCTLR.HA bit. That is, in an implementation where this bit is RW, it deprecates
setting this bit to 1 to enable hardware management of the Access flag.
Hardware management of the Access flag is never supported for:

• Non-secure PL1&0 stage 2 translations.
• Non-secure PL2 stage 1 translations.
B3.7.5 PL2 control of Non-secure access permissions

Non-secure software executing at PL2 controls two sets of translation tables, both of which use the Long-descriptor
translation table format:
• The translation tables that control the Non-secure PL2 stage 1 translations. These map VAs to PAs, for
memory accesses made when executing in Non-secure state at PL2, and are indicated and controlled by the
HTTBR and HTCR.
These translations have similar access controls to other Non-secure stage 1 translations using the
Long-descriptor translation table format, as described in:
— AP[2:1] access permissions model on page B3-1353.
— Execute-never restrictions on instruction fetching on page B3-1355.
The differences from the Non-secure stage 1 translations are that:
— The APTable[0], PXNTable, and PXN bits are reserved, SBZ.
— AP[1] is reserved, SBO.
• The translation tables that control the Non-secure PL1&0 stage 2 translations. These map the IPAs from the
stage 1 translation onto PAs, for memory accesses made when executing in Non-secure state at PL1 or PL0,
and are indicated and controlled by the VTTBR and VTCR.
The descriptors in the virtualization translation tables define a second level of access permissions, that are
overlaid onto the permissions defined in the stage 1 translation. This section describes this overlaying of
access permissions.
Note
In an implementation of virtualization, the second-level access permissions mean a hypervisor can define additional
access restrictions to those defined by a Guest OS in the stage 1 translation tables. For a particular access, the actual
access permission is the more restrictive of the permissions defined by:
• The Guest OS, in the stage 1 translation tables.
• The hypervisor, in the stage 2 translation tables.
The stage 2 access controls defined at PL2:

• Affect only the Non-secure stage 1 access permissions settings.
• Take no account of whether the accesses are from a PL1 mode or a PL0 mode.
• Permit software executing at PL2 to assign a write-only attribute to a memory region.
The HAP[2:1] field in the stage 2 descriptors define the stage 2 access permissions, as Table B3-9 on page B3-1361
shows:
Table B3-9 Stage 2 control of access permissions
HAP[2:1] Access permission
00 No access permitted
01 Read-only. Writes to the region are not permitted, regardless of the stage 1 permissions.
10 Write-only. Reads from the region are not permitted, regardless of the stage 1 permissions.
11 Read/write. The stage 1 permissions determine the access permissions for the region.
For more information about the HAP[2:1] field see Attribute fields in stage 2 Long-descriptor Block and Page
descriptors on page B3-1339.
If the stage 2 permissions cause a Permission fault, this is a stage 2 MMU fault. Stage 2 MMU faults are taken to
Hyp mode, and reported in the HSR using an EC code of 0x20 or 0x24. For more information, see Use of the HSR
on page B3-1421.
Note
The combination of the EC code and the STATUS value in the HSR indicate that the fault is a stage 2 MMU fault.
The stage 2 permissions include an XN attribute. If this is set to 1, execution from the region is not permitted,
regardless of the value of the XN attribute in the stage 1 translation. If a Permission fault is generated because the
stage 2 XN bit is set to 1, this is reported as a stage 2 MMU fault.
Prioritization of aborts on page B3-1404 describes the abort prioritization if both stages of a translation generate a
fault.
B3.8 Memory region attributes

In addition to an output address, a translation table entry that refers to a page or region of memory includes fields
that define properties of that target memory region. Information returned by a translation table lookup on
page B3-1318 describes the classification of those fields as address map control, access control, and memory
attribute fields. The memory region attribute fields control the memory type, accesses to the caches, and whether
the memory region is Shareable and therefore is coherent.
The following sections describe the assignment of memory region attributes for stage 1 translations:
• Overview of memory region attributes for stage 1 translations.
• Short-descriptor format memory region attributes, without TEX remap on page B3-1363.
• Short-descriptor format memory region attributes, with TEX remap on page B3-1364.
• Long-descriptor format memory region attributes on page B3-1368.
For an implementation that does not include the Virtualization Extensions, and for an implementation that includes
the Virtualization Extensions and is operating in Secure state, or in Hyp mode, these assignments define the memory
attributes of the accessed region.
For an implementation that includes the Virtualization Extensions and is operating in a Non-secure PL1 or PL0
mode, the Non-secure PL1&0 stage 2 translation can modify the memory attributes assigned by the stage 1
translation. PL2 control of Non-secure memory region attributes on page B3-1370 describes these stage 2
assignments.
B3.8.1 Overview of memory region attributes for stage 1 translations

The description of the memory region attributes in a translation descriptor divides into:
Memory type and attributes

These are described either:
• Directly, by bits in the translation table descriptor.
• Indirectly, by registers referenced by bits in the table descriptor. This is described as
remapping the memory type and attribute description.
The Short-descriptor translation table format can use either of these approaches, selected by the
SCTLR.TRE bit:
TRE == 0 Remap disabled. The TEX[2:0], C, and B bits in the translation table descriptor define
the memory region attributes. Short-descriptor format memory region attributes,
without TEX remap on page B3-1363 describes this encoding.
Note
With the Short-descriptor format, remapping is called TEX remap, and the SCTLR.TRE
bit is the TEX remap enabled bit.
The description of the TRE == 0 encoding includes information about the encoding in
previous versions of the architecture.
TRE == 1 Remap enabled. The TEX[0], C, and B bits in the translation table descriptor are index
bits to the MMU remap registers, that define the memory region attributes:
• The Primary Region Remap Register, PRRR.
• The Normal Memory Remap Register, NMRR.
Short-descriptor format memory region attributes, with TEX remap on page B3-1364
describes this encoding scheme.
This scheme reassigns translation table descriptor bits TEX[2:1] for use as bits managed
by the operating system.
The Long-descriptor translation table format always uses remapping. This means the VMSA
behaves as if SCTLR.TRE is set to 1, regardless of the value that software has written to this bit.
Note
When use of the Long-descriptor format is enabled, SCTLR.TRE is UNK/SBOP.
Long-descriptor format memory region attributes on page B3-1368 describes this encoding.
Shareability In the Short-descriptor translation table format, the S bit in the translation table descriptor encodes
whether the region is shareable. Enabling TEX remap extends the shareability description. For more
information see:
• Shareability and the S bit, without TEX remap on page B3-1364.
• Shareability and the S bit, with TEX remap on page B3-1366.
In the Long-descriptor translation table format, the SH[1:0] field in the translation table descriptor
encodes shareability information. For more information see Shareability, Long-descriptor format on
page B3-1369.
B3.8.2 Short-descriptor format memory region attributes, without TEX remap

When using the Short-descriptor translation table formats, TEX remap is disabled when SCTLR.TRE is set to 0.
Note
• The Short-descriptor format scheme without TEX remap is the scheme used in VMSAv6.
• The B (Bufferable), C (Cacheable), and TEX (Type extension) bit names are inherited from earlier versions
of the architecture. These names no longer adequately describe the function of the B, C, and TEX bits.
Table B3-10 shows the C, B, and TEX[2:0] encodings when TEX remap is disabled:
Table B3-10 TEX, C, and B encodings when TRE == 0
TEX[2:0] C B Description Memory type Page Shareable
000 0 0 Strongly-ordered Strongly-ordered Shareable
1 Shareable Device a Device Shareable a
1 0 Outer and Inner Write-Through, no Write-Allocate Normal S bit b
1 Outer and Inner Write-Back, no Write-Allocate Normal S bit b
001 0 0 Outer and Inner Non-cacheable Normal S bit b
1 Reserved - -
1 0 IMPLEMENTATION DEFINED IMPLEMENTATION IMPLEMENTATION

DEFINED DEFINED
1 Outer and Inner Write-Back, Write-Allocate Normal S bit b
010 0 0 Non-shareable Device a Device Non-shareable a
1 Reserved - -
1 x Reserved - -
Table B3-10 TEX, C, and B encodings when TRE == 0 (continued)
TEX[2:0] C B Description Memory type Page Shareable
011 x x Reserved - -
1BB A A Cacheable memory: AA = Inner attribute c Normal S bit b

BB = Outer attribute
a. For more information, see Shareable attribute for Device memory regions on page A3-134. Some implementations make no distinction
between Shareable Device memory and Non-shareable Device memory, and refer to both memory types as Shareable Device memory.
b. For more information, see Shareability and the S bit, without TEX remap.
c. For more information, see Cacheable memory attributes, without TEX remap.
See Memory types and attributes and the memory order model on page A3-123 for an explanation of Normal,
Strongly-ordered and Device memory types, and of the shareability attribute.
Cacheable memory attributes, without TEX remap

When TEX[2] == 1, the translation table entry describes Cacheable memory, and the rest of the encoding defines
the Inner and Outer cache attributes:
TEX[1:0] Define the Outer cache attribute.
C, B Define the Inner cache attribute.
The translation table entries use the same encoding for the Outer and Inner cache attributes, as Table B3-11 shows.
Table B3-11 Inner and Outer cache attribute encoding
Encoding Cache attribute
00 Non-cacheable
01 Write-Back, Write-Allocate
10 Write-Through, no Write-Allocate
11 Write-Back, no Write-Allocate
Shareability and the S bit, without TEX remap

The translation table entries also include an S bit. This bit:
• Is ignored if the entry refers to Device or Strongly-ordered memory.
• For Normal memory, determines whether the memory region is Shareable or Non-shareable:
S == 0 Normal memory region is Non-shareable.
S == 1 Normal memory region is Shareable.
B3.8.3 Short-descriptor format memory region attributes, with TEX remap

When using the Short-descriptor translation table formats, TEX remap is enabled when SCTLR.TRE is set to 1. In
this configuration:
• The software that defines the translation tables must program the PRRR and NMRR to define seven possible
memory region attributes.
• The TEX[0], C, and B bits of the translation table descriptors define the memory region attributes, by
indexing PRRR and NMRR.
• Hardware makes no use TEX[2:1], see The OS managed translation table bits on page B3-1368.
When TEX remap is enabled:
• or seven of the eight possible combinations of the TEX[0], C and B bits, fields in the PRRR and NMRR
define the region attributes, as described in this section.
• The meaning of the eighth combination for the TEX[0], C and B bits is IMPLEMENTATION DEFINED.
• Four bits in the PRRR define whether the region is shareable, as described in Shareability and the S bit, with
TEX remap on page B3-1366.
For each of the possible encodings of the TEX[0], C, and B bits in a translation table entry, Table B3-12 shows
which fields of the PRRR and NMRR registers describe the memory region attributes.
Table B3-12 TEX, C, and B encodings when TRE == 1
Encoding Cache attributes a, b:

Memory type a Outer Shareable attribute a, c
TEX[0] C B Inner cacheability Outer cacheability
0 0 0 PRRR[1:0] NMRR[1:0] NMRR[17:16] NOT(PRRR[24])
1 PRRR[3:2] NMRR[3:2] NMRR[19:18] NOT(PRRR[25])
1 0 PRRR[5:4] NMRR[5:4] NMRR[21:20] NOT(PRRR[26])
1 0 0 PRRR[9:8] NMRR[9:8] NMRR[25:24] NOT(PRRR[28])
1 0 IMPLEMENTATION DEFINED
a. For details of the Memory type and Outer Shareable encodings see PRRR, Primary Region Remap Register, VMSA on page B4-1693. For
details of the Cache attributes encodings see Table B3-11 on page B3-1364.
b. Applies only if the memory type for the region is mapped as Normal memory.
c. Applies only if the memory type for the region is mapped as Normal or Device memory and the region is Shareable.
If an implementation includes the Security Extensions, the TEX remap registers and the SCTLR.TRE bit are Banked
between the Secure and Non-secure security states. For more information, see The effect of the Security Extensions
on TEX remap on page B3-1368.
When TEX remap is enabled, the mappings specified by the PRRR and NMRR determine the mapping of the
TEX[0], C and B bits in the translation tables to memory type and cacheability attributes:
1. The primary mapping, indicated by a field in the PRRR as shown in the Memory region column of
Table B3-12, takes precedence.
2. For any region that the PRRR maps as Normal memory, the NMRR determines the Inner cacheability and
Outer cacheability attributes.
3. If it is supported, the Outer Shareable mapping identifies Shareable memory as either Inner Shareable or
Outer Shareable, see Interpretation of the NOSn fields in the PRRR, with TEX remap on page B3-1367.
The TEX remap registers must be static during normal operation. In particular, when the remap registers are
changed:
I
• t is IMPLEMENTATION DEFINED when the changes take effect.
• It is UNPREDICTABLE whether the TLB caches the effect of the TEX remap on translation tables.
The software sequence to ensure the synchronization of changes to the TEX remap registers is:
1. Perform a DSB. This ensures any memory accesses using the old mapping have completed.
2. Write the TEX remap registers or SCTLR.TRE bit.
3. Perform an ISB. This ensures synchronization of the register updates.
4. Invalidate the entire TLB.
5. Perform a DSB. This ensures completion of the entire TLB operation.
6. Clean and invalidate all caches. This removes any cached information associated with the old mapping.
7. Perform a DSB. This ensures completion of the cache maintenance.
8. Perform an ISB. This ensures instruction synchronization.
This extends the standard rules for the synchronization of changes to CP15 registers described in Synchronization
of changes to system control registers on page B3-1457, and provides implementation freedom as to whether or not
the effect of the TEX remap is cached.
Shareability and the S bit, with TEX remap

The memory type of a region, as indicated in the Memory type column of Table B3-12 on page B3-1365, provides
the first level of control of whether the region is shareable:
• If the memory type is Strongly-ordered then the region is Shareable.
• If the memory type is Device then:

— If the implementation includes the Large Physical Address Extension, then no distinction is made
between Shareable and Non-shareable Device memory, and effectively the region is Shareable.
— Otherwise, the shareability is determined by using the value of the S bit in the translation table
descriptor to index bits in the PRRR.
Some implementations make no distinction between Shareable Device memory and Non-shareable Device
memory, and refer to both memory types as Shareable Device memory.
• If the memory type is Normal then the shareability is determined by using the value of the S bit in the
translation table descriptor to index bits in the PRRR.
Table B3-13 shows this determination:
Table B3-13 Determining shareability, with TEX remap
Memory type LPAE a implemented Remapping when S == 0 Remapping when S == 1
Strongly-ordered - Shareable Shareable
Device No PRRR[16] PRRR[17]
Yes Shareable Shareable
Normal - PRRR[18] PRRR[19]
a. LPAE is an abbreviation for the Large Physical Address Extension.
In the cases where the shareability is remapped, the appropriate bit of the PRRR indicates whether the region is
Shareable or Non-shareable, as follows:
PRRR[n] == 0 Not shareable.
PRRR[n] == 1 Shareable.
Note
When TEX remap is enabled, a translation table entry with S == 0 can be mapped as Shareable memory.
Interpretation of the NOSn fields in the PRRR, with TEX remap

When all of the following apply, the NOSn fields in the PRRR distinguish between Inner Shareable and Outer
Shareable memory regions:
• The SCTLR.TRE bit is set to 1.
• The region is mapped as Normal memory, or the implementation does not include the Large Physical Address
Extension and the region is mapped as Device memory.
• The Normal memory remapping or Device memory remapping of the S bit value for the entry makes the
region Shareable.
• The implementation supports the distinction between Inner Shareable and Outer Shareable.
If the SCTLR.TRE bit is set to 0, an implementation can provide an IMPLEMENTATION DEFINED mechanism to
interpret the NOSn fields in the PRRR, see SCTLR.TRE, SCTLR.M, and the effect of the TEX remap registers.
The values of the NOSn fields in the PRRR have no effect if any of the following apply:
• The SCTLR.TRE bit is set to 0 and the IMPLEMENTATION DEFINED mechanism has not been invoked.
• The region is mapped as Strongly-ordered memory.
• The implementation includes the Large Physical Address Extension, and the region is mapped as Device
memory.
• The Normal memory remapping or Device memory remapping of the S bit value for the entry makes the
region Non-shareable.
The NOSn fields in the PRRR are RAZ/WI if the implementation does not support the distinction between Inner
Shareable and Outer Shareable memory regions.
Note
The meaning of shareability attributes for Device memory is IMPLEMENTATION DEFINED for an implementation that
does not include the Large Physical Address Extension, and otherwise has no meaning. For more information, see
Shareable attribute for Device memory regions on page A3-134.
SCTLR.TRE, SCTLR.M, and the effect of the TEX remap registers

When TEX remap is disabled, because the SCTLR.TRE bit is set to 0:
• The effect of the MMU remap registers can be IMPLEMENTATION DEFINED.
• The interpretation of the fields of the PRRR and NMRR registers can differ from the description given earlier
in this section.
VMSAv7 requires that the effect of these registers is limited to remapping the attributes of memory locations. These
registers must not change whether any cache hardware or MMUs are enabled. The mechanism by which the TEX
remap registers have an effect when the SCTLR.TRE bit is set to 0 is IMPLEMENTATION DEFINED. The ARMv7
architecture requires that from reset, if the IMPLEMENTATION DEFINED mechanism has not been invoked:
• If the PL1&0 stage 1 MMU is enabled and is using the Short-descriptor format translation tables, the
architecturally-defined behavior of the TEX[2:0], C, and B bits must apply, without reference to the TEX
remap functionality. In other words, memory attribute assignment must comply with the scheme described
in Short-descriptor format memory region attributes, without TEX remap on page B3-1363.
• If the PL1&0 stage 1 MMU is disabled, then the architecturally-defined behavior of the VMSA with MMUs
disabled must apply, without reference to the TEX remap functionality. See The effects of disabling MMUs
on VMSA behavior on page B3-1312.
Possible mechanisms for enabling the IMPLEMENTATION DEFINED effect of the TEX remap registers when
SCTLR.TRE is set to 0 include:
• A control bit in the ACTLR, or in a CP15 c15 register.
• Changing the behavior when the PRRR and NMRR registers are changed from their IMPLEMENTATION
DEFINED reset values.
In addition, if the MMU is disabled and the SCTLR.TRE bit is set to 1, the architecturally-defined behavior of the
VMSA with the MMU disabled must apply without reference to the TEX remap functionality.
In an implementation that includes the Security Extensions, the IMPLEMENTATION DEFINED effect of these registers
must only take effect in the security state of the registers. See also The effect of the Security Extensions on TEX
remap.
The OS managed translation table bits

When TEX remap is enabled, the TEX[2:1] bits in the translation table descriptors are available as two bits that can
be managed by the operating system. In VMSAv7, as long as the SCTLR.TRE bit is set to 1, the values of the
TEX[2:1] bits are ignored by the memory management hardware. Software can write any value to these bits in the
translation tables.
Note
In a system that implements hardware management of the Access flag, a hardware Access flag update never changes
these bits.
The effect of the Security Extensions on TEX remap

In an implementation that includes the Security Extensions, the TEX remap registers are Banked in the Secure and
Non-secure security states. The register versions for the current security state apply to all PL1&0 stage 1 translation
table lookups in that state. The SCTLR.TRE bit is Banked in the Secure and Non-secure copies of the register, and
the appropriate version of this bit determines whether TEX remap is applied to translation table lookups in the
current security state.
Write accesses to the Secure copies of the TEX remap registers are disabled when the CP15SDISABLE input is
asserted HIGH, meaning the MCR operations to access these registers are UNDEFINED. For more information, see The
CP15SDISABLE input on page B3-1454.
B3.8.4 Long-descriptor format memory region attributes

When a processor is using the Long-descriptor translation table format, the AttrIndx[2:0] field in a block or page
translation table descriptor for a stage 1 translation indicates the 8-bit field in the appropriate MAIR, that specifies
the attributes for the corresponding memory region:
• AttrIndx[2] indicates the value of n in MAIRn:

AttrIndx[2] == 0 Use MAIR0.
AttrIndx[2] == 1 Use MAIR1.
• AttrIndx[2:0] indicates the required Attr field, Attrn, where n = AttrIndx[2:0].
Each AttrIndx field defines, for the corresponding memory region:
• The memory type, Strongly-ordered, Device, or Normal.
• For Normal memory:

— The inner and outer cacheability, Non-cacheable, Write-Through, or Write-Back.
— For Write-Through Cacheable and Write-Back Cacheable regions, the Read-Allocate and
Write-Allocate policy hints, each of which is Allocate or Do not allocate.
For more information about the AttrIndx[2:0] descriptor field, see Attribute fields in stage 1 Long-descriptor Block
and Page descriptors on page B3-1338.
Shareability, Long-descriptor format

When a processor is using the Long-descriptor translation table format, the SH[1:0] field in a block or page
translation table descriptor specifies the Shareability attributes of the corresponding memory region, if the MAIR
entry for that region identifies it as Normal memory. Table B3-14 shows the encoding of this field.
Table B3-14 SH[1:0] field encoding for Normal memory, Long-descriptor format
SH[1:0] Normal memory
00 Non-shareable
01 UNPREDICTABLE
10 Outer Shareable
11 Inner Shareable
See Overlaying the shareability attribute on page B3-1373 for constraints on the Shareability attributes of a Normal
memory region that is Inner Non-cacheable, Outer Non-cacheable.
For a Device or Strongly-ordered memory region, the value of the SH[1:0] field of the translation table descriptor
is ignored.
Other fields in the Long-descriptor translation table format descriptors

The following subsections describe the other fields in the translation table block and page descriptors when a
processor is using the Long-descriptor translation table format:
• Contiguous bit.
• IGNORED fields on page B3-1370.
• Field reserved for software use on page B3-1370.
Contiguous bit
The Long-descriptor translation table format descriptors contain a Contiguous bit. Setting this bit to 1 indicates that
16 adjacent translation table entries point to a contiguous output address range. These 16 entries must be aligned in
the translation table so that the top 5 bits of their input addresses, that index their position in the translation table,
are the same. For example, referring to Figure B3-21 on page B3-1350, to use this hint for a block of 16 entries in
the third-level translation table, bits[20:16] of the input addresses for the 16 entries must be the same.
The contiguous output address range must be aligned to size of 16 translation table entries at the same translation
table level.
Use of this bit means that the TLB can cache a single entry to cover the 16 translation table entries.
The architecture does not require a processor to cache TLB entries in this way. To avoid TLB coherency issues, any
TLB maintenance by address must not assume any optimization of the TLB tables that might result from use of this
bit.
Note
• This capability is similar to the approach used, in the Short-descriptor translation table format, for optimized
caching of Large Pages and Supersections in the TLB. However, an important difference in the Contiguous
bit capability is that TLB maintenance must be performed based on the size of the underlying translation table
entries, to avoid TLB coherency issues
• This bit was previously called the Contiguous bit.
IGNORED fields
For stage 1 and stage 2 Block and Page descriptors, the architecture defines bits[63:59] and bits[58:55] as IGNORED
fields, meaning the architecture guarantees that the processor hardware does not update these fields. In addition:
• Bits[58:55] are reserved for software use, see Field reserved for software use.
• In the stage 2 Block and Page descriptors, bits[63:60] are reserved for use by a System MMU.
Field reserved for software use
The architecture reserves a 4-bit field in the Block and Page table descriptors, bits[58:55], for software use. In
considering migration from using the Short-descriptor format to the Long-descriptor format, this field is an
extension of the Short-descriptor field described in The OS managed translation table bits on page B3-1368.
Note
This means there is no need to invalidate the TLB if these bits are changed.
B3.8.5 PL2 control of Non-secure memory region attributes

Software executing at PL2 controls two sets of translation tables, both of which use the Long-descriptor translation
table format:
• The translation tables that control Non-secure PL2 stage 1 translations. These map VAs to PAs, and are
indicated and controlled by the HTTBR and HTCR.
These translations have exactly the same memory region attribute controls as any other stage 1 translations,
as described in Long-descriptor format memory region attributes on page B3-1368.
• The translation tables that control Non-secure PL1&0 stage 2 translations. These map the IPAs from the stage
1 translation onto PAs, and are indicated and controlled by the VTTBR and VTCR.
The descriptors in the virtualization translation tables define a second level of memory region attributes, that
are overlaid onto the attributes defined in the stage 1 translation. This section describes this overlaying of
attributes.
Long-descriptor translation table format descriptors on page B3-1335 describes the format of the entries in these
tables.
Note
In a virtualization implementation, a hypervisor might usefully:
• Reduce the permitted cacheability of a region.
• Increase the required shareability of a region.
The overlaying of attributes from stage 1 and stage 2 translations supports both of these options.
In the stage 2 translation table descriptors for memory regions and pages, the MemAttr[3:0] and SH[1:0] fields
describe the stage 2 memory region attributes:
• The definition of the stage 2 SH[1:0] field is identical to the same field for a stage 1 translation, see
Shareability, Long-descriptor format on page B3-1369.
• MemAttr[3:2] give a top-level definition of the memory type, and of the cacheability of a Normal memory
region, as Table B3-15 shows:
Table B3-15 Long-descriptor MemAttr[3:2] encoding, stage 2 translation
MemAttr[3:2] Memory type Cacheability
00 Strongly-ordered or Device, determined by MemAttr[1:0] Not applicable
01 Normal Outer Non-cacheable
10 Outer Write-Through Cacheable
11 Outer Write-Back Cacheable
The encoding of MemAttr[1:0] depends on the Memory type indicated by MemAttr[3:2]:

— When MemAttr[3:2]== 0b00, indicating Strongly-ordered or Device memory, Table B3-16 shows the
encoding of MemAttr[1:0]:
Table B3-16 MemAttr[1:0] encoding for Strongly-ordered or Device memory
MemAttr[1:0] Meaning when MemAttr[3:2] == 0b00
00 Region is Strongly-ordered memory
01 Region is Device memory
10 UNPREDICTABLE
11 UNPREDICTABLE
— When MemAttr[3:2]!= 0b00, indicating Normal memory, Table B3-17 shows the encoding of
MemAttr[1:0]:
Table B3-17 MemAttr[1:0] encoding for Normal memory
MemAttr[1:0] Meaning when MemAttr[3:2] != 0b00
00 UNPREDICTABLE
01 Inner Non-cacheable
10 Inner Write-Through Cacheable
11 Inner Write-Back Cacheable
Note
The stage 2 translation does not assign any allocation hints.
The following sections describe how the memory type attributes assigned at stage 2 of the translation are overlaid
onto those assigned at stage 1:
• Overlaying the memory type attribute on page B3-1372.
• Overlaying the cacheability attribute on page B3-1372.
• Overlaying the shareability attribute on page B3-1373.
Note
The following stage 2 translation table attribute settings leave the stage 1 settings unchanged:
• MemAttr[3:2] == 0b11, Normal memory, Outer Write-Back Cacheable.
• MemAttr[1:0] == 0b11, Inner Write-Back Cacheable.
Overlaying the memory type attribute

Table B3-18 shows how the stage 1 and stage 2 memory type assignments are combined:
Table B3-18 Combining the stage 1 and stage 2 memory type assignments
Assignment in stage 1 Assignment in stage 2 Resultant type
Strongly-ordered Any Strongly-ordered
Any Strongly-ordered Strongly-ordered
Device Normal or Device Device
Normal or Device Device Device
Normal Normal Normal
See Overlaying the shareability attribute on page B3-1373 for information about:
• The shareability of a region for which the resultant type is Strongly-ordered or Device.
• The shareability requirements of a region with a resultant type of Normal for which the resultant cacheability,
described in Overlaying the cacheability attribute, is Inner Non-cacheable, Outer Non-cacheable.
The overlaying of the memory type attribute means a translation table walk for a stage 1 translation can be made to
Strongly-ordered or Device memory. This is likely to indicate a Guest OS error, and setting the HCR.PTW bit to 1
causes such an access to generate a Translation fault, see Stage 2 fault on a stage 1 translation table walk,
Overlaying the cacheability attribute

For a Normal memory region, Table B3-19 shows how the stage 1 and stage 2 cacheability assignments are
combined. This combination applies, independently, for the Inner cacheability and Outer cacheability attributes:
Table B3-19 Combining the stage 1 and stage 2 cacheability assignments
Assignment in stage 1 Assignment in stage 2 Resultant cacheability
Non-cacheable Any Non-cacheable
Any Non-cacheable Non-cacheable
Write-Through Cacheable Write-Through or Write-Back Cacheable Write-Through Cacheable
Write-Through or Write-Back Cacheable Write-Through Cacheable Write-Through Cacheable
Write-Back Cacheable Write-Back Cacheable Write-Back Cacheable
Note
Only Normal memory has a cacheability attribute.
Overlaying the shareability attribute

A memory region for which the resultant memory type attribute, described in Overlaying the memory type attribute
on page B3-1372, is Strongly-ordered or Device, is treated as Outer Shareable, regardless of any shareability
assignments at either stage of translation. For more information about the effect of the Large Physical Address
Extension on the shareability of Device and Strongly-ordered memory, see Device and Strongly-ordered memory
shareability, Large Physical Address Extension on page A3-135.
For a memory region with a resultant memory type attribute of Normal, Table B3-20 shows how the stage 1 and
stage 2 shareability assignments are combined:
Table B3-20 Combining the stage 1 and stage 2 shareability assignments
Assignment in stage 1 Assignment in stage 2 Resultant shareability
Outer Shareable Any Outer Shareable
Inner Shareable Outer Shareable Outer Shareable
Inner Shareable Inner Shareable Inner Shareable
Inner Shareable Non-shareable Inner Shareable
Non-shareable Outer Shareable Outer Shareable
Non-shareable Inner Shareable Inner Shareable
Non-shareable Non-shareable Non-shareable
A memory region with a resultant memory type attribute of Normal, and a resultant cacheability attribute of Inner
Non-cacheable, Outer Non-cacheable, must have a resultant shareability attribute of Outer Shareable, otherwise
shareability is UNPREDICTABLE.
B3.9 Translation Lookaside Buffers (TLBs)

Translation Lookaside Buffers (TLBs) are an implementation technique that caches translations or translation table
entries. TLBs avoid the requirement for every memory access to perform a translation table walk in memory. The
ARM architecture does not specify the exact form of the TLB structures for any design. In a similar way to the
requirements for caches, the architecture only defines certain principles for TLBs:
• The architecture has a concept of an entry locked down in the TLB. The method by which lockdown is
achieved is IMPLEMENTATION DEFINED, and an implementation might not support lockdown.
• The architecture does not guarantee that an unlocked TLB entry remains in the TLB.
• The architecture guarantees that a locked TLB entry remains in the TLB. However, a locked TLB entry might
be updated by subsequent updates to the translation tables. Therefore, when a change is made to the
translation tables, the architecture does not guarantee that a locked TLB entry remains incoherent with an
entry in the translation table.
• The architecture guarantees that a translation table entry that generates a Translation fault or an Access flag
fault is not held in the TLB. However a translation table entry that generates a Domain fault or a Permission
fault might be held in the TLB.
• Any translation table entry that does not generate a Translation or Access flag fault and is not out of context
might be allocated to an enabled TLB at any time. The only translation table entries guaranteed not to be held
in the TLB are those that generate a Translation or Access flag fault.
Note
An enabled TLB can hold translation table entries that do not generate a Translation fault but point to
subsequent tables in the translation table walk. This can be referred to as intermediate caching of TLB
entries.
• Software can rely on the fact that between disabling and re-enabling a stage of address translation, entries in
the TLB relating to that stage of translation have not have been corrupted to give incorrect translations.
The following sections give more information about TLB implementation:

• Global and process-specific translation table entries.
• TLB matching on page B3-1375.
• TLB behavior at reset on page B3-1375.
• TLB lockdown on page B3-1375.
• TLB conflict aborts on page B3-1376.
See also TLB maintenance requirements on page B3-1377.
B3.9.1 Global and process-specific translation table entries

In a VMSA implementation, system software can divide a virtual memory map used by memory accesses at PL1
and PL0 into global and non-global regions, indicated by the nG bit in the translation table descriptors:
nG == 0 The translation is global, meaning the region is available for all processes.
nG == 1 The translation is non-global, or process-specific, meaning it relates to the current ASID, as defined
by the CONTEXTIDR.
Each non-global region has an associated Address Space Identifier (ASID). These identifiers mean different
translation table mappings can co-exist in a caching structure such as a TLB. This means that software can create a
new mapping of a non-global memory region without removing previous mappings.
For a symmetric multiprocessor cluster where a single operating system is running on the set of processing elements,
ARMv7 requires all ASID values to be assigned uniquely within any single Inner Shareable domain. In other words,
each ASID value must have the same meaning to all processing elements in the system.
The translation regime used for accesses made at PL2 does not support ASIDs, and all pages are treated as global.
When a processor is using the Long-descriptor translation table format, and is in Secure state, a translation must be
treated as non-global, regardless of the value of the nG bit, if NSTable is set to 1 at any level of the translation table
walk.
For more information see Control of Secure or Non-secure memory access, Long-descriptor format on
page B3-1340.
B3.9.2 TLB matching

A TLB is a hardware caching structure for translation table information. Like other hardware caching structures, it
is mostly invisible to software. However, there are some situations where it can become visible. These are associated
with coherency problems caused by an update to the translation table that has not been reflected in the TLB. Use of
the TLB maintenance operations described in TLB maintenance requirements on page B3-1377 can prevent any
TLB incoherency becoming a problem.
A particular case where the presence of the TLB can become visible is if the translation table entries that are in use
under a particular ASID and VMID are changed without suitable invalidation of the TLB. This is an issue regardless
of whether or not the translation table entries are global. In some cases, the TLB can hold two mappings for the same
address, and this might lead to UNPREDICTABLE behavior
B3.9.3 TLB behavior at reset

The ARMv7 architecture does not require a reset to invalidate the TLBs. ARMv7 recognizes that an implementation
might require caches, including TLBs, to maintain context over a system reset. Possible reasons for doing so include
power management and debug requirements.
For ARMv7:
• All TLBs are disabled from reset. All MMUs are disabled from reset, and the contents of the TLBs have no
effect on address translation. For more information see Enabling MMUs on page B3-1314.
• An implementation can require the use of a specific TLB invalidation routine, to invalidate the TLB arrays
before they are enabled after a reset. The exact form of this routine is IMPLEMENTATION DEFINED, but if an
invalidation routine is required it must be documented clearly as part of the documentation of the device.
ARM recommends that if an invalidation routine is required for this purpose, the routine is based on the
ARMv7 TLB maintenance operations described in TLB maintenance operations, not in Hyp mode on
page B4-1738.
• When TLBs that have not been invalidated by some mechanism since reset are enabled, the state of those
TLBs is UNKNOWN.
• To cache behavior, see Behavior of the caches at reset on page B2-1267.
• To branch predictor behavior, see Behavior of the branch predictors at reset on page B2-1271.
B3.9.4 TLB lockdown

ARMv7 recognizes that any TLB lockdown scheme is heavily dependent on the microarchitecture, making it
inappropriate to define a common mechanism across all implementations. This means that:
• ARMv7 does not require TLB lockdown support.
• If TLB lockdown support is implemented, the lockdown mechanism is IMPLEMENTATION DEFINED. However,
key properties of the interaction of lockdown with the architecture must be documented as part of the
implementation documentation.
This means that:
• In ARMv7, the TLB Type Register, TLBTR, does not define the lockdown scheme in use.
Note
This is a change from previous versions of the architecture, see CP15 c0, TLB Type ID Register, TLBTR,
ARMv6 on page D12-2514.
• A region of the CP15 c10 encodings is reserved for IMPLEMENTATION DEFINED TLB functions, such as TLB
lockdown functions. The reserved encodings are those with:
— <CRm> == {c0, c1, c4, c8}.
— All values of <opc2> and <opc1>.
See also IMPLEMENTATION DEFINED TLB control operations, VMSA on page B4-1745.
An implementation might use some of the CP15 c10 encodings that are reserved for IMPLEMENTATION DEFINED
TLB functions to implement additional TLB control functions. These functions might include:
• Unlock all locked TLB entries.
• Preload into a specific level of TLB. This is beyond the scope of the PLI and PLD hint instructions.
The Virtualization Extensions do not affect the TLB lockdown requirements. However, in a processor that
implements the Virtualization Extensions, exceptions generated by problems related to TLB lockdown, in a
Non-secure PL1 mode, can be routed to either:
• Non-secure Abort mode, using the Non-secure Data Abort exception vector.
• Hyp mode, using the Hyp Trap exception vector.
For more information, see Trapping accesses to lockdown, DMA, and TCM operations on page B1-1251.
B3.9.5 TLB conflict aborts

The Large Physical Address Extension introduces the concept of a TLB conflict abort, and adds fault status
encodings for such an abort, for both the Short-descriptor and Long-descriptor translation table formats, see:
• PL1 fault reporting with the Short-descriptor translation table format on page B3-1411.
• Fault reporting with the Long-descriptor translation table format on page B3-1413.
An implementation can generate a TLB conflict abort if it detects that the address being looked up in the TLB hits
multiple entries. This can happen if the TLB has been invalidated inappropriately, for example if TLB invalidation
required by this manual has not been performed. If it happens, the resulting behavior is UNPREDICTABLE, but must
not permit access to regions of memory with permissions or attributes that mean they cannot be accessed in the
current Security state at the current privilege level.
In some implementations, multiple hits in the TLB can generate a synchronous Data Abort or Prefetch Abort
exception. In any case where this is possible it is IMPLEMENTATION DEFINED whether the abort is a stage 1 abort or
a stage 2 abort.
Note
A stage 2 abort cannot be generated if the Non-secure PL1&0 stage 2 MMU is disabled.
The priority of the TLB conflict abort is IMPLEMENTATION DEFINED, because it depends on the form of any TLB
that can generate the abort.
Note
The TLB conflict abort must have higher priority than any abort that depends on a value held in the TLB.
An implementation can generate TLB conflict aborts on either or both instruction fetches and data accesses.
On a TLB conflict abort, the fault address register returns the address that generated the fault. That is, it returns the
address that was being looked up in the TLB.
B3.10 TLB maintenance requirements

Translation Lookaside Buffers (TLBs) are an implementation mechanism that caches translations or translation
table entries. The ARM architecture does not specify the form of any TLB structures, but defines the mechanisms
by which TLBs can be maintained.The following sections describe the VMSAv7 TLB maintenance operations:
• General TLB maintenance requirements.
• Maintenance requirements on changing system control register values on page B3-1381.
• Atomicity of register changes on changing virtual machine on page B3-1382.
• Synchronization of changes of ASID and TTBR on page B3-1382.
• Multiprocessor effects on TLB maintenance operations on page B3-1385.
• The scope of TLB maintenance operations on page B3-1385.
B3.10.1 General TLB maintenance requirements

TLB maintenance operations provide a mechanism to invalidate entries from a TLB. As stated at the start of
Translation Lookaside Buffers (TLBs) on page B3-1374, any translation table entry that does not generate a
Translation fault or an Access flag fault might be allocated to an enabled TLB at any time. This means that software
must perform TLB maintenance between updating translation table entries that apply in a particular context and
accessing memory locations whose translation is determined by those entries in that context.
Note
This requirement applies to any translation table entry at any level of the translation tables, including an entry that
points to further levels of the tables, provided that the entry in that level of the tables does not cause a Translation
fault or Access flag fault
In addition to any TLB maintenance requirement, when changing the cacheability attributes of an area of memory,
software must ensure that any cached copies of affected locations are removed from the caches. For more
information, see Cache maintenance requirement created by changing translation table attributes on page B3-1391.
Because a TLB never holds any translation table entry that generates a Translation fault or an Access Flag fault, a
change from a translation table entry that causes a Translation or Access flag fault to one that does not fault, does
not require any TLB or branch predictor invalidation.
Special considerations can apply to translation table updates that change the memory type, cacheability, or output
address of an entry, see Using break-before-make when updating translation table entries on page B3-1378.
In addition, software must perform TLB maintenance after updating the system control registers if the updates mean
that the TLB might hold information that applies to a current translation context, but is no longer valid for that
context. Maintenance requirements on changing system control register values on page B3-1381 gives more
information about this maintenance requirement.
Each of the translation regimes defined in Figure B3-1 on page B3-1307 is a different context, and:
• For the Non-secure PL1&0 regime, a change in the VMID or ASID value changes the context.
• For the Secure PL1&0 regime, a change in the ASID value changes the context.
For operation in Non-secure PL1&0 modes, a change of HCR.VM, unless made at the same time as a change of
VMID, requires the invalidation of all TLB entries for the Non-secure PL1&0 translation regime that apply to the
current VMID. Otherwise, there is no guarantee that the effect of the change of HCR.VM is visible to software
executing in the Non-secure PL1&0 modes.
Any TLB operation can affect any other TLB entries that are not locked down.
The architecture defines CP15 c8 functions for TLB maintenance operations, and supports the following operations:
• Invalidate all unlocked entries in the TLB.
• Invalidate a single TLB entry, by MVA, or MVA and ASID for a non-global entry.
• Invalidate all TLB entries that match a specified ASID.
A TLB maintenance operation that specifies a virtual address that would generate any MMU abort, including a
virtual address that is not in the range of virtual addresses that can be translated, does not generate an abort.
The Multiprocessing Extensions add the following operations:
• Invalidate all TLB entries that match a specified MVA, regardless of the ASID.
• Operations that apply across multiprocessors in the same Inner Shareable domain, see Multiprocessor effects
on TLB maintenance operations on page B3-1385.
Note
An address-based TLB maintenance operation that applies to the Inner Shareable domain does so regardless of the
Shareability attributes of the address supplied as an argument to the operation.
The Virtualization Extensions include additional TLB maintenance operations for use at PL2, and have some
implications for the effect of the other TLB maintenance operations, see The scope of TLB maintenance operations
on page B3-1385.
In an implementation that includes the Security Extensions, the TLB operations take account of the current security
state, as part of the address translation required for the TLB operation.
Some TLB operations are defined as operating only on instruction TLBs, or only on data TLBs. ARMv7 includes
these operations for backwards compatibility, and more recent TLB operations do not support this distinction. From
the introduction of ARMv7, ARM deprecates any use of Instruction TLB operations, or of Data TLB operations,
and developers must not rely on this distinction being maintained in future versions of the ARM architecture.
The ARM architecture does not dictate the form in which the TLB stores translation table entries. However, for TLB
invalidate operations, the minimum size of the table entry that is invalidated from the TLB must be at least the size
that appears in the translation table entry.
Note
In an implementation that includes the Large Physical Address Extension and is using the Long-descriptor
translation table format, the Contiguous bit does not affect the minimum size of entry that must be invalidated from
the TLB
TLB maintenance operations, not in Hyp mode on page B4-1738 describes these operations.
Using break-before-make when updating translation table entries

To avoid the effects of TLB caching possibly breaking coherency, ordering guarantees or uniprocessor semantics,
or possibly failing to clear the exclusive monitors, ARM strongly recommends the use of a break-before-make when
changing translation table entries whenever multiple threads of execution can use the same translation tables and
the change to the translation entries involves any of:
• A change of the memory type.
• A change of the cacheability attributes.
• A change of the output address (OA), if the OA of at least one of the old translation table entry and the new
translation table entry is writable.
A break-before-make approach on changing from an old translation table entry to a new translation table entry
requires the following steps:
1. Replace the old translation table entry with an invalid entry, and execute a DSB instruction.
2. Invalidate the translation table entry with a broadcast TLB invalidation instruction, and execute a DSB
instruction to ensure the completion of that invalidation.
3. Write the new translation table entry, and execute a DSB instruction to ensure that the new entry is visible.
This sequence ensures that at no time are both the old and new entries simultaneously visible to different threads of
execution. This means the problems described at the start of this subsection cannot arise.
The interaction of TLB lockdown with TLB maintenance operations

The precise interaction of TLB lockdown with the TLB maintenance operations is IMPLEMENTATION DEFINED.
However, the architecturally-defined TLB maintenance operations must comply with these rules:
• The effect on locked entries of the TLB invalidate all unlocked entries and TLB invalidate by MVA all ASID
operations is IMPLEMENTATION DEFINED. However, these operations must implement one of the following
options:
— Have no effect on entries that are locked down.
— Generate an IMPLEMENTATION DEFINED Data Abort exception if an entry is locked down, or might be
locked down. The CP15 c5 fault status register definitions include a fault code for cache and TLB
lockdown faults, see Table B3-23 on page B3-1412 for the codes used with the Short-descriptor
translation table formats, or Table B3-24 on page B3-1413 for the codes used with the Long-descriptor
In an implementation that includes the Virtualization Extensions, if HCR.TIDCP is set to 1, any such
exceptions taken from a Non-secure PL1 mode are routed to Hyp mode, see Trapping accesses to
lockdown, DMA, and TCM operations on page B1-1251.
This permits a usage model for TLB invalidate routines, where the routine invalidates a large range of
addresses, without considering whether any entries are locked in the TLB.
• The effect on locked entries of the TLB invalidate by MVA and invalidate by ASID match operations is
IMPLEMENTATION DEFINED. However, the implementation must be one of the following:
— A locked entry is invalidated in the TLB.

— The operation has no effect on a locked entry in the TLB. In the case of the Invalidate single entry by
MVA, this means the processor treats the operation as a NOP.
— The operation generates an IMPLEMENTATION DEFINED Data Abort exception if it operates on an entry
that is locked down, or might be locked down. The CP15 c5 fault status register definitions include a
fault code for cache and TLB lockdown faults, see Table B3-23 on page B3-1412 and Table B3-24 on
page B3-1413.
Note
Any implementation that uses an abort mechanism for entries that can be locked down but are not actually locked
down must:
• Document the IMPLEMENTATION DEFINED instruction sequences that perform the required operations on
entries that are not locked down.
• Implement one of the other specified alternatives for the locked entries.
ARM recommends that, when possible, such IMPLEMENTATION DEFINED instruction sequences use the
architecturally-defined operations. This minimizes the number of customized operations required.
In addition, an implementation that uses an abort mechanism for handling TLB maintenance operations on entries
that can be locked down but are not actually locked down must also must provide a mechanism that ensures that no
TLB entries are locked.
Similar rules apply to cache lockdown, see The interaction of cache lockdown with cache maintenance operations
on page B2-1286.
The architecture does not guarantee that any unlocked entry in the TLB remains in the TLB. This means that, as a
side-effect of a TLB maintenance operation, any unlocked entry in the TLB might be invalidated.
TLB maintenance operations and the memory order model

The following rules describe the relations between the memory order model and the TLB maintenance operations:
• A TLB invalidate operation is complete when all memory accesses using the invalidated TLB entries have
been observed by all observers, to the extent that those accesses must be observed. The shareability and
cacheability of the accessed memory locations determine the extent to which the accesses must be observed.
In addition, once the TLB invalidate operation is complete, no new memory accesses that can be observed
by those observers will be performed using the invalidated TLB entries.
For a TLB invalidate operation that affects other processors, the set of memory accesses that have been
observed when the TLB maintenance operation is complete.must include the memory accesses from those
processes that used the invalidated TLB entries.
• A TLB maintenance operation is only guaranteed to be complete after the execution of a DSB instruction.
• An ISB instruction, or a return from an exception, causes the effect of all completed TLB maintenance
operations that appear in program order before the ISB or return from exception to be visible to all subsequent
instructions, including the instruction fetches for those instructions.
• An exception causes all completed TLB maintenance operations, that appear in the instruction stream before
the point where the exception was taken, to be visible to all subsequent instructions, including the instruction
fetches for those instructions.
• All TLB Maintenance operations are executed in program order relative to each other.
• The execution of a Data or Unified TLB maintenance operation is only guaranteed to be visible to a
subsequent explicit load or store operation after both:
— The execution of a DSB instruction to ensure the completion of the TLB operation.
— Execution of a subsequent context synchronization operation.
• The execution of an Instruction or Unified TLB maintenance operation is only guaranteed to be visible to a
subsequent instruction fetch after both:
— The execution of a DSB instruction to ensure the completion of the TLB operation.
— Execution of a subsequent context synchronization operation.
The following rules apply when writing translation table entries. They ensure that the updated entries are visible to
subsequent accesses and cache maintenance operations.
For TLB maintenance, the translation table walk is treated as a separate observer. This means:
• A write to the translation tables, after it has been cleaned from the cache if appropriate, is only guaranteed to
be seen by a translation table walk caused by an explicit load or store after the execution of both a DSB and an
ISB.
However, the architecture guarantees that any writes to the translation tables are not seen by any explicit
memory access that occurs in program order before the write to the translation tables.
• For an ARMv7 implementation that does not include the Multiprocessing Extension, and in implementations
of architecture versions before ARMv7, if the translation tables are held in Write-Back Cacheable memory,
the caches must be cleaned to the point of unification after writing to the translation tables and before the DSB
instruction. This ensures that the updated translation tables are visible to a hardware translation table walk.
• A write to the translation tables, after it has been cleaned from the cache if appropriate, is only guaranteed to
be seen by a translation table walk caused by the instruction fetch of an instruction that follows the write to
the translation tables after both a DSB and an ISB.
Therefore, an example instruction sequence for writing a translation table entry, covering changes to the instruction
or data mappings in a uniprocessor system is:
STR rx, [Translation table entry] ; write new entry to the translation table
Clean cache line [Translation table entry] : This operation is not required with the
; Multiprocessing Extensions.
DSB ; ensures visibility of the data cleaned from the D Cache
Invalidate TLB entry by MVA (and ASID if non-global) [page address]
Invalidate BTC
DSB ; ensure completion of the Invalidate TLB operation
ISB ; ensure table changes visible to instruction fetch
B3.10.2 Maintenance requirements on changing system control register values

The TLB contents can be influenced by control bits in a number of system control registers. This means the TLB
must be invalidated after any changes to these bits, unless the changes are accompanied by a change to the VMID
or ASID that defines the context to which the bits apply. The general form of the required invalidation sequence is
as follows:
; Change control bits in system control registers

ISB ; Synchronize changes to the control bits
; Perform TLB invalidation of all entries that might be affected by the changed control bits
The system control register changes that this applies to are:
• Any change to the NMRR, PRRR, MAIRn, or HMAIRn registers.
• Any change to the SCTLR.AFE bit, see Changing the Access flag enable.
• Any change to the SCTLR.TRE bit.
• Any change to the translation table base address in TTBR0.
• Any change to the translation table base address in TTBR1.

— Any change to the SCTLR.{WXN, UWXN} bits.
— Any change to the SCR.SIF bit.
— Any change to the HCR.VM bit.
— Any change to HCR.PTW bit, see Changing HCR.PTW.
— Any change to the HTTBR.BADDR field.
— Any change to the VTTBR.BADDR field.
• In an implementation that includes the Large Physical Address Extension, changing TTBCR.EAE, see
Changing the current Translation table format on page B3-1382.
• When using the Short-descriptor translation table format:

— Any change to the RGN, IRGN, S, or NOS fields in TTBR0 or TTBR1.
— Any change to the PD0 or PD1 fields in TTBCR.
• When using the Long-descriptor translation table format:

— Any change to the TnSZ, ORGNn, IRGNn, SHn, or EPDn fields in the TTBCR, where n is 0 or 1.
— Any change to the T0SZ, ORGN0, IRGN0, or SH0 fields in the HTCR.
— Any change to the T0SZ, ORGN0, IRGN0, or SH0 fields in the VTCR.
Changing the Access flag enable

In a processor that is using the Short-descriptor translation table format, it is UNPREDICTABLE whether the TLB
caches the effect of the SCTLR.AFE bit on translation tables. This means that, after changing the SCTLR.AFE bit
software must invalidate the TLB before it relies on the effect of the new value of the SCTLR.AFE bit.
Note
There is no enable bit for use of the Access flag when using the Long-descriptor translation table format.
Changing HCR.PTW
When the Protected table walk bit, HCR.PTW, is set to 1, a stage 1 translation table access in the Non-secure PL1&0
translation regime, to an address that is mapped to Device or Strongly-ordered memory by its stage 2 translation,
generates a stage 2 Permission fault. A TLB associated with a particular VMID might hold entries that depend on
the effect of HCR.PTW. Therefore, if the value of HCR.PTW is changed without a change to the VMID value, all
TLB entries associated with the current VMID must be invalidated before executing software in a Non-secure PL1
or PL0 mode. If this is not done, behavior is UNPREDICTABLE.
Changing the current Translation table format

In an implementation that includes the Large Physical Address Extension, the effect of changing TTBCR.EAE when
executing in the translation regime affected by TTBCR.EAE with any MMU for that translation regime enabled is
UNPREDICTABLE. When TTBCR.EAE is changed for a given context, the TLB must be invalidated before resuming
execution in that context, otherwise the effect is UNPREDICTABLE.
B3.10.3 Atomicity of register changes on changing virtual machine

From the viewpoint of software executing in a Non-secure PL1 or PL0 mode, when there is a switch from one virtual
machine to another, the registers that control or affect address translation must be changed atomically. This applies
to the registers for:
• Non-secure PL1&0 stage 1 address translations. This means that all of the following registers must change
atomically:
— PRRR and NMRR, if using the Short-descriptor translation table format.
— MAIR0 and MAIR1, if using the Long-descriptor translation table format.
— TTBR0, TTBR1, TTBCR, DACR, and CONTEXTIDR.
— The SCTLR.
• Non-secure PL1&0 stage 2 address translations. This means that all of the following registers and register
fields must change atomically:
— VTTBR and VTCR.
— HMAIR0 and HMAIR1.
— The HSCTLR.
Note
Only some bits of SCTLR affect the stage 1 translation, and only some bits of HSCTLR affect the stage 2 translation.
However, in each case, changing these bits requires a write to the register, and that write must be atomic with the
other register updates.
These registers apply to execution in Non-secure PL1&0 modes. However, when updated as part of a switch of
virtual machines they are updated by software executing in Hyp mode. This means the registers are out of context
when they are updated, and no synchronization precautions are required.
Note
By contrast, a translation table change associated with a change of ASID, made by software executing at PL1, can
require changes to registers that are in context. Synchronization of changes of ASID and TTBR describes appropriate
precautions for such a change.
The Virtualization Extensions require that when an implementation is in Hyp mode, or in Secure state, the registers
associated with the Non-secure PL1&0 translation regime must not be used for speculative memory accesses.
Note
This does not imply that on taking an exception to Hyp or Monitor mode that translation table walks before the
exception will be completed by the time the entry into Hyp or Monitor mode, and this might include the translation
table walks for those accesses being performed in effect speculatively. A DSB will ensure that these memory accesses
are complete.
B3.10.4 Synchronization of changes of ASID and TTBR

A common virtual memory management requirement is to change the ASID and Translation table base registers
together to associate the new ASID with different translation tables, without any change to the current translation
regime. When using the Short-descriptor translation table format, different registers hold the ASID and the
translation table base address, meaning these two values cannot be updated atomically. Since a processor can
perform a speculative memory access at any time, this lack of atomicity is a problem that software must address.
Such a change is complicated by:
• The depth of speculative fetch being IMPLEMENTATION DEFINED.
• The use of branch prediction.
When using the Short-descriptor translation table format, the virtual memory management operations must ensure
the synchronization of changes of the ContextID and the translation table registers. For example, some or all of the
TLBs, branch predictors, and other caching of ASID and translation information might become corrupt with invalid
translations. Synchronization is necessary to avoid either:
• The old ASID being associated with translation table walks from the new translation tables.
• The new ASID being associated with translation table walks from the old translation tables.
There are a number of possible solutions to this problem, and the most appropriate approach depends on the system.
Example B3-3, Example B3-4, and Example B3-5 on page B3-1384 describe three possible approaches.
Note
Another instance of the synchronization problem occurs if a branch is encountered between changing the ASID and
performing the synchronization. In this case the value in the branch predictor might be associated with the incorrect
ASID. Software can address this possibility using any of these approaches, but might, instead, be written to avoid
such branches.
Example B3-3 Using a reserved ASID to synchronize ASID and TTBR changes
In this approach, a particular ASID value is reserved for use by the operating system, and is used only for the
synchronization of the ASID and Translation table base register. This example uses the value of 0 for this purpose,
but any value could be used.
This approach can be used only when the size of the mapping for any given virtual address is the same in the old
and new translation tables.
The maintenance software uses the following sequence, that must be executed from memory marked as global:
Change ASID to 0
ISB
Change Translation Table Base Register
ISB
Change ASID to new value
This approach ensures that any non-global pages fetched at a time when it is uncertain whether the old or new
translation tables are being accessed are associated with the unused ASID value of 0. Since the ASID value of 0 is
not used for any normal operations these entries cannot cause corruption of execution.
Example B3-4 Using translation tables containing only global mappings when changing the ASID
A second approach involves switching the translation tables to a set of translation tables that only contain global
mappings while switching the ASID.
The maintenance software uses the following sequence, that must be executed from memory marked as global:
Change Translation Table Base Register to the global-only mappings

ISB
ISB
Change Translation Table Base Register to new value
This approach ensures that no non-global pages can be fetched at a time when it is uncertain whether the old or new
ASID value will be used.
This approach works without the need for TLB invalidations in systems that have caching of intermediate levels of
translation tables, as described in General TLB maintenance requirements on page B3-1377, provided that the
translation tables containing only global mappings have only level 1 translation table entries of the following kinds:
• Entries that are global.
• Pointers to level 2 tables that hold only global entries, and that are the same level 2 tables that are used for
accessing global entries by both:
— The set of translation tables that were used under the old ASID value.
— The set of translation tables that will be used with the new ASID value.
• Invalid level 1 entries.
In addition, all sets of translation tables in this example should have the same shareability and cacheability
attributes, as held in the TTBR0.{ORGN, IRGN} or TTBR1.{ORGN, IRGN} fields.
If these rules are not followed, then the implementation might cache level 1 translation table entries that require
explicit invalidation.
Example B3-5 Disabling non-global mappings when changing the ASID
In systems where only the translation tables indexed by TTBR0 hold non-global mappings, maintenance software
can use the TTBCR.PD0 field to disable use of TTBR0 during the change of ASID. This means the system does not
require a set of global-only mappings.
The maintenance software uses the following sequence, that must be executed from a memory region with a
translation that is accessed using the base address in the TTBR1 register, and is marked as global:
Set TTBCR.PD0 = 1
ISB
Change Translation Table Base Register to new value
ISB
Set TTBCR.PD0 = 0
This approach ensures that no non-global pages can be fetched at a time when it is uncertain whether the old or new
ASID value will be used.
When using the Long-descriptor translation table format, TTBCR.A1 holds the number, 0 or 1, of the TTBR that
holds the current ASID. This means the current Translation Table Base Register can also hold the current ASID, and
the current translation table base address and ASID can be updated atomically when:
• TTBR0 is the only Translation Table Base Register being used. TTBCR.A1 must be set to 0.
• TTBR0 points to the only translation tables that hold non-global entries, and TTBCR.A1 is set to 0.
• TTBR1 points to the only translation tables that hold non-global entries, and TTBCR.A1 is set to 1.
In these cases, software can update the current translation table base address and ASID atomically, by updating the
appropriate TTBR, and does not require a specific routine to ensure synchronization of the change of ASID and base
address.
However, in all other cases using the Long-descriptor format, the synchronization requirements are identical to
those when using the Short-descriptor formats, and the examples in this section indicate how synchronization might
be achieved.
Note
When using the Long-descriptor translation table format, CONTEXTIDR.ASID has no significance for address
translation, and is only an extension of CONTEXTIDR.
B3.10.5 Multiprocessor effects on TLB maintenance operations

For an ARMv7 implementation that does not include the Multiprocessing Extensions, the architecture defines that
a TLB maintenance operation applies only to any TLBs that are used in translating memory accesses made by the
processor performing the maintenance operation.
The ARMv7 Multiprocessing Extensions are an OPTIONAL set of extensions that improve the implementation of a
multiprocessor system. These extensions provide additional TLB maintenance operations that apply to the TLBs of
processors in the same Inner Shareable domain.
Note
The Multiprocessing Extensions can be implemented in a uniprocessor system with no hardware support for cache
coherency. In such a system, the Inner Shareable domain applies only to the single processor, and all instructions
defined to apply to the Inner Shareable domain behave as aliases of the local operations.
B3.10.6 The scope of TLB maintenance operations

TLB maintenance operations provide a mechanism for invalidating entries from TLB caching structures, to ensure
that changes to the translation tables are reflected correctly in the TLB caching structures.
The architecture permits the caching of any translation table entry that has been returned from memory without a
fault and that does not, itself, cause a Translation Fault or an Access Flag fault. This means the TLB:
• Cannot hold an entry that, when used for a translation table lookup, causes a Translation Fault or an Access
Flag fault.
• Can hold an entry for a translation table lookup for a translation that causes a Translation Fault or an Access
Flag fault at a subsequent level of translation table lookup. For example, it can hold an entry for the first level
lookup of a translation that causes a a Translation Fault or an Access Flag fault at the second or third level of
lookup.
This means that entries cached in the TLB can include:

• Translation table entries that point to a subsequent table to be used in the current stage of translation.
— Stage 2 translation table entries that are used as part of a stage 1 translation table walk.
— Stage 2 translation table entries for translating the output address of a stage 1 translation.
Such entries might be held in intermediate TLB caching structures that are distinct from the data caches, in that they
are not required to be invalidated as the result of writes of the data. The architecture makes no restriction on the form
of these intermediate TLB caching structures.
The architecture does not intend to restrict the form of TLB caching structures used for holding translation table
entries, and in particular for translation regimes that involve two stages of translation, it recognizes that such
caching structures might contain:
• At any level of the translation table walk, entries containing information from stage 1 translation table entries.

— At any level of the translation table walk, entries containing information from stage 2 translation table
entries.
— At any level of the translation table walk, entries combining information from both stage 1 and stage
2 translation table entries.
Where a TLB maintenance operation is required to apply to stage 1 entries, then it must apply to any cached entry
in the caching structures that includes any stage 1 information that would be used to translate the address being
invalidated, including any entry that combines information from both stage 1 and stage 2 translation table entries.
Where a TLB maintenance operation is required to apply to stage 2 entries it must apply to any cached entry in the
caching structures that includes any information from stage 2 translation table entries, including any entry that
combines information from both stage 1 and stage 2 translation table entries.
Table B3-21 on page B3-1387 summarizes the required effect of the preferred TLB operations that operate only on
TLBs on the processor that executes the instruction. Additional TLB operations:
• In an implementation that includes the Multiprocessing Extensions, apply across all processors in the same
Inner Shareable domain. In such an implementation, each operation shown in the table has an Inner Shareable
equivalent, identified by an IS suffix. For example, the Inner Shareable equivalent of TLBIALL is
TLBIALLIS. See also Virtualization Extensions upgrading of TLB maintenance operations on
page B3-1388.
• Can apply to separate Instruction or Data TLBs, as indicated by a footnote to the table. ARM deprecates any
use of these operations.
Note
• The architecture permits a TLB invalidation operation to affect any unlocked entry in the TLB. Table B3-21
on page B3-1387 defines only the entries that each operation must invalidate.
• All TLB operations, including those that operate on an MVA match, operate regardless of the value of
SCTLR.M.
When interpreting the table:
Related operations Each operation description applies also to any equivalent operation that either:
• Applies to all processors in the same Inner Shareable domain.
• Applies only to a data TLB, or only to an instruction TLB.
So, for example, the TLBIALL description applies also to TLBIALLIS, ITLBIALL, and
DTLBIALL.
Matches the MVA Means the MVA argument for the operation must match the MVA value in the TLB entry.
Matches the ASID Means the ASID argument for the operation must match the ASID in use when the TLB
entry was assigned.
Matches the current VMID

Means the current VMID must match the VMID in use when the TLB entry was assigned.
This condition applies only on implementations that include the Virtualization Extensions.
The dependency on the VMID applies even when HCR.VM is set to 0, including situations
where there is no use of virtualization. However, VTTBR.VMID resets to zero, meaning
there is a valid VMID from reset.
Execution at PL2 Descriptions of operations at PL2 apply only to an implementation that includes the
For the definitions of the translation regimes referred to in the table, see About the VMSA on page B3-1306.
Table B3-21 Effect of the TLB maintenance operations
Executed from
Operation Effect, must invalidate any entry that matches all stated conditions
State Mode
TLBIALL a, b Secure PL1 All entries for the Secure PL1&0 translation regime. That is, any entry that was
allocated in Secure state.
Non-secure PL1 All entries for stage 1 of the Non-secure PL1&0 translation regime that match the
current VMID.
PL2 All entries for stage 1 or stage 2 of the Non-secure PL1&0 translation regime that
match the current VMID.
TLBIMVA a, b Secure PL1 Any entry for the Secure PL1&0 translation regime that both:
• Matches the MVA argument.
• Matches the ASID argument, or is global.
Non-secure PL1 or Any entry for stage 1 of the Non-secure PL1&0 translation regime for which all of
PL2 the following apply. The entry:
• Matches the MVA argument.
• Matches the ASID argument, or is global.
• Matches the current VMID.
TLBIASID a, b Secure PL1 Any entry for the Secure PL1&0 translation regime that is non-global and matches
the ASID argument.
Non-secure PL1 or Any entry for stage 1 of the Non-secure PL1&0 translation regime that both:
PL2 • Is not global and matches the ASID argument.
TLBIMVAA a Secure PL1 Any entry for the Secure PL1&0 translation regime that matches the MVA argument.
Non-secure PL1 or Any entry for stage 1 of the Non-secure PL1&0 translation regime that both:
PL2 • Matches the MVA argument.
TLBIALLNSNH c Secure Monitor All entries for stage 1 or stage 2 of the Non-secure PL1&0 translation regime,
regardless of the associated VMID.
Non-secure PL2
TLBIALLH c Secure Monitor All entries for the Non-secure PL2 translation regime. That is, any entry that was
allocated in Non-secure state at PL2.
Non-secure PL2
TLBIMVAH c Secure Monitor Any entry for the Non-secure PL2 translation regime that matches the MVA
argument.
Non-secure PL2
a. See TLB maintenance operations, not in Hyp mode on page B4-1738.

b. The architecture defines variants of these operations that apply only to instruction TLBs, and only to data TLBs. ARM deprecates any use
of these variants. For more information, see the referenced description of the operation.
c. Available only in an implementation that includes the Virtualization Extensions, see Hyp mode TLB maintenance operations, Virtualization
Extensions on page B4-1741.
Virtualization Extensions upgrading of TLB maintenance operations

In an implementation that includes the Virtualization Extensions, when HCR.FB is set to 1, the TLB maintenance
operations that are not broadcast across the Inner Shareable domain are upgraded to operate across the Inner
Shareable domain when performed in a Non-secure PL1 mode. For example, when HCR.FB is set to 1, a TLBIMVA
operation performed in a Non-secure PL1 mode operates as a TLBIMVAIS operation,
B3.11 Caches in a VMSA implementation

The ARM architecture describes the required behavior of an implementation of the architecture. As far as possible
it does not restrict the implemented microarchitecture, or the implementation techniques that might achieve the
required behavior.
Maintaining this level of abstraction is difficult when describing the relationship between memory address
translation and caches, especially regarding the indexing and tagging policy of caches. This section:
• Summarizes the architectural requirements for the interaction between caches and memory translation.
• Gives some information about the likely implementation impact of the required behavior.
The following sections give this information:

• Data and unified caches
• Instruction caches
In addition, Cache maintenance requirement created by changing translation table attributes on page B3-1391
describes the cache maintenance required after updating the translation tables to change the attributes of an area of
memory.
For more information about cache maintenance, see:
• About ARMv7 cache and branch predictor maintenance functionality on page B2-1272. This section
describes the ARMv7 cache maintenance operations, that apply to both PMSA and VMSA implementations.
• Cache maintenance operations, functional group, VMSA on page B3-1491. This section summarizes the
CP15 encodings used for these operations.
B3.11.1 Data and unified caches

For data and unified caches, the use of memory address translation is entirely transparent to any data access that is
not UNPREDICTABLE.
This means that the behavior of accesses from the same observer to different VAs, that are translated to the same PA
with the same memory attributes, is fully coherent. This means these accesses behave as follows, regardless of
which VA is accessed:
• Two writes to the same PA occur in program order.
• A read of a PA returns the value of the last successful write to that PA.
• A write to a PA that occurs, in program order, after a read of that PA, has no effect on the value returned by
that read.
The memory system behaves in this way without any requirement to use barrier or cache maintenance operations.
In addition, if cache maintenance is performed on a memory location, the effect of that cache maintenance is visible
to all aliases of that physical memory location.
These properties are consistent with implementing all caches that can handle data accesses as Physically-indexed,
physically-tagged (PIPT) caches.
B3.11.2 Instruction caches

In the ARM architecture, an instruction cache is a cache that is accessed only as a result of an instruction fetch.
Therefore, an instruction cache is never written to by any load or store instruction executed by the processor.
The ARMv7 architecture supports three different behaviors for instruction caches. For ease of reference and
description these are identified by descriptions of the associated expected implementation, as follows:
• PIPT instruction caches.
• Virtually-indexed, physically-tagged (VIPT) instruction caches.
• ASID and VMID tagged Virtually-indexed, virtually-tagged (VIVT) instruction caches.
The CTR identifies the form of the instruction caches, see CTR, Cache Type Register, VMSA on page B4-1552.
The following subsections describe the behavior associated with these cache types, including any occasions where
explicit cache maintenance is required to make the use of memory address translation transparent to the instruction
cache:
• PIPT instruction caches.
• VIPT instruction caches.
• ASID and VMID tagged VIVT instruction caches.
Note
For software to be portable between implementations that might use any of PIPT instruction caches, VIPT
instruction caches, or ASID and VMID tagged VIVT instruction caches, the software must invalidate the instruction
cache whenever any condition occurs that would require instruction cache maintenance for at least one of the
instruction cache types.
PIPT instruction caches

For PIPT instruction caches, the use of memory address translation is entirely transparent to all instruction fetches
that are not UNPREDICTABLE.
If cache maintenance is performed on a memory location, the effect of that cache maintenance is visible to all aliases
of that physical memory location.
An implementation that provides PIPT instruction caches implements the IVIPT extension, see IVIPT architecture
extension on page B3-1391.
VIPT instruction caches

For VIPT instruction caches, the use of memory address translation is transparent to all instruction fetches that are
not UNPREDICTABLE, except for the effect of memory address translation on instruction cache invalidate by address
operations.
Note
Cache invalidation is the only cache maintenance operation that can be performed on an instruction cache.
If instruction cache invalidation by address is performed on a memory location, the effect of that invalidation is
visible only to the virtual address supplied with the operation. The effect of the invalidation might not be visible to
any other aliases of that physical memory location.
The only architecturally-guaranteed way to invalidate all aliases of a physical address from a VIPT instruction cache
is to invalidate the entire instruction cache.
An implementation that provides VIPT instruction caches implements the IVIPT extension, see IVIPT architecture
extension on page B3-1391.
ASID and VMID tagged VIVT instruction caches

For ASID and VMID tagged VIVT instruction caches, if the instructions at any virtual address change, for a given
translation regime and a given ASID and VMID, as appropriate, then instruction cache maintenance is required to
ensure that the change is visible to subsequent execution. This maintenance is required when writing new values to
instruction locations. It can also be required as a result of any of the following situations that change the translation
of a virtual address to a physical address, if, as a result of the change to the translation, the instructions at the virtual
addresses change:
• Any change to the TTBR0, TTBR1, or TTBCR registers, unless accompanied by a change to the ASID, or a
change to the VMID.
• Changes to the VTTBR or VTCR registers, unless accompanied by a change to the VMID.
Note
For ASID and VMID tagged VIVT instruction caches only, invalidation is not required if a change to the translations
is such that the instructions associated with the non-faulting translations of a virtual address, for a given translation
regime and a given ASID and VMID, as appropriate, remain unchanged through the change of translation even if
the physical locations being mapped to by the change of translation have been written as part of changing the
translation.
Examples of situations where this might occur include:

• Copy-on-Write.
• Demand Paging of memory locations to/from disk.
This does not apply for VIPT or PIPT instruction caches as those hold copies of physical addresses, and so must be
invalidated when the contents are written to, to avoid using stale entries.
If instruction cache invalidation by address is performed on a memory location, the effect of that invalidation is
visible only to the virtual address supplied with the operation. The effect of the invalidation might not be visible to
any other aliases of that physical memory location.
The only architecturally-guaranteed way to invalidate all aliases of a physical address from an ASID and VMID
tagged VIVT instruction cache is to invalidate the entire instruction cache.
IVIPT architecture extension

An implementation in which the instruction cache exhibits the behaviors described in PIPT instruction caches on
page B3-1390, or those described in VIPT instruction caches on page B3-1390, is said to implement the IVIPT
Extension to the ARMv7 architecture.
The formal definition of the IVIPT extension to the ARMv7 architecture is that it reduces the instruction cache
maintenance requirement to the following condition:
• Instruction cache maintenance is required only after writing new data to a physical address that holds an
instruction.
B3.11.3 Cache maintenance requirement created by changing translation table attributes

Any change to the translation tables to change the attributes of an area of memory can require maintenance of the
translation tables, as described in General TLB maintenance requirements on page B3-1377. If the change affects
the cacheability attributes of the area of memory, including any change between Write-Through and Write-Back
attributes, software must ensure that any cached copies of affected locations are removed from the caches, typically
by cleaning and invalidating the locations from the levels of cache that might hold copies of the locations affected
by the attribute change. Any of the following changes to the inner cacheability or outer cacheability attribute creates
this maintenance requirement:
• Write-Back to Write-Through.
• Write-Back to Non-cacheable.
• Write-Through to Non-cacheable.
• Write-Through to Write-Back.
The cache clean and invalidate avoids any possible coherency errors caused by mismatched memory attributes.
Similarly, to avoid possible coherency errors caused by mismatched memory attributes, the following sequence
must be followed when changing the shareability attributes of a cacheable memory location:
1. Make the memory location Non-cacheable, Outer Shareable.
2. Clean and invalidate the location from them cache.
3. Change the shareability attributes to the required new values.
B3.12 VMSA memory aborts

In a VMSAv7 implementation, the following mechanisms cause a processor to take an exception on a failed memory
access:
Debug exception An exception caused by the debug configuration, see About debug exceptions on
page C4-2076.
Alignment fault An Alignment fault is generated if the address used for a memory access does not have the
required alignment for the operation. For more information, see Unaligned data access on
page A3-106 and Alignment faults on page B3-1399.
MMU fault An MMU fault is a fault generated by the fault checking sequence for the current translation
regime.
External abort Any memory system fault other than a Debug exception, an Alignment fault, or an MMU
fault.
Collectively, these mechanisms are called aborts. Chapter C4 Debug Exceptions describes Debug exceptions, and
the remainder of this section describes Alignment faults, MMU faults, and External aborts.
The exception generated on a synchronous memory abort:

• On an instruction fetch is called the Prefetch Abort exception.
• On a data access is called the Data Abort exception.
Note
The Prefetch Abort exception applies to any synchronous memory abort on an instruction fetch. It is not restricted
to speculative instruction fetches.
In the ARM architecture, asynchronous memory aborts are a type of External abort, and are treated as a special type
of Data Abort exception.
The following sections describe the abort mechanisms:

• Routing of aborts on page B3-1393.
• VMSAv7 MMU fault terminology on page B3-1395.
• The MMU fault-checking sequence on page B3-1395.
• Alignment faults on page B3-1399.
• MMU faults on page B3-1400.
• External aborts on page B3-1402.
• Prioritization of aborts on page B3-1404.
Note
The introduction of the Large Physical Address Extension changes some aspects of the terminology used for
describing MMU faults, and this section uses the new terminology throughout. For more information, see VMSAv7
MMU fault terminology on page B3-1395.
An access that causes an abort is said to be aborted, and uses the Fault Address Registers (FARs) and Fault Status
Registers (FSRs) to record context information. For more information about the FARs and FSRs, see Exception
reporting in a VMSA implementation on page B3-1406.
B3.12.1 Routing of aborts

A memory abort is either a Data Abort exception or a Prefetch Abort exception. The mode to which a memory abort
is taken depends on the reason for the exception, the mode the processor is in when it takes the exception, and
configuration settings, as follows:
Memory aborts taken to Monitor mode

If an implementation includes the Security Extensions, when SCR.EA is set to 1, all External aborts
are taken to Monitor mode. This applies to aborts taken from Secure modes and from Non-secure
modes. For more information, see Asynchronous exception routing controls on page B1-1174.
Note
• Although the referenced section mostly describes the routing of asynchronous exceptions, it
includes the SCR.EA control that applies to both synchronous and asynchronous external
aborts.
• The SCR is implemented only as part of the Security Extensions.
Memory aborts taken to Secure Abort mode

If an implementation includes the Security Extensions, when the processor is executing in Secure
state, all memory aborts that are not routed to Monitor mode are taken to Secure Abort mode.
Note
The only memory aborts that can be routed to Monitor mode are External aborts.
Memory aborts taken to Hyp mode

If an implementation includes the Virtualization Extensions, when the processor is executing in
Non-secure state, the following aborts are taken to Hyp mode:
• Alignment faults taken:
— When the processor is in Hyp mode.
— When the processor is in a PL1 or PL0 mode and the exception is generated because
the Non-secure PL1&0 stage 2 translation identifies the target of an unaligned access
as Device or Strongly-ordered memory.
— When the processor is in the PL0 mode and HCR.TGE is set to 1. For more
information see Synchronous external abort, when HCR.TGE is set to 1 on
page B1-1192.
• When the processor is using the Non-secure PL1&0 translation regime:
— MMU faults from stage 2 translations, for which the stage 1 translation did not cause
an MMU fault.
— Any abort taken during the stage 2 translation of an address accessed in a stage 1
translation table walk that is not routed to Secure Monitor mode, see Stage 2 fault on
a stage 1 translation table walk, Virtualization Extensions on page B3-1399.
• When the processor is using the Non-secure PL2 translation regime, MMU faults from
stage 1 translations.
Note
The Non-secure PL2 translation regime has only one stage of translation.
• External aborts, if SCR.EA is set to 0 and any of the following applies:

— The processor was executing in Hyp mode when it took the exception.
— The processor was executing in a Non-secure PL0 or PL1 mode when it took the
exception, the abort is asynchronous, and HCR.AMO is set to 1. For more information,
see Asynchronous exception routing controls on page B1-1174.
— The processor was executing in the Non-secure PL0 mode when it took the exception,
the abort is synchronous, and HCR.TGE is set to 1. For more information see
Synchronous external abort, when HCR.TGE is set to 1 on page B1-1192.
— The abort occurred on a stage 2 translation table walk.
• Debug exceptions, if HDCR.TDE is set to 1. For more information, see Routing Debug
exceptions to Hyp mode on page B1-1193.
Memory aborts taken to Non-secure Abort mode

In an implementation that does not include the Security Extensions, all memory aborts are taken to
Abort mode.
Otherwise, when the processor is executing in Non-secure state, the following aborts are taken to
Non-secure Abort mode:
• When the processor is in a Non-secure PL1 or PL0 mode, Alignment faults taken for any of
the following reasons:
— SCTLR.A is set to 1.
— An instruction that does not support unaligned accesses is committed for execution,
and the instruction accesses an unaligned address.
— The implementation includes the Virtualization Extensions, and the PL1&0 stage 1
translation identifies the target of an unaligned access as Device or Strongly-ordered
memory.
Note
In an implementation that does not include the Virtualization Extensions, this case
results in an UNPREDICTABLE memory access, see Cases where unaligned accesses are
UNPREDICTABLE on page A3-107.
In an implementation includes the Virtualization Extensions and is in the Non-secure PL0

mode, these exceptions are taken to Abort mode only if HCR.TGE is set to 0.
• When the processor is using the Non-secure PL1&0 translation regime, MMU faults from
stage 1 translations.
• External aborts, if all of the following apply:
— The abort is not on a stage 2 translation table walk.
— The processor is not in Hyp mode.
— SCR.EA is set to 0.
— The abort is asynchronous, and HCR.AMO is set to 0.
— The abort is synchronous, and HCR.TGE is set to 0.
• Virtual Aborts, see Virtual exceptions in the Virtualization Extensions on page B1-1196.
• When HDCR.TDE is set to 0, Debug exceptions. For more information, see Routing Debug
exceptions to Hyp mode on page B1-1193.
Memory aborts with IMPLEMENTATION DEFINED behavior

In addition, a processor can generate an abort for an IMPLEMENTATION DEFINED reason associated
with lockdown, or with a coprocessor. In an implementation that includes the Virtualization
Extensions, whether such an abort is taken to Non-secure Abort mode or taken to Hyp mode is
IMPLEMENTATION DEFINED, and an implementation might include a mechanism to select whether
the abort is routed to Non-secure Abort mode or to Hyp mode.
When the processor is in a Non-secure mode other than Hyp mode, if multiple factors cause an Alignment fault, the
abort is taken to Non-secure Abort mode if any of the factors require the abort to be taken to Abort mode. For
example, if the SCTLR.A bit is set to 1, and the access is an unaligned access to an address that the stage 2
translation tables mark as Strongly-ordered, then the abort is taken to Non-secure Abort mode.
For more information, see Exception handling on page B1-1164.
B3.12.2 VMSAv7 MMU fault terminology

The Large Physical Address Extension introduce new terminology for MMU faults, to provide consistent
terminology across all VMSAv7 implementations. Table B3-22 shows the terminology used in this manual for
MMU faults, compared with older ARM documentation. The current terms are the same for faults that occur with
the Short-descriptor translation table format and with the Long-descriptor format, and also applies to faults in a
third-level lookup when using the Long-descriptor translation table format.
Table B3-22 Changes in MMU fault terminology
Current term Old term Note
First level Translation fault Section Translation fault -
Second level Translation fault Page Translation fault -
Third level Translation fault - Long-descriptor translation table format only.
First level Access flag fault Section Access flag fault -
Second level Access flag fault Page Access flag fault -
Third level Access flag fault - Long-descriptor translation table format only.
First level Domain fault Section Domain fault Short-descriptor translation table format only, except for reporting faults
on address translation operations in the 64-bit PAR, see Determining the
Second level Domain fault Page Domain fault PAR format, Large Physical Address Extension on page B3-1437.
Cannot occur at third level.
First level Permission fault Section Permission fault -
Second level Permission fault Page Permission fault -
Third level Permission fault - Long-descriptor translation table format only.
In an implementation that includes the Virtualization Extensions, MMU faults are also classified by the translation
stage at which the fault is generated. This means that a memory access from a Non-secure PL1 or PL0 mode can
generate:
• A stage 1 MMU fault, for example, a stage 1 Translation fault.
• A stage 2 MMU fault, for example, a stage 2 Translation fault.
B3.12.3 The MMU fault-checking sequence

This section describes the MMU checks made for the memory accesses required for instruction fetches and for
explicit memory accesses:
• If an instruction fetch faults it generates a Prefetch Abort exception.
• If an data memory access faults it generates a Data Abort exception.
For more information about Prefetch Abort exceptions and Data Abort exceptions, see Exception handling on
page B1-1164.
In a VMSA implementation, all memory accesses require VA to PA translation. Therefore, when a corresponding
MMU is enabled, each access requires a lookup of the translation table descriptor for the accessed VA. For more
information, see Translation tables on page B3-1316 and subsequent sections of this chapter. MMU fault checking
is performed for each level of translation table lookup. If an implementation includes the Virtualization Extensions
and is operating in Non-secure state, MMU fault checking is performed for each stage of address translation.
Note
For a processor that includes the Virtualization Extensions, operating in Non-secure state, the operating system or
similar Non-secure system software defines the stage 1 translation tables in the IPA address space, and typically is
unaware of the stage 2 translation, from IPA to PA. However, each Non-secure translation table access is subject to
stage 2 address translation, and might be faulted at that stage.
The MMU fault checking sequence is largely independent of the translation table format, as the figures in this
section show. The differences are:
When using the Short-descriptor format

• There are one or two levels of lookup.
• Lookup always starts at the first level.
• The final level of lookup checks the Domain field of the descriptor and:
— Faults if there is no access to the Domain.
— Checks the access permissions only for Client domains.
When using the Long-descriptor format

• There are one, two, or three levels of lookup.
• Lookup starts at either the first level or the second level.
• Domains are not supported. All accesses are treated as Client domain accesses.
The fault-checking sequence shows a translation from an Input address to an Output address. For more information
about this terminology, see About address translation on page B3-1309.
Note
The descriptions in this section do not include the possibility that the attempted address translation generates a TLB
conflict abort, as described in TLB conflict aborts on page B3-1376.
MMU faults on page B3-1400 describes the faults that an MMU fault-checking sequence can report.
Figure B3-23 on page B3-1397 shows the process of fetching a descriptor from the translation table. For the
top-level fetch for any translation, the descriptor is fetched only if the input address passes any required alignment
check. As the figure shows, in an implementation that includes the Virtualization Extensions, if the translation is
stage 1 of the Non-secure PL1&0 translation regime, then the descriptor address is in the IPA address space, and is
subject to a stage 2 translation to obtain the required PA. This stage 2 translation requires a recursive entry to the
fault checking sequence.
Descriptor address
Is this address an IPA for a
Non-secure PL0 or PL1 access?
Translate address.
Translation Descriptor address is input
Yes
required address for stage 2
? translation
A1
No
Fault checking sequence,

for stage 2 translation
A2
Returns descriptor PA
Fetch descriptor
External abort
External Yes on translation
abort? table walk
No
Return descriptor
Figure B3-23 Fetching the descriptor in a translation table walk
Figure B3-24 on page B3-1398 shows the full VMSA fault checking sequence, including the alignment check on
the initial access.
A1† Input address

Is the access subject to an alignment check?
Alignment Yes Check address alignment

check?
No Alignment
No Misaligned Yes
? fault
Fetch descriptor ‡
Descriptor Translation
No
valid? fault
Yes Table not possible at lowest level
Table Access Access flag

Yes No Yes
entry flag fault fault
? ?
No Fault unaligned access to Device
or Strongly-Ordered memory
Have Alignment Alignment
Yes No
V.Exts.* valid fault
? ?
No Yes
Short Domain
Yes No access Yes
descriptors fault
domain
?
?
No No
Manager
domain
Client
Yes domain No
Check access permissions ?
* V.Exts. = Virtualization
Extensions
Permission
‡ See Fetching the descriptor Violation Yes
fault
flowchart ?
† Links to and from Fetching the No
descriptor flowchart
Output address A2†
Figure B3-24 VMSA fault checking sequence
Stage 2 fault on a stage 1 translation table walk, Virtualization Extensions

When an implementation that includes the Virtualization Extensions is operating in a Non-secure PL1 or PL0 mode,
any memory access goes through two stages of translation:
• Stage 1, from VA to IPA.
• Stage 2, from IPA to PA.
Note
In a virtualized system, typically, a Guest OS operating in a Non-secure PL1 mode defines the translation tables and
translation table register entries controlling the Non-secure PL1&0 stage 1 translations. A Guest OS has no
awareness of the stage 2 address translation, and therefore believes it is specifying translation table addresses in the
physical address space. However, it actually specifies these addresses in its IPA space. Therefore, to support
virtualization, translation table addresses for the Non-secure PL1&0 stage 1 translations are always defined in the
IPA address space.
On performing a translation table walk for the stage 1 translations, the descriptor addresses must be translated from
IPA to PA, using a stage 2 translation. This means that a memory access made as part of a stage 1 translation table
lookup might generate, on a stage 2 translation:
• A Translation fault, Access flag fault, or Permission fault.
• A synchronous external abort on the memory access.
If SCR.EA is set to 1, a synchronous external abort is taken to Secure Monitor mode. Otherwise, these faults are
reported as stage 2 memory aborts. HSR.ISS[7] is set to 1, to indicate a stage 2 fault during a stage 1 translation
table walk, and the part of the ISS field that might contain details of the instruction is invalid. For more information
see Use of the HSR on page B3-1421.
Alternatively, a memory access made as part of a stage 1 translation table lookup might target an area of memory
with the Device or Strongly-ordered attribute assigned on the stage 2 translation of the address accessed. When the
HCR.PTW bit is set to 1, such an access generates a stage 2 Permission fault.
Note
• On most systems, such a mapping to Strongly-ordered or Device memory on the stage 2 translation is likely
to indicate a Guest OS error, where the stage 1 translation table is corrupted. Therefore, it is appropriate to
trap this access to the hypervisor.
A TLB might hold entries that depend on the effect of HCR.PTW. Therefore, if HCR.PTW is changed without
changing the current VMID, the TLBs must be invalidated before executing in a Non-secure PL1 or PL0 mode. For
more information, see Changing HCR.PTW on page B3-1381.
A cache maintenance operation performed from a Non-secure PL1 mode can cause a stage 1 translation table walk
that might generate a stage 2 Permission fault, as described in this section. This is an exception to the general rule
that a cache maintenance operation cannot generate a Permission fault.
B3.12.4 Alignment faults

The ARMv7 memory architecture requires support for strict alignment checking. This checking is controlled by
SCTLR.A. In addition, some instructions do not support unaligned accesses, regardless of the value of SCTLR.A.
Unaligned data access on page A3-106 defines when Alignment faults are generated, for both values of SCTLR.A.
An Alignment fault can occur on an access for which the MMU is disabled.
In an implementation that includes the Virtualization Extensions, any unaligned access to memory region with the
Device or Strongly-ordered memory type attribute generates an Alignment fault.
Note
• In versions of the ARMv7 architecture before the introduction of the Virtualization Extensions, the behavior
of an unaligned access to Device or Strongly-ordered memory is architecturally UNPREDICTABLE. Most
implementations generate an abort on such an access.
• In some documentation, including issues A and B of this manual, Alignment faults are classified as a type of
MMU fault. However, the behavior of Alignment faults differs, in a number of ways, from the behavior of
MMU faults. This change in the classification of Alignment faults has no effect on their behavior.
Routing of aborts on page B3-1393 defines the mode to which an Alignment fault is taken.
In an implementation that includes the Virtualization Extensions, the prioritization of Alignment faults depends on
whether the fault was generated because of an access to Device or Strongly-ordered memory, or for another reason.
For more information, see Prioritization of aborts on page B3-1404.
B3.12.5 MMU faults

This section describes the faults that might be detected during one of the fault-checking sequences described in The
MMU fault-checking sequence on page B3-1395. Unless indicated otherwise, information in this section applies to
the fault checking sequences for both the Short-descriptor translation table format and the Long-descriptor
MMU faults are always synchronous. For more information, see Terminology for describing exceptions on
page B1-1136.
When an MMU fault generates an abort for a region of memory, no memory access is made if that region is or could
be marked as Strongly-ordered or Device.
The following subsections describe the MMU faults that might be detected during a fault checking sequence:
• External abort on a translation table walk
• Translation fault
• Access flag fault on page B3-1401
• Domain fault, Short-descriptor format translation tables only on page B3-1401
• Permission fault on page B3-1402.
External abort on a translation table walk

The section External aborts on page B3-1402 describes this abort. See, in particular, External abort on a translation
table walk on page B3-1403.
Translation fault
A Translation fault can be generated at any level of lookup, and the reported fault code identifies the lookup level.
A Translation fault is generated if bits[1:0] of a translation table descriptor identify the descriptor as either a Fault
encoding or a reserved encoding. For more information see:
• Short-descriptor translation table format descriptors on page B3-1322
• Long-descriptor translation table format descriptors on page B3-1335.
In addition, if an implementation includes the Virtualization Extensions, then a Translation fault is generated if the
input address for a translation either does not map on to an address range of a Translation Table Base Register, or
the Translation Table Base Register range that it maps on to is disabled. In these cases the fault is reported as a first
level Translation fault on the translation stage at which the mapping to a region described by a Translation Table
Base Register failed.
The architecture guarantees that any translation table entry that causes a Translation fault is not cached, meaning
the TLB never holds such an entry. Therefore, when a Translation fault occurs, the fault handler does not have to
perform any TLB maintenance operations to remove the faulting entry.
A data or unified cache maintenance operation by MVA can generate a Translation fault. Whether an instruction
cache invalidate by MVA operation can generate a Translation fault is IMPLEMENTATION DEFINED, because it is
IMPLEMENTATION DEFINED whether the operation requires an address translation. If the instruction cache invalidate
by MVA operation requires an address translation then the operation can generate a Translation fault, otherwise it
cannot generate a Translation fault.
Whether branch predictor maintenance operations can generate Translation faults is IMPLEMENTATION DEFINED,
because it is IMPLEMENTATION DEFINED whether the operation requires an address translation. If the branch
predictor maintenance operation requires an address translation then the operation can generate a Translation fault,
otherwise it cannot generate a Translation fault.
Access flag fault

An Access flag fault can be generated at any level of lookup, and the reported fault code identifies the lookup level.
An Access flag fault is generated only if all of the following apply:
• The translation tables support an Access flag bit:

— the Short-descriptor format supports an Access flag only when SCTLR.AFE is set to 1
— the Long-descriptor format always supports an Access flag.
• For the relevant stage of address translation, the processor is not performing hardware management of the
Access flag. Support for hardware management of the Access flag is OPTIONAL and deprecated, but
SCTLR.HA is set to 1 when hardware management is supported and enabled.
Note
Hardware management of the Access flag cannot be supported for either:
— Non-secure PL2 stage 1 address translation
— Non-secure PL1&0 stage 2 address translation.
• A translation table descriptor with the Access flag bit set to 0 is loaded.
For more information about the Access flag bit see:

• Short-descriptor translation table format descriptors on page B3-1322
• Long-descriptor translation table format descriptors on page B3-1335.
The architecture guarantees that any translation table entry that causes an Access flag fault is not cached, meaning
the TLB never holds such an entry. Therefore, when an Access flag fault occurs, the fault handler does not have to
perform any TLB maintenance operations to remove the faulting entry.
Whether any cache maintenance operations by MVA can generate Access flag faults is IMPLEMENTATION DEFINED.
Whether branch predictor invalidate by MVA operations can generate Access flag faults is IMPLEMENTATION
DEFINED.
For more information, see The Access flag on page B3-1358.
Domain fault, Short-descriptor format translation tables only

When using the Short-descriptor translation table format, a Domain fault can be generated at the first level or second
level of lookup. The reported fault code identifies the lookup level. The conditions for generating a Domain fault
are:
First level When a first-level descriptor fetch returns a valid Section first-level descriptor, the domain field of
that descriptor is checked against the DACR. A first-level Domain fault is generated if this check
fails.
Second level When a second-level descriptor fetch returns a valid second-level descriptor, the domain field of the
first-level descriptor that required the second-level fetch is checked against the DACR, and a
second-level Domain fault is generated if this check fails.
For more information, see Domains, Short-descriptor format only on page B3-1358.
Domain faults cannot occur on cache or branch predictor maintenance operations.
A TLB might hold a translation table entry that cause a Domain fault. Therefore, if the handling of a Domain fault
results in an update to the associated translation tables, the software that updates the translation tables must
invalidate the appropriate TLB entry, to prevent the stale information in the TLB being used on a subsequent
memory access. For more information, see the translation table entry update examples in TLB maintenance
operations and the memory order model on page B3-1379.
Any change to the DACR must be synchronized by a context synchronization operation. For more information see
Synchronization of changes to system control registers on page B3-1457.
Permission fault
A Permission fault can be generated at any level of lookup, and the reported fault code identifies the lookup level.
See Access permissions on page B3-1352 for information about conditions that cause a Permission fault.
Note
When using the Short-descriptor translation table format, the translation table descriptors are checked for
Permission faults only for accesses to memory regions in Client domains.
A TLB might hold a translation table entry that cause a Permission fault. Therefore, if the handling of a Permission
fault results in an update to the associated translation tables, the software that updates the translation tables must
invalidate the appropriate TLB entry, to prevent the stale information in the TLB being used on a subsequent
memory access. For more information, see the translation table entry update examples in TLB maintenance
operations and the memory order model on page B3-1379.
Note
In an implementation that includes the Virtualization Extensions, this maintenance requirement applies to
Permission faults in both stage 1 and stage 2 translations.
Cache or branch predictor maintenance operations cannot cause a Permission fault, except that:
• a stage 1 translation table walk performed as part of a cache or branch predictor maintenance operation can
generate a stage 2 Permission fault as described in Stage 2 fault on a stage 1 translation table walk,
• a DCIMVAC issued in Non-secure state that attempts to update date in a location for which it does not have
stage 2 write access can generate a stage 2 Permission fault, as described in Virtualization Extensions
upgrading of maintenance operations on page B2-1284.
B3.12.6 External aborts

The ARM architecture defines external aborts as errors that occur in the memory system, other than those that are
detected by the MMU or Debug hardware. External aborts include parity errors detected by the caches or other parts
of the memory system. An external abort is one of:
• synchronous
• precise asynchronous
• imprecise asynchronous.
For more information, see Terminology for describing exceptions on page B1-1136.
The ARM architecture does not provide any method to distinguish between precise asynchronous and imprecise
asynchronous aborts.
The ARM architecture handles asynchronous aborts in a similar way to interrupts, except that they are reported to
the processor using the Data Abort exception. Setting the CPSR.A bit to 1 masks asynchronous aborts, see Program
Status Registers (PSRs) on page B1-1147.
Normally, external aborts are rare. An imprecise asynchronous external abort is likely to be fatal to the process that
is running. An example of an event that might cause an external abort is an uncorrectable parity or ECC failure on
a Level 2 Memory structure.
It is IMPLEMENTATION DEFINED which external aborts, if any, are supported.
VMSAv7 permits external aborts on data accesses, translation table walks, and instruction fetches to be either
synchronous or asynchronous. The reported fault code identifies whether the external abort is synchronous or
asynchronous.
Note
Because imprecise asynchronous external aborts are normally fatal to the process that caused them, ARM
recommends that implementations make external aborts precise wherever possible.
The following subsections give more information about possible external aborts:
• External abort on instruction fetch
• External abort on data read or write
• External abort on a translation table walk
• Behavior of external aborts on a translation table walk caused by address translation
• Provision for classification of external aborts on page B3-1404
• Parity error reporting on page B3-1404.
The section Exception reporting in a VMSA implementation on page B3-1406 describes the reporting of external
aborts.
External abort on instruction fetch

An external abort on an instruction fetch can be either synchronous or asynchronous. A synchronous external abort
on an instruction fetch is taken precisely.
An implementation can report the external abort asynchronously from the instruction that it applies to. In such an
implementation these aborts behave essentially as interrupts. The aborts are masked when CPSR.A is set to 1,
otherwise they are reported using the Data Abort exception.
External abort on data read or write

Externally-generated errors during a data read or write can be either synchronous or asynchronous.
An implementation can report the external abort asynchronously from the instruction that generated the access. In
such an implementation these aborts behave essentially as interrupts. The aborts are masked when CPSR.A is set
to 1, otherwise they are reported using the Data Abort exception.
External abort on a translation table walk

An external abort on a translation table walk can be either synchronous or asynchronous. An external abort on a
translation table walk is reported:
• if the external abort is synchronous, using:
— a synchronous Prefetch Abort exception if the translation table walk is for an instruction fetch
— a synchronous Data Abort exception if the translation table walk is for a data access
• if the external abort is asynchronous, using an asynchronous Data Abort exception.
If an implementation reports the error in the translation table walk asynchronously from executing the instruction
whose instruction fetch or memory access caused the translation table walk, these aborts behave essentially as
interrupts. The aborts are masked when CPSR.A is set to 1, otherwise they are reported using the Data Abort
exception.
Behavior of external aborts on a translation table walk caused by address translation
The address translation operations summarized in Address translation operations, functional group on
page B3-1493 require translation table walks. An external abort can occur in the translation table walk. The abort
generates a Data Abort exception, and can be synchronous or asynchronous. For more information, see Handling of
faults and aborts during an address translation operation on page B3-1437.
Provision for classification of external aborts

An implementation can use the DFSR.ExT and IFSR.ExT bits to provide more information about external aborts:
• DFSR.ExT can provide an IMPLEMENTATION DEFINED classification of external aborts on data accesses.
• IFSR.ExT can provide an IMPLEMENTATION DEFINED classification of external aborts on instruction accesses.
• HSR.ISS[9] can provide an IMPLEMENTATION DEFINED classification of external aborts routed to Hyp mode.
For all aborts other than external aborts these bits return a value of 0.
Parity error reporting

The ARM architecture supports the reporting of both synchronous and asynchronous parity errors from the cache
systems. It is IMPLEMENTATION DEFINED what parity errors in the cache systems, if any, result in synchronous or
asynchronous parity errors.
A fault code is defined for reporting parity errors, see Exception reporting in a VMSA implementation on
page B3-1406. However when parity error reporting is implemented it is IMPLEMENTATION DEFINED whether a
parity error is reported using the assigned fault code, or using another appropriate encoding.
For all purposes other than the fault status encoding, parity errors are treated as external aborts.
B3.12.7 Prioritization of aborts

This section describes the abort prioritization that applies to a single memory access that might generate multiple
aborts:
On a single memory access, the following rules apply:
• If a memory access generates an Alignment fault because SCTLR.A is set to 1, or because it is an unaligned
access by an instruction that does not support unaligned accesses, then that access cannot generate any of:
— an MMU fault, on either the stage 1 translation or the stage 2 translation
— an external abort
— a Watchpoint debug event.
In an implementation that includes the Virtualization Extensions, an Alignment fault generated by an
unaligned access to Device or Strongly-ordered memory is prioritized as an MMU fault. For more
information see Alignment faults caused by accessing Device or Strongly-ordered memory on page B3-1405.
• If a memory access generates an MMU fault on its stage 1 translation, and also generates an abort on its stage
2 translation, the fault from the stage 1 translation has priority:
— if a memory access made as part of a stage 1 translation table walk generates an MMU fault on its stage
2 translation, as described in Stage 2 fault on a stage 1 translation table walk, Virtualization
Extensions on page B3-1399, the stage 1 translation table walk does not generate an MMU fault on the
stage 1 translation
— a fault on a particular stage of translation might be a synchronous external abort on a translation table
walk made at that stage of translation.
• If a memory access generates an MMU fault on either its stage 1 translation or on its stage 2 translation, then
the processor cannot generate a Watchpoint debug event on that access.
• If a memory access generates an MMU fault on either its stage 1 translation or on its stage 2 translation, or
generates a synchronous Watchpoint debug event, then the memory access cannot generate an external abort.
• Except as defined in this list, the architecture does not define any prioritization of asynchronous external
aborts relative to any other asynchronous aborts.
If a single instruction generates aborts on more than one memory access, the architecture does not define any
prioritization between those aborts.
In general, the ARM architecture does not define when asynchronous events are taken, and therefore the
prioritization of asynchronous events is IMPLEMENTATION DEFINED.
Note
Debug event prioritization on page C3-2064 describes:
• the relationship between debug events, MMU faults, and external aborts, for synchronous aborts generated
by the same memory access
• the special requirement that applies to asynchronous watchpoints.
Alignment faults caused by accessing Device or Strongly-ordered memory

In an implementation that includes the Virtualization Extensions, any unaligned access to Device or
Strongly-ordered memory generates an Alignment fault. When applying the prioritization rules, this fault is
prioritized as an MMU fault. The priority of this Alignment fault relative to possible MMU faults is as follows:
• the Alignment fault has lower priority than an Access flag fault
• if the translation stage that generates the Alignment fault:
— can generate Domain faults, the Alignment fault has higher priority than a Domain fault
— cannot generate Domain faults, the Alignment fault has higher priority than a Permission fault.
The MMU fault checking sequence in Figure B3-24 on page B3-1398 shows this prioritization.
B3.13 Exception reporting in a VMSA implementation

This section describes exception reporting in a VMSA implementation. The Virtualization Extensions introduce an
enhanced reporting mechanism for exceptions taken to the Non-secure PL2 mode, Hyp mode. This means that, for
a VMSA implementation, the exception reporting depends on the mode to which the exception is taken.
About exception reporting introduces the general approach to exception reporting, and the following sections then
describe exception reporting at different privilege levels:
• Reporting exceptions taken to PL1 modes on page B3-1407.
• Fault reporting in PL1 modes on page B3-1410
• Summary of register updates on faults taken to PL1 modes on page B3-1414
• Reporting exceptions taken to the Non-secure PL2 mode on page B3-1417
• Use of the HSR on page B3-1421
• Summary of register updates on exceptions taken to the PL2 mode on page B3-1431.
Note
The registers used for exception reporting also report information about debug exceptions. For more information
see:
• Data Abort exceptions, taken to a PL1 mode on page B3-1407
• Prefetch Abort exceptions, taken to a PL1 mode on page B3-1410
• Reporting exceptions taken to the Non-secure PL2 mode on page B3-1417.
B3.13.1 About exception reporting

In an implementation that includes the Virtualization Extensions, exceptions can be taken to:
• a Secure or Non-secure PL1 mode
• the Non-secure PL2 mode, Hyp mode.
Otherwise, they are taken to a PL1 mode. Exception reporting in the PL2 mode differs significantly from that in the
PL1 modes, but in general, exception reporting returns
• information about the exception:

— on taking an exception to the PL2 mode, the Hyp Syndrome Register, HSR, returns syndrome
information
— on taking an exception to a PL1 mode, a Fault Status Register (FSR) returns status information
• for synchronous exceptions, one or more addresses associated with the exceptions, returned in Fault Address
Registers (FARs)
In both PLI modes and the PL2 mode, additional IMPLEMENTATION DEFINED registers can provide additional
information about exceptions.
Note
• Processor mode for taking exceptions on page B1-1172 describes how the mode to which an exception is
taken is determined.
• The Virtualization Extensions introduce:

— new exception types, that can only be taken from Non-secure PL1 and PL0 modes, and are always
taken to Hyp mode
— new routing controls that can route some exceptions from Non-secure PL1 and PL0 modes to Hyp
mode.
These exceptions are reported using the same mechanism as the PL2 reporting of VMSA memory aborts, as
described in this section.
Memory system faults generate either a Data Abort exception or a Prefetch Abort exception, as summarized in:
• Reporting exceptions taken to PL1 modes
• Memory fault reporting at PL2 on page B3-1418.
On an access that might have multiple aborts, the MMU fault checking sequence and the prioritization of aborts
determine which abort occurs. For more information, see The MMU fault-checking sequence on page B3-1395 and
Prioritization of aborts on page B3-1404.
B3.13.2 Reporting exceptions taken to PL1 modes

The following sections give general information about the reporting of exceptions when they are taken to a PL1
mode:
• Registers used for reporting exceptions taken to a PL1 mode
• Data Abort exceptions, taken to a PL1 mode
• Prefetch Abort exceptions, taken to a PL1 mode on page B3-1410.
Fault reporting in PL1 modes on page B3-1410 then describes the fault reporting in these modes, including the
encodings used for reporting the faults.
Registers used for reporting exceptions taken to a PL1 mode

ARMv7 defines the following registers, and register encodings, for exceptions taken to PL1 modes:
• the DFSR holds information about a Data Abort exception
• the DFAR holds the faulting address for some synchronous Data Abort exceptions
• the IFSR holds information about a Prefetch Abort exception
• the IFAR holds the faulting address of a Prefetch Abort exception
• on a Watchpoint debug exception, the DBGWFAR can hold fault information.
Note
Before ARMv7, the Data Fault Address Register (DFAR) was called the Fault Address Register (FAR).
In addition, if implemented, the optional ADFSR and AIFSR can provide additional fault information, see Auxiliary
Fault Status Registers.
Auxiliary Fault Status Registers
The ARMv7 architecture defines the following Auxiliary Fault Status Registers:
• the Auxiliary Data Fault Status Register, ADFSR
• the Auxiliary Instruction Fault Status Register, AIFSR.
The position of these registers is architecturally-defined, but the content and use of the registers is IMPLEMENTATION
DEFINED. An implementation can use these registers to return additional fault status information. An example use
of these registers is to return more information for diagnosing parity errors.
An implementation that does not need to report additional fault information must implement these registers as
UNK/SBZP. This ensures that an attempt to access these registers from software executing at PL1 does not cause
an Undefined Instruction exception.
For more information, see ADFSR and AIFSR, Auxiliary Data and Instruction Fault Status Registers, VMSA on
page B4-1519
Data Abort exceptions, taken to a PL1 mode

On taking a Data Abort exception to a PL1 mode:
• If the exception is on an instruction cache or branch predictor maintenance operation by MVA, its reporting
depends on the current translation table format. For more information about the registers used when reporting
the exception, see Data Abort on an instruction cache maintenance operation by MVA on page B3-1408.
• If the exception is generated by a Watchpoint debug event, then its reporting depends on whether the
Watchpoint debug event is synchronous or asynchronous, and on the Debug architecture version. For more
information, see Data Abort on a Watchpoint debug event.
Otherwise:
• The DFSR is updated with details of the fault, including the appropriate fault status code.
If the Data Abort exception is synchronous, DFSR.WnR is updated to indicate whether the faulted access was
caused by a read instruction or a write instruction. However, if the fault is:
— On a cache maintenance operation, or on a CP15 address translation operation, WnR is set to 1, to
indicate a write access fault, and if the implementation includes the Large Physical Address Extension,
the CM bit is set to 1
— Generated by an SWP or SWPB instruction, WnR is set to 0 if a read of the location would have generated
a fault, otherwise it is set to 1.
DFSR.WnR is UNKNOWN on an asynchronous Data Abort exception.
See the register description for more information about the returned fault information.
• If the Data Abort exception is

— synchronous, the DFAR is updated with the VA that caused the exception
— asynchronous, the DFAR becomes UNKNOWN.
For all Data Abort exceptions, if the implementation includes the Security Extensions, the security state of the
processor in the mode to which the Data Abort exception is taken determines whether the Secure or Non-secure
DFSR and DFAR are updated.
Data Abort on an instruction cache maintenance operation by MVA
If an instruction cache or branch predictor invalidation by MVA operation generates a Data Abort exception that is
taken to a PL1 mode, the DFAR is updated to hold the faulting VA. However, the reporting of the fault depends on
the current translation table format:
Short-descriptor format
It is IMPLEMENTATION DEFINED which of the following is used when reporting the fault:
• The DFSR indicates an Instruction cache maintenance operation fault, and the IFSR is valid
and indicates the cause of the fault, a Translation fault or Access flag fault.
• The DFSR indicates the cause of the fault, a Translation fault or Access flag fault. The IFSR
is UNKNOWN.
In either case:
• DFSR.WnR is set to 1
• if the implementation includes the Large Physical Address Extension, DFSR.CM is set to 1,
to indicate a fault on a cache maintenance operation.
Long-descriptor format
• DFSR.CM is set to 1, to indicates a fault on a cache maintenance operation
• DFSR.STATUS indicates the cause of the fault, a Translation or Access flag fault
• DFSR.WnR is set to 1
• the IFSR is UNKNOWN.
Data Abort on a Watchpoint debug event
On taking a Data Abort exception caused by a Watchpoint debug event, DFSR is updated with the details of the
fault:
• if using the Short-descriptor format, DFSR.FS is updated to indicate a debug event and DFSR.Domain is
UNKNOWN.
• if using the Long-descriptor format, DFSR.STATUS is updated to indicate a debug event.
• if the implementation includes the Large Physical Address Extension, DFSR.CM is updated to indicate
whether the Watchpoint was caused by a cache maintenance operation.
• DFSR.WnR is UNKNOWN.
The remaining register updates depend on the Debug architecture version, and in v7.1 debug, on whether the
Watchpoint debug event is synchronous or asynchronous:
v7 Debug, and for an asynchronous Watchpoint debug event in v7.1 Debug

• DFAR is UNKNOWN
• DBGWFAR is set to the VA of the instruction that caused the watchpointed access, plus an
offset that depends on the instruction set state of the processor for that instruction, as follows:
— 8 for ARM state
— 4 for Thumb or ThumbEE state
— IMPLEMENTATION DEFINED for Jazelle state.
v7.1 Debug, for a synchronous Watchpoint debug event

• DFAR is set to the address that generated the watchpoint
• DBGWFAR is UNKNOWN.
A watchpointed address can be any byte-aligned address. The address reported in DFAR might not
be the watchpointed address, and can be any address between and including:
• the lowest address accessed by the instruction that triggered the watchpoint
• the highest watchpointed address accessed by that instruction.
If multiple watchpoints are set in this range, there is no guarantee of which watchpoint is generated.
Note
In particular, there is no guarantee of generating the watchpoint with the lowest address in the range.
In addition, it is IMPLEMENTATION DEFINED whether there is an additional restriction on the lowest

value that might be reported in the DFAR, see Synchronous Watchpoint debug event additional
restriction on DFAR or HDFAR reporting, v7.1 Debug.
Note
For a synchronous Watchpoint debug event:
• in v7 Debug, both LR_abt and DBGWFAR indicate the address of the instruction that triggered the
watchpoint, and ARM deprecates using DBGWFAR to determine the address of this instruction.
• in v7.1 Debug, only LR_abt indicates the address of the instruction that triggered the watchpoint
Synchronous Watchpoint debug event additional restriction on DFAR or HDFAR reporting, v7.1
Debug
In v7.1 Debug, when reporting a synchronous Watchpoint debug event triggered by a Load or Store instruction, it
is IMPLEMENTATION DEFINED whether there is an additional restriction on the lower value of the permitted range of
values that might be reported in the DFAR or HDFAR. ARM recommends that implementations define such a
restriction, and that the restriction requires that:
• For a Watchpoint debug event triggered by a Load or Store instruction, the lowest address that is reported in
the DFAR or HDFAR is both:
— no lower than the address of the watchpointed location rounded down to a multiple of an
IMPLEMENTATION DEFINED number of bytes
— no lower than the lowest address accessed by the instruction that triggered the watchpoint.
• The IMPLEMENTATION DEFINED number of bytes that defines this lowest address is a power of two, and less
than or equal to the cache line size specified in CCSIDR.LineSize.
This additional restriction does not apply to any watchpoint generated by a cache maintenance instruction. For these
instructions, the lowest address accessed by the instruction can be less than the address passed to the operation,
because the operation acts on a whole cache line.
Note
A debugger can choose to ignore this restriction. However, a debugger can use this restriction to refine its
interpretation of the value returned in the DFAR or HDFAR.
There is no mechanism by which software can discover whether this restriction is implementation. The
documentation of any implementation that includes this restriction must include a full description of its
implementation of the restriction.
Prefetch Abort exceptions, taken to a PL1 mode

For a Prefetch Abort exception generated by an instruction fetch, the Prefetch Abort exception is taken
synchronously with the instruction that the abort is reported on. This means:
• If the processor attempts to execute the instruction a Prefetch Abort exception is generated.
• If an instruction fetch is issued but the processor does not attempt to execute the prefetched instruction, no
Prefetch Abort exception is generated for that instruction. For example, if the execution flow branches round
a prefetched instruction, no Prefetch Abort exception is generated.
In addition, debug exceptions caused by a BKPT instruction, Breakpoint, or a Vector catch debug event, generate a
Prefetch Abort exception, see Debug exception on BKPT instruction, Breakpoint, or Vector catch debug events on
page C4-2076.
On taking a Prefetch Abort exception to PL1:
• The IFSR is updated with details of the fault, including the appropriate fault code. If appropriate, the fault
code indicates that the exception was generated by a debug exception.
See the register description for more information about the returned fault information.
• For a Prefetch Abort exception generated by an instruction fetch, the IFAR is updated with the VA that caused
the exception.
• For a Prefetch Abort exception generated by a debug exception, the IFAR is UNKNOWN.
If the implementation includes the Security Extensions, the security state of the processor in the mode to which it
takes the Prefetch Abort exception determines whether the exception updates the Secure or Non-secure IFSR and
IFAR.
B3.13.3 Fault reporting in PL1 modes

The FSRs provide fault information, including an indication of the fault that occurred. The Large Physical Address
Extension introduces:
• an alternative translation table format, the Long-descriptor format
• an alternative FSR format, used with the Long-descriptor translation tables
• an additional bit in the FSR format used with the Short-descriptor translation tables, FSR.CM.
Therefore, the following subsections describe fault reporting in PL1 modes for each of the translation table formats:
• PL1 fault reporting with the Short-descriptor translation table format on page B3-1411
• Fault reporting with the Long-descriptor translation table format on page B3-1413.
Reserved encodings in the IFSR and DFSR encodings tables on page B3-1414 gives some additional information
about the encodings for both formats.
Summary of register updates on faults taken to PL1 modes on page B3-1414 shows which registers are updated on
each of the reported faults.
Reporting of External aborts taken from Non-secure state to Monitor mode describes how the fault status register
format is determined for those aborts. For all other aborts, the current translation table format determines the format
of the fault status registers.
Note
Previous ARM documentation classified faults using the terms precise and imprecise instead of synchronous and
asynchronous. For details of the more exact terminology introduced in this manual see Terminology for describing
Reporting of External aborts taken from Non-secure state to Monitor mode

When an External abort is taken from Non-secure state to Monitor mode:
• for a Data Abort exception, the Secure DFSR and DFAR hold information about the abort
• for a Prefetch Abort exception, the Secure IFSR and IFAR hold information about the abort
• the abort does not affect the contents of the Non-secure copies of the fault reporting registers.
Normally, the current translation table format determines the format of the DFSR and IFSR. However, when
SCR.EA is set to 1, to route external aborts to Monitor mode, and an external abort is taken from Non-secure state,
this section defines the DFSR and IFSR format.
For an External abort taken from Non-secure state to Monitor mode, the DFSR or IFSR uses the format associated
with the Long-descriptor translation table format, as described in Fault reporting with the Long-descriptor
translation table format on page B3-1413, if any of the following applies:
• the Secure TTBCR.EAE bit is set to 1
• the External abort is synchronous and either:

— it is taken from Hyp mode
— it is taken from a Non-secure PL1 or PL0 mode, and the Non-secure TTBCR.EAE bit is set to 1.
Otherwise, the DFSR or IFSR uses the format associated with the Short-descriptor translation table format, as
described in PL1 fault reporting with the Short-descriptor translation table format.
PL1 fault reporting with the Short-descriptor translation table format

This subsection describes the fault reporting for a fault taken to a PL1 mode when either:
• the implementation does not include the Large Physical Address Extension
• the implementation includes the Large Physical Address Extension, and address translation is using the
Short-descriptor translation table format.
On taking an exception, bit[9] of the FSR is RAZ, or set to 0, if the processor is using this FSR format.
An FSR encodes the fault in a 5-bit FS field, that comprises FSR[10, 3:0]. Table B3-23 on page B3-1412 shows the
encoding of that field. Summary of register updates on faults taken to PL1 modes on page B3-1414 shows:
• Whether the corresponding FAR is updated on the fault. That is:
— for a fault reported in the IFSR, whether the IFAR holds a valid address
— for a fault reported in the DFSR, whether the DFAR holds a valid address
• For faults that update DFSR, whether DFSR.Domain is valid
When reading Table B3-23 on page B3-1412:

• FS values not shown in the table are reserved
• FS values shown as DFSR only are reserved for the IFSR
• LPAE is an abbreviation for the Large Physical Address Extension.
Table B3-23 Short-descriptor format FSR encodings
FS Source Notes
00001 Alignment fault DFSR only. Fault on first lookup
00010 Debug event See About debug events on page C3-2024
00011 a Access flag fault First level

MMU fault
00110 Second level
00100 Fault on instruction cache maintenance DFSR only
00101 Translation fault First level

MMU fault
00111 Second level
01000 Synchronous external abort -
01001 Domain fault First level MMU fault

01011 Second level
01100 Synchronous external abort on translation table walk First level

-
01110 Second level
01101 Permission fault First level MMU fault

01111 Second level
10000 TLB conflict abort See TLB conflict aborts on page B3-1376
10100 IMPLEMENTATION DEFINED Lockdown
10110 Asynchronous external abort b DFSR only
11000 Asynchronous parity error on memory access c DFSR only
11001 Synchronous parity error on memory access -
11010 IMPLEMENTATION DEFINED Coprocessor abort
11100 Synchronous parity error on translation table walk First level

-
11110 Second level
a. Previously, this encoding was a deprecated encoding for Alignment fault. The extensive changes in the memory model in VMSAv7
mean there should be no possibility of confusing the new use of this encoding with its previous use
b. Including Virtual Abort and asynchronous data external abort on translation table walk or instruction fetch.
c. Including asynchronous parity error on translation table walk.
The Domain field in the DFSR
The DFSR includes a Domain field. This is inherited from previous versions of the VMSA. The IFSR does not
include a Domain field. Summary of register updates on faults taken to PL1 modes on page B3-1414 describes when
DFSR.Domain is valid.
ARM deprecates any use of the Domain field in the DFSR. The Long-descriptor translation table format does not
support a Domain field, and future versions of the ARM architecture might not support a Domain field in the
Short-descriptor translation table format. ARM strongly recommends that new software does not use this field.
For both Data Abort exceptions and Prefetch Abort exceptions, software can find the domain information by
performing a translation table read for the faulting address and extracting the Domain field from the translation table
entry.
Fault reporting with the Long-descriptor translation table format

This subsection describes the fault reporting for a fault taken to a PL1 mode in an implementation that includes the
Large Physical Address Extension, when address translation is using the Long-descriptor translation table format.
When the processor takes an exception, bit[9] of the FSR is set to 1 if the processor is using this FSR format.
The FSRs encode the fault in a 6-bit STATUS field, that comprises FSR[5:0]. Table B3-24 shows the encoding of
that field. In addition:
• For a fault taken to a PL1 mode, Summary of register updates on faults taken to PL1 modes on page B3-1414
shows whether the corresponding FAR is updated on the fault. That is:
— for a fault reported in the IFSR, whether the IFAR holds a valid address
— for a fault reported in the DFSR, whether the DFAR holds a valid address
• For a fault taken to the PL2 mode, Summary of register updates on exceptions taken to the PL2 mode on
page B3-1431 shows what registers are updated on the fault
Table B3-24 Long-descriptor format FSR encodings
STATUS a Source Notes
0001LL Translation fault. LL bits indicate level b. MMU fault
0010LL Access flag fault. LL bits indicate level b. MMU fault
0011LL Permission fault. LL bits indicate level b. MMU fault
010000 Synchronous external abort. -
010001 Asynchronous external abortc . DFSR only
0101LL Synchronous external abort on translation table walk. -

LL bits indicate level b.
011000 Synchronous parity error on memory access. -
011001 Asynchronous parity error on memory access. DFSR only
0111LL Synchronous parity error on memory access on translation table -

walk.
LL bits indicate level b.
100001 Alignment fault. Fault on first lookup
100010 Debug event. See About debug events on page C3-2024
110000 TLB conflict abort. See TLB conflict aborts on page B3-1376
110100 IMPLEMENTATION DEFINED. Lockdown, DFSR only
111010 IMPLEMENTATION DEFINED. Coprocessor abort, DFSR only
1111LL Domain fault. MMU fault. 64-bit PAR only, First or second
LL bits indicate level b. level only. Never used in DFSR, IFSR, or HSR d
a. STATUS values not shown in this table are reserved. STATUS values not supported in the IFSR or DFSR are reserved for the register or
registers in which they are not supported.
b. See The level associated with MMU faults on page B3-1414.
c. Including Virtual Abort.
d. A Domain fault can be reported using the Long-descriptor STATUS encodings only as a result of a fault on an address translation operation.
For more information see MMU fault on an address translation operation on page B3-1438.
The level associated with MMU faults
For MMU faults, Table B3-25 shows how the LL bits in the xFSR.STATUS field encode the lookup level associated
with the fault.
Table B3-25 Use of LL bits to encode the lookup level at which the fault occurred
LL bits Meaning
00 Reserved.
01 First level.
10 Second level.
11 Third level. When xFSR.STATUS indicates a Domain fault, this value is reserved.
The lookup level associated with a fault is:
• For a fault generated on a translation table walk, the lookup level of the walk being performed.
• For a Translation fault, the lookup level of the translation table that gave the fault. If a fault occurs because
an MMU is disabled, or because the input address is outside the range specified by the appropriate base
address register or registers, the fault is reported as a First level fault.
• For an Access flag fault, the lookup level of the translation table that gave the fault.
• For a Permission fault, including a Permission fault caused by hierarchical permissions, the lookup level of
the final level of translation table accessed for the translation. That is, the lookup level of the translation table
that returned a Block or Page descriptor.
Reserved encodings in the IFSR and DFSR encodings tables

With both the Short-descriptor and the Long-descriptor FSR format, the fault encodings reserve a single encoding
for each of:
• Cache and TLB lockdown faults. The details of these faults and any associated subsidiary registers are
• Aborts associated with coprocessors. The details of these faults are IMPLEMENTATION DEFINED.
B3.13.4 Summary of register updates on faults taken to PL1 modes

For faults that generate exceptions that are taken to a PL1 mode, Table B3-26 on page B3-1415 shows the registers
affected by each fault. In this table:
• Yes indicates that the register is updated
• UNK indicates that the fault makes the register value UNKNOWN
• a null entry, -, indicates that the fault does not affect the register.
For faults that update the DFSR using the Short-descriptor format FSR encodings, Table B3-27 on page B3-1416
shows whether DFSR.Domain is valid.
Table B3-26 Effect of a fault taken to a PL1 mode on the reporting registers
Fault IFSR IFAR DFSR DFAR DBGWFAR
Faults reported as Prefetch Abort exceptions:
MMU fault, always synchronous. Yes Yes - - -
Synchronous external abort on translation table walk. Yes Yes - - -
Synchronous parity error on translation table walk. Yes Yes - - -
Synchronous external abort. Yes Yes - - -
Synchronous parity error on memory access. Yes Yes - - -
TLB conflict abort. Yes Yes - - -
Fault reported as Data Abort exception:
Alignment fault, always synchronous. - - Yes Yes -
MMU fault, always synchronous. - - Yes Yes -
Fault on instruction cache maintenance, when using Long-descriptor UNK - Yes Yes -
translation table format a.
Fault on instruction cache maintenance, when using either Yes - Yes Yes -
Short descriptor translation table format b.
or UNK - Yes Yes -
Synchronous external abort on translation table walk. - - Yes Yes -
Synchronous parity error on translation table walk. - - Yes Yes -
Synchronous external abort. - - Yes Yes -
Synchronous parity error on memory access. - - Yes Yes -
Asynchronous external abortc. - - Yes UNK -
Asynchronous parity error on memory access. - - Yes UNK -
TLB conflict abort. - - Yes Yes -
Debug exceptions:
Breakpoint, BKPT instruction, or Vector catch debug event d. Yes UNK - - -
Synchronous Watchpoint debug event e. v7 Debug - - Yes UNK Yes
v7.1 Debug - - Yes Yes UNK
Asynchronous Watchpoint debug event e. - - Yes UNK Yes
a. When using the Long-descriptor translation table format, there is not a specific fault code for a fault on an instruction cache maintenance
operation. For more information see Data Abort on an instruction cache maintenance operation by MVA on page B3-1408.
b. The two lines of this entry show the alternative ways of reporting the fault when using the Short-descriptor translation table format. It is
IMPLEMENTATION DEFINED which methods is used, see Data Abort on an instruction cache maintenance operation by MVA on
page B3-1408.
c. Including Virtual Abort.
d. Generates a Prefetch Abort exception.
e. Generates a Data Abort exception.
For those faults for which Table B3-26 on page B3-1415 shows that the DFSR is updated, if the fault is reported
using the Short-descriptor FSR encodings, Table B3-27 shows whether DFSR.Domain is valid. In this table, UNK
indicates that the fault makes DFSR.Domain UNKNOWN.
Table B3-27 Validity of Domain field on faults that update the DFSR using the Short-descriptor encodings
DFSR.FS Source DFSR.Domain Notes
00001 Alignment fault UNK -
00100 Fault on instruction cache maintenance operation UNK -
01100 First level UNK

Synchronous external abort on translation table walk -
01110 Second level Valid
11100 First level UNK

Synchronous parity error on translation table walk -
00101 Translation fault First level UNK MMU fault

00011 a Access flag fault First level UNK MMU fault

01001 Domain fault First level Valid MMU fault

01101 Permission fault No LPAE First level Valid MMU fault

With LPAE First level UNK
01111 No LPAE Second level Valid

With LPAE Second level UNK
01000 Synchronous external abort UNK -
10000 TLB conflict abort UNK -
11001 Synchronous parity error on memory access UNK -
10110 Asynchronous external abort b UNK -
11000 Asynchronous parity error on memory access c UNK -
00010 Watchpoint debug event, synchronous or asynchronous UNK
a. Previously, this encoding was a deprecated encoding for Alignment fault. The extensive changes in the memory model in
VMSAv7 mean there should be no possibility of confusing the new use of this encoding with its previous use
b. Including asynchronous data external abort on translation table walk or instruction fetch.
c. Including asynchronous parity error on translation table walk.
Note
As Table B3-27 shows, if an implementation includes the Large Physical Address Extension, and address translation
is using the Short-descriptor translation table format, on a Permission fault that causes a Data Abort exception, the
DFSR.Domain field is UNKNOWN. This is a change from the architecturally-required behavior on an implementation
that does not include the Large Physical Address Extension.
B3.13.5 Reporting exceptions taken to the Non-secure PL2 mode

The Virtualization Extensions introduce Hyp mode as the Non-secure PL2 mode. Hyp mode is entered by taking an
exception to Hyp mode.
Note
Software executing in Monitor mode can perform an exception return to Hyp mode. This means Hyp mode is
entered either by taking an exception, or by a permitted exception return.
The following exceptions are taken to Hyp mode:
• Asynchronous external aborts, IRQ exceptions, and FIQ exceptions, from Non-secure PL0 and PL1 modes,
if not routed to Secure Monitor mode, can each be routed to Hyp mode. For more information see
Asynchronous exception routing controls on page B1-1174.
• If HCR.TGE is set to 1, the following exceptions. if taken from the Non-secure PL0 mode, are routed to Hyp
mode:
— Undefined Instruction exceptions
— Supervisor Call exception
— synchronous external aborts
— Alignment faults.
For more information, see Routing general exceptions to Hyp mode on page B1-1190.
• If HCR.TDE is set to 1, any Debug exception take from a Non-secure PL1 or PL0 mode, is routed to Hyp
mode. For more information, see Routing Debug exceptions to Hyp mode on page B1-1193.
• The privilege rules for taking exceptions mean that any exception taken from Hyp mode, if not routed to
Secure Monitor mode, must be taken to Hyp mode. See Exceptions, privilege, and security state on
page B1-1137. This includes a Prefetch Abort exception generated by a Debug exception on a BKPT
instruction.
Note
Debug exceptions other than the exception on a BKPT instruction are not permitted in Hyp mode.
• Hypervisor Call exceptions, and Hyp Trap exceptions, are always taken to Hyp mode. These exceptions are
supported only as part of the Virtualization Extensions.
In an implementation that includes the Virtualization Extensions, various operations from Non-secure PL0
and PL1 modes can be trapped to Hyp mode, using the Hyp Trap exception. For more information, see Traps
to the hypervisor on page B1-1246.
These exceptions include any memory system fault that occurs:

• on a memory access from Hyp mode
• on memory access from a Non-secure PL0 or PL1 mode:
— on a stage 2 translation, from IPA to PA
— on the stage 2 translation of an address accessed in performing a stage 1 translation table walk.
Memory fault reporting at PL2 on page B3-1418 gives more information about these faults.
The following exceptions provide syndrome information syndrome information in the HSR:
• Any synchronous exception taken to Hyp mode.
• Some exceptions taken from Debug state that would be taken to Hyp mode if the processor was not in Debug
state, see Exceptions in Debug state on page C5-2093.
Note
— In Debug state, the processor does not change mode on taking an exception.
— As Exceptions in Debug state on page C5-2093 describes, some other exceptions taken from Debug
state make the HSR UNKNOWN.
The syndrome information in the HSR includes the fault status code otherwise provided by the fault status register,
and greatly extends the fault reporting. For more information, see Use of the HSR on page B3-1421.
In addition, for a Debug exception taken to Hyp mode, DBGDSCR.MOE shows what caused the Debug exception.
This bit is valid regardless of whether the Debug exception was taken from Hyp mode or from another Non-secure
mode.
Registers used for reporting exceptions taken to Hyp mode lists all of the registers used for exception reporting at
PL2.
Registers used for reporting exceptions taken to Hyp mode

The Virtualization Extensions define the following registers for exceptions taken to Hyp mode:
• the HSR holds syndrome information for the exception
• the HDFAR holds the VA associated with a Data Abort exception
• the HIFAR holds the VA associated with a Prefetch Abort exception
• the HPFAR holds bits[39:12] of the IPA associated with some aborts on stage 2 address translations.
In addition, if implemented, the optional HADFSR and HAIFSR can provide additional fault information, see Hyp
Auxiliary Fault Syndrome Registers.
Hyp Auxiliary Fault Syndrome Registers
The Virtualization Extensions define the following Hyp Auxiliary Fault Syndrome Registers:
• the Hyp Auxiliary Data Fault Syndrome Register, HADFSR
• the Hyp Auxiliary Instruction Fault Syndrome Register, HAIFSR.
An implementation can use these registers to return additional fault status information for aborts taken to Hyp mode.
They are the Hyp mode equivalents of the registers described in Auxiliary Fault Status Registers on page B3-1407.
An example use of these registers is to return more information for diagnosing parity errors.
The architectural requirements for the HADFSR and HAIFSR are:
• The position of these registers is architecturally-defined, but the content and use of the registers is
• An implementation with no requirement for additional fault reporting can implement these registers as
UNK/SBZP, but the architecture does not require it to do so.
For more information, see HADFSR and HAIFSR, Hyp Auxiliary Fault Syndrome Registers, Virtualization
Extensions on page B4-1572.
Memory fault reporting at PL2

Prefetch Abort and Data Abort exceptions taken to Hyp mode report memory faults. For these aborts, the HSR
contains the following fault status information:
• The HSR.EC field indicates the type of abort, as Table B3-28 on page B3-1419 shows.
• The HSR.ISS field holds more information about the abort. In particular:
— bits[5:0] of this field hold the STATUS field for the abort, using the encodings defined in Fault
reporting with the Long-descriptor translation table format on page B3-1413
— other subfields of the ISS give more information about the exception, equivalent to the information
returned in the FSR for a memory fault reported at PL1.
See the descriptions of the ISS fields for the memory faults, referenced from the Syndrome description
column of Table B3-28 on page B3-1419, for information about the returned fault information.
Table B3-28 HSR.EC encodings for aborts taken to Hyp mode
HSR.EC Abort Syndrome description
0x20 Prefetch Abort taken from Non-secure PL0 or PL1 mode ISS encoding for Prefetch Abort exceptions taken to Hyp
mode on page B3-1428
0x21 Prefetch Abort taken from Hyp mode
0x24 Data Abort taken from Non-secure PL0 or PL1 mode ISS encoding for Data Abort exceptions taken to Hyp mode
on page B3-1429
0x25 Data Abort taken from Hyp mode
For more information, see Use of the HSR on page B3-1421.
A Prefetch Abort exception is taken synchronously with the instruction that the abort is reported on. This means:
• If the processor attempts to execute the instruction a Prefetch Abort exception is generated.
• If an instruction fetch is issued but the processor does not attempt to execute the prefetched instruction, no
Prefetch Abort exception is generated for that instruction. For example, if the execution flow branches round
a prefetched instruction, no Prefetch Abort exception is generated.
Register updates on exception reporting at PL2
The use of the HSR, and of the other registers listed in Registers used for reporting exceptions taken to Hyp mode
on page B3-1418, depends on the cause of the Abort. In reporting these faults, in general:
• If the fault generates a synchronous Data Abort exception, the HDFAR holds the associated VA.
• If the fault generates a Prefetch Abort exception, the HIFAR holds the associated VA.
• In the following cases, the HPFAR holds the faulting IPA:
— a Translation or Access flag fault on a stage 2 translation
— a fault on the stage 2 translation of an address accessed in a stage 1 translation table walk.
In all other cases, the HPFAR is UNKNOWN.
• On a Data Abort exception that is taken to Hyp mode, the HIFAR is UNKNOWN.
• On a Prefetch Abort exception that is taken to Hyp mode, the HDFAR is UNKNOWN.
In addition, the reporting of particular aborts is as follows:
Abort on the stage 1 translation for a memory access from Hyp mode
The HDFAR or HIFAR holds the VA that caused the fault. The STATUS subfield of HSR.ISS
indicates the type of fault, Translation, Access flag, or Permission. The HPFAR is UNKNOWN.
Abort on the stage 2 translation for a memory access from a Non-secure PL1 or PL0 mode
This includes aborts on the stage 2 translation of a memory access made as part of a translation table
walk for a stage 1 translation. The HDFAR or HIFAR holds the VA that caused the fault. The
STATUS subfield of HSR.ISS indicates the type of fault, Translation, Access flag, or Permission.
For any Access flag fault or Translation fault, and also for any Permission fault on the stage 2
translation of a memory access made as part of a translation table walk for a stage 1 translation, the
HPFAR holds the IPA that caused the fault. Otherwise, the HPFAR is UNKNOWN.
Abort caused by a synchronous external abort, or synchronous parity error, and taken to Hyp mode
The HDFAR or HIFAR holds the VA that caused the fault. The HPFAR is UNKNOWN.
Abort caused by a Watchpoint debug event and routed to Hyp mode because HDCR.TDE is set to 1
When HDCR.TDE is set to 1, a debug exception on a Watchpoint debug event, generated in a
Non-secure PL1 or PL0 mode, that would otherwise generate a Data Abort exception, is routed to
Hyp mode and generates a Hyp Trap exception.
The reporting of the exception depends on whether the Watchpoint debug event is synchronous or
asynchronous:
Synchronous Watchpoint debug event
HDFAR is set to the address that generated the watchpoint, and DBGWFAR is
UNKNOWN.
A watchpointed address can be any byte-aligned address. The address reported in
HDFAR might not be the watchpointed address, and can be any address between and
including:
• the lowest address accessed by the instruction that triggered the watchpoint
• the highest watchpointed address accessed by that instruction.
If multiple watchpoints are set in this range, there is no guarantee of which watchpoint
is generated.
Note
In particular, there is no guarantee of generating the watchpoint with the lowest address
in the range.
In addition, it is IMPLEMENTATION DEFINED whether there is an additional restriction on

the lowest value that might be reported in the HDFAR. It is IMPLEMENTATION DEFINED
whether this restriction, described in Synchronous Watchpoint debug event additional
restriction on DFAR or HDFAR reporting, v7.1 Debug on page B3-1409:
• is implemented
• applies to both DFAR and HDFAR, if it is implemented.
Asynchronous Watchpoint debug event
HDFAR is UNKNOWN, and DBGWFAR is set to the VA of the instruction that caused
the watchpointed access, plus an offset that depends on the instruction set state of the
processor for that instruction, as follows:
• 8 for ARM state
• 4 for Thumb or ThumbEE state
• IMPLEMENTATION DEFINED for Jazelle state.
See also Debug exception on Watchpoint debug event on page C4-2077.

In all cases, HPFAR is UNKNOWN.
Prefetch Abort caused by a Debug exception on a BKPT instruction debug event and taken to Hyp mode
This abort is generated if a BKPT instruction is executed in Hyp mode. The abort leaves the HIFAR
and HPFAR UNKNOWN.
See also Debug exception on BKPT instruction, Breakpoint, or Vector catch debug events on
page C4-2076.
Abort caused by a BKPT instruction, Breakpoint, or Vector catch debug event, and routed to Hyp mode
because HDCR.TDE is set to 1
When HDCR.TDE is set to 1, a debug exception, generated in a Non-secure PL1 or PL0 mode, that
would otherwise generate a Prefetch Abort exception, is routed to Hyp mode and generates a Hyp
Trap exception.
The abort leaves the HIFAR and HPFAR UNKNOWN. This is identical to the reporting of a Prefetch
Abort exception caused by a Debug exception on a BKPT instruction that is executed in Hyp mode.
Note
The difference between these two cases is:
• the Debug exception on a BKPT instruction executed in Hyp mode generates a Prefetch Abort
exception, taken to Hyp mode, and reported in the HSR using EC value 0x21.
• aborts generated because HDCR.TDE is set to 1 generate a Hyp Trap exception, and are
reported in the HSR using EC value 0x20.
B3.13.6 Use of the HSR

The HSR holds syndrome information for any synchronous exception taken to Hyp mode. Compared with the
reporting of exceptions taken to PL1 modes, the HSR:
• Always provides details of the fault. The DFSR and IFSR are not used.
• Provides more extensive information, for a wider range of exceptions.
Note
IRQ and FIQ exceptions taken to Hyp mode do not report any syndrome information in the HSR.
The general format of the HSR is that it comprises:
• A 6-bit exception class field, EC, that indicates the cause of the exception.
• An instruction length bit, IL. When an exception is caused by trapping an instruction to Hyp mode, this bit
indicates the length of the trapped instruction, as follows:
0 16-bit instruction trapped.
1 32-bit instruction trapped.
This field is not valid for the following cases:
— When the EC field is 0x00, indicating an exception with an unknown reason.
— Prefetch Aborts.
— Data Aborts that do not have ISS information, or for which the ISS is not valid.
In these cases, the IL field is UNK/SBZP.
• An instruction specific syndrome field, ISS. Architecturally, this field can be defined independently for each
defined exception class.
This field is not valid, UNK/SBZP, when the EC field is 0x00, indicating an exception with an unknown
reason.
Figure B3-25 shows the format of the HSR, with the subdivision of the ISS field that applies to nonzero EC values
with the two most significant bits 0b00.
31 30 29 26 25 24 23 20 19 0
xx not 00, or EC zero x x
EC nonzero 0 0 COND
CV
EC IL ISS
Figure B3-25 Format of the HSR, with subdivision of the ISS field for specified EC encodings
HSR exception classes and associated ISS encodings

Table B3-29 on page B3-1422 shows the encoding of the HSR exception class field, EC. Values of EC not shown
in the table are reserved. The table divides the EC values into three groups, relating to the interpretation of the
associated ISS fields. For each EC value, the table references a subsection that gives information about:
• the cause of the exception, for example the configuration required to enable the trap
• the encoding of the associated ISS.

Table B3-29 HSR.EC field encoding
EC Exception class ISS description, or notes
0x00 Unknown reason Exceptions with an unknown reason.
Nonzero EC values with HSR[31:30] zero a
0x01 Trapped WFI or WFE instruction ISS encoding for trapped WFI or WFE instruction on page B3-1423.
0x03 Trapped MCR or MRC access to CP15 ISS encoding for trapped MCR or MRC access on page B3-1424.
0x04 Trapped MCRR or MRRC access to CP15 ISS encoding for trapped MCRR or MRRC access on page B3-1424.
0x05 Trapped MCR or MRC access to CP14 ISS encoding for trapped MCR or MRC access on page B3-1424.
0x06 Trapped LDC or STC access to CP14 ISS encoding for trapped LDC or STC access on page B3-1425.
0x07 HCPTR-trapped access to CP0-CP13 ISS encoding for HCPTR-trapped access to CP0-CP13 on page B3-1426.
Includes trap on use of Advanced SIMD.
0x08 Trapped MRC or VMRS access to CP10, ISS encoding for trapped MCR or MRC access on page B3-1424.
for ID group traps This trap is not taken if the HCPTR settings trap the access.
0x0A Trapped BXJ instruction ISS encoding for trapped BXJ execution on page B3-1427.
0x0C Trapped MRRC access to CP14 ISS encoding for trapped MCRR or MRRC access on page B3-1424.
EC values with HSR[31:30] nonzero
0x11 Supervisor Call exception routed to ISS encoding for Hypervisor Call exception, or Supervisor Call exception
Hyp mode routed to Hyp mode on page B3-1427.
0x12 Hypervisor Call
0x13 Trapped SMC instruction ISS encoding for trapped SMC execution on page B3-1428.
0x20 Prefetch Abort routed to Hyp mode ISS encoding for Prefetch Abort exceptions taken to Hyp mode on
page B3-1428.
0x21 Prefetch Abort taken from Hyp mode
0x24 Data Abort routed to Hyp mode ISS encoding for Data Abort exceptions taken to Hyp mode on
page B3-1429.
0x25 Data Abort taken from Hyp mode
a. For more information see Encoding of ISS[24:20] when HSR[31:30] is 0b00 on page B3-1423.
All EC encodings not shown in Table B3-28 on page B3-1419 are reserved by ARM.
Exceptions with an unknown reason

An HSR.EC value of 0x00 indicates an exception with an unknown reason. Any exception not covered by a nonzero
EC value defined in Table B3-29 returns this value. When HSR.EC returns a value of 0x00, all other fields of HSR
are invalid.
Undefined Instruction exception, when HCR.TGE is set to 1 on page B1-1191 describes the configuration settings
for a trap that returns an HSR.EC value of 0x00.
Encoding of ISS[24:20] when HSR[31:30] is 0b00
For EC values that are nonzero and have the two most-significant bits 0b00, ISS[24:20] provides the condition code
field for the trapped instruction, together with a valid flag for this field. The encoding of this part of the ISS field is:
CV, ISS[24] Condition code valid. Possible values of this bit are:
0 The COND field is not valid.
1 The COND field is valid
COND, ISS[23:20]
The condition code for the trapped instruction. This field is valid only when CV is set to 1.
If CV is set to 0, this field is UNK/SBZP.
When an ARM instruction is trapped, CV is set to 1 and:

• if the instruction is conditional, COND is set to the condition code field value from the instruction
• if the instruction is unconditional, COND is set to 0xE.
A conditional ARM instruction that is known to pass its condition code check can be presented either:
• with COND set to 0xE, the value for unconditional
• with the COND value held in the instruction.
When a Thumb instruction is trapped, it is IMPLEMENTATION DEFINED whether:

• CV set to 0 and COND is set to an UNKNOWN value
• CV set to 1 and COND is set to the condition code for the condition that applied to the instruction.
When CV is set to 0, software must examine the SPSR.IT field to determine the conditionality of a Thumb
instruction.
Except for unconditional Thumb instructions reported with CV set to 0, a trapped unconditional instruction is
reported with CV set to 1 and a COND value of 0x0E, the condition code value for unconditional.
For an implementation that, for both ARM and Thumb instructions, takes an exception on a trapped conditional
instruction only if the instruction passes its condition code check, these definitions mean that when CV is set to 1 it
is IMPLEMENTATION DEFINED whether the COND field is set to 0xE, or to the value of any condition that applied to
the instruction.
Note
In some circumstances, it is IMPLEMENTATION DEFINED whether a conditional instruction that fails its condition
code check generates an Undefined Instruction exception, see Conditional execution of undefined instructions on
page B1-1208.
ISS encoding for trapped WFI or WFE instruction
This is the exception with EC value 0x01. When HSR.EC returns this value, the encoding of the ISS field is:
24 23 20 19 1 0
CV COND Reserved, UNK/SBZP
Trapped instruction
ISS[24:20] See Encoding of ISS[24:20] when HSR[31:30] is 0b00.
ISS[19:1] Reserved, UNK/SBZP.
ISS[0] Indicates the trapped instruction. The possible values of this bit are:
0 WFI trapped.
1 WFE trapped.
Trapping use of the WFI and WFE instructions on page B1-1253 describes the configuration settings for this trap.
ISS encoding for trapped MCR or MRC access
These are the exceptions with the following EC values:

• 0x03, trapped MRC or MCR access to CP15.
• 0x05, trapped MRC or MCR access to CP14.
• 0x08, trapped MRC or VMRS access to CP10.
When HSR.EC returns one of these values, the encoding of the ISS field is:
24 23 20 19 17 16 14 13 10 9 8 5 4 1 0
CV COND Opc2 Opc1 CRn (0) Rt CRm
Direction
ISS[24:20] See Encoding of ISS[24:20] when HSR[31:30] is 0b00 on page B3-1423.
ISS[19:17] The Opc2 value from the issued instruction.
For a trapped VMRS access, this field holds the value 0b000.
ISS[13:10] The CRn value from the issued instruction, the coprocessor primary register value.
For a trapped VMRS access, this field holds the reg field from the VMRS instruction encoding.
ISS[9] Reserved, UNK/SBZP.
ISS[8:5] The Rt value from the issued instruction, the ARM core register used for the transfer.
ISS[4:1] The CRm value from the issued instruction.
ISS[0] Indicates the direction of the trapped instruction. The possible values of this bit are:
0 Write to coprocessor. MCR instruction.
1 Read from coprocessor. MRC or VMRS instruction.
The following sections describe configuration settings for traps that are reported using EC value 0x03:
• Trapping ID mechanisms on page B1-1249
• Trapping accesses to lockdown, DMA, and TCM operations on page B1-1251
• Trapping accesses to cache maintenance operations on page B1-1252
• Trapping accesses to TLB maintenance operations on page B1-1252
• Trapping accesses to the Auxiliary Control Register on page B1-1252
• Trapping accesses to the Performance Monitors Extension on page B1-1253
• Trapping CPACR accesses on page B1-1256
• ID group 0, Primary device identification registers on page B1-1250
• Trapping accesses to Jazelle functionality on page B1-1254, for accesses to Jazelle registers
• Trapping accesses to the ThumbEE configuration registers on page B1-1254
• Trapping CP14 accesses to Debug ROM registers on page B1-1258
• Trapping CP14 accesses to OS-related debug registers on page B1-1258
• Trapping general CP14 accesses to debug registers on page B1-1258
• Trapping CP14 accesses to trace registers on page B1-1259.
Trapping ID mechanisms on page B1-1249 describes configuration settings for traps that are reported using EC
value 0x08.
ISS encoding for trapped MCRR or MRRC access

• 0x04, trapped MRRC or MCRR access to CP15
• 0x0C, trapped MRRC access to CP14.
24 23 20 19 16 15 14 13 10 9 8 5 4 1 0
CV COND Opc1 (0) (0) Rt2 (0) Rt CRm
Direction
ISS[13:10] The Rt2 value from the issued instruction, one of the ARM core registers for the transfer.
ISS[8:5] The Rt value from the issued instruction, one of the ARM core registers for the transfer.
ISS[4:1] The CRm value from the issued instruction, the coprocessor primary register value.
0 Write to coprocessor. MCRR instruction.
1 Read from coprocessor, MRRC instruction.
• Trapping writes to virtual memory control registers on page B1-1256
The following sections describe configuration settings for traps that are reported using EC value 0x0C:
• Trapping general CP14 accesses to debug registers on page B1-1258
• Trapping CP14 accesses to Debug ROM registers on page B1-1258.
ISS encoding for trapped LDC or STC access

24 23 20 19 12 11 9 8 5 4 3 2 1 0
Immediate instruction Rn 0
CV COND imm8 (0) (0) (0) x x
Literal instruction, LDC only UNKNOWN 1
Offset sign
Offset form
Addressing mode
Direction
ISS[19:12] imm8. The immediate value from the issued instruction.
ISS[8:5] Encoding depends on the instruction form indicated by ISS[3]:

ISS[3]==0 Encodes Rn, the ARM core register that holds the base address. Applies only to
immediate instruction forms.
ISS[3]==1 UNKNOWN. Applies only to literal instruction forms, that are available only for LDC
instructions
ISS[4] Indicates whether the offset is added or subtracted:

0 Subtract offset.
1 Add offset.
This bit corresponds to the U bit in the instruction encoding.
ISS[3:1] Addressing mode. The permitted values of this field are:

0b000 Immediate unindexed.
0b001 Immediate post-indexed.
0b010 Immediate offset.
0b011 Immediate pre-indexed.
0b100 Literal unindexed.
LDC instruction in ARM instruction set only.
For a trapped STC instruction or a trapped LDC Thumb instruction, this encoding is
reserved.
0b101 Reserved.
0b110 Literal offset.
LDC instruction only.
For a trapped STC instruction, this encoding is reserved.
0b111 Reserved.
ISS[3] indicates the instruction form, immediate or literal. See the description of ISS[8:5].
ISS[2:1] correspond to the bits {P, W} in the instruction encoding.
0 Write to memory. STC instruction.
1 Read from memory. LDC instruction.
Note
The only architected uses of these instructions to access CP14 are:
• an STC to write to DBGDTRRXint
• an LDC to read DBGDTRTXint.
For more information see CP14 debug register interface accesses on page C6-2110.
Trapping general CP14 accesses to debug registers on page B1-1258 describes the configuration settings for the
trap that is reported using EC value 0x06.
ISS encoding for HCPTR-trapped access to CP0-CP13
24 23 20 19 6 5 4 3 0
CV COND Reserved, UNK/SBZP (0) coproc
Trapped Advanced SIMD
ISS[5] Indicates trapped use of the Advanced SIMD Extension for instructions that are not also VFP
instructions. The possible values of this bit are:
0 Exception was not caused by trapped use of the Advanced SIMD Extension.
1 Exception was caused by trapped use of the Advanced SIMD Extension.
Any use of an Advanced SIMD instruction that is not also a floating point instruction that is trapped
to Hyp mode because of any traps configured in the HCPTR causes this bit to be set to 1.
ISS[3:0] coproc. The number of the coprocessor accessed by the trapped operation, 0-13.
This field is valid only when ISS[5] returns 0. Otherwise, it is UNK/SBZP.
Any use of a Floating-point instruction or access to a Floating-point Extension register that is

trapped to Hyp mode because of a trap configured in the HCPTR sets this field to 0xA.
The following sections describe the configuration settings for the traps that are reported using EC value 0x07:
• Trapping of Advanced SIMD functionality on page B1-1255
• General trapping of coprocessor accesses on page B1-1256
ISS encoding for trapped BXJ execution

This is the exception with EC value 0x0A. When HSR.EC returns this value, the encoding of the ISS field is:
24 23 20 19 4 3 0
CV COND Reserved, UNK/SBZP Rm
Trapping accesses to Jazelle functionality on page B1-1254 describes the configuration settings for this trap.
ISS encoding for Hypervisor Call exception, or Supervisor Call exception routed to Hyp mode

• 0x11, Supervisor Call exception taken to Hyp mode
• 0x12, Hypervisor Call exception.
Note
• A Supervisor Call exception is generated by executing an SVC instruction, see SVC (previously SWI) on
page A8-721.
• A Hypervisor Call exception is generated by executing an HVC instruction, see HVC on page B9-1970.
24 16 15 0
Reserved, UNK/SBZP imm16
ISS[15:0] imm16. The value of the immediate field from the issued instruction.
For an SVC instruction:
• If the instruction is unconditional:
— For the 16-bit Thumb instruction, this field is zero-extended from the imm8 field of
the instruction.
— For the ARM instruction, this field is the bottom 16 bits of the imm24 field of the
instruction.
• If the instruction is conditional, this field is UNKNOWN.
Note
The HVC instruction is unconditional, and a conditional SVC instruction generates a Supervisor Call exception that is
routed to Hyp mode only if it passes its condition code check. Therefore, the syndrome information for these
exceptions does not include conditionality information.
Supervisor Call exception, when HCR.TGE is set to 1 on page B1-1191 describes the configuration settings for the
trap reported with EC value 0x11.
ISS encoding for trapped SMC execution
This is the exception with EC value 0x13. When HSR.EC returns this value, the ISS field does not return any
syndrome information, and the encoding of the ISS field is:
Note
SMC instructions cannot be trapped if they fail their condition code check. Therefore, the syndrome information for
this exception does not include conditionality information.
Trapping use of the SMC instruction on page B1-1253 describes the configuration settings for this trap, for
instructions executed in Non-secure PL1 modes.
ISS encoding for Prefetch Abort exceptions taken to Hyp mode

• 0x20, for a Prefetch Abort exception taken from a mode other than Hyp mode and routed to Hyp mode.
• 0x21, for a Prefetch Abort exception taken from Hyp mode.
24 10 9 8 7 6 5 0
Reserved, UNK/SBZP (0) (0) IFSC
EA
S1PTW
ISS[9] EA, External abort type. Can provide an IMPLEMENTATION DEFINED classification of external
aborts. If the implementation does not provide any classification of external aborts, this bit is
UNK/SBZP.
For any abort other than an External abort this bit returns a value of 0.
Note
This bit is equivalent to the IFSR.ExT bit.
ISS[7] S1PTW. For a stage 2 fault, indicates whether the fault was a fault on the stage 2 translation of an
address accessed during a stage 1 translation table walk:
0 Fault not on a stage 2 translation for a stage 1 translation table walk.
1 Fault on the stage 2 translation of an access for a stage 1 translation table walk.
For a stage 1 fault, this bit is UNK/SBZP.
ISS[5:0] IFSC, Instruction fault status code. Indicates the fault that caused the exception, using the fault
codes defined for use with the Long-descriptor translation table format, see Fault reporting with the
Note
This field is equivalent to the IFSR.STATUS field, and only valid IFSR.STATUS values are valid
for this field.
The following sections describe cases where Prefetch Abort exceptions can be routed to Hyp mode, generating
exceptions that are reported in the HSR with EC value 0x20:
ISS encoding for Data Abort exceptions taken to Hyp mode

• 0x24, for a Data Abort exception taken from a mode other than Hyp mode and routed to Hyp mode.
• 0x25, for a Data Abort exception taken from Hyp mode.
24 23 22 21 20 19 18 17 16 15 10 9 8 7 6 5 0
0 Reserved, UNK/SBZP Reserved,
DFSC
1 SAS (0) SRT UNK/SBZP
ISV EA
SSE CM
S1PTW
Instruction syndrome WnR
ISS[24] Instruction syndrome valid. Indicates whether ISS[24:16] provide a valid instruction syndrome, as
part of the returned ISS. The possible values of this bit are:
0 No valid instruction syndrome. ISS[23:16] are UNK/SBZP.
1 ISS[24:16] hold a valid instruction syndrome.
This bit is 0 for all faults except for those generated by a stage 2 translation. For Data Abort
exceptions generated by a stage 2 translation, this bit is 1 and a valid instruction syndrome is
returned only if all of the following are true:
• The instruction that generated the Data Abort exception:
— Is an LDR, LDRT, LDRSH, LDRSHT, LDRH, LDRHT, LDRSB, LDRSBT, LDRB, LDRBT, STR, STRT, STRH,
STRHT, STRB, or STRBT.
— Is not performing register writeback.
— Is not using the PC as its destination register.
A stage 2 abort on a stage 1 translation table lookup sets ISV[24] to 0.
Note
• In the ARM instruction set, LDR*T and STR*T instructions always perform register writeback
and therefore never return a valid instruction syndrome.
• A valid instruction syndrome provides information that can help a hypervisor to emulate the
instruction efficiently. Instruction syndromes are returned for instructions for which such
accelerated emulation is possible.
ISS[23:16], when ISS[24] is 0

Reserved, UNK/SBZP.
ISS[23:16], when ISS[24] is 1

The remainder of the valid instruction syndrome, defined as follows:
ISS[23:22] SAS, Syndrome access size. Indicate the size of the access attempted by the faulted
operation. The possible values of this field are:
0b00 Byte.
0b01 Halfword.
0b10 Word.
0b11 Reserved.
ISS[21] SSE, Syndrome sign extend. For a byte or halfword load operation, indicates whether
the data item must be sign extended. For these cases, the possible values of this bit are:
0 Sign-extension not required.
1 Data item must be sign-extended.

For all other operations this bit is 0.
ISS[19:16] SRT, Syndrome Register Transfer. The value of the Rt operand of the faulting
instruction. This specifies:
• the destination register for a load operation
• the source register for a store operation.
Note
Normally, software emulating an instruction must consider both the Rt value and the
Mode value saved in the SPSR, to determine the physical register to access.
ISS[9] EA, External abort type. Can provide an IMPLEMENTATION DEFINED classification of external
aborts. If the implementation does not provide any classification of external aborts, this bit is
UNK/SBZP.
For any abort other than an External abort this bit returns a value of 0.
Note
This bit is equivalent to the DFSR.ExT bit.
ISS[8] CM, Cache maintenance. For a synchronous fault, identifies fault that comes from a cache
maintenance or address translation operation. For synchronous faults, the possible values of this bit
are:
0 Fault not generated by a cache maintenance or address translation operation.
1 Fault generated by a cache maintenance or address translation operation.
For asynchronous faults, this bit is 0.
Note
This bit is equivalent to the DFSR.CM bit.
ISS[7] S1PTW. For a stage 2 fault, indicates whether the fault was a fault on the stage 2 translation of an
address accessed during a stage 1 translation table walk:
0 Fault not on a stage 2 translation for a stage 1 translation table walk.
1 Fault on the stage 2 translation of an access for a stage 1 translation table walk.
For a stage 1 fault, this bit is UNK/SBZP.
ISS[6] WnR. Indicates whether a synchronous abort was caused by a write instruction or by a read
instruction. The possible values of this bit are:
0 Abort caused by a read instruction.
1 Abort caused by a write instruction.
For synchronous faults on cache maintenance and address translation operations, this bit always
returns a value of 1.
Note
ISS[8] is set to 1 to identify a fault on a cache maintenance or address translation operation.
For an asynchronous Data Abort exception this bit is UNKNOWN.

For a fault generated by an SWP or SWPB instruction, the WnR bit is 0 if a read to the location would
have generated a fault, otherwise it is 1.
Note
This bit is equivalent to the DFSR.WnR bit.
ISS[5:0] DFSC, Data fault status code. Indicates the fault that caused the exception, using the fault codes
defined for use with the Long-descriptor translation table format, see Fault reporting with the
Note
This field is equivalent to the DFSR.STATUS field, and all valid DFSR.STATUS values are valid
for this field.
The following describe cases where Data Abort exceptions can be routed to Hyp mode, generating exceptions that
are reported in the HSR with EC value 0x24:
• Alignment fault, when HCR.TGE is set to 1 on page B1-1192.
B3.13.7 Summary of register updates on exceptions taken to the PL2 mode

For memory system faults that generate exceptions that are taken to Hyp mode, Table B3-30 shows the registers
affected by each fault. In this table:
• Yes indicates that the register is updated
• UNK indicates that the fault makes the register value UNKNOWN
• a null entry, -, indicates that the fault does not affect the register.
Table B3-30 Effect of an exception taken to the PL2 mode on the reporting registers
Fault HSR HIFAR HDFAR HPFAR DBGWFAR
Faults reported as Prefetch Abort exceptions:
MMU fault a at stage 1. Yes Yes UNK UNK -
MMU Translation or Access flag fault a at stage 2. Yes Yes UNK Yes -
MMU Permission fault a at stage 2. Yes Yes UNK UNK -
MMU stage 2 fault a on stage 1 translation. Yes Yes UNK Yes -
Synchronous external abort on translation table walk. Yes Yes UNK UNK -
Synchronous parity error on translation table walk. Yes Yes UNK UNK -
Synchronous external abort. Yes Yes UNK UNK -
Synchronous parity error on memory access. Yes Yes UNK UNK -
TLB conflict abort. Yes Yes UNK UNK -
Table B3-30 Effect of an exception taken to the PL2 mode on the reporting registers (continued)
Fault HSR HIFAR HDFAR HPFAR DBGWFAR
Fault reported as Data Abort exception:
Alignment fault, always synchronous Yes UNK Yes UNK -
MMU fault a at stage 1. Yes UNK Yes UNK -
MMU Translation or Access flag fault a at stage 2. Yes UNK Yes Yes -
MMU Permission fault a at stage 2. Yes UNK Yes UNK -
MMU stage 2 fault a on stage 1 translation. Yes UNK Yes Yes -
Synchronous external abort on translation table walk. Yes UNK Yes UNK -
Synchronous parity error on translation table walk. Yes UNK Yes UNK -
Synchronous external abort. Yes UNK Yes UNK -
Synchronous parity error on memory access. Yes UNK Yes UNK -
Asynchronous external abort. Yes UNK UNK UNK -
Asynchronous parity error on memory access. Yes UNK UNK UNK -
TLB conflict abort. Yes UNK Yes UNK -
Debug exception:
BKPT instruction debug event b, generates a Prefetch Abort exception. Yes UNK UNK UNK -
Debug exception routed to Hyp mode because HDCR.TDE is set to 1. Generates a Hyp Trap exception.
Breakpoint, BKPT instruction, or Vector catch debug event Yes UNK UNK UNK -
Watchpoint exception, on synchronous watchpoint. Yes UNK Yes UNK UNK
Watchpoint exception, on asynchronous watchpoint. Yes UNK UNK UNK Yes
a. For more information see Classification of MMU faults taken to the PL2 mode on page B3-1433.
b. All other debug exceptions are not permitted in Hyp mode.
Note
Unlike Table B3-26 on page B3-1415, the PL2 fault reporting table does not include an entry for a fault on an
instruction cache maintenance operation. That is because, when the fault is taken to the PL2 mode, the reporting
indicates the cause of the fault, for example a Translation fault, and ISS.CM is set to 1 to indicate that the fault was
on a cache maintenance operation, see ISS encoding for Data Abort exceptions taken to Hyp mode on page B3-1429.
Classification of MMU faults taken to the PL2 mode

This subsection gives more information about the MMU faults shown in Table B3-30 on page B3-1431.
Note
All MMU faults are synchronous.
The table uses the following descriptions for MMU faults taken to the PL2 mode:
MMU fault at stage 1 This is an MMU fault generated on a stage 1 translation performed in the Non-secure PL2
translation regime.
MMU fault at stage 2 This is an MMU fault generated on a stage 2 translation performed in the Non-secure
PL1&0 translation regime.
As the table shows, for the faults in this group:
• Translation and Access flag faults update the HPFAR
• Permission faults leave the HPFAR UNKNOWN.
MMU stage 2 fault on a stage 1 translation

This is an MMU fault generated on the stage 2 translation of an address accessed in a stage
1 translation table walk performed in the Non-secure PL1&0 translation regime. For more
information about these faults see Stage 2 fault on a stage 1 translation table walk,
Figure B3-1 on page B3-1307 shows the different translation regimes and associated stages of translation.
B3.14 Virtual Address to Physical Address translation operations

CP15 c7 includes operations for Virtual Address (VA) to Physical Address (PA) translation. Address translation
operations, functional group on page B3-1493 summarizes these operations. Each of the following architecture
extensions affects the details of these operations:
• the Security Extensions
• the Large Physical Address Extension
• the Virtualization Extensions.
When using the Short-descriptor translation table format, all VA to PA translations take account of TEX remap when
this is enabled, see Short-descriptor format memory region attributes, with TEX remap on page B3-1364.
Note
A processor that does not implement the Large Physical Address Extension always uses the Short-descriptor
A VA to PA translation operation returns the PA in the PAR. The Large Physical Address Extension extends the PAR
to 64 bits, to hold PAs of up to 40 bits.
The following sections give more information about these operations:

• Naming of the address translation operations, and operation summary
• Encoding and availability of the address translation operations on page B3-1436
• Determining the PAR format, Large Physical Address Extension on page B3-1437
• Handling of faults and aborts during an address translation operation on page B3-1437.
B3.14.1 Naming of the address translation operations, and operation summary

The Virtualization Extensions introduce additional address translation operations. Therefore, the older operations
are renamed to give consistent naming for all operations. The operation names now indicate the corresponding
translation stage. In an implementation that does not include the Virtualization Extensions, there is no distinction
between stage 1 translations and stage 1 and 2 combined translations.
Table B3-31 Naming of address translation operations
Name Old name Description
ATS1CPR, ATS1CPW, V2PCWPR, V2PCWPW, See Address translation stage 1, current security state on
ATS1CUR, ATS1CUW V2PCWUR, V2PCWUW page B3-1435
ATS12NSOPR, ATS12NSOPW, V2POWPR, V2POWPW, See Address translation stages 1 and 2, Non-secure state only on
ATS12NSOUR, ATS12NSOUW V2POWUR, V2POWUW page B3-1435
ATS1HR, ATS1HW Not applicable a See Address translation stage 1, Hyp mode on page B3-1436
a. Operations are part of the Virtualization Extensions and have no equivalent in the older descriptions.
In the stage 1 current state and stages 1 and 2 Non-secure state only operations, the meanings of the last two letters
of the names are:
PR PL1 mode, read operation.
PW PL1 mode, write operation.
UR PL0 mode, read operation.
UW PL0 mode, write operation.
Note
PL0 modes can also be described as unprivileged modes. User mode is the only PL0 mode.
In the stage 1 Hyp mode operations, the last letter of the operation name is R for the read operation and W for the
write operation.
The following sections describe the use and availability of these operations:
• Address translation stage 1, current security state
• Address translation stages 1 and 2, Non-secure state only
• Address translation stage 1, Hyp mode on page B3-1436.
Encoding and availability of the address translation operations on page B3-1436 gives the encodings of the
operations.
Address translation stage 1, current security state

These are the ATS1Cxx operations. Any VMSAv7 implementation supports these operations. They can be executed
by any software executing at PL1 or higher, in either security state.
These instructions perform the address translations of the PL1&0 translation regime of the current security state. In
an implementation that includes the Virtualization Extensions, when executed in Non-secure state, they return the
IPA that is the output address of the stage 1 translation. Figure B3-1 on page B3-1307 shows the different translation
regimes.
Note
The Non-secure PL1 and PL0 modes have no visibility of the stage 2 address translations, that can be defined only
at PL2, and translate IPAs to be PAs.
For an implementation that includes the Large Physical Address Extension, see Determining the PAR format, Large
Physical Address Extension on page B3-1437 for the format used when returning the result of these operations.
Address translation stages 1 and 2, Non-secure state only

These are the ATS12NSOxx operations. A VMSAv7 implementation supports these operations only if it includes
the Security Extensions. They can be executed:
• By any software executing in Secure state at PL1.
• If the implementation includes the Virtualization Extensions, by software executing in Non-secure state at
PL2. This means by software executing in Hyp mode.
ARM deprecates use of these operations from any Secure PL1 mode other than Monitor mode.
In Secure state, and in Non-secure Hyp mode on an implementation that includes the Virtualization Extensions,
these operations perform the translations made by the Non-secure PL1&0 translation regime.
These operations always return the PA and final attributes generated by the translation.That is, for an
implementation that includes the Virtualization Extensions, they return:
• the result of the two stages of address translation for the specified Non-secure input address.
• the memory attributes obtained by the combination of the stage 1 and stage 2 attributes.
Note
From Hyp mode, the ATS1Cxx and ATS12NSOxx operations both return the results of address translations that
would be performed in the Non-secure modes other than Hyp mode. The difference is:
• The ATS1Cxx operations return the Non-secure PL1 view of these operations. That is, they return the IPA
output address corresponding to the VA input address.
• The ATS12NSOxx operations return the PL2, or Hyp mode, view of these operations. That is, they return the
PA output address corresponding to the VA input address, generated by two stages of translation.
For an implementation that includes the Large Physical Address Extension, see Determining the PAR format, Large
Physical Address Extension on page B3-1437 for the format used when returning the result of these operations.
Address translation stage 1, Hyp mode

These are the ATS1Hx operations. A VMSAv7 implementation supports these operations only if it includes the
Virtualization Extensions. They can be executed by:
• Software executing in Non-secure state at PL2. This means by software executing in Hyp mode.
• Software executing in Secure state in Monitor mode.
These operations are UNPREDICTABLE if used in a Secure PL1 mode other than Monitor mode.
These operations perform the translations made by the Non-secure PL2 translation regime. The operation takes a
VA input address and returns a PA output address.
These operations always return a result in a 64-bit format PAR.
B3.14.2 Encoding and availability of the address translation operations

Software executing at PL0 never has any visibility of the address translation operations, but software executing at
PL1 or higher can use the unprivileged address translation operations to find the address translations used for
memory accesses by software executing at PL0 and PL1.
Note
For information about translations when the MMU is disabled see Address translation operations when the MMU
is disabled on page B4-1744.
Table B3-32 shows the encodings for the address translation operations, and their availability in different
implementations in different processor modes and states.
Table B3-32 CP15 c7 address translation operations
opc1 CRm opc2 Name Type Description
All VMSAv7 implementations, in all modes, at PL1 or higher
0 c8 0 ATS1CPR WO PL1 stage 1 read translation, current state a
1 ATS1CPW WO PL1 stage 1 write translation, current state a
2 ATS1CUR WO Unprivileged stage 1 read translation, current state a
3 ATS1CUW WO Unprivileged stage 1 write translation, current state a
Implementations that include the Security Extensions, in Secure PL1 modes and Non-secure Hyp mode
0 c8 4 ATS12NSOPR WO Non-secure PL1 stage 1 and 2 read translation b
5 ATS12NSOPW WO Non-secure PL1 stage 1 and 2 write translation b
6 ATS12NSOUR WO Non-secure unprivileged stage 1 and 2 read translation b
7 ATS12NSOUW WO Non-secure unprivileged stage 1 and 2 write translation b
Implementations that include the Virtualization Extensions, in Non-secure Hyp mode and Secure Monitor mode
4 c8 0 ATS1HR WO Hyp mode stage 1 read translation c
1 ATS1HW WO Hyp mode stage 1 write translation c
a. For more information about these operations see Address translation stage 1, current security state on page B3-1435.
b. For more information about these operations see Address translation stages 1 and 2, Non-secure state only on page B3-1435.
c. For more information about these operations see Address translation stage 1, Hyp mode.
The result of an operation is always returned in the PAR. The PAR is a RW register and:
• in all implementations, the 32-bit format PAR is accessed using an MCR or MRC instruction with CRn set to c7,
CRm set to c4, and opc1 and opc2 both set to 0
• in an implementation that includes the Large Physical Address Extension, the 64-bit format PAR is accessed
using an MCRR or MRRC instruction with CRm set to c7, and opc1 set to 0.
CP15 c7 address translation operations that are not available in a particular implementation are reserved and
UNPREDICTABLE. For example, in an implementation that does not include the Security Extensions, the encodings
with opc2 values of 4-7, and the encodings with an opc1 value of 4, are reserved and UNPREDICTABLE.
B3.14.3 Determining the PAR format, Large Physical Address Extension

The Large Physical Address Extension extends the PAR to become a 64-bit register, and supports both 32-bit and
64-bit PAR formats. This section describes how the PAR format is determined, for returning a result from each of
the groups of address translation operations. The returned result might be the translated address, or might indicate
a fault on the translation, see Handling of faults and aborts during an address translation operation.
ATS1Cxx operations
Address translations for the current state. From modes other than Hyp mode:
• TTBCR.EAE determines whether the result is returned using the 32-bit or the 64-bit PAR
format.
• If the implementation includes the Security Extensions, the translation performed is for the
current security state and, depending on that state:
— the Secure or Non-secure TTBCR.EAE determines the PAR format.
— the result is returned to the Secure or Non-secure copy of the PAR
Operations from Hyp mode always return a result to the Non-secure PAR, using the 64-bit format.
ATS12NSOxx operations
Address translations for the Non-secure PL1 and PL0 modes. These operations return a result using
the 64-bit PAR format if at least one of the following is true:
• the Non-secure TTBCR.EAE bit is set to 1
• the implementation includes the Virtualization Extensions, and HCR.VM is set to 1.
Otherwise, the operation returns a result using the 32-bit PAR format.
Operations from a Secure PL1 mode return a result to the Secure PAR. Operations from Hyp mode
return a result to the Non-secure PAR.
ATS1Hx operations
Address translations from Hyp mode. These operations always return a result using the 64-bit PAR
format.
Operations from Secure Monitor mode return a result to the Secure PAR. Operations from
Non-secure Hyp mode return a result to the Non-secure PAR.
B3.14.4 Handling of faults and aborts during an address translation operation

When an MMU is enabled, any corresponding address translation operation requires a translation table lookup, and
this might require a translation table walk. However, the input address for the translation might be a faulting address,
either because:
• the translation table entries used for the translation indicate a fault
• a stage 2 fault or an external abort occurs on the required translation table walk.
VMSA memory aborts on page B3-1392 describes the faults that might occur on a translation table walk.
How the fault is handled, and whether it generates an exception, depends on the cause of the fault, as described in:
• MMU fault on an address translation operation on page B3-1438
• External abort during an address translation operation on page B3-1438
• Stage 2 fault on a current state address translation operation on page B3-1439.
Because an address translation operation does not access the output address of the associated address translation,
watchpoints cannot be generated by address translation operations.
MMU fault on an address translation operation

In the following cases, an MMU fault on an address translation is reported in the PAR, and no abort is taken. This
applies:
• For a faulting address translation operation executed in Hyp mode, or in a Secure PL1 mode.
• For a faulting address translation operation executed in a Non-secure PL1 mode, for cases where the fault
would generate a stage 1 abort if it occurred on the on the equivalent load or store operation.
Using the PAR to report a fault on an address translation operation gives more information about how these faults
are reported.
Note
• The Domain fault encodings shown in Table B3-24 on page B3-1413 are used only for reporting a fault on
an address translation operation that uses the 64-bit PAR format. That is, they are used only in an
implementation that includes the Virtualization Extensions, and are used for reporting a Domain fault on
either:
— an ATS1Cxx operation from Hyp mode
— an ATS12NSOxx operation when HCR.VM is set to 1.
These encodings are never used for fault reporting in the DFSR, IFSR, or HSR.
• For an address translation operation executed in a Non-secure PL1 mode, for a fault that would generate a
stage 2 abort if it occurred on the equivalent load or store operation, the stage 2 abort is generated as described
in Stage 2 fault on a current state address translation operation on page B3-1439.
Using the PAR to report a fault on an address translation operation
For a fault on an address translation operation for which no abort is taken, the PAR is updated with the following
information, to indicate the fault:
• The fault code, that would normally be written to the Fault status register. The code used depends on the
current translation table format, as described in either:
— PL1 fault reporting with the Short-descriptor translation table format on page B3-1411
— Fault reporting with the Long-descriptor translation table format on page B3-1413.
See also the Note at the start of Determining the PAR format, Large Physical Address Extension on
page B3-1437 about the Domain fault encodings shown in Table B3-24 on page B3-1413.
• A status bit, that indicates that the translation operation failed.
The fault does not update any Fault Address Register.
External abort during an address translation operation

As stated in Behavior of external aborts on a translation table walk caused by address translation on page B3-1403,
an external abort on a translation table walk generates a Data Abort exception. The abort can be synchronous or
asynchronous, and behaves as follows:
Synchronous external abort on a translation table walk

The fault status and fault address registers of the security state to which the abort is taken are
updated. The fault status register indicates the appropriate external abort on Translation fault, and
the fault address register indicates the input address for the translation.
The PAR is UNKNOWN.
Asynchronous external abort on a translation table walk

The fault status register of the security state to which the abort is taken is updated, to indicate the
asynchronous external abort. No fault address registers are updated.
The PAR is UNKNOWN.
Stage 2 fault on a current state address translation operation

If the processor is in a Non-secure PL1 mode and performs one of the ATS1C** operations, then a fault in the stage
2 translation of an address accessed in a stage 1 translation table lookup generates an exception. This is equivalent
to the case described in Stage 2 fault on a stage 1 translation table walk, Virtualization Extensions on page B3-1399.
When this fault occurs on an ATS1C** address translation operation:
• a Hyp Trap exception is taken to Hyp mode
• the PAR is UNKNOWN
• the HSR indicates that:
— the fault occurred on a translation table walk
— the operation that faulted was a cache maintenance operation
• the HPFAR holds the IPA that faulted
• the HDFAR holds the VA that the executing software supplied to the address translation operation.
B3.15 About the system control registers for VMSA

On an ARMv7-A or ARMv7-R implementation, the system control registers comprise:
• the registers accessed using the System Control Coprocessor, CP15
• registers accessed using the CP14 coprocessor, including:
— debug registers
— trace registers
— execution environment registers.
Note
Do not confuse this general term, system control registers, with the full name of the SCTLR, described in SCTLR,
System Control Register, VMSA on page B4-1700.
Organization of the CP14 registers in a VMSA implementation on page B3-1464 summarizes the CP14 registers,
and indicates where the CP14 registers are described, either in this manual or in other architecture specifications.
Organization of the CP15 registers in a VMSA implementation on page B3-1465 summarizes the CP15 registers,
and indicates where in this manual the CP15 registers are described.
This section gives general information about the control registers, the CP14 and CP15 interfaces to these registers,
and the conventions used in describing these registers.
Note
Many implementations include other interfaces to some functional groups of CP14 and CP15 registers, for example
memory-mapped interfaces to the CP14 Debug registers. These are described in the appropriate sections of this
manual.
This section is organized as follows:

• About system control register accesses
• General behavior of system control registers on page B3-1442
• Classification of system control registers on page B3-1447
• Effect of the LPAE and Virtualization Extensions on the system control registers on page B3-1456
• Synchronization of changes to system control registers on page B3-1457
• Meaning of fixed bit values in register bit assignment diagrams on page B3-1461.
B3.15.1 About system control register accesses

Before the introduction of the Large Physical Address Extension, Virtualization Extensions, and Generic Timer, in
ARMv7 all control registers were 32-bits wide. Accessing 32-bit control registers on page B3-1441 describes how
these registers are accessed.
Note
Optionally, an ARMv6 implementation can include some block transfer operations that are accessed using 64-bit
CP15 accesses, see Block transfer operations on page D12-2520.
The Large Physical Address Extension, Virtualization Extensions, and the OPTIONAL Generic Timer introduce a
small number of 64-bit control registers. Accessing 64-bit control registers on page B3-1441 describes how these
registers are accessed.
When using the MCR, MRC, MCRR, and MRRC instructions to access these registers, the instruction arguments include:
• a coprocessor identifier, coproc, as a value p0-p15, corresponding to CP0-CP15
• a coprocessor register, CRn or CRm, as a value c0-c15, to specify a coprocessor register number
• an opcode, opc1 or opc2, as a value in the range 0-7.
Note
• When accessing CP15, the primary coprocessor register is the top-level indicator of the accessed
functionality, and when:
— using an MCR or MRC instruction, CRn specifies the primary coprocessor register
— using an MCRR or MRRC instruction, CRm specifies the primary coprocessor register.
• When accessing CP14 using any of these instructions, opc1 is the top-level indicator of the accessed
functionality.
Ordering of reads of system control registers

Reads of the system control registers can occur out of order with respect to earlier instructions executed on the same
processor, provided that the data dependencies between the instructions, specified in Synchronization of changes to
system control registers on page B3-1457, are met.
Note
In particular, system control registers holding self-incrementing counts, for example the Performance Monitors
counters or the Generic Timer counter or timers, can be read early. This means that, for example, if a memory
communication is used to communicate a read of the Generic Timer counter, an ISB must be inserted between the
read of the memory location used for this communication and the read of the Generic Timer counter if it is required
that the Generic Timer counter returns a count value that is later than the memory communication.
Accessing 32-bit control registers

Software accesses a 32-bit control register using the generic MCR and MRC coprocessor interface, specifying:
• A coprocessor identifier, coproc, identifying one of coprocessors CP0-CP15.
• Two coprocessor registers, CRn and CRm. CRn specifies the primary coprocessor register.
• Two coprocessor-specific opcodes, opc1 and opc2.
• An ARM core register to hold a 32-bit value to transfer to or from the coprocessor.
CP15 and CP14 provides the control registers. A processor access to a specific 32-bit control register uses:
• p15 to specify CP15, or p14 to specify CP14
• a unique combination of CRn, opc1, CRm, and opc2, to specify the required control register
• an ARM core register for the transferred 32-bit value.
The processor accesses a 32-bit control register using:

• an MCR instruction to write to a control register, see MCR, MCR2 on page A8-477
• an MRC instruction to read a control register, see MRC, MRC2 on page A8-493.
Accessing 64-bit control registers

Software accesses a 64-bit control register using the generic MCRR and MRRC coprocessor interface, specifying:
• A coprocessor identifier, coproc, identifying one of coprocessors CP0-CP15.
• A coprocessor register, CRm. In this case, CRm specifies the primary coprocessor register.
• A single coprocessor-specific opcode, opc1.
• Two ARM core registers to hold two 32-bit values to transfer to or from the coprocessor.
CP15 and CP14 provide the control registers. A processor access to a specific 64-bit control register uses:
• p15 to specify CP15, or p14 to specify CP14
• a unique combination of CRm and opc1, to specify the required 64-bit system control register
• two ARM core registers, each holding 32 bits of the value to transfer.
Therefore, processor accesses a 64-bit control register using:

• an MCRR instruction to write to a control register, see MCRR, MCRR2 on page A8-479
• an MRRC instruction to read a control register, see MRRC, MRRC2 on page A8-495.
When using a MCRR or MRRC instruction:
• Rt contains the least-significant 32 bits of the transferred value, and Rt2 contains the most-significant 32 bits
of that value
• the access is 64-bit atomic.
The Large Physical Address Extension extends some registers from 32-bits to 64-bits. The MCR and MRC encodings
for these registers access the least significant 32 bits of the register. For example, to access the PAR, software can:
• use the following instructions to access all 64 bits of the register:
MRRC p15, 0, <Rt>, <Rt2>, c7 ; Read 64-bit PAR into Rt (low word) and Rt2 (high word)
MCRR p15, 0, <Rt>, <Rt2>, c7 ; Write Rt (low word) and Rt2 (high word) to 64-bit PAR
• use the following instructions to access the least-significant 32 bits of the register:
MRC p15, 0, <Rt>, c7, c4, 0 ; Read PAR[31:0] into Rt
MCR p15, 0, <Rt>, c7, c4, 0 ; Write Rt to PAR[31:0]
B3.15.2 General behavior of system control registers

Except where indicated, system control registers are 32-bits wide. As stated in About system control register
accesses on page B3-1440, there are some 64-bit registers, and these include cases where software can access either
a 32-bit view or a 64-bit view of a register. The register summaries, and the individual register descriptions, identify
the 64-bit registers and how they can be accessed.
The following sections give information about the general behavior of these registers. Unless otherwise indicated,
information applies to both CP14 and CP15 registers:
• Read-only bits in read/write registers
• UNPREDICTABLE and UNDEFINED behavior for CP14 and CP15 accesses
• Reset behavior of CP14 and CP15 registers on page B3-1446.
See also About system control register accesses on page B3-1440 and Meaning of fixed bit values in register bit
assignment diagrams on page B3-1461.
Read-only bits in read/write registers

Some read/write registers include bits that are read-only. These bits ignore writes.
An example of this is the SCTLR.NMFI bit, bit[27].
UNPREDICTABLE and UNDEFINED behavior for CP14 and CP15 accesses

In ARMv7 the following operations are UNDEFINED:
• all CDP, LDC and STC operations to CP14 and CP15, except for the LDC access to DBGDTRTXint and the STC
access to DBGDTRRXint specified in CP14 debug register interface accesses on page C6-2110
• all MCRR and MRRC operations to CP14 and CP15, except for those explicitly defined as accessing 64-bit CP14
and CP15 registers
• all CDP2, MCR2, MRC2, MCRR2, MRRC2, LDC2, LDCL, LDC2L, STC2, STCL and STC2L operations to CP14 and CP15.
Unless otherwise indicated in the individual register descriptions:

• reserved fields in registers are UNK/SBZP
• assigning a reserved value to a field can have an UNPREDICTABLE effect.
The following subsections give more information about UNPREDICTABLE and UNDEFINED behavior for CP14 and
CP15 accesses:
• Accesses to unallocated CP14 and CP15 encodings on page B3-1443
• Effects of the Security Extensions and Virtualization Extensions on CP15 register accesses on page B3-1444.
Accesses to unallocated CP14 and CP15 encodings
The general rules for the behavior of accesses to unallocated register encodings are similar for CP14 and CP15, but
because the primary register specifier is different for CP14 and CP15, the details differ. Therefore, the rules are:
For CP14 For any MCR or MRC access to CP14, the opc1 value for the instruction is the primary specifier for the
functional group of registers accessed, see Organization of the CP14 registers in a VMSA
implementation on page B3-1464. Accesses to unallocated functional groups of registers are
UNDEFINED. This means any access with <opc1> =={2, 3, 4, 5} is UNDEFINED.
For MCR or MRC accesses to an allocated functional group of registers, the behavior of accesses to
unallocated registers in the functional group depends on the group:
opc1==0, Debug registers
The behavior of accesses to unallocated registers depends on the Debug architecture
version, see:
• Access to unallocated CP14 debug register encodings, v7 Debug on
page C6-2124
• Access to unallocated CP14 debug register encodings, v7.1 Debug on
page C6-2133.
opc1==1, Trace registers
See the appropriate trace architecture specification for the behavior of CP14 accesses to
unallocated Trace registers.
opc1=={6, 7}, ThumbEE and Jazelle registers
Accesses to unallocated register encodings are UNPREDICTABLE.
Note
The opc1==7 functional group, the Jazelle registers, can include registers that are
defined by the Jazelle subarchitecture.
For MCRR or MRRC accesses to CP14, all accesses are UNDEFINED unless this manual, or the appropriate
trace architecture specification, explicitly defines them as accessing a 64-bit system register:
• Chapter C11 The Debug Registers identifies valid MCRR or MRRC accesses with opc1==0
• the appropriate trace architecture specification identifies any valid MCRR or MRRC accesses with
opc1==1
• there are no valid MCRR or MRRC accesses with opc1==6 or opc1==7.
For CP15 For an MCR or MRC access to CP15, the CRn value for the instruction is the primary register specifier
for the CP15 space, and the following rules define the behavior of accesses to unallocated
encodings:
1. Accesses to unallocated primary registers are UNDEFINED. For the ARMv7-A Architecture,
this means that:
• For any implementation, accesses to CP15 primary register c4 are UNDEFINED.
• For an implementation that does not include the Security Extensions, accesses to CP15
primary register c12 are UNDEFINED.
• For an implementation that does not include the Generic Timer Extension, accesses to
CP15 primary register c14 are UNDEFINED.
See rule 3 for the behavior of accesses to CP15 primary register c15.
2. In an allocated CP15 primary register, accesses to all unallocated encodings are
UNPREDICTABLE for accesses at PL1 or higher.
This means that any MCR or MRC access from PL1 or higher with a combination of <CRn>,
<opc1>, <CRm> and <opc2> values not shown in, or referenced from, Full list of VMSA CP15
registers, by coprocessor register number on page B3-1475, that would access an allocated
CP15 primary register, is UNPREDICTABLE. As indicated by rule 1, for the ARMv7-A
architecture, the allocated CP15 primary registers are:
• in any VMSA implementation, c0-c3, c5-c11, c13, and c15
• in addition, in an implementation that includes the Security Extensions, c12

• in addition, in an implementation that includes the Generic Timer, c14.
Note
As shown in Figure B3-27 on page B3-1467, accesses to unallocated principal ID registers
map onto the MIDR. These are accesses with <CRn> = c0, <opc1> = 0, <CRm> = c0, and
<opc2> = {4, 6, 7}.
3. CP15 primary register c15 is reserved for IMPLEMENTATION DEFINED registers. This means it
is IMPLEMENTATION DEFINED whether this primary register is allocated or unallocated:
• if an implementation does not define any registers in CP15 primary register c15, then
that primary register is unallocated, and all MCR and MRC accesses to it are UNDEFINED
• otherwise, CP15 primary register c15 is allocated, and MCR and MRC accesses to
unallocated encodings with CRn set to c15 are UNPREDICTABLE for accesses at PL1 or
higher.
For MCRR or MRRC accesses to CP15, all accesses are UNDEFINED unless this manual explicitly defines
them as accessing a 64-bit system register. Full list of VMSA CP15 registers, by coprocessor register
number on page B3-1475 identifies the valid MCRR and MRRC accesses to CP15.
Additional rules for MCR and MRC accesses to CP14 and CP15 registers
All MCR operations from the PC are UNPREDICTABLE for all coprocessors, including for CP14 and CP15.
All MRC operations to APSR_nzcv are UNPREDICTABLE for CP14 and CP15, except for the CP14 MRC to APSR_nzcv
shown in CP14 debug register interface accesses on page C6-2110.
Except for CP14 and CP15 encodings that the appropriate register description identifies as accessible by software
executing at PL0, all MCR and MRC accesses from User mode are UNDEFINED. This applies to all User mode accesses
to unallocated CP14 and CP15 encodings.
Some individual registers can be made inaccessible by setting configuration bits, possibly including
IMPLEMENTATION DEFINED configuration bits, to disable access to the register. The effects of the
architecturally-defined configuration bits are defined individually in this manual. Unless explicitly stated otherwise
in this manual, setting a configuration bit to disable access to a register results in the register becoming UNDEFINED
for MRC and MCR accesses.
See also Read-only and write-only register encodings on page B3-1445.
Effects of the Security Extensions and Virtualization Extensions on CP15 register accesses
The Security Extensions and Virtualization Extensions introduce classes of system control registers, described in
Classification of system control registers on page B3-1447. Some of these classes of register are either:
• accessible only from certain modes or states
• accessible from certain modes or states only when configuration settings permit the access.
Accesses to these registers that are not permitted are UNDEFINED, meaning execution of the register access
instruction generates an Undefined Instruction exception.
Note
This section applies only to registers that are accessible from some modes and states. That is, it applies only to
register access instructions using an encoding that, under some circumstances, would perform a valid register
access.
The following register classes restrict access in this way:
Restricted access system control registers

This register class is defined in any implementation that includes the Security Extensions.
Restricted access registers other than the NSACR are accessible only from Secure PL1 modes. All
other accessed to these registers are UNDEFINED.
The NSACR is a special case of a Restricted access register and:

• the NSACR is:
— read/write accessible from Secure PL1 modes
— is Read-only accessible from Non-secure PL2 and PL1 modes
• all other accesses to the NSACR are UNDEFINED.
For more information, see Restricted access system control registers on page B3-1449.
Configurable access system control registers

This register class is defined in any implementation that includes the Security Extensions.
Most Configurable access registers are accessible from Non-secure state only if control bits in the
NSACR permit Non-secure access to the register. Otherwise, a Non-secure access to the register is
UNDEFINED.
For other Configurable access registers, control bits in the NSACR control the behavior of bits or
fields in the register when it is accessed from Non-secure state. That is, Non-secure accesses to the
register are permitted, but the NSACR controls how they behave. The only architecturally-defined
register of this type is the CPACR.
For more information, see Configurable access system control registers on page B3-1449.
PL2-mode system control registers

This register class is defined only in an implementation that includes the Virtualization Extensions.
PL2-mode registers are accessible only from:
• the Non-secure PL2 mode, Hyp mode
• Secure Monitor mode when SCR.NS is set to 1.
All other accesses to these registers are UNDEFINED.
For more information, see Banked PL2-mode CP15 read/write registers on page B3-1450 and
PL2-mode encodings for shared CP15 registers on page B3-1451.
PL2-mode write-only operations

This register class is defined only in an implementation that includes the Virtualization Extensions.
PL2-mode write-only operations are accessible only from:
• the Non-secure PL2 mode, Hyp mode
• Secure Monitor mode, regardless of the value of SCR.NS.
Write accesses to these operations are:
• UNPREDICTABLE in Secure PL1 modes other than Monitor mode
• UNDEFINED in Non-secure modes other than Hyp mode.
For more information, see Banked PL2-mode CP15 write-only operations on page B3-1452.
In addition, in any implementation that includes the Security Extensions, if write access to a register is disabled by
the CP15SDISABLE signal then any MCR access to that register is UNDEFINED.
Read-only and write-only register encodings

Some system control registers are read-only (RO) or write-only (WO). For example:
• most identification registers are read-only
• most encodings that perform an operation, such as a cache maintenance operation, are write-only.
If this manual defines a register to be RO at a particular privilege level then, at that privilege level:
• an MCR access to the register is UNPREDICTABLE
• an MCRR access to the register is UNDEFINED, regardless of whether the register can be read by an MRRC
instruction.
If this manual defines a register to be WO at a particular privilege level then, at that privilege level:
• an MRC access to the register is UNPREDICTABLE
• an MRRC access to the register is UNDEFINED, regardless of whether the register can be written by an MCRR
instruction.
Note
• This section applies only to registers that this manual defines as RO or WO. It does not apply to registers for
which other access permissions are explicitly defined.
• Although the FPSID is a RO register, a write using the FPSID encoding is a valid serializing operation, see
Asynchronous bounces, serialization, and Floating-point exception barriers on page B1-1237. Such a write
does not access the register.
Reset behavior of CP14 and CP15 registers

After a reset, only a limited subset of the processor state is guaranteed to be set to defined values. Also, for CP14
debug and trace registers, reset requirements must take account of different levels of reset. For more information
about the reset behavior of CP14 and CP15 registers, see:
• Reset and debug on page C7-2148, for the Debug CP14 registers
• the appropriate Trace architecture specification, for the Trace CP14 registers
• ThumbEE configuration on page A2-94
• Application level configuration and control of the Jazelle extension on page A2-98
• Reset behavior of CP15 registers
• Pseudocode details of resetting CP14 and CP15 registers on page B3-1447.
Reset behavior of CP15 registers
On reset, the VMSAv7 architecture defines a required reset value for all or part of each of the following CP15
registers:
• The SCTLR, CPACR, and TTBCR.
• The FCSEIDR, if the implementation includes the Fast Context Switch Extension (FCSE). This register is
RAZ/WI when the FCSE is not implemented.
• In an implementation that includes the Security Extensions, the SCR, the Secure copy of the VBAR, and the
NSACR.
• In an implementation that includes the Virtualization Extensions, the VPIDR, VMPIDR, HCR, HDCR,
HCPTR, HSTR, and VTTBR.
• In an implementation that includes the Performance Monitors extension, the PMCR, the PMUSERENR, and
in an implementation of PMUv2, the instance of PMXEVTYPER that relates to the cycle counter.
• In an implementation that includes the Generic Timer Extension, the CNTKCTL and CNTHCTL registers.
Note
In an implementation that includes the Security Extensions, unless this manual explicitly states otherwise, only the
Secure copy of a Banked register is reset to the defined value, and software must program the Non-secure copy of
the register with the required values. Typically, this programming is part of the processor boot sequence.
For details of the reset values of these registers see the register descriptions. If the description of a register or register
field does not include its reset value then the architecture does not require that register or field to reset to a defined
value.
The values of all other registers at reset are architecturally UNKNOWN. An implementation can assign an
IMPLEMENTATION DEFINED reset value to a register whose reset value is architecturally UNKNOWN. After a reset,
software must not rely on the value of any read/write register that does not have either an architecturally-defined
reset value or an IMPLEMENTATION DEFINED reset value.
Pseudocode details of resetting CP14 and CP15 registers
The ResetControlRegisters() pseudocode function resets all CP14 and CP15 registers, and register fields, that have
defined reset values, as described in this section.
Note
For CP14 debug and trace registers this function resets registers as defined for the appropriate level of reset.
B3.15.3 Classification of system control registers

The Security Extensions and Virtualization Extensions integrate with many features of the architecture. Therefore,
the descriptions of the individual system control registers include information about how these extensions affect the
register. This section:
• summarizes how the Security Extensions and Virtualization Extensions affect the implementation of the
system control registers, and the classification of those registers.
• summarizes how the Security Extensions control access to the system control registers
• describes a Security Extensions signal that can control access to some CP15 registers.
It contains the following subsections:

• Banked system control registers on page B3-1448
• Restricted access system control registers on page B3-1449
• Configurable access system control registers on page B3-1449
• PL2-mode system control registers on page B3-1450
• Common system control registers on page B3-1453
• The CP15SDISABLE input on page B3-1454
• Access to registers from Monitor mode on page B3-1455.
Note
• This section describes the effect of the Security Extensions on all of system control registers, including those
that are added by the Security Extensions, or by the Virtualization Extensions.
• The Security Extensions define the register classifications of Banked, Restricted access, Configurable, and
Common. The Virtualization Extensions add the PL2-mode classification. Some of these classifications can
apply to some coprocessor registers other than the CP14 and CP15 system control registers.
It is IMPLEMENTATION DEFINED whether each IMPLEMENTATION DEFINED register is Banked, Restricted access,
Configurable, PL2-mode, or Common.
Banked system control registers

In an implementation that includes the Security Extensions, some system control registers are Banked. Banked
system control registers have two copies, one Secure and one Non-secure. The SCR.NS bit selects the Secure or
Non-secure copy of the register. Table B3-33 shows which CP15 registers are Banked in this way, and the permitted
access to each register. No CP14 registers are Banked.
Table B3-33 Banked CP15 registers
CRn a Banked register Permitted accesses b
c0 CSSELR, Cache Size Selection Register Read/write only at PL1 or higher
c1 SCTLR, System Control Register c Read/write only at PL1 or higher
ACTLR, Auxiliary Control Register d Read/write only at PL1 or higher
c2 TTBR0, Translation Table Base 0 Read/write only at PL1 or higher
TTBR1, Translation Table Base 1 Read/write only at PL1 or higher
TTBCR, Translation Table Base Control Read/write only at PL1 or higher
c3 DACR, Domain Access Control Register Read/write only at PL1 or higher
c5 DFSR, Data Fault Status Register Read/write only at PL1 or higher
IFSR, Instruction Fault Status Register Read/write only at PL1 or higher
ADFSR, Auxiliary Data Fault Status Register d Read/write only at PL1 or higher
AIFSR, Auxiliary Instruction Fault Status Register d Read/write only at PL1 or higher
c6 DFAR, Data Fault Address Register Read/write only at PL1 or higher
IFAR, Instruction Fault Address Register Read/write only at PL1 or higher
c7 PAR, Physical Address Register Read/write only at PL1 or higher
c10 PRRR, Primary Region Remap Register Read/write only at PL1 or higher
NMRR, Normal Memory Remap Register Read/write only at PL1 or higher
c12 VBAR, Vector Base Address Register Read/write only at PL1 or higher
c13 FCSEIDR, FCSE PID Register e Read/write only at PL1 or higher
CONTEXTIDR, Context ID Register Read/write only at PL1 or higher
TPIDRURW, User Read/Write Thread ID Read/write at all privilege levels, including PL0
TPIDRURO, User Read-only Thread ID Read-only at PL0

Read/write at PL1 or higher
TPIDRPRW, PL1 only Thread ID Read/write only at PL1 or higher
a. For accesses to 32-bit registers. More correctly, this is the primary coprocessor register.
b. Any attempt to execute an access that is not permitted results in an Undefined Instruction exception.
c. Some bits are common to the Secure and the Non-secure copies of the register, see SCTLR, System Control Register,
VMSA on page B4-1700.
d. See ADFSR and AIFSR, Auxiliary Data and Instruction Fault Status Registers, VMSA on page B4-1519. Register is
e. Banked only in an implementation that includes the FCSE. The FCSE PID Register is RAZ/WI if the FCSE is not
implemented.
A Banked CP15 register can contain a mixture of:

• fields that are Banked
• fields that are read-only in Non-secure PL1 or PL2 modes but read/write in the Secure state.
The System Control Register SCTLR is an example of a register of that contains this mixture of fields.
The Secure copies of the Banked CP15 registers are sometimes referred to as the Secure Banked CP15 registers.
The Non-secure copies of the Banked CP15 registers are sometimes referred to as the Non-secure Banked CP15
registers.
Restricted access system control registers

In an implementation that includes the Security Extensions, some system control registers are present only in the
Secure security state. These are called Restricted access registers, and their read/write access permissions are:
• In Non-secure state, software cannot modify Restricted access registers.
• For the NSACR, in Non-secure state:

— software running at PL1 or higher can read the register
— unprivileged software, meaning software running at PL0, cannot read the register.
This means that Non-secure software running at PL1 or higher can read the access permissions for system
control registers that have Configurable access.
• For all other Restricted access registers, Non-secure software cannot read the register.
Table B3-34 shows the Restricted access CP15 registers in an implementation that includes the Security Extensions.
There are no Restricted access CP14 registers.
Table B3-34 Restricted access CP15 registers
CRn a Register Permitted accesses b
c1 SCR, Secure Configuration Read/write in Secure PL1 modes
SDER, Secure Debug Enable Read/write in Secure PL1 modes
NSACR, Non-Secure Access Control Read/write in Secure PL1 modes

Read-only in Non-secure PL1 and PL2 modes
c12 MVBAR, Monitor Vector Base Address Read/write in Secure PL1 modes
Configurable access system control registers

Secure software can configure the access to some system control registers. These registers are called Configurable
access registers, and the control can be:
• A bit in the control register determines whether the register is:

— accessible from Secure state only
— accessible from both Secure and Non-secure states.
• A bit in the control register changes the accessibility of a register bit or field. For example, setting a bit in the
control register might mean that a R/W field behaves as RAZ/WI when accessed from Non-secure state.
Bits in the NSACR control access.
In an ARMv7 implementation of the Security Extensions:

• there are no Configurable access CP14 registers
• the only required Configurable access CP15 register is the CPACR, Coprocessor Access Control Register
• the following registers in the CP10 and CP11 register space are Configurable access:
— Floating-point Status and Control Register, FPSCR
— Floating-point Exception register, FPEXC
— Floating-point System ID register, FPSID
— Media and VFP Feature Register 0, MVFR0
— Media and VFP Feature Register 1, MVFR1
— Floating-Point Instruction Registers, FPINST and FPINST2, if implemented.
PL2-mode system control registers

An implementation that includes both the Security Extensions and the Virtualization Extensions includes a number
of registers for use in the PL2 mode, Hyp mode. As with other system control register encodings, some of these
register encodings provide write-only operations. Secure software can access the register by moving to Monitor
mode and setting SCR.NS to 1, before accessing the register.
The following subsections describe the PL2-mode registers:

• Banked PL2-mode CP15 read/write registers
• PL2-mode encodings for shared CP15 registers on page B3-1451
• Banked PL2-mode CP15 write-only operations on page B3-1452.
There are no PL2-mode CP14 registers.
Banked PL2-mode CP15 read/write registers

Architecturally, these are an extension of the Banked registers described in Banked system control registers on
page B3-1448, where:
• the processor does not implement the Secure copy of the register
• the Non-secure copy of the register is accessible only at PL2, that is, only from Hyp mode.
Except for accesses to CNTVOFF in an implementation that includes the Security Extensions but not the
Virtualization Extensions, the behavior of accesses to these registers is as follows:
• in Secure state, the registers can be accessed from Monitor mode when SCR.NS is set to 1, see Access to
registers from Monitor mode on page B3-1455
• the following accesses are UNDEFINED:

— accesses from Non-secure PL1 modes
— accesses in Secure state when SCR.NS is set to 0.
In an implementation that includes the Security Extensions but not the Virtualization Extensions, the behavior of
accesses to CNTVOFF is as follows:
• any access from Secure Monitor mode is UNPREDICTABLE, regardless of the value of SCR.NS
• all other accesses are UNDEFINED.
Note
Except for CNTVOFF, the Banked PL2-mode registers are part of the Virtualization Extensions, meaning they are
implemented only if the implementation includes the Virtualization Extensions. However, conceptually, CNTVOFF
is part of any implementation that includes the Generic Timer Extension, see Status of the CNTVOFF register on
page B8-1955. This means the behavior of CNTVOFF in an implementation that includes the Generic Timer
Extension but does not include the Virtualization Extensions is not covered by the general definition of the behavior
of the Banked PL2-mode CP15 read/write registers.
Table B3-35 shows the PL2-mode CP15 read/write registers:
Table B3-35 Banked PL2-mode CP15 read/write registers
CRn or CRm a Register Width Permitted accesses b
c0 VPIDR 32-bit Read/write. In Non-secure state, accessible only from Hyp mode
VMPIDR 32-bit Read/write. In Non-secure state, accessible only from Hyp mode
c1 HSCTLR 32-bit Read/write. In Non-secure state, accessible only from Hyp mode
HACTLR 32-bit Read/write. In Non-secure state, accessible only from Hyp mode
HCR 32-bit Read/write. In Non-secure state, accessible only from Hyp mode
HDCR 32-bit Read/write. In Non-secure state, accessible only from Hyp mode
HCPTR 32-bit Read/write. In Non-secure state, accessible only from Hyp mode
HSTR 32-bit Read/write. In Non-secure state, accessible only from Hyp mode
HACR 32-bit Read/write. In Non-secure state, accessible only from Hyp mode
c2 HTCR 32-bit Read/write. In Non-secure state, accessible only from Hyp mode
VTCR 32-bit Read/write. In Non-secure state, accessible only from Hyp mode
HTTBR 64-bit Read/write. In Non-secure state, accessible only from Hyp mode
VTTBR 64-bit Read/write. In Non-secure state, accessible only from Hyp mode
c5 HADFSRc 32-bit Read/write. In Non-secure state, accessible only from Hyp mode
HAIFSRc 32-bit Read/write. In Non-secure state, accessible only from Hyp mode
HSR 32-bit Read/write. In Non-secure state, accessible only from Hyp mode
c6 HPFAR 32-bit Read/write. In Non-secure state, accessible only from Hyp mode
c10 HMAIR0 32-bit Read/write. In Non-secure state, accessible only from Hyp mode
HMAIR1 32-bit Read/write. In Non-secure state, accessible only from Hyp mode
HAMAIR0 32-bit Read/write. In Non-secure state, accessible only from Hyp mode
HAMAIR1 32-bit Read/write. In Non-secure state, accessible only from Hyp mode
c12 HVBAR 32-bit Read/write. In Non-secure state, accessible only from Hyp mode
c13 HTPIDR 32-bit Read/write. In Non-secure state, accessible only from Hyp mode
c14 CNTVOFF d 64-bit Read/write. In Non-secure state, accessible only from Hyp mode
a. CRn for accesses to 32-bit registers, CRm for accesses to 64-bit registers. More correctly, this is the primary coprocessor register.
c. See HADFSR and HAIFSR, Hyp Auxiliary Fault Syndrome Registers, Virtualization Extensions on page B4-1572
d. Implemented only in an implementation that includes the Generic Timer Extension. See, also, the Note earlier in this section.
PL2-mode encodings for shared CP15 registers
Some Hyp mode registers share the Secure copy of an existing Banked register. In this case the implementation
includes an encoding for the register that is accessible only in Hyp mode, or in Monitor mode when SCR.NS is set
to 1.
For these registers, the following accesses are UNDEFINED:

• Accesses from Non-secure PL1 modes.
• Accesses in Secure state when SCR.NS is set to 0.
Table B3-36 lists the PL2-mode encodings for shared registers.
Table B3-36 PL2-mode CP15 register encodings for shared registers
CRn a Register Permitted accesses b Shared register
c6 HDFAR Read/write. In Non-secure state, accessible only from Hyp mode c Secure DFAR
c6 HIFAR Read/write. In Non-secure state, accessible only from Hyp mode c Secure IFAR
c. Also accessible from Monitor mode when SCR.NS set to 1.
In Monitor mode, the Secure copies of these registers can be accessed either:
• using the DFAR or IFAR encoding with SCR.NS set to 0
• using the HDFAR or HIFAR encoding with SCR.NS set to 1.
However, between accessing a register using one alias and accessing the register using the other alias, a Context
synchronization operation is required to ensure the ordering of the accesses.
Banked PL2-mode CP15 write-only operations
Architecturally, these encodings are an extension of the Banked register encodings described in Banked system
control registers on page B3-1448, where:
• the processor does not implement the operation in Secure state
• in Non-secure state, the operation is accessible only at PL2, that is, only from Hyp mode.
In Secure state:
• these operations can be accessed from Monitor mode regardless of the value of SCR.NS, see Access to
registers from Monitor mode on page B3-1455
• accesses to these operations are UNPREDICTABLE if executed in a Secure mode other than Monitor mode.
Accesses to these operations are UNDEFINED if accessed from a Non-secure PL1 mode.
Table B3-37 on page B3-1453 shows the PL2-mode CP15 write-only operations:
Table B3-37 Banked PL2-mode CP15 write-only operations
CRn Register Width Permitted accesses a
c8 ATS1HR 32-bit Write-only. In Non-secure state, accessible only from Hyp mode
ATS1HW 32-bit Write-only. In Non-secure state, accessible only from Hyp mode
TLBIALLHIS 32-bit Write-only. In Non-secure state, accessible only from Hyp mode
TLBIMVAHIS 32-bit Write-only. In Non-secure state, accessible only from Hyp mode
TLBIALLNSNHIS 32-bit Write-only. In Non-secure state, accessible only from Hyp mode
TLBIALLH 32-bit Write-only. In Non-secure state, accessible only from Hyp mode
TLBIMVAH 32-bit Write-only. In Non-secure state, accessible only from Hyp mode
TLBIALLNSNH 32-bit Write-only. In Non-secure state, accessible only from Hyp mode
a. This section describes the behavior of write accesses that are not permitted. See also Read-only and write-only register encodings
on page B3-1445.
For more information about these operations, see:

• Address translation stage 1, Hyp mode on page B3-1436
• Hyp mode TLB maintenance operations, Virtualization Extensions on page B4-1741
Common system control registers

Some system control registers and operations are common to the Secure and Non-secure security states. These are
described as the Common access registers, or simply as the Common registers. These registers include:
• read-only registers that hold configuration information
• register encodings used for various memory system operations, rather than to access registers
• the ISR
• all CP14 registers.
Table B3-38 shows the Common CP15 system control registers in an ARMv7-A implementation that includes the
Security Extensions. These registers are not affected by the implementation of the Security Extensions.
Table B3-38 Common CP15 registers
c0 MIDR, Main ID Register Read-only, only at PL1 or higher
CTR, Cache Type Register Read-only, only at PL1 or higher
TCMTR, TCM Type Register c Read-only, only at PL1 or higher
TLBTR, TLB Type Register c Read-only, only at PL1 or higher
MPIDR, Multiprocessor Affinity Register Read-only, only at PL1 or higher
REVIDR, Revision ID Read-only, only at PL1 or higher
Table B3-38 Common CP15 registers (continued)
c0 ID_PFRx, Processor Feature Registers Read-only, only at PL1 or higher
ID_DFR0, Debug Feature Register 0 Read-only, only at PL1 or higher
ID_AFR0, Auxiliary Feature Register 0 Read-only, only at PL1 or higher
ID_MMFRx, Memory Model Feature Registers Read-only, only at PL1 or higher
ID_ISARx, Instruction Set Attribute Registers Read-only, only at PL1 or higher
CCSIDR, Cache Size ID Register Read-only, only at PL1 or higher
CLIDR, Cache Level ID Register Read-only, only at PL1 or higher
AIDR, Auxiliary ID Register c Read-only, only at PL1 or higher
c7 Cache maintenance operations See Cache maintenance operations, functional group, VMSA on
page B3-1491
Address translation operations See Address translation operations, functional group on page B3-1493
Data barrier operations Write-only at all privilege levels, including PL0
c8 TLB maintenance operations Write-only, only at PL1 or higher
c9 Performance monitors See Access permissions on page C12-2316
c12 ISR, Interrupt Status Register Read-only, only at PL1 or higher
c. Register or operation details are IMPLEMENTATION DEFINED.
Secure CP15 registers

The Secure CP15 registers comprise:
• The Secure copies of the Banked CP15 registers
• The Restricted access CP15 registers
• The Configurable access CP15 registers that are configured to be accessible only from Secure state.
In an implementation that includes the Security Extensions, the Non-secure CP15 registers are the CP15 registers
other than the Secure CP15 registers.
The CP15SDISABLE input

The Security Extensions include an input signal, CP15SDISABLE, that disables write access to some of the Secure
registers when asserted HIGH.
Note
The interaction between CP15SDISABLE and any IMPLEMENTATION DEFINED register is IMPLEMENTATION
DEFINED.
Table B3-39 on page B3-1455 shows the registers and operations affected.
Table B3-39 Secure registers affected by CP15SDISABLE
CRn Register name Affected operation
c1 SCTLR, System Control Register MCR p15, 0, <Rt>, c1, c0, 0
c2 TTBR0, Translation Table Base Register 0 MCR p15, 0, <Rt>, c2, c0, 0
TTBCR, Translation Table Base Control Register MCR p15, 0, <Rt>, c2, c0, 2
c3 DACR, Domain Access Control Register MCR p15, 0, <Rt>, c3, c0, 0
c10 PRRR. Primary Region Remap Register MCR p15, 0, <Rt>, c10, c2, 0
NMRR, Normal Memory Remap Register MCR p15, 0, <Rt>, c10, c2, 1
c12 VBAR, Vector Base Address Register MCR p15, 0, <Rt>, c12, c0, 0
MVBAR, Monitor Vector Base Address Register MCR p15, 0, <Rt>, c12, c0, 1
c13 FCSEIDR, FCSE PID Register a MCR p15, 0, <Rt>, c13, c0, 0
a. In an implementation that includes the FCSE. The FCSE PID Register is RAZ/WI if the FCSE is not implemented.
On a reset by the external system, the CP15SDISABLE input signal must be taken LOW. This permits the Reset
code to set up the configuration of the Security Extensions. When the input is asserted HIGH, any attempt to write
to the Secure registers shown in Table B3-39 results in an Undefined Instruction exception.
The CP15SDISABLE input does not affect reading Secure registers, or reading or writing Non-secure registers. It
is IMPLEMENTATION DEFINED how the input is changed and when changes to this input are reflected in the processor,
and an implementation might not provide any mechanism for driving the CP15SDISABLE input HIGH. However,
in an implementation in which the CP15SDISABLE input can be driven HIGH, changes in the state of
CP15SDISABLE must be reflected as quickly as possible. Any change must occur before completion of a
Instruction Synchronization Barrier operation, issued after the change, is visible to the processor with respect to
instruction execution boundaries. Software must perform a Instruction Synchronization Barrier operation meeting
the above conditions to ensure all subsequent instructions are affected by the change to CP15SDISABLE.
Use of CP15SDISABLE means key Secure features that are accessible only at PL1 can be locked in a known good
state. This provides an additional level of overall system security. ARM expects control of CP15SDISABLE to
reside in the system, in a block dedicated to security.
Access to registers from Monitor mode

When the processor is in Monitor mode, the processor is in Secure state regardless of the value of the SCR.NS bit.
In Monitor mode, the SCR.NS bit determines whether valid uses of the MRC, MCR, MRRC and MCRR instructions access
the Secure Banked CP15 registers or the Non-secure Banked CP15 registers. That is, when:
NS == 0 Common, Restricted access, and Secure Banked registers are accessed by CP15 MRC, MCR, MRRC and
MCRR instructions.
If the implementation includes the Virtualization Extensions, the registers listed in Banked
PL2-mode CP15 read/write registers on page B3-1450 and PL2-mode encodings for shared CP15
registers on page B3-1451 are not accessible, and any attempt to access them generates an
Undefined Instruction exception.
Note
The operations listed in Banked PL2-mode CP15 write-only operations on page B3-1452 are
accessible in Monitor mode regardless of the value of SCR.NS.
CP15 operations use the security state to determine all resources used, that is, all CP15-based
operations are performed in Secure state.
NS == 1 Common, Restricted access and Non-secure Banked registers are accessed by CP15 MRC, MCR, MRRC
and MCRR instructions.
If the implementation includes the Virtualization Extensions, all the registers and operations listed
in the subsections of PL2-mode system control registers on page B3-1450 are accessible, using the
MRC, MCR, MRRC, or MCRR instructions required to access them from Hyp mode.
CP15 operations use the security state to determine all resources used, that is, all CP15-based
operations are performed in Secure state.
The security state determines whether the Secure or Non-secure Banked registers determine the control state.
Note
Where the contents of a register select the value accessed by an MRC or MCR access to a different register, then the
register that is used for selection is being used as control state. For example, CSSELR selects the current CCSIDR,
and therefore CSSELR is used as control state. Therefore, in Monitor mode:
• SCR.NS determines whether the Secure or Non-secure CSSELR is accessible
• because the processor is in Secure state, the Secure CSSELR selects the current CCSIDR.
B3.15.4 Effect of the LPAE and Virtualization Extensions on the system control registers
The Large Physical Address Extension (LPAE) adds:
• two reserved CP15 encodings, for applying IMPLEMENTATION DEFINED memory attributes, AMAIR0 and
AMAIR1.
• 64-bit encodings of the TTBR0, TTBR1, and PAR
• 64-bit encodings of the DBGDRAR and DBGDSAR.
The Virtualization Extensions add:
• the CP15 registers and operations summarized in Virtualization Extensions registers, functional group on
page B3-1496.
• the PMOVSSET register
• the DBGBXVRs.
B3.15.5 Synchronization of changes to system control registers

In this section, this processor means the processor on which accesses are being synchronized.
Note
See Definitions of direct and indirect reads and writes and their side-effects on page B3-1460 for definitions of the
terms direct write, direct read, indirect write, and indirect read.
A direct write to a system control register might become visible at any point after the change to the register, but
without a Context synchronization operation there is no guarantee that the change becomes visible.
Any direct write to a system control register is guaranteed not to affect any instruction that appears, in program
order, before the instruction that performed the direct write, and any direct write to a system control register must
be synchronized before any instruction that appears after the direct write, in program order, can rely on the effect of
that write. The only exceptions to this are:
• All direct writes to the same register, using the same encoding, are guaranteed to occur in program order.
• All direct writes to a register are guaranteed to occur in program order relative to all direct reads of the same
register using the same encoding.
• If an instruction that appears in program order before the direct write performs a memory access, such as a
memory-mapped register access, that causes an indirect read or write to a register, that memory access is
subject to the ARM ordering model. In this case, if permitted by the ARM ordering model, the instruction
that appears in program order before the direct write can be affected by the direct write.
These rules mean that an instruction that writes to one of the address translation operations described in Virtual
Address to Physical Address translation operations on page B3-1434 must be explicitly synchronized to guarantee
that the result of the address translation operation is visible in the PAR.
Note
In this case, the direct write to the encoding of the address translation operation causes an indirect write to the PAR.
Without a Context synchronization operation after the direct write there is no guarantee that the indirect write to the
PAR is visible.
Conceptually, the explicit synchronization occurs as the first step of any Context synchronization operation. This
means that if the operation uses state that had been changed but not synchronized before the operation occurred, the
operation is guaranteed to use the state as if it had been synchronized.
Note
• This explicit synchronization is applied as the first step of the execution of any instruction that causes the
operation. This means it does not synchronize any effect of system registers that might affect the fetch and
decode of the instructions that cause the operation, such as breakpoints or changes to translation tables.
• For a synchronous exception, the control state in use at the time the exception is generated determines the
exception syndrome information, and this syndrome information is not changed by this synchronization at
the start of taking the exception.
Except for the register reads listed in Registers with some architectural guarantee of ordering or observability on
page B3-1459, if no context synchronization operation is performed, direct reads of system control registers can
occur in any order.
Table B3-40 on page B3-1458 shows the synchronization requirement between two reads or writes that access the
same system control register. In the column headings, First and Second refer to:
• Program order, for any read or write caused by the execution of an instruction by this processor, other than a
read or write caused by a memory access made by that instruction.
• The order of arrival of asynchronous reads or writes made by this processor relative to the execution of
instructions by this processor.
In addition:
• For indirect reads or writes caused by an external agent, such as a debugger, the mechanism that determines
the order of the reads or writes is defined by that external agent. The external agent can provide mechanisms
that ensure that any reads or writes it makes arrive at the processor. These indirect reads and writes are
asynchronous to software execution on the processor.
• For indirect reads or writes caused by memory-mapped reads or writes made by this processor, the ordering
of the memory accesses is subject to the memory order model, including the effect of the memory type of the
accessed memory address. This applies, for example, if this processor reads or writes one of its registers in a
memory-mapped register interface.
The mechanism for ensuring completion of these memory accesses, including ensuring the arrival of the
asynchronous read or write at the processor, is defined by the system.
Note
Such accesses are likely to be given the Device or Strongly-ordered attribute, but requiring this is outside the
scope of the processor architecture.
• For indirect reads or writes caused by autonomous asynchronous events that count, for example events
caused by the passage of time, the events are ordered so that:
— Counts progress monotonically.
— The events arrive at the processor in finite time and without undue delay.
Table B3-40 Synchronization requirements for updates to system control registers
First read or write Second read or write Context synchronization operation required
Direct read Direct read No
Direct write No
Indirect read No a
Indirect write No a, but see text in this section for exceptions
Direct write Direct read No
Direct write No
Indirect read Yes a
Indirect write No, but see text in this section for exceptions
Indirect read Direct read No
Direct write No
Indirect read No
Indirect write No
Indirect write Direct read Yes, but see text in this section for exceptions
Direct write No, but see text in this section for exceptions
Indirect read Yes, but see text in this section for exceptions
Indirect write No, but see text in this section for exceptions
a. Although no synchronization is required between a Direct write and a Direct read, or between a Direct read and an
Indirect write, this does not imply that a Direct read causes synchronization of a previous Direct write. This means
that the sequence Direct write followed by Direct read followed by Indirect read, with no intervening context
synchronization, does not guarantee that the Indirect read observes the result of the Direct write.
If the indirect write is to a register that Registers with some architectural guarantee of ordering or observability
shows as having some guarantee of the visibility of an indirect writes, synchronization might not be required.
If a direct read or a direct write to a register is followed by an indirect write to that register that is caused by an
external agent, or by an autonomous asynchronous event, or as a result of a memory-mapped write, then
synchronization is required to guarantee the ordering of the indirect write relative to the direct read or direct write.
If an indirect write caused by a direct write is followed by an indirect write caused by an external agent, or by an
autonomous asynchronous event, or as a result of a memory-mapped write, then synchronization is required to
guarantee the ordering of the two indirect writes.
If a direct read causes an indirect write, synchronization is required to guarantee that the indirect write is visible to
subsequent direct or indirect reads or writes. This synchronization must be performed after the direct read, before
the subsequent direct or indirect reads or writes.
If a direct write causes an indirect write, synchronization is required to guarantee that the indirect write is visible to
subsequent direct or indirect reads or writes. This synchronization must be performed after the direct write, before
the subsequent direct or indirect reads or writes.
Note
Where a register has more that one encoding, a direct write to the register using a particular encoding is not an
indirect write to the same register with a different encoding.
Where an indirect write is caused by the action of an external agent, such as a debugger, or by a memory-mapped
read or write by the processor, then an indirect write by that agent to a register using a particular access mechanism,
followed by an indirect read by that agent to the same register using the same access mechanism and address does
not need synchronization.
For information about the additional synchronization requirements for memory-mapped registers, see
Synchronization requirements for memory-mapped register interfaces on page C6-2103.
To guarantee the visibility of changes to some registers, additional operations might be required before the context
synchronization operation. For such a register, the definition of the register identifies these additional requirements.
In this manual, unless the context indicates otherwise:

• Accessing a system control register refers to a direct read or write of the register.
• Using a system control register refers to an indirect read or write of the register.
Registers with some architectural guarantee of ordering or observability

For the registers for which Table B3-41 shows that the ordering of direct reads is guaranteed, multiple direct reads
of a single register, using the same encoding, occur in program order without any explicit ordering.
For the registers for which Table B3-41 shows that some observability of indirect writes is guaranteed, an indirect
write to the register caused by an external agent, an autonomous asynchronous events, or as a result of a memory
mapped write, is both:
• Observable to direct reads of the register, in finite time, without explicit synchronization.
• Observable to subsequent indirect reads of the register without explicit synchronization.
These two sets of registers are similar, as Table B3-41 shows:
Table B3-41 Registers with a guarantee of ordering or observability, in a VMSA implementation
Register Ordering of direct reads Observability of indirect writes Notes
ISR Guaranteed Guaranteed Interrupt Status Register
DBGCLAIMCLR Guaranteed Guaranteed Debug claim registers
DBGCLAIMSET - Guaranteed
Table B3-41 Registers with a guarantee of ordering or observability, in a VMSA implementation (continued)
Register Ordering of direct reads Observability of indirect writes Notes
DBGDTRRX Guaranteed Guaranteed Debug Communication Channel

registers
DBGDTRTX Guaranteed Guaranteed
CNTPCT Guaranteed Guaranteed Generic Timer Extension registers, if

the implementation includes the
CNTP_TVAL Guaranteed Guaranteed extension
CNTVCT Guaranteed Guaranteed
CNTV_TVAL Guaranteed Guaranteed
CNTHP_TVAL Guaranteed Guaranteed
PMCCNTR Guaranteed Guaranteed Performance Monitors Extension

registers, if the implementation includes
PMXEVCNTR Guaranteed Guaranteed the extension
PMOVSSET Guaranteed Guaranteed
For the specified registers, the observability requirement is more demanding than the observability requirements for
other registers. However, the possibility that direct reads can occur early, in the absence of context synchronization,
described in Ordering of reads of system control registers on page B3-1441, still applies to these registers.
In Debug state, additional synchronization requirements can apply to the registers shown in Table B3-41 on
page B3-1459. For more information, see:
• Synchronization of accesses to the Debug Communications Channel on page C6-2103.
• Synchronization of accesses to the DCC and the DBGITR on page C8-2164.
Definitions of direct and indirect reads and writes and their side-effects
Direct and indirect reads and writes are defined as follows:
Direct read Is a read of a register, using an MRC, MRC2, MRRC, MRRC2, LDC, or LDC2 instruction, that the architecture
permits for the current processor state.
If a direct read of a register has a side-effect of changing the value of a register, the effect of a direct
read on that register is defined to be an indirect write, and has the synchronization requirements of
an indirect write. This means the indirect write is guaranteed to have occurred, and to be visible to
subsequent direct or indirect reads and writes only if synchronization is performed after the direct
read.
Note
The indirect write described here can affect either the register written to by the direct write, or some
other register. The synchronization requirement is the same in both cases.
Direct write Is a write to a register, using an MCR, MCR2, MCRR, MCRR2, STC, or STC2 instruction, that the architecture
permits for the current processor state.
In the following cases, the side-effect of the direct write is defined to be an indirect write of the
affected register, and has the synchronization requirements of an indirect write:
• If the direct write has a side-effect of changing the value of a register other than the register
accessed by the direct write.
• If the direct write has a side-effect of changing the value of the register accessed by the direct
write, so that the value in that register might not be the value that the direct write wrote to the
register.
In both cases, this means that the indirect write is not guaranteed to be visible to subsequent direct
or indirect reads and writes unless synchronization is performed after the direct write.
Note
• As an example of a direct write to a register having an effect that is an indirect write of that
register, writing 1 to a PMCNTENCLR.Px bit is also an indirect write, because if the Px bit
had the value 1 before the direct write, the side-effect of the write changes the value of that
bit to 0.
• The indirect write described here can affect either the register written to by the direct write,
or some other register. The synchronization requirement is the same in both cases.
For example, writing 1 to a PMCNTENCLR.Px bit that is set to 1 also changes the
corresponding PMCNTENSET.Px bit from 1 to 0. This means that the direct write to the
PMCNTENCLR defines indirect writes to both itself and to the PMCNTENSET.
Indirect read Is a use of the register by an instruction to establish the operating conditions for the instruction.
Examples of operating conditions that might be determined by an indirect read are the translation
table base address, or whether a cache is enabled.
Indirect reads include situations where the value of one register determines what value is returned
by a second register. This means that any read of the second register is an indirect read of the register
that determines what value is returned.
Indirect reads also include:
• Reads of the system control registers by external agents, such as debuggers, as described in
Chapter C6 Debug Register Interfaces.
• Memory-mapped reads of the system control registers made by the processor that implements
the system control registers.
Where an indirect read of a register has a side-effect of changing the value of a register, that change
is defined to be an indirect write, and has the synchronization requirements of an indirect write.
Indirect write Is an update to the value of a register as a consequence of either:

• An exception, operation, or execution of an instruction that is not a direct write to that
register.
• The asynchronous operation of some external agent.
This can include:
• The passage of time, as seen in counters or timers, including performance counters.
• The assertion of an interrupt.
• A write from an external agent, such as a debugger.
However, for some registers, the architecture gives some guarantee of visibility without any explicit
synchronization, see Registers with some architectural guarantee of ordering or observability on
page B3-1459.
Note
Taking an exception is a context-synchronizing operation. Therefore, any indirect write performed
as part of an exception entry does not require additional synchronization. This includes the indirect
writes to the registers that report the exception, as described in Exception reporting in a VMSA
implementation on page B3-1406.
B3.15.6 Meaning of fixed bit values in register bit assignment diagrams

In register bit assignment diagrams, fixed bits are indicated by one of following:
0 In any implementation:
• the bit must read as 0
• writes to the bit must be ignored
• software:
— can rely on the bit reading as 0
— must use an SBZP policy to write to the bit.
(0) The Large Physical Address Extension creates a small number of cases where a bit is (0) in some
contexts, and has a different defined behavior in other contexts. The meaning of (0) is modified for
these bits. For a read/write register, this means:
If a register bit is (0) for all uses of the register
• software:
— must not rely on the bit reading as 0
Note
This definition applies to all bits marked as (0) in an implementation that does not
include the Large Physical Address Extension.
If a register bit is (0) only for some uses of the register, when that bit is described as (0)
• A read of the bit must return the value last successfully written to the bit,
regardless of the use of the register when the bit was written.
If the bit has not been successfully written since reset, then the read of the bit
returns the reset value if there is one, or otherwise returns an UNKNOWN value.
• A Direct write to the bit must update a storage location associated with the bit.
• An Indirect write to the register sets the bit to 0.
• While the use of the register is such that the bit is described as (0), or as
UNK/SBZP, the value of the bit must have no effect on the operation of the
processor, other than determining the value read back from that bit.
• Software:
Note
This definition applies only to bits that are defined as (0), or as UNK/SBZP, for one use
of a register, and are defined differently for another use of the register.
Fields that are more than one bit wide are sometimes described as UNK/SBZP, instead of having
each bit marked as (0).
In a read-only register, (0) indicates that the bit reads as 0, but software must treat the bit as UNK.
In a write-only register, (0) indicates that software must treat the bit as SBZ.
1 In any implementation:
• writes to the bit must be ignored.
• software:
— can rely on the bit reading as 1
— must use an SBOP policy to write to the bit.
(1) The Large Physical Address Extension creates a small number of cases where a bit is (1) in some
contexts, and has a different defined behavior in other contexts. The meaning of (1) is modified for
these bits. For a read/write register, this means:
If a register bit is (1) for all uses of the register
• software:
Note
This definition applies to all bits marked as (1) in an implementation that does not
include the Large Physical Address Extension.
If a register bit is (1) only for some uses of the register, when that bit is described as (1)
• A read of the bit must return the value last successfully written to the bit,
regardless of the use of the register when the bit was written.
If the bit has not been successfully written since reset, then the read of the bit
returns the reset value if there is one, or otherwise returns an UNKNOWN value.
• A Direct write to the bit must update a storage location associated with the bit.
• An Indirect write to the register sets the bit to 1.
• While the use of the register is such that the bit is described as (1), or as
UNK/SBOP, the value of the bit must have no effect on the operation of the
processor, other than determining the value read back from that bit.
• Software:
Note
This definition applies only to bits that are defined as (1), or as UNK/SBOP, for one use
of a register, and are defined differently for another use of the register.
Fields that are more than one bit wide are sometimes described as UNK/SBOP, instead of having
each bit marked as (1).
In a read-only register, (1) indicates that the bit reads as 1, but software must treat the bit as UNK.
In a write-only register, (1) indicates that software must treat the bit as SBO.
B3.16 Organization of the CP14 registers in a VMSA implementation

The CP14 registers provide a number of distinct control functions, covering:
• Debug
• Trace
• Execution environment control, for the Jazelle and ThumbEE execution environments.
Because these functions are so distinct, the descriptions of these registers are distributed, as follows:
• in this manual:
— Chapter C11 The Debug Registers describes the Debug registers
— ThumbEE configuration on page A2-94 summarizes the ThumbEE registers
— Application level configuration and control of the Jazelle extension on page A2-98 summarizes the
Jazelle registers
• the following ARM trace architecture specifications describe the Trace registers:
— Embedded Trace Macrocell Architecture Specification
— CoreSight Program Flow Trace Architecture Specification.
This section summarizes the allocation of the CP14 registers between these different functions, and the CP14
register encodings that are reserved.
The CP14 register encodings are classified by the {CRn, opc1, CRm, opc2} values required to access them using
an MCR or an MRC instruction. The opc1 value determines the primary allocation of these registers, as follows:
opc1==0 Debug registers.
opc1==1 Trace registers.
opc1==6 ThumbEE registers.
opc1==7 Jazelle registers. Can include Jazelle SUBARCHITECTURE DEFINED registers.
Other opc1 values
Reserved.
Note
Primary allocation of CP14 register function by opc1 value differs from the allocation of CP15 registers, where
primary allocation is by CRn value.
For the Debug registers, considering accesses using MCR or MCR instructions:
• Register encodings with CRn values 8-15 are unallocated.
• For registers with CRn values 0-7, the {CRn, opc2, CRm} values used for accessing the registers map onto
a set of register numbers, as defined in Using CP14 to access debug registers on page C6-2109. These
register numbers define the order of the registers in:
— the memory-mapped interfaces to the registers
— the top-level register summary in Debug register summary on page C11-2181.
Note
Some Debug registers are not visible in some of the Debug register interfaces. For more information see Chapter C6
Debug Register Interfaces.
The ARM trace architectures use the same mapping of {CRn, opc2, CRm} values to register numbers for the Trace
registers. The associated opc1 value determines whether a particular CP14 register number refers to the Trace
register or the Debug register.

Previous documentation has described the CP15 registers in order of their primary coprocessor register number.
More precisely, the ordered set of values {CRn, opc1, CRm, opc2} determined the register order. As the number of
system control registers has increased this ordering has become less appropriate. Also, it applies only to 32-bit
registers, since 64-bit registers are identified only by {CRm, opc1}, making it difficult to include 32-bit and 64-bit
versions of a single register in a common ordering scheme.
This document now:
• Groups the CP15 registers by functional group. For more information about this grouping in a VMSA
implementation, including a summary of each functional group, see Functional grouping of VMSAv7 system
control registers on page B3-1486.
• Describes all of the system control registers for a VMSA implementation, including the CP15 registers, in
Chapter B4 System Control Registers in a VMSA implementation. The description of each register is in the
section VMSA System control registers descriptions, in register order on page B4-1518.
This section gives additional information about the organization of the CP15 registers in a VMSA implementation,
as follows:
Register ordering by {CRn, opc1, CRm, opc2}

See:
• CP15 register summary by coprocessor register number
• Full list of VMSA CP15 registers, by coprocessor register number on page B3-1475.
Note
The ordered listing of CP15 registers by the {CRn, opc1, CRm, opc2} encoding of the 32-bit
registers is most likely to be useful to those implementing ARMv7 processors, and to those
validating such implementations. However, otherwise, the grouping of registers by function is more
logical.
Views of the registers, that depend on the current state of the processor
See Views of the CP15 registers on page B3-1483.
Note
The different register views are particularly significant in implementations that include the
In addition, the indexes in Appendix D18 Registers Index include all of the CP15 registers.
Note
ARMv7 introduced significant changes to the memory system registers, especially in relation to caches. For more
information about:
• how the ARMv7 registers must be used for discovering what caches can be accessed by the processor, see
Identifying the cache resources in ARMv7 on page B2-1265.
• the CP15 register implementation in VMSAv6, see Organization of CP15 registers for an ARMv6 VMSA
implementation on page D12-2510
B3.17.1 CP15 register summary by coprocessor register number

Figure B3-26 on page B3-1466 summarizes the grouping of CP15 registers by primary coprocessor register number
for a VMSAv7 implementation.
CRn opc1 CRm opc2

c0 {0-2} {c0-c7} {0-7} ¶ ID registers
c1 {0, 4} {c0, c1} {0-7} System control registers
c2 {0, 4} {c0, c1} {0-2} Memory protection and
c3 0 c0 0 control registers
c5 {0, 4} {c0,c1} {0,1} Memory system
c6 {0, 4} c0 {0, 2, 4} fault registers
c7 {0, 4} Various Various ¶ Cache maintenance, address translations, miscellaneous
c8 {0, 4} Various Various TLB maintenance operations
c9 {0-7} Various {0-7} ¶ Reserved for performance monitors and maintenance operations
c10 {0-7} Various {0-7} ¶ Memory mapping registers and TLB operations
c11 {0-7} {c0-c8,c15} {0-7} ¶ Reserved for DMA operations for TCM access
c12 {0, 4} {c0,c1} {0,1} ¶ Security Extensions registers, if implemented
c13 {0, 4} c0 {0-4} ¶ Process, context, and thread ID registers
c14 {0-7} {c0-c15} {0-7} ¶ Generic Timer registers, if implemented
c15 {0-7} {c0-c15} {0-7} ¶ IMPLEMENTATION DEFINED registers
Read-only Read/Write Write-only ¶ Access depends on the implementation
Figure B3-26 CP15 register grouping by primary coprocessor register, CRn, VMSA implementation
Note
Figure B3-26 gives only an overview of the assigned encodings for each of the CP15 primary registers c0-c15. See
the description of each primary register for the definition of the assigned and unassigned encodings for that register,
including any dependencies on whether the implementation includes architectural extensions.
The following sections give the register assignments for each of the CP15 primary registers, c0-c15:
• VMSA CP15 c0 register summary, identification registers
• VMSA CP15 c1 register summary, system control registers on page B3-1468
• VMSA CP15 c2 and c3 register summary, Memory protection and control registers on page B3-1469
• CP15 c4, Not used on page B3-1469
• VMSA CP15 c5 and c6 register summary, Memory system fault registers on page B3-1470
• VMSA CP15 c7 register summary, Cache maintenance, address translation, and other functions on
page B3-1470
• VMSA CP15 c8 register summary, TLB maintenance operations on page B3-1472
• VMSA CP15 c9 register summary, reserved for cache and TCM control and performance monitors on
page B3-1472
• VMSA CP15 c10 register summary, memory remapping and TLB control registers on page B3-1473
• VMSA CP15 c11 register summary, reserved for TCM DMA registers on page B3-1473
• VMSA CP15 c12 register summary, Security Extensions registers on page B3-1474
• VMSA CP15 c13 register summary, Process, context and thread ID registers on page B3-1474
• VMSA CP15 c14, reserved for Generic Timer Extension on page B3-1474
• VMSA CP15 c15 register summary, IMPLEMENTATION DEFINED registers on page B3-1475.
VMSA CP15 c0 register summary, identification registers

The CP15 c0 registers provide processor and feature identification. Figure B3-27 on page B3-1467 shows the CP15
c0 registers in a VMSA implementation.
CRn opc1 CRm opc2

c0 0 c0 0 MIDR, Main ID Register
1 CTR, Cache Type Register
2 TCMTR, TCM Type Register, details IMPLEMENTATION DEFINED
3 TLBTR, TLB Type Register, details IMPLEMENTATION DEFINED
{4,7} Aliases of MIDR
5 MPIDR, Multiprocessor Affinity Register
6 REVIDR, Revision ID Register ª
c1 0 ID_PFR0, Processor Feature Register 0 *
1 ID_PFR1, Processor Feature Register 1 *
2 ID_DFR0, Debug Feature Register 0 *
3 ID_AFR0, Auxiliary Feature Register 0 *
4 ID_MMFR0, Memory Model Feature Register 0 *
c2 0 ID_ISAR0, ISA Feature Register 0 *
1 ID_ISAR1, ISA Feature Register 1 *
{6,7} Read-As-Zero
{c3-c7} {0-7} Read-As-Zero
1 c0 0 CCSIDR, Cache Size ID Registers
1 CLIDR, Cache Level ID Register
7 AIDR, Auxiliary ID Register IMPLEMENTATION DEFINED
2 c0 0 CSSELR, Cache Size Selection Register
4 c0 0 VPIDR, Virtualization Processor ID Register ‡
5 VMPIDR, Virtualization Multiprocessor ID Register ‡
Read-only Read/Write Write-only * CPUID registers
ª Optional register. If not implemented, the encoding is an alias of the MIDR.
‡ Implemented only as part of the Virtualization Extensions.
Figure B3-27 CP15 c0 registers in a VMSA implementation
CP15 c0 register encodings not shown in Figure B3-27, and encodings that are part of an unimplemented
architectural extension, are UNPREDICTABLE, see Accesses to unallocated CP14 and CP15 encodings on
page B3-1443.
Note
• Chapter B7 The CPUID Identification Scheme describes the CPUID registers shown in Figure B3-27.
• The CPUID scheme includes information about the implementation of the OPTIONAL Floating-point and
Advanced SIMD architecture extensions. See Advanced SIMD and Floating-point Extensions on page A2-54
for a summary of the implementation options for these features.
VMSA CP15 c1 register summary, system control registers

The CP15 c1 registers provide system control. Figure B3-28 shows the CP15 c1 registers in a VMSA
implementation.
CRn opc1 CRm opc2

c1 0 c0 0 SCTLR, System Control Register
1 ACTLR, Auxiliary Control Register, IMPLEMENTATION DEFINED
2 CPACR, Coprocessor Access Control Register
c1 0 SCR, Secure Configuration Register †
1 SDER, Secure Debug Enable Register †
2 NSACR, Non-Secure Access Control Register †
4 c0 0 HSCTLR, Hyp System Control Register ‡
1 HACTLR, Hyp Auxiliary Control Register, IMPLEMENTATION DEFINED ‡
c1 0 HCR, Hyp Configuration Register ‡
1 HDCR, Hyp Debug Configuration Register ‡
2 HCPTR, Hyp Coprocessor Trap Register ‡
3 HSTR, Hyp System Trap Register ‡
7 HACR, Hyp Auxiliary Configuration Register, IMPLEMENTATION DEFINED ‡
Read-only Read/Write Write-only
† Implemented only as part of the Security Extensions
‡ Implemented only as part of the Virtualization Extensions
architectural extension, are UNPREDICTABLE. For more information, see Accesses to unallocated CP14 and CP15
encodings on page B3-1443.
VMSA CP15 c2 and c3 register summary, Memory protection and control registers
On an ARMv7-A implementation, the CP15 c2 and c3 registers provide memory protection and control.
Figure B3-29 shows the 32-bit registers in CP15 primary registers c2 and c3.
CRn opc1 CRm opc2

c2 0 c0 0 TTBR0, Translation Table Base Register 0
1 TTBR1, Translation Table Base Register 1
2 TTBCR, Translation Table Base Control Register
4 c0 2 HTCR, Hyp Translation Control Register ‡
c1 2 VTCR, Virtualization Translation Control Register ‡
c3 0 c0 0 DACR, Domain Access Control Register
Figure B3-29 CP15 32-bit c2 and c3 registers
CP15 c2 and c3 32-bit register encodings not shown in Figure B3-29, and encodings that are part of an
unimplemented architectural extension, are UNPREDICTABLE, see Accesses to unallocated CP14 and CP15
On an ARMv7-A implementation that includes the Large Physical Address Extension or Virtualization Extensions,
the CP15 c2 register includes some 64-bit system control registers. Figure B3-29 shows these registers.
CRm opc1
c2 0 TTBR0, Translation Table Base Register 0 §
1 TTBR1, Translation Table Base Register 1 §
4 HTTBR, Hyp Translation Table Base Register ‡
6 VTTBR, Virtualization Translation Table Base Register ‡
§ Implemented only as part of the Large Physical Address Extension
Figure B3-30 CP15 64-bit c2 registers
CP15 c2 64-bit register encodings not shown in Figure B3-30 are UNPREDICTABLE, and the allocations shown in
Figure B3-30 are UNPREDICTABLE when the Virtualization Extensions are not implemented. For more information,
see Accesses to unallocated CP14 and CP15 encodings on page B3-1443.
CP15 c4, Not used

CP15 c4 is not used on any ARMv7 implementation, see Accesses to unallocated CP14 and CP15 encodings on
page B3-1443.
VMSA CP15 c5 and c6 register summary, Memory system fault registers

The CP15 c5 and c6 registers provide memory system fault reporting. Figure B3-31 shows the CP15 c5 and c6
registers in a VMSA implementation.
CRn opc1 CRm opc2

c5 0 c0 0 DFSR, Data Fault Status Register
1 IFSR, Instruction Fault Status Register
c1 0 ADFSR, Auxiliary DFSR
1 AIFSR, Auxiliary IFSR Details are
IMPLEMENTATION
4 c1 0 HADFSR, Hyp Auxiliary DFSR ‡ DEFINED
1 HAIFSR, Hyp Auxiliary IFSR ‡
c2 0 HSR, Hyp Syndrome Register ‡
c6 0 c0 0 DFAR, Data Fault Address Register
2 IFAR, Instruction Fault Address Register
4 c0 0 HDFAR, Hyp Data Fault Address Register ‡
2 HIFAR, Hyp Instruction Fault Address Register ‡
4 HPFAR, Hyp IPA Fault Address Register ‡
Figure B3-31 CP15 c5 and c6 registers in a VMSA implementation
CP15 c5 and c6 register encodings not shown in Figure B3-31, and encodings that are part of an unimplemented
page B3-1443.
VMSA CP15 c7 register summary, Cache maintenance, address translation, and other
functions
On an ARMv7-A implementation, the CP15 c7 registers provide cache maintenance operations, address translation
operations, and CP15 versions of the memory barrier operations. Figure B3-32 on page B3-1471 shows the CP15
c7 registers.
CRn opc1 CRm opc2

c7 0 c0 4 UNPREDICTABLE, was Wait For Interrupt (CP15WFI) in ARMv6
c1 0 ICIALLUIS, Invalidate all instruction caches to PoU Inner Shareable ø
6 BPIALLIS, Invalidate all branch predictors Inner Shareable ø
c4 0 PAR, Physical Address Register
c5 0 ICIALLU, Invalidate all instruction caches to PoU
1 ICIMVAU, Invalidate instruction caches by MVA to PoU
4 CP15ISB, Instruction Synchronization Barrier operation
6 BPIALL, Invalidate all branch predictors
7 BPIMVA, Invalidate MVA from branch predictors
c6 1 DCIMVAC, Invalidate data* cache line by MVA to PoC
2 DCISW, Invalidate data* cache line by set/way
c8 0 ATS1CPR, PL1 read translation
1 ATS1CPW, PL1 write translation Stage 1
translation,
2 ATS1CUR, unprivileged read translation current state
3 ATS1CUW, unprivileged write translation
4 ATS12NSOPR, PL1 read translation †
5 ATS12NSOPW, PL1 write translation † Stage 1 and 2
translation,
6 ATS12NSOUR, unprivileged read translation † Non-secure state
7 ATS12NSOUW, unprivileged write translation †
c10 1 DCCMVAC, Clean data* cache line by MVA to PoC
2 DCCSW, Clean data* cache line by set/way
4 CP15DSB, Data Synchronization Barrier operation
5 CP15DMB, Data Memory Barrier operation
c11 1 DCCMVAU, Clean data* cache line by MVA to PoU
c13 1 UNPREDICTABLE, was Prefetch instruction by MVA in ARMv6
c14 1 DCCIMVAC, Clean and invalidate data* cache line by MVA to PoC
2 DCCISW, Clean and invalidate data* cache line by set/way
4 c8 0 ATS1HR, Hyp mode read translation ‡
1 ATS1HW, Hyp mode write translation ‡
Read-only Read/Write Write-only Bold text = Accessible At PL0
*
data or unified PoU: Point of Unification PoC: Point of Coherency
ø Introduced as part of the Multiprocessing Extensions
Figure B3-32 CP15 32-bit c7 registers in a VMSA implementation

page B3-1443.
Note
Figure B3-32 shows only those UNPREDICTABLE CP15 c7 encodings that had defined functions in ARMv6.
On an ARMv7-A implementation that includes the Large Physical Address Extension, the CP15 c7 register includes
a 64-bit implementation of the PAR, as Figure B3-33 shows.
CRm opc1
c7 0 PAR, Physical Address Register §
Figure B3-33 CP15 64-bit c7 registers
CP15 c7 64-bit register encodings not shown in Figure B3-33 on page B3-1471 are UNPREDICTABLE, and the
allocations shown in Figure B3-33 on page B3-1471 are UNPREDICTABLE when the Large Physical Address
Extension is not implemented. For more information, see Accesses to unallocated CP14 and CP15 encodings on
page B3-1443.
VMSA CP15 c8 register summary, TLB maintenance operations

On an ARMv7-A implementation, the CP15 c8 registers provide TLB maintenance functions. Figure B3-34 shows
the CP15 c8 registers.
CRn opc1 CRm opc2

c8 0 c3 0 TLBIALLIS, Invalidate entire TLB IS* ø
1 TLBIMVAIS, Invalidate unified TLB entry by MVA and ASID IS* ø
2 TLBIASIDIS, Invalidate unified TLB by ASID match IS* ø
3 TLBIMVAAIS, Invalidate unified TLB entry by MVA all ASID IS* ø
c5 0 ITLBIALL, invalidate instruction TLB
1 ITLBIMVA, invalidate instruction TLB entry by MVA and ASID
2 ITLBIASID, invalidate instruction TLB by ASID match
c6 0 DTLBIALL, invalidate data TLB
1 DTLBIMVA, invalidate data TLB entry by MVA and ASID
2 DTLBIASID, invalidate data TLB by ASID match
c7 0 TLBIALL, invalidate unified TLB
1 TLBIMVA, invalidate unified TLB entry by MVA and ASID
2 TLBIASID, invalidate unified TLB by ASID match
3 TLBIMVAA, invalidate unified TLB entries by MVA all ASID ø
4 c3 0 TLBIALLHIS, Invalidate entire Hyp unified TLB IS* ‡
1 TLBIMVAHIS, Invalidate Hyp unified TLB entry by MVA IS* ‡
4 TLBIALLNSNHIS, Invalidate entire Non-secure non-Hyp unified TLB IS* ‡
c7 0 TLBIALLH, Invalidate entire Hyp unified TLB ‡
1 TLBIMVAH, Invalidate Hyp unified TLB entry by MVA ‡
4 TLBIALLNSNH, Invalidate entire Non-secure non-Hyp unified TLB ‡
*
Read-only Read/Write Write-only IS = Inner Shareable
ø Introduced as part of the Multiprocessing Extensions ‡ Implemented only as part of the Virtualization Extensions
page B3-1443.
VMSA CP15 c9 register summary, reserved for cache and TCM control and performance
monitors
ARMv7 reserves some CP15 c9 encodings for IMPLEMENTATION DEFINED memory system functions, in particular:
• cache control, including lockdown
• TCM control, including lockdown
• branch predictor control.
Additional CP15 c9 encodings are reserved for performance monitors. These encodings fall into two groups:
• the OPTIONAL Performance Monitors Extension described in Chapter C12 The Performance Monitors
Extension
• additional IMPLEMENTATION DEFINED performance monitors.
The reserved encodings permit implementations that are compatible with previous versions of the ARM
architecture, in particular with the ARMv6 requirements. Figure B3-35 on page B3-1473 shows the reserved CP15
c9 register encodings in a VMSA implementation.
CRn opc1 CRm opc2

c9 {0-7} {c0-c2} {0-7} ¶ Reserved for Branch Predictor, Cache and TCM operations
{c5-c8} {0-7} ¶ Reserved for Branch Predictor, Cache and TCM operations
{c12-c14} {0-7} Reserved for ARM Performance Monitors Extension
c15 {0-7} ¶ Reserved for IMPLEMENTATION DEFINED performance monitors
Read-only Read/Write Write-only ¶ Access depends on the operation
Figure B3-35 Reserved CP15 c9 encodings
CP15 c9 encodings not shown in Figure B3-35 are UNPREDICTABLE, see Accesses to unallocated CP14 and CP15
VMSA CP15 c10 register summary, memory remapping and TLB control registers
On an ARMv7-A implementation, the CP15 c10 registers provide:
• memory remapping registers
• reserved encodings for IMPLEMENTATION DEFINED TLB control functions, including lockdown.
Figure B3-36 shows the CP15 c10 registers and reserved encodings in a VMSA implementation.
CRn opc1 CRm opc2

c10 0 {c0,c1,c4,c8} {0-7} ¶ Reserved for TLB Lockdown operations
c2 0 PRRR or MAIR0, see table
1 NMRR or MAIR1, see table
c3 0 AMAIR0, Auxiliary Memory Attribute Indirection Register 0 §
1 AMAIR1, Auxiliary Memory Attribute Indirection Register 1 §
{1-3} {c0,c1,c4,c8} {0-7} ¶ Reserved for TLB Lockdown operations
4 {c0,c1,c4,c8} {0-7} ¶ Reserved for TLB Lockdown operations
c2 0 HMAIR0, Hyp Memory Attribute Indirection Register 0 ‡
1 HMAIR1, Hyp Memory Attribute Indirection Register 1 ‡
c3 0 HAMAIR0, Hyp Auxiliary Memory Attribute Indirection Register 0 ‡
1 HAMAIR1, Hyp Auxiliary Memory Attribute Indirection Register 1‡
{5-7} {c0,c1,c4,c8} {0-7} ¶ Reserved for TLB Lockdown operations
Without Large Physical Address Extension With Large Physical Address Extension
PRRR, Primary Region Remap Register MAIR0, Memory Attribute Indirection Register 0
NMRR, Normal Memory Remap Register MAIR1, Memory Attribute Indirection Register 1
page B3-1443.
VMSA CP15 c11 register summary, reserved for TCM DMA registers
ARMv7 reserves some CP15 c11 register encodings for IMPLEMENTATION DEFINED DMA operations to and from
TCM. Figure B3-37 shows the reserved CP15 c11 encodings:
CRn opc1 CRm opc2

c11 {0-7} {c0-c8} {0-7} ¶ Reserved for DMA operations for TCM access
c15 {0-7} ¶ Reserved for DMA operations for TCM access
Figure B3-37 Reserved CP15 c11 encodings
CP15 c11 encodings not shown in Figure B3-37 on page B3-1473 are UNPREDICTABLE, see Accesses to unallocated
CP14 and CP15 encodings on page B3-1443.
VMSA CP15 c12 register summary, Security Extensions registers

On an ARMv7-A implementation that includes the Security Extensions, the CP15 c12 registers provide Security
Extensions functions. Figure B3-38 shows the CP15 c12 registers.
CRn opc1 CRm opc2

c12 0 c0 0 VBAR, Vector Base Address Register †
1 MVBAR, Monitor Vector Base Address Register †
c1 0 ISR, Interrupt Status Register †
4 c0 0 HVBAR, Hyp Vector Base Address Register ‡
Figure B3-38 Security Extensions CP15 c12 registers
In an implementation that includes the Security Extensions, CP15 c12 encodings not shown in Figure B3-38, and
encodings that are part of an unimplemented architectural extension, are UNPREDICTABLE. On an implementation
that does not include the Security Extensions all CP15 c12 encodings are UNDEFINED. For more information, see
Accesses to unallocated CP14 and CP15 encodings on page B3-1443.
VMSA CP15 c13 register summary, Process, context and thread ID registers
On an ARMv7-A implementation, the CP15 c13 registers provide:
• an FCSE Process ID Register, that indicates whether the implementation includes the FCSE
• a Context ID Register
• Software Thread ID Registers.
Figure B3-39 shows the CP15 c13 registers:
CRn opc1 CRm opc2

c13 0 c0 0 * FCSEIDR, FCSE PID Register
1 CONTEXTIDR, Context ID Register
2 TPIDRURW, User Read/Write
3 TPIDRURO, User Read Only ª Software Thread ID
4 TPIDRPRW, PL1 only Registers
4 c0 2 HTPIDR, Hyp Read/Write ‡
Read-only Read/Write Write-only Bold text = Accessible at PL0
* RAZ/WI when FCSE is not implemented, see register description ª Read-only at PL0
CP15 c13 encodings not shown in Figure B3-39, and encodings that are part of an unimplemented architectural
extension, are UNPREDICTABLE, see Accesses to unallocated CP14 and CP15 encodings on page B3-1443.
VMSA CP15 c14, reserved for Generic Timer Extension

From issue C.a of this manual, CP15 c14 is reserved for the system control registers of the OPTIONAL Generic Timer
Extension. For more information, see Chapter B8 The Generic Timer. On an implementation that does not include
the Generic Timer, c14 is an unallocated CP15 primary register, see UNPREDICTABLE and UNDEFINED behavior
for CP14 and CP15 accesses on page B3-1442.
Figure B3-40 on page B3-1475 shows the 32-bit CP15 c14 registers in a VMSAv7 implementation that includes the
Generic Timer Extension:
CRn opc1 CRm opc2

c14 0 c0 0 CNTFRQ, Counter Frequency register ª
c1 0 CNTKCTL, Timer PL1 Control register
c2 0 CNTP_TVAL, PL1 Physical TimerValue register ª
1 CNTP_CTL, PL1 Physical Timer Control register ª
c3 0 CNTV_TVAL, Virtual TimerValue register ª
1 CNTV_CTL, Virtual Timer Control register ª
4 c1 0 CNTHCTL, Timer PL2 Control register ‡
c2 0 CNTHP_TVAL, PL2 Physical TimerValue register ‡
1 CNTHP_CTL, PL2 Physical Timer Control register ‡
ª Can be configured as accessible at PL0, see the register description for more information
All registers are implemented only as part of the optional Generic Timer Extension
‡ Implemented only if the implementation includes the Virtualization Extensions
Figure B3-40 CP15 32-bit c14 registers in a VMSA implementation that includes the Generic Timer Extension
Figure B3-41 shows the 64-bit CP15 c14 registers in a VMSAv7 implementation that includes the Generic Timer
Extension:
CRm opc1
c14 0 CNTPCT, Physical Count register ª
1 CNTVCT, Virtual Count register ª
2 CNTP_CVAL, PL1 Physical Timer CompareValue register ª
3 CNTV_CVAL, Virtual Timer CompareValue register ª
4 CNTVOFF, Virtual Offset register †
6 CNTHP_CVAL, PL2 Physical Timer CompareValue register ‡
ª Can be configured as accessible at PL0, see the register description for more information
All registers are implemented only as part of the optional Generic Timer Extension
† Implemented as RW only if the implementation includes the Virtualization Extensions, see the register
description for more information
‡ Implemented only if the implementation includes the Virtualization Extensions
Figure B3-41 CP15 64-bit c14 registers in a VMSA implementation that includes the Generic Timer Extension
VMSA CP15 c15 register summary, IMPLEMENTATION DEFINED registers

ARMv7 reserves CP15 c15 for IMPLEMENTATION DEFINED purposes, and does not impose any restrictions on the
use of the CP15 c15 encodings. For more information, see IMPLEMENTATION DEFINED registers, functional
group on page B3-1497.
B3.17.2 Full list of VMSA CP15 registers, by coprocessor register number

Table B3-42 on page B3-1476 shows the CP15 registers in a VMSA implementation, in the order of the {CRn, opc1,
CRm, opc2} values used in MCR or MRC accesses to the 32-bit registers:
• For MCR or MRC accesses to the 32-bit registers, CRn identifies the CP15 primary register used for the access.
• For MCRR or MRRC accesses to the 64-bit registers, CRm identifies the CP15 primary register used for the access.
Table B3-42 on page B3-1476 lists the 64-bit registers with the 32-bit registers accessed using the same CP15
primary register number.
The table also includes links to the descriptions of each of the CP15 primary registers, c0 to c15.
The only UNPREDICTABLE encodings shown in the table are those that had defined functions in ARMv6.
Table B3-42 Summary of VMSA CP15 register descriptions, in coprocessor register number order
CRn opc1 CRm opc2 Name Width Description
c0 0 c0 0 MIDR 32-bit Main ID Register
1 CTR 32-bit Cache Type Register
2 TCMTR 32-bit TCM Type Register
3 TLBTR 32-bit TLB Type Register
4, 6 a, 7 MIDR 32-bit Aliases of Main ID Register
5 MPIDR 32-bit Multiprocessor Affinity Register
6a REVIDR 32-bit Revision ID Register
c0 0 c1 0 ID_PFR0 32-bit Processor Feature Register 0
1 ID_PFR1 32-bit Processor Feature Register 1
2 ID_DFR0 32-bit Debug Feature Register 0
3 ID_AFR0 32-bit Auxiliary Feature Register 0
4 ID_MMFR0 32-bit Memory Model Feature Register 0
c2 0 ID_ISAR0 32-bit Instruction Set Attribute Register 0
1 ID_ISAR1 32-bit Instruction Set Attribute Register 1
c0 1 c0 0 CCSIDR 32-bit Cache Size ID Registers
1 CLIDR 32-bit Cache Level ID Register
7 AIDR 32-bit IMPLEMENTATION DEFINED Auxiliary ID Register b
2 c0 0 CSSELR 32-bit Cache Size Selection Register
4 c0 0 VPIDR c 32-bit Virtualization Processor ID Register
5 VMPIDRc 32-bit Virtualization Multiprocessor ID Register
Table B3-42 Summary of VMSA CP15 register descriptions, in coprocessor register number order (continued)
c1 0 c0 0 SCTLR 32-bit System Control Register
1 ACTLR 32-bit IMPLEMENTATION DEFINED Auxiliary Control Register
2 CPACR 32-bit Coprocessor Access Control Register
c1 0 SCR d 32-bit Secure Configuration Register
1 SDERd 32-bit Secure Debug Enable Register
2 NSACRd 32-bit Non-Secure Access Control Register
c1 4 c0 0 HSCTLRc 32-bit Hyp System Control Register
1 HACTLRc 32-bit Hyp Auxiliary Control Register
c1 4 c1 0 HCR c 32-bit Hyp Configuration Register
1 HDCRc 32-bit Hyp Debug Configuration Register
2 HCPTRc 32-bit Hyp Coprocessor Trap Register
3 HSTR c 32-bit Hyp System Trap Register
7 HACR c 32-bit Hyp Auxiliary Configuration Register
c2 0 c0 0 TTBR0 32-bit Translation Table Base Register 0
- 0 c2 - TTBR0e 64-bit
c2 0 c0 1 TTBR1 32-bit Translation Table Base Register 1
- 1 c2 - TTBR1e 64-bit
c2 0 c0 2 TTBCR 32-bit Translation Table Base Control Register
4 c0 2 HTCR c 32-bit Hyp Translation Control Register
c1 2 VTCR c 32-bit Virtualization Translation Control Register
- 4 c2 - HTTBRc 64-bit Hyp Translation Table Base Register
- 6 c2 - VTTBRc 64-bit Virtualization Translation Table Base Register
c3 0 c0 0 DACR 32-bit Domain Access Control Register
c5 0 c0 0 DFSR 32-bit Data Fault Status Register
1 IFSR 32-bit Instruction Fault Status Register
c1 0 AxFSR 32-bit ADFSR, Auxiliary Data Fault Status Register
1 32-bit AIFSR, Auxiliary Instruction Fault Status Register
4 c1 0 HAxFSRc 32-bit HADFSR, Hyp Auxiliary Data Fault Syndrome Register
1 32-bit HAIFSR, Hyp Auxiliary Instruction Fault Syndrome

Register
c2 0 HSR c 32-bit Hyp Syndrome Register
c6 0 c0 0 DFAR 32-bit Data Fault Address Register
2 IFAR 32-bit Instruction Fault Address Register
c6 4 c0 0 HDFARc 32-bit Hyp Data Fault Address Register
2 HIFAR c 32-bit Hyp Instruction Fault Address Register
4 HPFAR c 32-bit Hyp IPA Fault Address Register
c7 0 c0 4 UNPREDICTABLE 32-bit See Retired operations on page B3-1494
c1 0 ICIALLUIS f 32-bit See Cache and branch predictor maintenance operations,

VMSA on page B4-1735
6 BPIALLIS f 32-bit
c7 0 c4 0 PAR 32-bit Physical Address Register
c7 - PARe 64-bit
c5 0 ICIALLU 32-bit See Cache and branch predictor maintenance operations,

1 ICIMVAU 32-bit
4 CP15ISB 32-bit See Data and instruction barrier operations, VMSA on

page B4-1744
6 BPIALL 32-bit See Cache and branch predictor maintenance operations,

7 BPIMVA 32-bit
c6 1 DCIMVAC 32-bit See Cache and branch predictor maintenance operations,

2 DCISW 32-bit
c7 0 c8 0 ATS1CPR 32-bit See Performing address translation operations on

page B4-1742
1 ATS1CPW 32-bit
2 ATS1CUR 32-bit
3 ATS1CUW 32-bit
4 ATS12NSOPRd 32-bit
5 ATS12NSOPWd 32-bit
6 ATS12NSOUR d 32-bit
7 ATS12NSOUW d 32-bit
c10 1 DCCMVAC 32-bit See Cache and branch predictor maintenance operations,
2 DCCSW 32-bit
4 CP15DSB 32-bit See Data and instruction barrier operations, VMSA on

page B4-1744
5 CP15DMB 32-bit
c11 1 DCCMVAU 32-bit See Cache and branch predictor maintenance operations,
c13 1 UNPREDICTABLE 32-bit See Retired operations on page B3-1494
c7 0 c14 1 DCCIMVAC 32-bit See Cache and branch predictor maintenance operations,
2 DCCISW 32-bit
4 c8 0 ATS1HRc 32-bit See Performing address translation operations on

page B4-1742
1 ATS1HW c 32-bit
c8 0 c3 0 TLBIALLISf 32-bit See TLB maintenance operations, not in Hyp mode on

page B4-1738
1 TLBIMVAIS f 32-bit
2 TLBIASIDIS f 32-bit
3 TLBIMVAAIS f 32-bit
c8 0 c5 0 ITLBIALL 32-bit See TLB maintenance operations, not in Hyp mode on

page B4-1738
1 ITLBIMVA 32-bit
2 ITLBIASID 32-bit
c6 0 DTLBIALL 32-bit See TLB maintenance operations, not in Hyp mode on

page B4-1738
1 DTLBIMVA 32-bit
2 DTLBIASID 32-bit
c7 0 TLBIALL 32-bit See TLB maintenance operations, not in Hyp mode on

page B4-1738
1 TLBIMVA 32-bit
2 TLBIASID 32-bit
3 TLBIMVAA f 32-bit
4 c3 0 TLBIALLHISc 32-bit See Hyp mode TLB maintenance operations,

Virtualization Extensions on page B4-1741
1 TLBIMVAHIS c 32-bit
4 TLBIALLNSNHIS c 32-bit
c7 0 TLBIALLH c 32-bit See Hyp mode TLB maintenance operations,

Virtualization Extensions on page B4-1741
1 TLBIMVAH c 32-bit
4 TLBIALLNSNH c 32-bit
c9 0-7 c0-c2 0-7 - 32-bit See Cache and TCM lockdown registers, VMSA on
page B4-1745
c5-c8 0-7 - 32-bit
c9 0 c12 0 PMCR 32-bit Performance Monitors Control Register
1 PMCNTENSET 32-bit Performance Monitors Count Enable Set register
2 PMCNTENCLR 32-bit Performance Monitors Count Enable Clear register
3 PMOVSR 32-bit Performance Monitors Overflow Flag Status Register
4 PMSWINC 32-bit Performance Monitors Software Increment register
5 PMSELR 32-bit Performance Monitors Event Counter Selection Register
6 PMCEID0 32-bit Performance Monitors Common Event Identification

register 0
7 PMCEID1 32-bit Performance Monitors Common Event Identification

register 1
c9 0 c13 0 PMCCNTR 32-bit Performance Monitors Cycle Count Register
1 PMXEVTYPER 32-bit Performance Monitors Event Type Select Register
2 PMXEVCNTR 32-bit Performance Monitors Event Count Register
c9 0 c14 0 PMUSERENR 32-bit Performance Monitors User Enable Register
1 PMINTENSET 32-bit Performance Monitors Interrupt Enable Set register
2 PMINTENCLR 32-bit Performance Monitors Interrupt Enable Clear register
3 PMOVSSET c 32-bit Performance Monitors Overflow Flag Status Set register
c9 0 c15 0-7 - 32-bit See Performance Monitors, functional group on

page B3-1495
1-7 c12- c15 0-7 - 32-bit
c10 0 c0, c1, 0-7 - See IMPLEMENTATION DEFINED TLB control

c4, c8 operations, VMSA on page B4-1745
c10 0 c2 0 PRRR g 32-bit Primary Region Remap Register
MAIR0g 32-bit MAIR0, Memory Attribute Indirection Register 0
1 NMRRg 32-bit Normal Memory Remap Register
MAIR1g 32-bit MAIR1, Memory Attribute Indirection Register 1
c3 0 AMAIR0 e 32-bit AMAIR0, Auxiliary Memory Attribute Indirection

Register 0
1 AMAIR1 e 32-bit AMAIR1, Auxiliary Memory Attribute Indirection

Register 1
4 c2 0 HMAIR0c 32-bit HMAIR0, Hyp Memory Attribute Indirection Register 0
1 HMAIR1c 32-bit HMAIR1, Hyp Memory Attribute Indirection Register 1
c3 0 HAMAIR0 c 32-bit HAMAIR0, Hyp Auxiliary Memory Attribute Indirection

Register 0
1 HAMAIR1 c 32-bit HAMAIR0, Hyp Auxiliary Memory Attribute Indirection

Register 1
c11 0-7 c0-c8 0-7 - 32-bit See DMA support, VMSA on page B4-1746
c15 c15 - 32-bit
c12 0 c0 0 VBARd 32-bit Vector Base Address Register
1 MVBARd 32-bit Monitor Vector Base Address Register
c1 0 ISR d 32-bit Interrupt Status Register
4 c0 0 HVBAR c, d 32-bit Hyp Vector Base Address Register
c13 0 c0 0 FCSEIDR 32-bit FCSE Process ID Register
1 CONTEXTIDR 32-bit Context ID Register
2 TPIDRURW 32-bit User Read/Write Thread ID Register
3 TPIDRURO 32-bit User Read-Only Thread ID Register
4 TPIDRPRW 32-bit PL1 only Thread ID Register
4 c0 2 HTPIDR c 32-bit Hyp Software Thread ID Register
c14 0 c0 0 CNTFRQ h 32-bit Counter Frequency register
- 0 c14 - CNTPCT h 64-bit Physical Count register
c14 0 c1 0 CNTKCTL h 32-bit Timer PL1 Control register
c2 0 CNTP_TVAL h 32-bit PL1 Physical TimerValue register
1 CNTP_CTL h 32-bit PL1 Physical Timer Control register
c3 0 CNTV_TVAL h 32-bit Virtual TimerValue register
1 CNTV_CTL h 32-bit Virtual Timer Control register
- 1 c14 - CNTVCT h 64-bit Virtual Count register
2 CNTP_CVAL h 64-bit PL1 Physical Timer CompareValue register1
3 CNTV_CVAL h 64-bit Virtual Timer CompareValue register
4 CNTVOFF i 64-bit Virtual Offset register
c14 4 c1 0 CNTHCTL 32-bit Timer PL2 Control register
c2 0 CNTHP_TVAL 32-bit PL2 Physical TimerValue register
1 CNTHP_CTL 32-bit PL2 Physical Timer Control register
- 6 c14 - CNTHP_CVAL 64-bit PL2 Physical Timer CompareValue register
c15 0-7 c0-c15 0-7 - 32-bit See IMPLEMENTATION DEFINED registers, functional
group on page B3-1497
a. REVIDR is an optional register. If it is not implemented, the encoding with opc2 set to 6 is an alias of MIDR.
b. In some ARMv7 implementations, the AIDR is UNDEFINED.
c. Implemented only as part of the Virtualization Extensions. Otherwise, encoding is unallocated and UNPREDICTABLE, see Accesses to
unallocated CP14 and CP15 encodings on page B3-1443.
d. Implemented only as part of the Security Extensions. Otherwise, as described in Accesses to unallocated CP14 and CP15 encodings on
page B3-1443, encoding is unallocated and:
UNDEFINED, for the registers accessed using CRn set to c12.
UNPREDICTABLE, for the register accessed using CRn values other than c12.
e. Implemented only as part of the Large Physical Address Extension. Otherwise, encoding is unallocated and UNPREDICTABLE, see Accesses
to unallocated CP14 and CP15 encodings on page B3-1443.
f. Added as part of the Multiprocessing Extensions. In earlier ARMv7 implementations, encoding is unallocated and UNPREDICTABLE, see
g. When an implementation is using the Long descriptor translation table format these encodings access the MAIRn registers. Otherwise,
including on any implementation that does not include the Large Physical Address Extension, they access the PRRR and NMRR.
h. Implemented only as part of the Generic Timers Extension. Otherwise, encoding is unallocated and UNDEFINED, see Accesses to unallocated
i. Implemented as RW only as part of the Generic Timers Extension on an implementation that includes the Virtualization Extensions. For
more information see Status of the CNTVOFF register on page B8-1955.
B3.17.3 Views of the CP15 registers

The following sections summarize the different software views of the CP15 registers, for a VMSA implementation:
• PL0 views of the CP15 registers
• PL1 views of the CP15 registers on page B3-1484
• Non-secure PL2 view of the CP15 registers on page B3-1485.
PL0 views of the CP15 registers

Software executing at PL0, unprivileged, can access only a small subset of the CP15 registers, as Table B3-43
shows. This table excludes possible PL0 access to CP15 registers that are part of the following OPTIONAL extensions
to the architecture:
• the Performance Monitors Extension, see Possible PL0 access to the Performance Monitors Extension CP15
registers
• the Generic Timer Extension, see Possible PL0 access to the Generic Timer Extension CP15 registers.
Table B3-43 CP15 registers accessible from PL0
Name Access Description Note
CP15ISB WO Data and instruction barrier operations, VMSA on page B4-1744 ARM deprecates use of these
operations
CP15DSB WO
CP15DMB WO
TPIDRURW RW TPIDRURW, User Read/Write Thread ID Register, VMSA on -

page B4-1715
TPIDRURO RO TPIDRURO, User Read-Only Thread ID Register, VMSA on RW at PL1

page B4-1714
Possible PL0 access to the Performance Monitors Extension CP15 registers
In a VMSAv7 implementation that includes the Performance Monitors Extension, when using CP15 to access the
Performance Monitors registers:
• The PMUSERENR is RO from PL0.
• When PMUSERENR.EN is set to 1:

— the PMCR, PMOVSR, PMSELR, PMCCNTR, PMXEVTYPER, PMXEVCNTR, and the
PMCNTENSET, PMCNTENCLR, and PMSWINC registers, are accessible from PL0
— if the implementation includes PMUv2, the PMCEIDn registers are accessible from PL0
— if the implementation includes the Virtualization Extensions, the PMOVSSET register is accessible
from PL0.
When PMUSERENR.EN is set to 1, these registers have the same access permissions from PL0 as they do
from PL1.
For more information, see CP15 c9 performance monitors registers on page C12-2314 and Access permissions on
page C12-2316.
Possible PL0 access to the Generic Timer Extension CP15 registers
In a VMSAv7 implementation that includes the Generic Timer Extension, when using CP15 to access the Generic
Timer registers:
• If CNTKCTL.PL0PCTEN is set to 1, then if the physical counter register CNTPCT is accessible from PL1
it is also accessible from PL0. For more information see Accessing the physical counter on page B8-1948.
• If CNTKCTL.PL0PVTEN is set to 1, the virtual counter register CNTVCT is accessible from PL0. For more
information, see Accessing the virtual counter on page B8-1949.
• If at least one of CNTKCTL.{PL0PCTEN, PL0PVTEN} is set to 1, the CNTFRQ register is RO from PL0.
• If:
— CNTKCTL.PL0PTEN is set to 1, the physical timer registers CNTP_CTL, CNTP_CVAL, and
CNTP_TVAL are accessible from PL0
— CNTKCTL.PL0VTEN is set to 1, the virtual timer registers CNTV_CTL, CNTV_CVAL, and
CNTV_TVAL, are accessible from PL0.
For more information, see Accessing the timer registers on page B8-1952.
PL1 views of the CP15 registers

Software executing at PL1 can access all CP15 registers, with the following exceptions:
Non-secure PL1 software

The Security Extensions restrict or prevent access to some registers by Non-secure PL1 software.
In particular:
• the Restricted access CP15 registers are either not accessible to Non-secure PL1 software, or
are read-only to Non-secure PL1 software, see Restricted access system control registers on
page B3-1449
• configuration settings determine whether Non-secure PL1 software can access the
Configurable access CP15 registers, see Configurable access system control registers on
page B3-1449.
The individual register descriptions identify these access restrictions.
In an implementation that includes the Virtualization Extensions, Non-secure PL1 software has no
visibility of the PL2-mode registers summarized in Banked PL2-mode CP15 read/write registers on
page B3-1450. The individual register descriptions identify these registers as PL2-mode registers.
Secure PL1 software

In general, Secure PL1 software has access to all CP15 registers. However:
• The CP15SDISABLE signal disables write access to a number of Secure registers, see The
CP15SDISABLE input on page B3-1454.
• To access the PL2-mode registers, Secure PL1 software must move into Monitor mode, and
set SCR.NS to 1.
Banked PL2-mode CP15 read/write registers on page B3-1450 summarizes these registers.
The individual register descriptions identify:
• the registers affected by the CP15SDISABLE signal
• the PL2-mode registers.
Non-secure PL2 view of the CP15 registers

Non-secure software executing at PL2 can access:
• The registers that are accessible to Non-secure software executing at PL1, as defined in PL1 views of the
CP15 registers on page B3-1484. Access permissions for these registers are identical to those for Non-secure
software executing at PL1.
• The PL2-mode registers summarized in Banked PL2-mode CP15 read/write registers on page B3-1450, and
described in Virtualization Extensions registers, functional group on page B3-1496.
B3.18 Functional grouping of VMSAv7 system control registers

This section describes how the system control registers in an VMSAv7 implementation divide into functional
groups.Chapter B4 System Control Registers in a VMSA implementation describes these registers, in alphabetical
order of the register names.
These registers are implemented in the CP15 System Control Coprocessor. Therefore, these sections and chapters
describe the CP15 registers for a VMSAv7 implementation.
Table B3-42 on page B3-1476 lists all of the CP15 registers in a VMSAv7 implementation, ordered by:
1. The CP15 primary register used when accessing the register. This is the CRn value for an access to a 32-bit
register, or the CRm value for an access to a 64-bit register.
2. The opc1 value used when accessing the register.
3. For 32-bit registers, the {CRm, opc2} values used when accessing the register.
Entries in this table index the detailed description of each register.
An ARMv7 implementation with a PMSA also implements some of the registers described in this chapter. For more
information, see Functional grouping of PMSAv7 system control registers on page B5-1791.
For other related information see:
• Coprocessors and system control on page B1-1225 for general information about the System Control
Coprocessor, CP15 and the register access instructions MRC and MCR
• About the system control registers for VMSA on page B3-1440 for general information about the CP15
registers in a VMSA implementation, including:
— their organization, both by CP15 primary registers c0 to c15, and by function
— their general behavior
— the effect of different ARMv7 architecture extensions on the registers
— different views of the registers, that depend on the state of the processor
— conventions used in describing the registers.
The remainder of this chapter, and Chapter B4 System Control Registers in a VMSA implementation, assumes you
are familiar with About the system control registers for VMSA on page B3-1440, and uses conventions and other
information from that section without any explanation.
Each of the following sections summarizes a functional group of VMSA system control registers:
• Identification registers, functional group on page B3-1487
• Virtual memory control registers, functional group on page B3-1488
• PL1 Fault handling registers, functional group on page B3-1489
• Other system control registers, functional group on page B3-1489
• Lockdown, DMA, and TCM features, functional group, VMSA on page B3-1490
• Cache maintenance operations, functional group, VMSA on page B3-1491
• TLB maintenance operations, functional group on page B3-1492
• Address translation operations, functional group on page B3-1493
• Miscellaneous operations, functional group on page B3-1494
• Performance Monitors, functional group on page B3-1495
• Security Extensions registers, functional group on page B3-1495
• Virtualization Extensions registers, functional group on page B3-1496
• Generic Timer Extension registers on page B3-1497
• IMPLEMENTATION DEFINED registers, functional group on page B3-1497.
B3.18.1 Identification registers, functional group

Table B3-44 shows the Identification registers in a VMSA implementation.
Table B3-44 Identification registers, VMSA
Name CRn opc1 CRm opc2 Width Type Description
AIDR c0 1 c0 7 32-bit RO IMPLEMENTATION DEFINED Auxiliary ID Register
CCSIDR c0 1 c0 0 32-bit RO Cache Size ID Registers
CLIDR c0 1 c0 1 32-bit RO Cache Level ID Register
CSSELR c0 2 c0 0 32-bit RW Cache Size Selection Register
CTR c0 0 c0 1 32-bit RO Cache Type Register
ID_AFR0 c0 0 c1 3 32-bit RO Auxiliary Feature Register 0 a
ID_DFR0 c0 0 c1 2 32-bit RO Debug Feature Register 0 a
ID_ISAR0 c0 0 c2 0 32-bit RO Instruction Set Attribute Register 0 a
ID_MMFR0 c0 0 c1 4 32-bit RO Memory Model Feature Register 0 a
ID_PFR0 c0 0 c1 0 32-bit RO Processor Feature Register 0 a
ID_PFR1 c0 0 c1 1 32-bit RO Processor Feature Register 1 a
MIDR c0 0 c0 0 32-bit RO Main ID Register
MPIDR c0 0 c0 5 32-bit RO Multiprocessor Affinity Register
REVIDR c0 0 c0 6 32-bit RO Revision ID Register
TCMTR c0 0 c0 2 32-bit RO TCM Type Register
TLBTR c0 0 c0 3 32-bit RO TLB Type Register
a. CPUID register, see also Chapter B7 The CPUID Identification Scheme.
The FPSID, MVFR0, MVFR1, and JIDR hold additional identification information.
B3.18.2 Virtual memory control registers, functional group

Table B3-45 shows the Virtual memory control registers in a VMSA implementation.
Table B3-45 Virtual memory control registers, VMSA only
AMAIR0 a c10 0 c3 0 32 bit RW Auxiliary Memory Attribute Indirection Register 0
AMAIR1 a 1 32 bit RW Auxiliary Memory Attribute Indirection Register 1
CONTEXTIDR c13 0 c0 1 32 bit RW Context ID Register
DACR c3 0 c0 0 32 bit RW Domain Access Control Register
MAIR0 c10 0 c2 0 32 bit RW Memory Attribute Indirection Register 0
MAIR1 1 32 bit RW Memory Attribute Indirection Register 1
NMRR c10 0 c2 1 32 bit RW Normal Memory Remap Register
PRRR 0 32 bit RW Primary Region Remap Register
SCTLR c1 0 c0 0 32 bit RW System Control Register
TTBCR c2 0 c0 2 32 bit RW Translation Table Base Control Register
TTBR0 c2 0 c0 0 32 bit RW Translation Table Base Register 0
TTBR0 - 0 c2 - 64 bit b RW Translation Table Base Register 0
TTBR1 c2 0 c0 1 32 bit RW Translation Table Base Register 1
TTBR1 - 1 c2 - 64 bit b RW Translation Table Base Register 1
a. Implemented as part of the Large Physical Address Extension. Otherwise, encodings are unallocated and reserved, see Accesses to
unallocated CP14 and CP15 encodings on page B3-1443
b. Implemented as part of the Large Physical Address Extension. Otherwise, encoding is unallocated and UNDEFINED, see Accesses to
The IMPLEMENTATION DEFINED ACTLR might provided additional virtual memory control. For more information
see Other system control registers, functional group on page B3-1489.
B3.18.3 PL1 Fault handling registers, functional group

Table B3-46 shows the PL1 Fault handling registers in a VMSA implementation.
Table B3-46 Fault handling registers, VMSA
AxFSR c5 0 c1 0 32-bit RW Auxiliary Data Fault Status Register
1 32-bit RW Auxiliary Instruction Fault Status Register
DFAR c6 0 c0 0 32-bit RW Data Fault Address Register
DFSR c5 0 c0 0 32-bit RW Data Fault Status Register
IFAR c6 0 c0 2 32-bit RW Instruction Fault Address Register
IFSR c5 0 c0 1 32-bit RW Instruction Fault Status Register
The processor returns fault information using the fault status registers and the fault address registers. For details of
how these registers are used see Exception reporting in a VMSA implementation on page B3-1406.
Note
• These registers also report information about debug exceptions. For more information see:
— Data Abort exceptions, taken to a PL1 mode on page B3-1407
— Prefetch Abort exceptions, taken to a PL1 mode on page B3-1410
— Reporting exceptions taken to the Non-secure PL2 mode on page B3-1417.
• Before ARMv7:
— The DFAR was called the Fault Address Register (FAR).
— The Watchpoint Fault Address Register, DBGWFAR, was implemented in CP15 c6, with <opc2> = 1.
In ARMv7, the DBGWFAR is only implemented as a CP14 debug register.
The Virtualization Extensions include additional fault handling registers. For more information see Virtualization
Extensions registers, functional group on page B3-1496.
B3.18.4 Other system control registers, functional group

Table B3-47 shows the Other system control registers in a VMSA implementation.
Table B3-47 Other system control registers, VMSA
ACTLR c1 0 c0 1 32-bit RW IMPLEMENTATION DEFINED Auxiliary Control Register
CPACR c1 0 c0 2 32-bit RW Coprocessor Access Control Register
FCSEIDR c13 0 c0 0 32-bit a FCSE Process ID Register
a. The FCSEIDR is RO if the processor does not implement the FCSE, and RW otherwise. See the register description for more
information.
The following sections summarize the system control registers added by the corresponding architecture extension:
• Security Extensions registers, functional group on page B3-1495
• Virtualization Extensions registers, functional group on page B3-1496.
B3.18.5 Lockdown, DMA, and TCM features, functional group, VMSA

Table B3-48 shows the Lockdown, DMA, and TCM features registers in a VMSA implementation.
Table B3-48 Lockdown, DMA, and TCM features, VMSA
Name CRn opc1 CRm Width opc2 Type Description
IMPLEMENTATION DEFINED c9 0-7 c0-c2 32-bit 0-7 a Cache and TCM lockdown registers, VMSA on
page B4-1745
c5-c8 32-bit 0-7 a
c10 0 c0-c1 32-bit 0-7 a IMPLEMENTATION DEFINED TLB control

operations, VMSA on page B4-1745
c4 32-bit 0-7 a
c8 32-bit 0-7 a
c11 0-7 c0-c8 32-bit 0-7 a DMA support, VMSA on page B4-1746
c15 32-bit 0-7 a
a. Access depends on the register or operation, and is IMPLEMENTATION DEFINED.
B3.18.6 Cache maintenance operations, functional group, VMSA

Table B3-49 shows the Cache and branch predictor maintenance operations in a VMSA implementation.
Table B3-49 Cache and branch predictor maintenance operations, VMSA
Name CRn opc1 CRm opc2 Width Type Description Limits a
BPIALL c c7 0 c5 6 32-bit WO Branch predictor invalidate all -
BPIALLIS b, c c7 0 c1 6 32-bit WO Branch predictor invalidate all IS
BPIMVA c c7 0 c5 7 32-bit WO Branch predictor invalidate by MVA -
DCCIMVAC c c7 0 c14 1 32-bit WO Data cache clean and invalidate by MVA PoC
DCCISW c c7 0 c14 2 32-bit WO Data cache clean and invalidate by set/way -
DCCMVAC c c7 0 c10 1 32-bit WO Data cache clean by MVA PoC
DCCMVAU c c7 0 c11 1 32-bit WO Data cache clean by MVA PoU
DCCSW c c7 0 c10 2 32-bit WO Data cache clean by set/way -
DCIMVAC c c7 0 c6 1 32-bit WO Data cache invalidate by MVA PoC
DCISW c c7 0 c6 2 32-bit WO Data cache invalidate by set/way -
ICIALLU c c7 0 c5 0 32-bit WO Instruction cache invalidate all PoU
ICIALLUIS b, c c7 0 c1 0 32-bit WO Instruction cache invalidate all PoU, IS
ICIMVAU c c7 0 c5 1 32-bit WO Instruction cache invalidate by MVA PoU
a. PoU = to Point of Unification, PoC = to Point of Coherence, IS = Inner Shareable.

b. Introduced in the Multiprocessing Extensions, UNPREDICTABLE in earlier ARMv7 implementations, see Accesses to unallocated CP14
and CP15 encodings on page B3-1443.
c. The links in this column are to a summary of the operation. Cache and branch predictor maintenance operations, VMSA on page B4-1735
describes the operation.
As stated in the table footnote, Cache and branch predictor maintenance operations, VMSA on page B4-1735
describes these operations.
B3.18.7 TLB maintenance operations, functional group

Table B3-50 shows the TLB maintenance operations in a VMSA implementation that does not implement the
Table B3-50 TLB maintenance operations, VMSA only
DTLBIALLb, d c8 0 c6 0 32-bit WO Invalidate entire data TLB -
DTLBIASID b, d c8 0 c6 2 32-bit WO Invalidate data TLB by ASID -
DTLBIMVAb, d c8 0 c6 1 32-bit WO Invalidate data TLB entry by MVA -
ITLBIALL b, d c8 0 c5 0 32-bit WO Invalidate entire instruction TLB -
ITLBIASIDb, d c8 0 c5 2 32-bit WO Invalidate instruction TLB by ASID -
ITLBIMVA b, d c8 0 c5 1 32-bit WO Invalidate instruction TLB by MVA -
TLBIALL c, d c8 0 c7 0 32-bit WO Invalidate entire unified TLB -
TLBIALLIS e, d c8 0 c3 0 32-bit WO Invalidate entire unified TLB IS
TLBIASID d c8 0 c7 2 32-bit WO Invalidate unified TLB by ASID -
TLBIASIDISe, d c8 0 c3 2 32-bit WO Invalidate unified TLB by ASID IS
TLBIMVAA d c8 0 c7 3 32-bit WO Invalidate unified TLB by MVA, all ASID -
TLBIMVAAIS e, d c8 0 c3 3 32-bit WO Invalidate unified TLB by MVA, all ASID IS
TLBIMVA d c8 0 c7 1 32-bit WO Invalidate unified TLB by MVA -
TLBIMVAIS e, d c8 0 c3 1 32-bit WO Invalidate unified TLB by MVA IS
a. IS = Inner Shareable.
b. Deprecated. ARM deprecates use of operations that operate only on an Instruction TLB, or only on a Data TLB.
c. The mnemonics for the operations with CRm==c7, opc2=={0, 1, 2} were previously UTLBIALL, UTLBIMVA and UTLBIMASID.
d. The links in this column are to a summary of the operation. TLB maintenance operations, not in Hyp mode on page B4-1738 describes the
operation.
e. Introduced in the Multiprocessing Extensions. In earlier ARMv7 implementations these encodings are unallocated and UNPREDICTABLE, see
TLB maintenance operations, not in Hyp mode on page B4-1738 describes these operations.
The Virtualization Extensions add other TLB operations for use in Hyp mode, see:
• Virtualization Extensions registers, functional group on page B3-1496
• Hyp mode TLB maintenance operations, Virtualization Extensions on page B4-1741.
B3.18.8 Address translation operations, functional group

Table B3-51 shows the Address translation register and operations in a VMSA implementation.
Table B3-51 Address translation operations, VMSA only
ATS12NSOPR a, c c7 0 c8 4 32-bit WO Stages 1 and 2 Non-secure only PL1 read
ATS12NSOPW a, c c7 0 c8 5 32-bit WO Stages 1 and 2 Non-secure only PL1 write
ATS12NSOUR a, c c7 0 c8 6 32-bit WO Stages 1 and 2 Non-secure only unprivileged read
ATS12NSOUW a, c c7 0 c8 7 32-bit WO Stages 1 and 2 Non-secure only unprivileged write
ATS1CPR c c7 0 c8 0 32-bit WO Stage 1 Current state PL1 read
ATS1CPW c c7 0 c8 1 32-bit WO Stage 1 Current state PL1 write
ATS1CUR c c7 0 c8 2 32-bit WO Stage 1 Current state unprivileged read
ATS1CUW c c7 0 c8 3 32-bit WO Stage 1 Current state unprivileged write
ATS1HR b, c c7 4 c8 0 32-bit WO Stage 1 Hyp mode read
ATS1HW b, c c7 4 c8 1 32-bit WO Stage 1 Hyp mode write
PAR c7 0 c4 0 32-bit RW Physical Address Register
- 0 c7 - 64-bit d RW
a. Implemented only as part of the Security Extensions. Otherwise, encoding is unallocated and UNPREDICTABLE, see Accesses to unallocated
b. Implemented only as part of the Virtualization Extensions. Otherwise, encoding is unallocated and UNPREDICTABLE, see Accesses to
c. Except for the link to the PAR, the links in this column are to a summary of the operation, and Performing address translation operations
on page B4-1742 describes the operation.
d. Implemented as part of the Large Physical Address Extension. Otherwise, encoding is unallocated and UNPREDICTABLE, see Accesses to
Performing address translation operations on page B4-1742 describes how to access the address translation
operations. Virtual Address to Physical Address translation operations on page B3-1434 describes these operations.
B3.18.9 Miscellaneous operations, functional group

Table B3-52 shows the Miscellaneous operations in a VMSA implementation.
The only UNPREDICTABLE encodings shown in the table are those that had defined functions in ARMv6.
Table B3-52 Miscellaneous system control operations, VMSA only
Name CRn opc1 CRm opc2 Width Type a Description
CP15DMB c7 0 c10 5 32-bit WO, PL0 Data and instruction barrier operations, VMSA on
page B4-1744
CP15DSB c7 0 c10 4 32-bit WO, PL0
CP15ISB c7 0 c5 4 32-bit WO, PL0
HTPIDR b c13 4 c0 2 32-bit RW Hyp Software Thread ID Register
TPIDRPRW c13 0 c0 4 32-bit RW PL1 only Thread ID Register
TPIDRURO c13 0 c0 3 32-bit RW, PL0 User Read-Only Thread ID Register
TPIDRURW c13 0 c0 2 32-bit RW, PL0 User Read/Write Thread ID Register
UNPREDICTABLE c7 0 c0 4 32-bit WO Retired operations
c13 1 32-bit WO
a. PL0 = Accessible from unprivileged software, that is, from software executing at PL0. See the register description for more information.
b. Implemented only as part of the Virtualization Extensions. Otherwise, encoding is unallocated and UNPREDICTABLE, see Accesses to
Retired operations
ARMv6 includes two CP15 c7 operations that are not supported in ARMv7, with encodings that become
UNPREDICTABLE in ARMv7. These are the ARMv6:
• Wait For Interrupt (CP15WFI) operation. In ARMv7 this operation is performed by the WFI instruction, that
is available in the ARM and Thumb instruction sets. For more information, see WFI on page A8-1107.
• Prefetch instruction by MVA operation. In ARMv7 this operation is replaced by the PLI instruction, that is
available in the ARM and Thumb instruction sets. For more information, see PLI (immediate, literal) on
page A8-531 and PLI (register) on page A8-533.
In ARMv7, the CP15 c7 encodings that were used for these operations are UNPREDICTABLE. These encodings are:
• for the ARMv6 CP15WFI operation:
— an MCR instruction with <opc1> set to 0, <CRn> set to c7, <CRm> set to c0, and <opc2> set to 4
• for the ARMv6 Prefetch instruction by MVA operation:
— an MCR instruction with <opc1> set to 0, <CRn> set to c7, <CRm> set to c13, and <opc2> set to 1.
Note
In some ARMv7 implementations, these encodings are write-only operations that perform a NOP.
B3.18.10 Performance Monitors, functional group

The Performance Monitors Extension is an OPTIONAL non-invasive debug extension, described in Chapter C12 The
Performance Monitors Extension. When a VMSA implementation includes this extension, it must provide a CP15
register interface to the Performance Monitors. Table B3-53 summarizes the performance monitor register
encodings in a VMSA implementation.
Table B3-53 Performance monitors, VMSA
CRn opc1 CRm opc2 Name Width Type Description
c9 0-7 c12-c14 0-7 See Performance Monitors registers on 32-bit RW or Performance monitors
page C12-2314 a RO b
c15 0-7 IMPLEMENTATION DEFINED 32-bit c
a. The referenced section describes the registers defined by the recommended Performance Monitors Extension.
b. The section referenced in footnote a shows the type of each of the recommended Performance Monitors Extension registers.
c. Access depends on the register or operation, and is IMPLEMENTATION DEFINED.
Performance monitors
ARMv7 reserves some encodings in the system control register space for performance monitors. These provide
encodings for:
• The OPTIONAL Performance Monitors Extension registers, summarized in Performance Monitors registers
on page C12-2314.
• Optional additional IMPLEMENTATION DEFINED performance monitors. Table B3-53 shows these reserved
encodings.
B3.18.11 Security Extensions registers, functional group

Table B3-54 shows the Security Extensions registers in a VMSA implementation.
Table B3-54 Security Extensions registers, VMSA only
ISR c12 0 c1 0 32-bit RO Interrupt Status Register
MVBAR c12 0 c0 1 32-bit RW Monitor Vector Base Address Register
NSACR c1 0 c1 2 32-bit RW Non-Secure Access Control Register
SCR c1 0 c1 0 32-bit RW Secure Configuration Register
SDER c1 0 c1 1 32-bit RW Secure Debug Enable Register
VBAR c12 0 c0 0 32-bit RW Vector Base Address Register
All the encodings shown in Table B3-54 are unallocated and UNPREDICTABLE on a processor that does not
implement the Security Extensions, see Accesses to unallocated CP14 and CP15 encodings on page B3-1443.
B3.18.12 Virtualization Extensions registers, functional group

This functional group comprises the registers added by the Virtualization Extensions. Table B3-55 shows the
Virtualization Extensions registers in a VMSA implementation.
Table B3-55 Virtualization Extensions registers, VMSA with Virtualization Extensions only
- c8 4 c3 {0, 1, 4} 32-bit WO Table B3-56 on page B3-1497 and Hyp mode TLB
maintenance operations, Virtualization Extensions on
c7 {0, 1, 4} 32-bit WO page B4-1741
HACR c1 4 c1 7 32-bit RW Hyp Auxiliary Configuration Register
HACTLR c1 4 c0 1 32-bit RW Hyp Auxiliary Control Register
HAMAIR0 c10 4 c3 0 32-bit RW Hyp Auxiliary Memory Attribute Indirection Register 0
HAMAIR1 1 32-bit RW Hyp Auxiliary Memory Attribute Indirection Register 1
HAxFSR c5 4 c1 0 32-bit RW Hyp Auxiliary Data Fault Syndrome Register
1 32-bit RW Hyp Auxiliary Instruction Fault Syndrome Register
HCPTR c1 4 c1 2 32-bit RW Hyp Coprocessor Trap Register
HCR c1 4 c1 0 32-bit RW Hyp Configuration Register
HDCR c1 4 c1 1 32-bit RW Hyp Debug Configuration Register
HDFAR c6 4 c0 0 32-bit RW Hyp Data Fault Address Register
HIFAR c6 4 c0 2 32-bit RW Hyp Instruction Fault Address Register
HMAIR0 c10 4 c2 0 32-bit RW Hyp Memory Attribute Indirection Register 0
HMAIR1 1 32-bit RW Hyp Memory Attribute Indirection Register 1
HPFAR c6 4 c0 4 32-bit RW Hyp IPA Fault Address Register
HSCTLR c1 4 c0 0 32-bit RW Hyp System Control Register
HSR c5 4 c2 0 32-bit RW Hyp Syndrome Register
HSTR c1 4 c1 3 32-bit RW Hyp System Trap Register
HTCR c2 4 c0 2 32-bit RW Hyp Translation Control Register
HTTBR - 4 c2 - 64-bit RW Hyp Translation Table Base Register
HVBAR c12 4 c0 0 32-bit RW Hyp Vector Base Address Register
VMPIDR c0 4 c0 5 32-bit RW Virtualization Multiprocessor ID Register
VPIDR c0 4 c0 0 32-bit RW Virtualization Processor ID Register
VTCR c2 4 c1 2 32-bit RW Virtualization Translation Control Register
VTTBR - 6 c2 - 64-bit RW Virtualization Translation Table Base Register
Table B3-56 on page B3-1497 lists the TLB maintenance operations added in this functional group and summarized
in Table B3-55.
Table B3-56 Hyp mode TLB maintenance operations, VMSA with Virtualization Extensions only
TLBIALLH b c8 4 c7 0 32-bit WO Invalidate entire Hyp unified TLB -
TLBIALLHIS b c8 4 c3 0 32-bit WO Invalidate entire Hyp unified TLB IS
TLBIALLNSNH b c8 4 c7 4 32-bit WO Invalidate entire Non-secure Non-Hyp -

unified TLB
TLBIALLNSNHIS b c8 4 c3 4 32-bit WO Invalidate entire Non-secure Non-Hyp IS

unified TLB
TLBIMVAH b c8 4 c7 1 32-bit WO Invalidate Hyp unified TLB by MVA -
TLBIMVAHIS b c8 4 c3 1 32-bit WO Invalidate Hyp unified TLB by MVA IS
a. IS = Inner Shareable.
b. The links in this column are to a summary of the operation, and Hyp mode TLB maintenance operations, Virtualization Extensions on
page B4-1741 describes the operation.
All the encodings shown in Table B3-55 on page B3-1496 are unallocated and UNPREDICTABLE on a processor that
does not implement the Virtualization Extensions, see Accesses to unallocated CP14 and CP15 encodings on
page B3-1443.
In addition to the registers shown in Table B3-55 on page B3-1496, the Virtualization Extensions add:
• the HTPIDR, see Miscellaneous operations, functional group on page B3-1494
• the PMOVSSET register, see Performance Monitors registers on page C12-2314
• the ATS1H* address translation operations, see Address translation operations, functional group on
page B3-1493 and Performing address translation operations on page B4-1742
• the DBGVIDSR, see Sample-based profiling registers on page C11-2188
• the DBGBXVRs, see Software debug event registers on page C11-2187
• if the implementation includes the Generic Timer Extension:

— the CNTHCTL, CNTHP_TVAL, CNTHP_CTL, and CNTHP_CVAL registers, see Generic Timer
registers summary on page B8-1955
— the CNTVOFF register as a RW register, see Status of the CNTVOFF register on page B8-1955.
B3.18.13 Generic Timer Extension registers

ARMv7 reserves CP15 primary coprocessor register c14 for access to the Generic Timer Extension registers. For
more information about these registers see Generic Timer registers summary on page B8-1955.
B3.18.14 IMPLEMENTATION DEFINED registers, functional group

ARMv7 reserves CP15 c15 for IMPLEMENTATION DEFINED purposes, and does not impose any restrictions on the
use of the CP15 c15 encodings. The documentation of the ARMv7 implementation must describe fully any registers
implemented in CP15 c15. Normally, for processor implementations by ARM, this information is included in the
Technical Reference Manual for the processor.
Typically, an implementation uses CP15 c15 to provide test features, and any required configuration options that
are not covered by this manual.
B3.19 Pseudocode details of VMSA memory system operations

This section contains pseudocode describing VMSA memory operations. The following subsections describe the
pseudocode functions:
• Alignment fault
• FCSE translation
• Address translation on page B3-1499
• Domain checking on page B3-1501
• TLB operations on page B3-1501
• Translation table walk on page B3-1501
• Writing to the HSR on page B3-1514
• Calling the hypervisor on page B3-1514
• Memory access decode when TEX remap is enabled on page B3-1515.
See also the pseudocode for general memory system operations in Pseudocode details of general memory system
operations on page B2-1291.
B3.19.1 Alignment fault

The following pseudocode describes the generation of an Alignment fault Data Abort exception:
// AlignmentFaultV()
// =================
AlignmentFaultV(bits(32) address, boolean iswrite, boolean taketohyp, boolean secondstageabort)
// parameters for calling DataAbort

bits(40) ipaddress = bits(40) UNKNOWN;
bits(4) domain = bits(4) UNKNOWN;
integer level = integer UNKNOWN;
boolean ipavalid = FALSE;
boolean LDFSRformat = taketohyp || TTBCR.EAE == '1';
boolean s2fs1walk = FALSE;
mva = FCSETranslate(address);
DataAbort(mva, ipaddress, domain, level, iswrite, DAbort_Alignment, taketohyp,
B3.19.2 FCSE translation

The following pseudocode describes the FCSE translation:
// FCSETranslate()
// ===============
bits(32) FCSETranslate(bits(32) va)

if va<31:25> == '0000000' then
mva = FCSEIDR.PID:va<24:0>;
// If FCSE is not implemented, FCSEIDR.PID is '0000000'
else
mva = va;
return mva;
B3.19.3 Address translation

The TranslateAddressV() pseudocode function describes address translation in a VMSA implementation. This
function calls either:
• the function described in Address translation when the stage 1 MMU is disabled on page B3-1500
• one of the functions described in Translation table walk on page B3-1501.
// TranslateAddressV()
// ===================
AddressDescriptor TranslateAddressV(bits(32) va, boolean ispriv, boolean iswrite,

integer size, boolean wasaligned)
AddressDescriptor result;
s2fs1walk = FALSE;
mva = FCSETranslate(va);
ishyp = CurrentModeIsHyp();
if (ishyp && HSCTLR.M == '1') || (!ishyp && SCTLR.M == '1') then

// Stage 1 translation enabled
if HaveVirtExt() && !IsSecure() && !ishyp && HCR.TGE == '1' then UNPREDICTABLE;
usesLD = ishyp || TTBCR.EAE == '1';
if usesLD then
ia_in = '00000000':mva;
tlbrecordS1 = TranslationTableWalkLD(ia_in, mva, iswrite, TRUE, s2fs1walk, size);
checkdomain = FALSE;
checkpermission = TRUE;
else
tlbrecordS1 = TranslationTableWalkSD(mva, iswrite, size);
checkdomain = TRUE;
checkpermission = TRUE;
else
tlbrecordS1 = TranslateAddressVS1Off(mva);
checkdomain = FALSE;
checkpermission = FALSE;
// Check for alignment issues if memory type is SO or Device

if !wasaligned && tlbrecordS1.addrdesc.memattrs.type IN {MemType_Device,MemType_StronglyOrdered} then
if !HaveVirtExt() then UNPREDICTABLE;
AlignmentFaultV(mva, iswrite, ishyp, secondstageabort);
// Check domain and permissions

if checkdomain then
checkpermission = CheckDomain(tlbrecordS1.domain, mva, tlbrecordS1.level, iswrite);
if checkpermission then
CheckPermission(tlbrecordS1.perms, mva, tlbrecordS1.level, tlbrecordS1.domain, iswrite,
ispriv, ishyp, usesLD);
if HaveVirtExt() && !IsSecure() && !ishyp then

if HCR.VM == '1' then
// Stage 2 translation enabled
s1outputaddr = tlbrecordS1.addrdesc.paddress.physicaladdress;
tlbrecordS2 = TranslationTableWalkLD(s1outputaddr, mva, iswrite,
FALSE, s2fs1walk, size);
// Check for alignment issues if memory type is SO or Device

if !wasaligned && tlbrecordS2.addrdesc.memattrs.type IN {MemType_Device,
MemType_StronglyOrdered} then
taketohypmode = TRUE;
secondstageabort = TRUE;
AlignmentFaultV(mva, is_write, taketohypmode, secondstageabort);
// Check permissions
CheckPermissionS2(tlbrecordS2.perms, mva, s1outputaddr,
tlbrecordS2.level, iswrite, s2fs1walk);
result = CombineS1S2Desc(tlbrecordS1.addrdesc, tlbrecordS2.addrdesc);
else
result = tlbrecordS1.addrdesc;
else
result = tlbrecordS1.addrdesc;
return result;
Stage 2 translation table walk on page B3-1511 describes the CheckPermissionS2() and CombineS1S2Desc()
pseudocode functions.
Address translation when the stage 1 MMU is disabled

The TranslateAddressVS1Off() pseudocode function describes the address translation performed when the stage 1
MMU is disabled.
// TranslateAddressVS1Off()
// ========================
// Only called for data accesses. Does not define instruction fetch behavior.
TLBRecord TranslateAddressVS1Off(bits(32) va)
TLBRecord result;
if !HaveVirtExt() || HCR.DC == '0' || IsSecure() || CurrentModeIsHyp() then

result.addrdesc.memattrs.type = MemType_StronglyOrdered;
result.addrdesc.memattrs.innerattrs = bits(2) UNKNOWN;
result.addrdesc.memattrs.innerhints = bits(2) UNKNOWN;
result.addrdesc.memattrs.outerattrs = bits(2) UNKNOWN;
result.addrdesc.memattrs.outerhints = bits(2) UNKNOWN;
result.addrdesc.memattrs.shareable = TRUE;
result.addrdesc.memattrs.outershareable = TRUE;
else
result.addrdesc.memattrs.type = MemType_Normal;
result.addrdesc.memattrs.innerattrs = '11';
result.addrdesc.memattrs.innerhints = '11';
result.addrdesc.memattrs.outerattrs = '11';
result.addrdesc.memattrs.outerhints = '11';
result.addrdesc.memattrs.shareable = FALSE;
result.addrdesc.memattrs.outershareable = FALSE;
if HCR.VM != '1' then
UNPREDICTABLE;
result.perms.ap = bits(3) UNKNOWN;

result.perms.xn = '0';
result.perms.pxn = '0';
result.nG = bit UNKNOWN;
result.contiguousbit = boolean UNKNOWN;
result.domain = bits(4) UNKNOWN;
result.level = integer UNKNOWN;
result.blocksize = integer UNKNOWN;
result.addrdesc.paddress.physicaladdress = '00000000':va;
result.addrdesc.paddress.NS = if IsSecure() then '0' else '1';
return result;
B3.19.4 Domain checking

The following pseudocode describes domain checking:
// CheckDomain()
// =============
boolean CheckDomain(bits(4) domain, bits(32) mva, integer level, boolean iswrite)
// variables used for dataabort function

bits (40) ipaddress = bits(40) UNKNOWN;
boolean taketohypmode = FALSE;
boolean secondstageabort = FALSE;
boolean ipavalid = FALSE;
boolean LDFSRformat = FALSE;
boolean s2fs1walk = FALSE;
bitpos = 2*UInt(domain);
case DACR<bitpos+1:bitpos> of
when '00' DataAbort(mva, ipaddress, domain, level, iswrite, DAbort_Domain, taketohypmode,
when '01' permissioncheck = TRUE;
when '11' permissioncheck = FALSE;
return permissioncheck;
B3.19.5 TLB operations

The TLBRecord type represents the contents of a TLB entry:
// Types of TLB entry
enumeration TLBRecType { TLBRecType_SmallPage,

TLBRecType_LargePage,
TLBRecType_Section,
TLBRecType_Supersection,
TLBRecType_MMUDisabled};
type TLBRecord is (
Permissions perms,
bit nG, // '0' = Global, '1' = not Global
bits(4) domain,
boolean contiguousbit,
integer level, // generalises Section/Page to Table level
integer blocksize, // describes size of memory translated in KBytes
AddressDescriptor addrdesc
)
B3.19.6 Translation table walk

Because of the complexity of a translation table walk, the following sections describe the different cases:
• Translation table walk using the Short-descriptor translation table format for stage 1 on page B3-1502
• Translation table walk using the Long-descriptor translation table format for stage 1 on page B3-1505
• Stage 2 translation table walk on page B3-1511.
Translation table walk using the Short-descriptor translation table format for stage 1
The TranslationTableWalkSD() pseudocode function describes the translation table walk when the stage 1 translation
tables use the Short-descriptor format. It calls the function described in Stage 2 translation table walk on
page B3-1511 if necessary:
// TranslationTableWalkSD()
// ========================
//
// Returns a result of a translation table walk using
// the Short-descriptor format for TLBRecord
//
// Implementations might cache information from memory in any
// number of non-coherent TLB caching structures, and so avoid
// memory accesses that have been expressed in this pseudocode
// The use of such TLBs is not expressed in this pseudocode.
TLBRecord TranslationTableWalkSD(bits(32) mva, boolean is_write, integer size)
// this is only called when the MMU is enabled

TLBRecord result;
AddressDescriptor l1descaddr;
AddressDescriptor l2descaddr;
// variables for DAbort function

taketohypmode = FALSE;
IA = bits(40) UNKNOWN;
ipavalid = FALSE;
stage2 = FALSE;
LDFSRformat = FALSE;
s2fs1walk = FALSE;
// default setting of the domain

domain = bits(4) UNKNOWN;
// Determine correct Translation Table Base Register to use.

bits(64) ttbr;
n = UInt(TTBCR.N);
if n == 0 || IsZero(mva<31:(32-n)>) then
ttbr = TTBR0;
disabled = (TTBCR.PD0 == '1');
else
ttbr = TTBR1;
disabled = (TTBCR.PD1 == '1');
n = 0; // TTBR1 translation always works like N=0 TTBR0 translation
// Check this Translation Table Base Register is not disabled.

if HaveSecurityExt() && disabled then
level = 1;
DataAbort(mva, IA, domain, level, is_write, DAbort_Translation,
taketohypmode, stage2, ipavalid, LDFSRformat, s2fs1walk);
// Obtain First level descriptor.

l1descaddr.paddress.physicaladdress = '00000000' : ttbr<31:(14-n)> : mva<(31-n):20> : '00';
l1descaddr.paddress.NS = if IsSecure() then '0' else '1';
l1descaddr.memattrs.type = MemType_Normal;
l1descaddr.memattrs.shareable = (ttbr<1> == '1');
l1descaddr.memattrs.outershareable = (ttbr<5> == '0' && ttbr<1> == '1');
hintsattrs = ConvertAttrsHints(ttbr<4:3>);
l1descaddr.memattrs.outerattrs = hintsattrs<1:0>;
l1descaddr.memattrs.outerhints = hintsattrs<3:2>;
if HaveMPExt() then
hintsattrs = ConvertAttrsHints(ttbr<0>:ttbr<6>);
l1descaddr.memattrs.innerattrs = hintsattrs<1:0>;
l1descaddr.memattrs.innerhints = hintsattrs<3:2>;
else
if ttbr<0> == '0' then
hintsattrs = ConvertAttrsHints('00');
l1descaddr.memattrs.innerattrs = hintsattrs<1:0>;
l1descaddr.memattrs.innerhints = hintsattrs<3:2>;
else
l1descaddr.memattrs.innerattrs = IMPLEMENTATION_DEFINED 10 or 11;
l1descaddr.memattrs.innerhints = IMPLEMENTATION_DEFINED 01 or 11;
if !HaveVirtExt() || IsSecure() then

// if only 1 stage of translation
l1descaddr2 = l1descaddr;
else
l1descaddr2 = SecondStageTranslate(l1descaddr, mva, 4, is_write);
l1desc = _Mem[l1descaddr2, 4];

if SCTLR.EE == '1' then
l1desc = BigEndianReverse(l1desc, 4);
// Process First level descriptor.

case l1desc<1:0> of
when '00' // Fault, Reserved
level = 1;
when '01' // Large page or Small page

domain = l1desc<8:5>;
level = 2;
pxn = l1desc<2>;
NS = l1desc<3>;
// Obtain Second level descriptor.

l2descaddr.paddress.physicaladdress = Zeros(8) : l1desc<31:10>:mva<19:12>:'00';
l2descaddr.paddress.NS = if IsSecure() then '0' else '1';
l2descaddr.memattrs = l1descaddr.memattrs;
if !HaveVirtExt() || IsSecure() then
l2descaddr2 = l2descaddr;
else
l2descaddr2 = SecondStageTranslate(l2descaddr, mva, 4, is_write);
l2desc = _Mem[l2descaddr2, 4];
l2desc = BigEndianReverse(l2desc,4);
// Process Second level descriptor.

if l2desc<1:0> == '00' then
S = l2desc<10>;
ap = l2desc<9,5:4>;
nG = l2desc<11>;
if SCTLR.AFE == '1' && l2desc<4> == '0' then

if SCTLR.HA == '0' then
DataAbort(mva, IA, domain, level, is_write, DAbort_AccessFlag,
taketohypmode, stage2, ipavalid, LDFSRformat,
s2fs1walk);
else // Hardware-managed Access flag must be set in memory
_Mem[l2descaddr2,4]<28> = '1';
else
if l2desc<1> == '0' then // Large page

texcb = l2desc<14:12,3,2>;
xn = l2desc<15>;
blocksize = 64;
physicaladdressext = '00000000';
physicaladdress = l2desc<31:16>:mva<15:0>;
else // Small page
texcb = l2desc<8:6,3,2>;
xn = l2desc<0>;
blocksize = 4;
when "1x" // Section or Supersection

texcb = l1desc<14:12,3,2>;
S = l1desc<16>;
ap = l1desc<15,11:10>;
xn = l1desc<4>;
pxn = l1desc<0>;
nG = l1desc<17>;
level = 1;
NS = l1desc<19>;
if SCTLR.AFE == '1' && l1desc<10> == '0' then

if SCTLR.HA == '0' then
DataAbort(mva, IA, domain, level, is_write,
DAbort_AccessFlag, taketohypmode, stage2,
ipavalid, LDFSRformat, s2fs1walk);
else // Hardware-managed Access flag must be set in memory
else
if l1desc<18> == '0' then // Section

domain = l1desc<8:5>;
blocksize = 1024;
else // Supersection
domain = '0000';
blocksize = 16384;
physicaladdressext = l1desc<8:5,23:20>;
// Decode the TEX, C, B and S bits to produce the TLBRecord's memory attributes
if SCTLR.TRE == '0' then
if RemapRegsHaveResetValues() then
result.addrdesc.memattrs = DefaultTEXDecode(texcb, S);
else
IMPLEMENTATION_DEFINED setting of result.addrdesc.memattrs;
else
result.addrdesc.memattrs = RemappedTEXDecode(texcb, S);
// transient bits are not supported in this format

result.addrdesc.memattrs.innertransient = FALSE;
result.addrdesc.memattrs.outertransient = FALSE;
// Set the rest of the TLBRecord, try to add it to the TLB, and return it.
result.perms.ap = ap;
result.perms.xn = xn;
result.perms.pxn = pxn;
result.nG = nG;
result.domain = domain;
result.level = level;
result.blocksize = blocksize;
result.addrdesc.paddress.physicaladdress = physicaladdressext:physicaladdress;
result.addrdesc.paddress.NS = if IsSecure() then NS else '1';
return result;
The ConvertAttrsHints() pseudocode function converts the Normal memory cacheability attribute, from the
translation table base register or the translation table TEX field, into the separate cacheability attribute and cache
allocation hint defined in a Long-descriptor translation table descriptor:
// ConvertAttrsHints()
// ===================
bits(4) ConvertAttrsHints(bits(2) RGN)

// Converts the Short-descriptor attribute fields for Normal memory as used
// in the TTBR and TEX fields to the orthogonal concepts of Attributes and Hints
bits(2) attributes;
bits(2) hints;
if RGN == '00' then // Non-cacheable

attributes = '00';
hints = '00';
elsif RGN<0> == '1' then // Write-Back
attributes = '11';
hints = '1':NOT(RGN<1>);
else
attributes = '10'; // Write-Through
hints = '10';
return hints:attributes;
Translation table walk using the Long-descriptor translation table format for stage 1
The TranslationTableWalkLD() pseudocode function describes the translation table walk when the stage 1 translation
tables use the Long-descriptor format. It calls the function described in Stage 2 translation table walk on
page B3-1511 if necessary:
// TranslationTableWalkLD()
// ========================
//
// Returns a result of a translation table walk using
// the longdescriptor in TLBRecord form
//
// Implementations might cache information from memory in any
// number of non-coherent TLB caching structures, and so avoid
// memory accesses that have been expressed in this pseudocode
// The use of such TLBs is not expressed in this pseudocode.
TLBRecord TranslationTableWalkLD(bits(40) IA, bits(32) va,

boolean is_write, boolean stage1,
boolean s2fs1walk, integer size)
TLBRecord result;
AddressDescriptor walkaddr;

LDFSRformat = TRUE;
bits(40) BaseAddress;
BaseAddress = Zeros(40);
BaseFound = FALSE;
Disabled = FALSE;
if stage1 then
// executing in Hyp mode
LookupSecure = FALSE;
T0Size = UInt(HTCR.T0SZ);
if T0Size == 0 || IsZero(IA<31:(32-T0Size)>) then
CurrentLevel = (if HTCR.T0SZ<2:1> == '00' then 1 else 2);
BALowerBound = 9*CurrentLevel - T0Size - 4;
BaseAddress = HTTBR<39:BALowerBound>:Zeros(BALowerBound);
if !IsZero(HTTBR<BALowerBound-1:3>) then UNPREDICTABLE;
BaseFound = TRUE;
StartBit = 31-T0Size;
// unpack type information from HTCR

walkaddr.memattrs.type = MemType_Normal;
hintsattrs = ConvertAttrsHints(HTCR.IRGN0);
walkaddr.memattrs.innerhints = hintsattrs<3:2>;
walkaddr.memattrs.innerattrs = hintsattrs<1:0>;
hintsattrs = ConvertAttrsHints(HTCR.ORGN0);
walkaddr.memattrs.outerhints = hintsattrs<3:2>;
walkaddr.memattrs.outerattrs = hintsattrs<1:0>;
walkaddr.memattrs.shareable = (HTCR.SH0<1> == '1');
walkaddr.memattrs.outershareable = (HTCR.SH0 == '10');
walkaddr.memattrs.shareable = (HTCR.SH0<1> == '1');
walkaddr.memattrs.outershareable = (HTCR.SH0 == '10');
walkaddr.paddress.NS = '1';
else
// not executing in Hyp mode
LookupSecure = IsSecure();
T0Size = UInt(TTBCR.T0SZ);
if T0Size == 0 || IsZero(IA<31:(32-T0Size)>) then
CurrentLevel = (if TTBCR.T0SZ<2:1> == '00' then 1 else 2);
BaseAddress = TTBR0<39:BALowerBound>:Zeros(BALowerBound);
if !IsZero(TTBR0<BALowerBound-1:3>) then UNPREDICTABLE;
BaseFound = TRUE;
Disabled = (TTBCR.EPD0 == '1');
// unpack type information from TTBCR

hintsattrs = ConvertAttrsHints(TTBCR.IRGN0);
hintsattrs = ConvertAttrsHints(TTBCR.ORGN0);
walkaddr.memattrs.shareable = (TTBCR.SH0<1> == '1');
walkaddr.memattrs.outershareable = (TTBCR.SH0 == '10');
T1Size = UInt(TTBCR.T1SZ);
if (T1Size == 0 && !BaseFound) || IsOnes(IA<31:(32-T1Size)>) then
CurrentLevel = (if TTBCR.T1SZ<2:1> == '00' then 1 else 2);
BaseAddress = TTBR1<39:BALowerBound>:Zeros(BALowerBound);
if !IsZero(TTBR1<BALowerBound-1:3>) then UNPREDICTABLE;
BaseFound = TRUE;
Disabled = (TTBCR.EPD1 == '1');
// unpack type information from TTBCR

hintsattrs = ConvertAttrsHints(TTBCR.IRGN1);
hintsattrs = ConvertAttrsHints(TTBCR.ORGN1);
walkaddr.memattrs.shareable = (TTBCR.SH1<1> == '1');
walkaddr.memattrs.outershareable = (TTBCR.SH1 == '10');
else
// not a stage 1 translation
T0Size = SInt(VTCR.T0SZ);
SLevel = UInt(VTCR.SL0);
BALowerBound = 14 - T0Size - 9*SLevel;
// check UNPREDICTABLE combinations of the Starting level and Size fields
// and check the VTTBR is aligned correctly
if SLevel == 0 && T0Size < -2 then UNPREDICTABLE;

if SLevel == 1 && T0Size > 1 then UNPREDICTABLE;
if VTCR.SL0<1> == '1' then UNPREDICTABLE;
if IsZero(VTTBR<BALowerBound-1:3>) == FALSE then UNPREDICTABLE;
if T0Size == -8 || IsZero(IA<39:(32-T0Size)>) then

CurrentLevel = 2-SLevel;
BaseAddress = VTTBR<39:BALowerBound>:Zeros(BALowerBound);
BaseFound = TRUE;
LookupSecure = FALSE;
// unpack type information from VTCR

hintsattrs = ConvertAttrsHints(VTCR.IRGN0);
hintsattrs = ConvertAttrsHints(VTCR.ORGN0);
walkaddr.memattrs.shareable = (VTCR.SH0<1> == '1');
walkaddr.memattrs.outershareable = (VTCR.SH0 == '10');
if !BaseFound || Disabled then

taketohypmode = CurrentModeIsHyp() || !stage1;
level = 1;
ipavalid = !stage1;
DataAbort(va, IA, domain, level, is_write, DAbort_Translation,
taketohypmode, !stage1, ipavalid, LDFSRformat, s2fs1walk);
FirstIteration = TRUE;
TableRW = TRUE;
TableUser = TRUE;
TableXN = FALSE;
TablePXN = FALSE;
repeat
LookUpFinished = TRUE;
BlockTranslate = FALSE;
Offset = 9*CurrentLevel;
if FirstIteration then
IASelect = ZeroExtend(IA<StartBit:39-Offset>:'000', 40);
else
IASelect = ZeroExtend(IA<47-Offset:39-Offset>:'000', 40);
LookupAddress = BaseAddress OR IASelect;
FirstIteration = FALSE;
// If there are two stages of translation, then the stage 1

// table walk addresses are themselves subject to translation
walkaddr.paddress.physicaladdress = LookupAddress;
if LookupSecure then
else
if !HaveVirtExt() || !stage1 || IsSecure() || CurrentModeIsHyp() then
if HaveVirtExt() && (CurrentModeIsHyp() || !stage1) then
bigendian = (HSCTLR.EE == '1');
else
bigendian = (SCTLR.EE == '1');
Descriptor = _Mem[walkaddr,8];
if bigendian then
Descriptor = BigEndianReverse(Descriptor,8);
else
walkaddr2 = SecondStageTranslate(walkaddr, IA<31:0>, 8, is_write);
Descriptor = _Mem[walkaddr2, 8] ;
Descriptor = BigEndianReverse(Descriptor,8);
if Descriptor<0> == '0' then

ipavalid = !stage1;
DataAbort(va, IA, domain, CurrentLevel, is_write,
DAbort_Translation, taketohypmode, !stage1,
else
if Descriptor<1> == '0' then
if CurrentLevel == 3 then
ipavalid = !stage1;

DAbort_Translation, taketohypmode, !stage1,
else
BlockTranslate = TRUE;
else
if CurrentLevel == 3 then
BlockTranslate = TRUE;
else // table translation
BaseAddress = Descriptor<39:12>:'000000000000';
LookupSecure = LookupSecure && (Descriptor<63> == '0');
TableRW = TableRW && (Descriptor<62> == '0');
TableUser = TableUser && (Descriptor<61> == '0');
TablePXN = TablePXN || (Descriptor<59> == '1');
TableXN = TableXN || (Descriptor<60> == '1');
LookUpFinished = FALSE;
if BlockTranslate then
OutputAddress = Descriptor<39:39-Offset> : IA<38-Offset:0>;
Attrs = Descriptor<54:52>: Descriptor<11:2>;
if stage1 then
if TableXN then Attrs<12> = '1';
if TablePXN then Attrs<11> = '1';
if IsSecure() && !(LookupSecure) then Attrs<9> = '1';
if !(TableRW) then Attrs<5> = '1';
if !(TableUser) then Attrs<4> = '0';
if !(LookupSecure) then Attrs<3> = '1';
else
CurrentLevel = CurrentLevel + 1;
until LookUpFinished;
// final Attrs<> bus contains:

// 12: XN
// 11: PXN
// 10: Contiguous Bit
// 9: nG
// 8: AccessFlag
// 7:6: Shareability
// 5: Stage 1: ReadOnly 0: Read/Write
// 4: Stage 1: User 0: Privileged only
// 5: Stage 2: Write permission
// 4: Stage 2: Read permission
// 3:0: Stage 2: Memory Type
// 3: Stage 1: Non-secure
// 2:0: Stage 1: Memory Type Index
// check the access flag

if Attrs<8> == '0' then
ipavalid = !stage1;
DAbort_AccessFlag, taketohypmode, !stage1,
result.perms.xn = Attrs<12>;
result.perms.pxn = Attrs<11>;
result.contiguousbit = Attrs<10>;
result.nG = Attrs<9>;
result.perms.ap<2:1> = Attrs<5:4>;
result.perms.ap<0> = '1';
if stage1 then
result.addrdesc.memattrs = MAIRDecode(Attrs<2:0>);
else
result.addrdesc.memattrs = S2AttrDecode(Attrs<3:0>);
if result.addrdesc.memattrs.type == MemType_Normal then

result.addrdesc.memattrs.shareable = (Attrs<7> == '1');
result.addrdesc.memattrs.outershareable = (Attrs<7:6> == '10');
else
result.addrdesc.memattrs.shareable = TRUE;
result.addrdesc.memattrs.outershareable = TRUE;
result.domain = bits(4) UNKNOWN; // domains not used

result.level = CurrentLevel;
result.blocksize = 512^(3-CurrentLevel)*4;
result.addrdesc.paddress.physicaladdress = OutputAddress<39:0>;
if stage1 then
result.addrdesc.paddress.NS = Attrs<3>;
else
result.addrdesc.paddress.NS = '1';
// not all bits are legal in Hyp mode

if stage1 && CurrentModeIsHyp() then
if Attrs<4> != '1' then UNPREDICTABLE;
if !TableUser then UNPREDICTABLE;
if !TablePXN then UNPREDICTABLE;
return result;
This function calls the ConvertAttrsHints() pseudocode function that is defined in Translation table walk using the
Short-descriptor translation table format for stage 1 on page B3-1502.
The MAIRDecode() pseudocode function uses the MAIRn registers to decode the Attr[2:0] value from a stage 1
translation table descriptor:
// MAIRDecode()
// ============
MemoryAttributes MAIRDecode(bits(3) attr)

// Converts the MAIR attributes to orthogonal attribute and
// hint fields.
mair = HMAIR1:HMAIR0;
else
mair = MAIR1:MAIR0;
index = UInt(attr);
attrfield = mair<8*index+7:8*index>;
if attrfield<7:4> == '0000' then

unpackinner = FALSE;

memattrs.innertransient = boolean UNKNOWN;
memattrs.outertransient = boolean UNKNOWN;
if attrfield<3:0> == '0000' then
elsif attrfield<3:0> == '0100' then
else
memattrs.type = IMPLEMENTATION_DEFINED;
memattrs.innerattrs = IMPLEMENTATION_DEFINED;
memattrs.outerattrs = IMPLEMENTATION_DEFINED;
memattrs.innerhints = IMPLEMENTATION_DEFINED;
memattrs.outerhints = IMPLEMENTATION_DEFINED;
memattrs.innertransient = IMPLEMENTATION_DEFINED;
memattrs.outertransient = IMPLEMENTATION_DEFINED;
elsif attrfield<7:6> =='00' then
unpackinner = TRUE;
if ImplementationSupportsTransient() then
memattrs.outerhints = attrfield<5:4>;
memattrs.outerattrs = '10'; //Write-through
memattrs.outertransient = TRUE;
else
elsif attrfield<7:6> =='01' then
unpackinner = TRUE;
if attrfield<5:4> == '00' then // Non-cacheable
memattrs.outertransient = FALSE;
else
memattrs.outerattrs = '11'; //Write-back
memattrs.outertransient = TRUE;
else
else
unpackinner = TRUE;
memattrs.outerattrs = attrfield<7:6>;
memattrs.outertransient = FALSE;
if unpackinner then
if attrfield<3> == '1' then
memattrs.innerhints = attrfield<1:0>;
memattrs.innerattrs = attrfield<3:2>;
memattrs.innertransient = FALSE;
elsif attrfield<2:0> == '100' then // Non-cacheable
memattrs.innertransient = TRUE;
else
if attrfield<2> == '0' then
memattrs.innerattrs = '10'; //Write-through
else
memattrs.innerattrs = '11'; //Write-back
else
memattrs.innerattrs = IMPLEMENTATION_DEFINED;
memattrs.innerhints = IMPLEMENTATION_DEFINED;
memattrs.innertransient = IMPLEMENTATION_DEFINED;
return memattrs;
The S2AttrDecode() pseudocode function decodes the Attr[3:0] value from a stage 2 translation table descriptor:
// S2AttrDecode()
// ==============
// Converts the Stage 2 attribute fields into
// orthogonal attributes and hints
MemoryAttributes S2AttrDecode(bits(4) attr)
if attr<3:2> == '00' then

if attr<1:0> == '00' then
elsif attr<1:0> == '01' then
else
memattrs.type = MemType UNKNOWN;
else
if attr<3> == '0' then // Non-cacheable
else // cacheable
memattrs.outerattrs = attr<3:2>;
if attr<1:0> == '00' then // Reserved

elsif attr<1> == '0' then // Non-cacheable
else // Cacheable
memattrs.innerattrs = attr<1:0>;
return memattrs;
Stage 2 translation table walk

The SecondStageTranslate() pseudocode function describes the stage 2 translation table walk. Stage 2 translations
tables always use the Long-descriptor format:
// SecondStageTranslate()
// ======================
// This function is called from a stage 1 translation table walk when

// the accesses generated from that requires a second stage of translation
AddressDescriptor SecondStageTranslate(AddressDescriptor s1outaddrdesc, bits(32) mva,

integer size, boolean is_write)
TLBRecord tlbrecordS2;

if HCR.VM == '1' then // second stage enabled
s2ia = s1outaddrdesc.paddress.physicaladdress;
stage1 = FALSE;
s2fs1walk = TRUE;
tlbrecordS2 = TranslationTableWalkLD(s2ia, mva, is_write,
stage1, s2fs1walk, size);
CheckPermissionS2(tlbrecordS2.perms, mva, s2ia, tlbrecordS2.level,
FALSE, s2fs1walk);
if HCR.PTW == '1' then
// protected table walk
if tlbrecordS2.addrdesc.memattrs.type != MemType_Normal then
ipavalid = TRUE;
LDFSRformat = TRUE;
s2fs1walk = TRUE;
DataAbort(mva, s2ia, domain, tlbrecordS2.level,
is_write, DAbort_Permission, taketohypmode,
result = CombineS1S2Desc(s1outaddrdesc, tlbrecordS2.addrdesc);
else
result = s1outaddrdesc;
return;
The CheckPermissionS2() pseudocode function checks the access permissions for the stage 2 translation.
Note
Access permission checking on page B2-1297 describes the equivalent function for stage 1 translations, because that
function is also used in the PMSA pseudocode.
// CheckPermissionS2()
// ===================
CheckPermissionS2(Permissions perms, bits(32) mva, bits(40) ipa,

integer level, boolean iswrite, boolean s2fs1walk)
abort = (iswrite && (perms.ap<2> == '0')) || (!iswrite && (perms.ap<1> == '0'));
if abort then
ipavalid = s2fs1walk;
LDFSRformat = TRUE;
DataAbort(mva, ipa, domain, level, iswrite, DAbort_Permission,
taketohypmode, secondstageabort, ipavalid, LDFSRformat,
s2fs1walk);
return;
The CombineS1S2Desc() pseudocode function combines the stage 1 and stage 2 address descriptors:
// CombineS1S2Desc()
// =================
AddressDescriptor CombineS1S2Desc(AddressDescriptor s1desc,

AddressDescriptor s2desc)
// Combines the address descriptors from stage 1 and stage 2
result.paddress = s2desc.paddress;
// default values:
result.memattrs.innerattrs = bits(2) UNKNOWN;
result.memattrs.outerattrs = bits(2) UNKNOWN;
result.memattrs.innerhints = bits(2) UNKNOWN;
result.memattrs.outerhints = bits(2) UNKNOWN;
result.memattrs.shareable = TRUE;
result.memattrs.outershareable = TRUE;
if s2desc.memattrs.type == MemType_StronglyOrdered ||
s1desc.memattrs.type == MemType_StronglyOrdered then
result.memattrs.type = MemType_StronglyOrdered;
elsif s2desc.memattrs.type == MemType_Device ||

s1desc.memattrs.type == MemType_Device then
result.memattrs.type = MemType_Device;
else
result.memattrs.type = MemType_Normal;
if result.memattrs.type == MemType_Normal then
if s2desc.memattrs.innerattrs == '01' ||
s1desc.memattrs.innerattrs == '01' then
// either encoding reserved
result.memattrs.innerattrs = bits(2) UNKNOWN;
elsif s2desc.memattrs.innerattrs == '00' ||
// either encoding Non-cacheable
result.memattrs.innerattrs = '00';
elsif s2desc.memattrs.innerattrs == '10' ||
// either encoding Write-Through cacheable
else
// both encodings Write-Back
if s2desc.memattrs.outerattrs == '01' ||
s1desc.memattrs.outerattrs == '01' then
// either encoding reserved
result.memattrs.outerattrs = bits(2) UNKNOWN;
if s2desc.memattrs.outerattrs == '00' ||
// either encoding Non-cacheable
result.memattrs.outerattrs = '00';
elsif s2desc.memattrs.outerattrs == '10' ||
// either encoding Write-Through cacheable
else
// both encodings Write-Back
result.memattrs.innerhints = s1desc.memattrs.innerhints;
result.memattrs.outerhints = s1desc.memattrs.outerhints;
result.memattrs.shareable = (s1desc.memattrs.shareable ||
s2desc.memattrs.shareable);
result.memattrs.outershareable = (s1desc.memattrs.outershareable ||
s2desc.memattrs.outershareable);
if result.memattrs.type == MemType_Normal then

if result.memattrs.innerattrs == '00' &&
result.memattrs.outerattrs == '00' then
// something Non-cacheable at each level is Outer Shareable
result.memattrs.outershareable = TRUE;
result.memattrs.shareable = TRUE;
return result;
B3.19.7 Writing to the HSR

The WriteHSR() pseudocode function writes a syndrome value to the HSR:
// WriteHSR()
// ==========
// Writes a syndrome into the HSR
WriteHSR(bits(6) ec, bits(25) HSRString)
bits(32) HSRValue = Zeros(32);
HSRValue<31:26> = ec;
// HSR.IL not valid for unknown reasons (0x00), Prefetch Aborts (0x20, 0x21), and Data
// Aborts (0x24, 0x25) for which the ISS information is not valid.
if UInt(ec) IN {0x00,0x20,0x21) || (UInt(ec) IN {0x24,0x25} && HSRString<24> == '1') then
HSRValue<25> = if ThisInstrLength() == 32 then '1' else '0';
// Condition code valid for EC[5:4] nonzero

if ec<5:4> == '00' && ec<3:0> != '0000' then
// in the ARM instruction set
HSRValue<24> = '1';
HSRValue<23:20> = CurrentCond();
else
HSRValue<24> = IMPLEMENTATION_DEFINED;
if HSRValue<24> == '1' then
HSRValue<23:20> = IMPLEMENTATION_DEFINED choice between CurrentCond() and '1110';
else
HSRValue<23:20> = CurrentCond();
HSRValue<19:0> = HSRString<19:0>;
else
HSRValue<24:0> = HSRString;
HSR = HSRValue;
return;
B3.19.8 Calling the hypervisor

The CallHypervisor() pseudocode function generates an HVC exception. Valid execution of the HVC instruction calls
this function.
// CallHypervisor()
// ================
//
// Performs a HVC call
CallHypervisor(bits(16) immediate)
HSRString<15:0> = immediate;
WriteHSR('010010', HSRString);
TakeHVCException();
B3.19.9 Memory access decode when TEX remap is enabled

When using the Short-descriptor translation table format, the function RemappedTEXDecode() decodes the texcb and
S attributes derived from the translation tables when TEX remap is enabled. Short-descriptor format memory region
attributes, with TEX remap on page B3-1364 shows the interpretation of the arguments.
// RemappedTEXDecode()
// ===================
MemoryAttributes RemappedTEXDecode(bits(5) texcb, bit S)
bits(4) hintsattrs;
region = UInt(texcb<2:0>); // texcb<4:3> are ignored in this mapping scheme
if region == 6 then
IMPLEMENTATION_DEFINED setting of memattrs;
else
case PRRR<(2*region+1):2*region> of
when '00'
memattrs.outershareable = TRUE;
when '01'
memattrs.outershareable = TRUE;
when '10'
hintsattrs = ConvertAttrsHints(NMRR<(2*region+1):2*region>);
memattrs.innerattrs = hintsattrs<1:0>;
memattrs.innerhints = hintsattrs<3:2>;
hintattrs = ConvertAttrsHints(NMRR<(2*region+17):(2*region+16)>);
memattrs.outerattrs = hintsattrs<1:0>;
memattrs.outerhints = hintsattrs<3:2>;
s_bit = if S == '0' then PRRR.NS0 else PRRR.NS1;

memattrs.shareable = (s_bit == '1');
memattrs.outershareable = (s_bit == '1') && (PRRR<region+24> == '0');
when '11' // reserved
memattrs.shareable = boolean UNKNOWN;
memattrs.outershareable = boolean UNKNOWN;
return memattrs;
Chapter B4
System Control Registers in a VMSA
implementation
This chapter describes the system control registers in a VMSA implementation. The registers are described in
alphabetic order. The chapter contains the following sections:
• VMSA System control registers descriptions, in register order on page B4-1518.
• VMSA system control operations described by function on page B4-1735.
Note
The architecture defines some registers identically for VMSAv7 and PMSAv7 implementations. Those registers are
described fully both in this chapter and in Chapter B6 System Control Registers in a PMSA implementation.
B4 System Control Registers in a VMSA implementation
B4.1 VMSA System control registers descriptions, in register order

This section describes all of the system control registers that might be present in a VMSAv7 implementation,
including registers that are part of an OPTIONAL architecture extension. Registers are shown in register name order.
Some register encodings provide functions that form part of a closely-related functional group, for example, the
encodings for cache maintenance operations. VMSA system control operations described by function on
page B4-1735 describes these operations. However, operations that have an architecturally-defined name also have
an alphabetic entry in VMSA System control registers descriptions, in register order. For example, the DCCISW
cache maintenance operation has a short entry in this section, DCCISW, Data Cache Clean and Invalidate by
Set/Way, VMSA on page B4-1555, that references its full description in Cache and branch predictor maintenance
operations, VMSA on page B4-1735.
B4.1.1 ACTLR, IMPLEMENTATION DEFINED Auxiliary Control Register, VMSA

The ACTLR characteristics are:
Purpose The ACTLR provides IMPLEMENTATION DEFINED configuration and control options.
This register is part of the Other system control registers functional group.
Usage constraints Only accessible from PL1 or higher.
Configurations If the implementation includes the Security Extensions, this register is Banked. However,
some bits might define global configuration settings, and be common to the Secure and
Non-secure copies of the register.
Attributes A 32-bit RW register. Because the register is IMPLEMENTATION DEFINED, the register reset
value is IMPLEMENTATION DEFINED. See also Reset behavior of CP14 and CP15 registers
on page B3-1446.
Table B3-47 on page B3-1489 shows the encodings of all of the registers in the Other
system control registers functional group.
The contents of this register are IMPLEMENTATION DEFINED. ARMv7 requires this register to be PL1 read/write
accessible, even if the implementation has not created any control bits in this register.
Accessing the ACTLR

To access the ACTLR, software reads or writes the CP15 registers with <opc1> set to 0, <CRn> set to c1, <CRm> set to
c0, and <opc2> set to 1. For example:
MRC p15, 0, <Rt>, c1, c0, 1 ; Read ACTLR into Rt

MCR p15, 0, <Rt>, c1, c0, 1 ; Write Rt to ACTLR
B4.1.2 ADFSR and AIFSR, Auxiliary Data and Instruction Fault Status Registers, VMSA
The ADFSR and AIFSR characteristics are:
Purpose The AxFSRs can provide additional IMPLEMENTATION DEFINED fault status information, see
Auxiliary Fault Status Registers on page B3-1407.
These registers are part of the PL1 Fault handling registers functional group.
Configurations These registers are not implemented in architecture versions before ARMv7.
If the implementation includes the Security Extensions, these registers are Banked.
Attributes 32-bit RW registers. Because these registers are IMPLEMENTATION DEFINED, the reset values
are IMPLEMENTATION DEFINED. See also Reset behavior of CP14 and CP15 registers on
page B3-1446.
Table B3-46 on page B3-1489 shows the encodings of all of the registers in the PL1 Fault
handling registers functional group.
The ADFSR and AIFSR bit assignments are IMPLEMENTATION DEFINED.
Accessing the ADFSR and AIFSR

To access the ADFSR or AIFSR, software reads or writes the CP15 registers with <opc1> set to 0, <CRn> set to c5,
<CRm> set to c1, and <opc2> set to:
• 0 for the ADFSR.
• 1 for the AIFSR.
For example:
MRC p15, 0, <Rt>, c5, c1, 0 ; Read ADFSR into Rt

MCR p15, 0, <Rt>, c5, c1, 0 ; Write Rt to ADFSR
MRC p15, 0, <Rt>, c5, c1, 1 ; Read AIFSR into Rt
MCR p15, 0, <Rt>, c5, c1, 1 ; Write Rt to AIFSR
B4.1.3 AIDR, IMPLEMENTATION DEFINED Auxiliary ID Register, VMSA

The AIDR characteristics are:
Purpose The AIDR provides IMPLEMENTATION DEFINED identification information.

This register is part of the Identification registers functional group.

The value of this register must be used in conjunction with the value of MIDR.
Configurations This register is not implemented in architecture versions before ARMv7.

In some ARMv7 implementations, this register is UNDEFINED.
If the implementation includes the Security Extensions, this register is Common.
Attributes A 32-bit RO register with an IMPLEMENTATION DEFINED value. See also Reset behavior of
CP14 and CP15 registers on page B3-1446.
Table B3-44 on page B3-1487 shows the encodings of all of the registers in the
Identification registers functional group.
The AIDR bit assignments are IMPLEMENTATION DEFINED.
Accessing the AIDR

To access the AIDR, software reads the CP15 registers with <opc1> set to 1, <CRn> set to c0, <CRm> set to c0, and
<opc2> set to 7. For example:
MRC p15, 1, <Rt>, c0, c0, 7 ; Read AIDR into Rt
B4.1.4 AIFSR, Auxiliary Instruction Fault Status Register, VMSA

ADFSR and AIFSR, Auxiliary Data and Instruction Fault Status Registers, VMSA on page B4-1519 describes the
AIFSR.
B4.1.5 AMAIR0 and AMAIR1, Auxiliary Memory Attribute Indirection Registers 0 and 1, VMSA
The AMAIR0 and AMAIR1 characteristics are:
Purpose When using the Long-descriptor format translation tables for stage 1 translations, AMAIR0
and AMAIR1 provide IMPLEMENTATION DEFINED memory attributes for the memory
regions specified by the MAIRn registers.
These registers are part of the Virtual memory control registers functional group.

If an implementation does not provide any IMPLEMENTATION DEFINED memory attributes,
these registers are UNK/SBZP. Otherwise, they are only valid when using the
Long-descriptor translation table format.
• The Secure copies of the registers give the values for memory accesses from Secure
state.
• The Non-secure copies of the registers give the values for memory accesses from
Non-secure modes other than Hyp mode.
Configurations AMAIR0 and AMAIR1 are implemented only as part of the Large Physical Address
Extension. In an implementation that includes the Security Extensions they:
• Are Banked.
• Have write access to the Secure copy of the register disabled when the
CP15SDISABLE signal is asserted HIGH.
Attributes 32-bit RW registers with UNKNOWN reset values. See also Reset behavior of CP14 and CP15
registers on page B3-1446.
Table B3-45 on page B3-1488 shows the encodings of all of the registers in the Virtual
memory control registers functional group.
The AMAIR0 and AMAIR1 bit assignments are IMPLEMENTATION DEFINED.
Note
In a typical implementation, AMAIR0 and AMAIR1 split into eight one-byte fields, corresponding to the
MAIRn.Attrm fields, but the architecture does not require them to do so.
Any IMPLEMENTATION DEFINED memory attributes are additional qualifiers for the memory locations and must not
change the architected behavior specified by the MAIRn registers.
Accessing AMAIR0 or AMAIR1

To access AMAIR0 or AMAIR1, software reads or writes the CP15 registers with <opc1> set to 0, <CRn> set to c10,
<CRm> set to c3, and <opc2> set to 0 for AMAIR0, or to 1 for AMAIR1. For example:
MRC p15, 0, <Rt>, c10, c3, 0 ; Read AMAIR0 into Rt

MCR p15, 0, <Rt>, c10, c3, 1 ; Write Rt to AMAIR1
B4.1.6 ATS12NSOPR, Address Translate Stages 1 and 2 Non-secure PL1 Read, VMSA only
Performing address translation operations on page B4-1742 describes this address translation operation.
This operation is part of the Address translation operations functional group. Table B3-51 on page B3-1493 shows
the encodings of all of the registers and operations in this functional group.
B4.1.7 ATS12NSOPW, Address Translate Stages 1 and 2 Non-secure PL1 Write, VMSA only
B4.1.8 ATS12NSOUR, Address Translate Stages 1 and 2 Non-secure Unprivileged Read, VMSA only
B4.1.9 ATS12NSOUW, Address Translate Stages 1 and 2 Non-secure Unprivileged Write, VMSA only
B4.1.10 ATS1CPR, Address Translate Stage 1 Current state PL1 Read, VMSA only
B4.1.11 ATS1CPW, Address Translate Stage 1 Current state PL1 Write, VMSA only
B4.1.12 ATS1CUR, Address Translate Stage 1 Current state Unprivileged Read, VMSA only
B4.1.13 ATS1CUW, Address Translate Stage 1 Current state Unprivileged Write, VMSA only
B4.1.14 ATS1HR, Address Translate Stage 1 Hyp mode Read, VMSA only
B4.1.15 ATS1HW, Address Translate Stage 1 Hyp mode Write, VMSA only
B4.1.16 BPIALL, Branch Predictor Invalidate All, VMSA

Cache and branch predictor maintenance operations, VMSA on page B4-1735 describes this branch predictor
maintenance operation.
This operation is part of the Cache maintenance operations functional group. Table B3-49 on page B3-1491 shows
B4.1.17 BPIALLIS, Branch Predictor Invalidate All, Inner Shareable, VMSA

B4.1.18 BPIMVA, Branch Predictor Invalidate by MVA, VMSA

B4.1.19 CCSIDR, Cache Size ID Registers, VMSA

The CCSIDR characteristics are:
Purpose The CCSIDR provides information about the architecture of the caches.

If CSSELR indicates a cache that is not implemented, the result of reading CCSIDR is
UNPREDICTABLE.
Configurations The implementation includes one CCSIDR for each cache that it can access. CSSELR
selects which Cache Size ID Register is accessible.
Architecture versions before ARMv7 do not define these registers.
If the implementation includes the Security Extensions, these registers are Common.
The CCSIDR bit assignments are:

31 30 29 28 27 13 12 3 2 0
NumSets Associativity LineSize
WA
RA
WB
WT
WT, bit[31] Indicates whether the cache level supports write-through, see Table B4-1.
WB, bit[30] Indicates whether the cache level supports write-back, see Table B4-1.
RA, bit[29] Indicates whether the cache level supports read-allocation, see Table B4-1.
WA, bit[28] Indicates whether the cache level supports write-allocation, see Table B4-1.
Table B4-1 WT, WB, RA and WA bit values
WT, WB, RA or WA bit value Meaning
0 Feature not supported
1 Feature supported
NumSets, bits[27:13]
(Number of sets in cache) - 1, therefore a value of 0 indicates 1 set in the cache. The number of sets
does not have to be a power of 2.
Associativity, bits[12:3]
(Associativity of cache) - 1, therefore a value of 0 indicates an associativity of 1. The associativity
does not have to be a power of 2.
LineSize, bits[2:0]
(Log2(Number of words in cache line)) -2. For example:
• For a line length of 4 words: Log2(4) = 2, LineSize entry = 0.
This is the minimum line length.

• For a line length of 8 words: Log2(8) = 3, LineSize entry = 1.
Note
The parameters NumSets, Associativity, and LineSize in these registers define the architecturally
visible parameters that are required for the cache maintenance by Set/Way instructions. They are not
guaranteed to represent the actual microarchitectural features of a design. You cannot make any
inference about the actual sizes of caches based on these parameters.
Accessing the currently selected CCSIDR

The CSSELR selects a CCSIDR. To access the currently-selected CCSIDR, software reads the CP15 registers with
<opc1> set to 1, <CRn> set to c0, <CRm> set to c0, and <opc2> set to 0. For example:
MRC p15, 1, <Rt>, c0, c0, 0 ; Read current CCSIDR into Rt
Any access to the CCSIDR when the value in CSSELR corresponds to a cache that is not implemented returns an
UNKNOWN value.
B4.1.20 CLIDR, Cache Level ID Register, VMSA

The CLIDR characteristics are:
Purpose The CLIDR identifies:

• The type of cache, or caches, implemented at each level, up to a maximum of seven
levels.
• The Level of Coherence (LoC) and Level of Unification (LoU) for the cache
hierarchy.

The CLIDR bit assignments are:

31 30 29 27 26 24 23 21 20 18 17 15 14 12 11 9 8 6 5 3 2 0
(0) (0) LoUU LoC LoUIS Ctype7 Ctype6 Ctype5 Ctype4 Ctype3 Ctype2 Ctype1
Bits[31:30] Reserved, UNK.
LoUU, bits[29:27]
Level of Unification Uniprocessor for the cache hierarchy, see Terminology for Clean, Invalidate,
and Clean and Invalidate operations on page B2-1273.
LoC, bits[26:24]
Level of Coherence for the cache hierarchy, see Terminology for Clean, Invalidate, and Clean and
Invalidate operations on page B2-1273.
LoUIS, bits[23:21]
Level of Unification Inner Shareable for the cache hierarchy, see Terminology for Clean, Invalidate,
and Clean and Invalidate operations on page B2-1273.
In an implementation that does not include the Multiprocessing Extensions, this field is RAZ.
Ctypen, bits[3(n - 1) + 2:3(n - 1)], for n = 1 to 7

Cache Type fields. Indicate the type of cache implemented at each level, from Level 1 up to a
maximum of seven levels of cache hierarchy. The Level 1 cache field, Ctype1, is bits[2:0], see
register diagram. Table B4-2 shows the possible values for each Ctypen field.
Table B4-2 Ctypen bit values
Ctypen value Meaning, cache implemented at this level
000 No cache
001 Instruction cache only
010 Data cache only
011 Separate instruction and data caches
Table B4-2 Ctypen bit values (continued)
Ctypen value Meaning, cache implemented at this level
100 Unified cache
101, 11X Reserved
If software reads the Cache Type fields from Ctype1 upwards, once it has seen a value of 0b000, no
caches exist at further-out levels of the hierarchy. So, for example, if Ctype3 is the first Cache Type
field with a value of 0b000, the values of Ctype4 to Ctype7 must be ignored.
The CLIDR describes only the caches that are under the control of the processor.
Accessing the CLIDR

To access the CLIDR, software reads the CP15 registers with <opc1> set to 1, <CRn> set to c0, <CRm> set to c0, and
MRC p15, 1, <Rt>, c0, c0, 1 ; Read CLIDR into Rt
B4.1.21 CNTFRQ, Counter Frequency register, VMSA

The CNTFRQ register characteristics are:
Purpose The CNTFRQ register indicates the clock frequency of the system counter.
This register is a Generic Timer register.
Usage constraints In an implementation that includes the Security Extensions, RW only from Secure PL1
modes, RO from Non-secure PL1 and PL2 modes.
Otherwise, RW only from PL1 modes.
In all implementations, when CNTKCTL.{PL0VCTEN, PL0PCTEN} is not set to 0b00, is
also RO from PL0 modes.
Configurations Implemented only as part of the Generic Timers Extension.

The VMSA, PMSA, and system level definitions of the register fields are identical.
In an implementation that includes the Security Extensions, this register is Common.
Attributes A 32-bit RW register with an UNKNOWN reset value.

Table B8-2 on page B8-1955 shows the encodings of all of the Generic Timer registers.
The CNTFRQ bit assignments are:

31 0
Clock frequency
Clock frequency, bits[31:0]

Indicates the system counter clock frequency, in Hz.
Note
Programming CNTFRQ does not affect the system clock frequency. However, on system initialization, CNTFRQ
must be correctly programmed with the system clock frequency, to make this value available to software. For more
information see Initializing and reading the system counter frequency on page B8-1947.
Accessing CNTFRQ
To access CNTFRQ, software reads or writes the CP15 registers with <opc1> set to 0, <CRn> set to c14, <CRm> set to
MRC p15, 0, <Rt>, c14, c0, 0 ; Read CNTFRQ into Rt

MCR p15, 0, <Rt>, c14, c0, 0 ; Write Rt to CNTFRQ
B4.1.22 CNTHCTL, Timer PL2 Control register, Virtualization Extensions

The CNTHCTL characteristics are:
Purpose Controls:
• Access to the following from Non-secure PL1 modes:
— The physical counter.
— The Non-secure PL1 physical timer.
• The generation of an event stream from the physical counter.
Usage constraints Only accessible from Hyp mode, or from Monitor mode when SCR.NS is set to 1, see
PL2-mode system control registers on page B3-1450.
Configurations Implemented only as part of the Generic Timers Extension, and only if the implementation
also includes the Virtualization Extensions.
This is a PL2-mode register, see Banked PL2-mode CP15 read/write registers on
page B3-1450.
Attributes A 32-bit RW register. See the field descriptions for information about the reset values.
In an ARMv7 implementation, the CNTHCTL bit assignments are:

31 8 7 4 3 2 1 0
Reserved, UNK/SBZP EVNTI
EVNTDIR
EVNTEN
PL1PCEN
PL1PCTEN
Bits[31:8] Reserved, UNK/SBZP.
EVNTI, bits[7:4] Selects which bit of CNTPCT is the trigger for the event stream generated from the physical
counter, when that stream is enabled. For example, if this field is 0b0110, CNTPCT[6] is the
trigger bit for the virtual counter event stream.
For more information, see Event streams on page B8-1950.
This field is UNKNOWN on reset.
EVNTDIR, bit[3] Controls which transition of the CNTPCT trigger bit, defined by EVNTI, generates an
event, when the event stream is enabled:
0 A 0 to 1 transition of the trigger bit triggers an event.
This bit is UNKNOWN on reset.
EVNTEN, bit[2] Enables the generation of an event stream from the physical counter:
0 Disables the event stream.
1 Enables the event stream.
This bit resets to 0.
PL1PCEN, bit[1] Controls whether the Non-secure copies of the physical timer registers are accessible from
Non-secure PL1 and PL0 modes:
0 The Non-secure CNTP_CVAL, CNTP_TVAL, and CNTP_CTL registers are
not accessible Non-secure PL1 and PL0 modes.
1 The Non-secure CNTP_CVAL, CNTP_TVAL, and CNTP_CTL registers are
accessible from Non-secure PL1 and PL0 modes.
PL1PCTEN, bit[0] Controls whether the physical counter, CNTPCT, is accessible from Non-secure PL1 and
PL0 modes:
0 The CNTPCT register is not accessible from Non-secure PL1 and PL0 modes.
1 The CNTPCT register is accessible from Non-secure PL1 and PL0 modes.
For more information, see Accessing the physical counter on page B8-1948.
Accessing CNTHCTL
To access CNTHCTL, software reads or writes the CP15 registers with <opc1> set to 4, <CRn> set to c14, <CRm> set to
MRC p15, 4, <Rt>, c14, c1, 0 ; Read CNTHCTL to Rt

MCR p15, 4, <Rt>, c14, c1, 0 ; Write Rt to CNTHCTL
B4.1.23 CNTHP_CTL, PL2 Physical Timer Control register, Virtualization Extension

The CNTHP_CTL characteristics are:
Purpose The control register for the Hyp mode physical timer.
page B3-1450.

The bit assignments of CNTHP_CTL are identical to those of CNTP_CTL.
Accessing CNTHP_CTL
To access CNTHP_CTL, software reads or writes the CP15 registers with <opc1> set to 4, <CRn> set to c14, <CRm> set
to c2, and <opc2> set to 1. For example:
MRC p15, 4, <Rt>, c14, c2, 1 ; Read CNTHP_CTL into Rt

MCR p15, 4, <Rt>, c14, c2, 1 ; Write Rt to CNTHP_CTL
B4.1.24 CNTHP_CVAL, PL2 Physical Timer CompareValue register, Virtualization Extensions

The CNTHP_CVAL characteristics are:
Purpose Holds the compare value for the Hyp mode physical timer.
page B3-1450.

The bit assignments of CNTHP_CVAL are identical to those of CNTP_CVAL.
Accessing CNTHP_CVAL
To access CNTHP_CVAL, software performs a 64-bit read or write of the CP15 registers with <CRm> set to c14 and
MRRC p15, 6, <Rt>, <Rt2>, c14 ; Read 64-bit CNTHP_CVAL into Rt (low word) and Rt2 (high word)
MCRR p15, 6, <Rt>, <Rt2>, c14 ; Write Rt (low word) and Rt2 (high word) to 64-bit CNTHP_CVAL
In these MRRC and MCRR instructions, Rt holds the least-significant word of CNTHP_CVAL, and Rt2 holds the
most-significant word.
B4.1.25 CNTHP_TVAL, PL2 Physical TimerValue register, Virtualization Extensions

The CNTHP_TVAL characteristics are:
Purpose Holds the timer value for the Hyp mode physical timer. This provides a 32-bit downcounter,
see Operation of the TimerValue views of the timers on page B8-1953.
When CNTHP_CTL.ENABLE is set to 0:
• A write to this register updates the register.
• The value held in the register continues to decrement.
• A read of the register returns an UNKNOWN value.
page B3-1450.

The bit assignments of CNTHP_TVAL are identical to those of CNTP_TVAL.
Accessing CNTHP_TVAL
To access CNTHP_TVAL, software reads or writes the CP15 registers with <opc1> set to 4, <CRn> set to c14, <CRm>
set to c2, and <opc2> set to 0. For example:
MRC p15, 4, <Rt>, c14, c2, 0 ; Read CNTHP_TVAL into Rt

MCR p15, 4, <Rt>, c14, c2, 0 ; Write Rt to CNTHP_TVAL
B4.1.26 CNTKCTL, Timer PL1 Control register, VMSA

The CNTKCTL characteristics are:
Purpose Controls:
• Access to the following from PL0 modes:
— The physical counter.
— The virtual counter.
— The PL1 physical timers.
— The virtual timer.
• The generation of an event stream from the virtual counter.
Usage constraints Accessible from Secure PL1 modes, and Non-secure PL1 and PL2 modes.

The VMSA and PMSA definitions of the register fields are identical.
Attributes A 32-bit RW register. See the field descriptions for information about the reset values.
In an ARMv7 implementation, the CNTKCTL register bit assignments are:

31 10 9 8 7 4 3 2 1 0
Reserved, UNK/SBZP EVNTI
PL0PTEN EVNTDIR
PL0VTEN EVNTEN
PL0VCTEN
PL0PCTEN
PL0PTEN, bit[9] Controls whether the physical timer registers are accessible from PL0 modes:
0 The CNTP_CVAL, CNTP_CTL, and CNTP_TVAL registers are not accessible
from PL0.
1 The CNTP_CVAL, CNTP_CTL, and CNTP_TVAL registers are accessible
from PL0.
PL0VTEN, bit[8] Controls whether the virtual timer registers are accessible from PL0 modes:
0 The CNTV_CVAL, CNTV_CTL, and CNTV_TVAL registers are not
accessible from PL0.
1 The CNTV_CVAL, CNTV_CTL, and CNTV_TVAL registers are accessible
from PL0.
EVNTI, bits[7:4] Selects which bit of CNTVCT is the trigger for the event stream generated from the virtual
counter, when that stream is enabled. For example, if this field is 0b0110, CNTVCT[6] is the
trigger bit for the virtual counter event stream.
This field is UNKNOWN on reset.
EVNTDIR, bit[3] Controls which transition of the CNTVCT trigger bit, defined by EVNTI, generates an
event, when the event stream is enabled:
This bit is UNKNOWN on reset.
EVNTEN, bit[2] Enables the generation of an event stream from the virtual counter:
0 Disables the event stream.
1 Enables the event stream.
PL0VCTEN, bit[1] Controls whether the virtual counter, CNTVCT, and the frequency register CNTFRQ, are
accessible from PL0 modes:
0 CNTVCT is not accessible from PL0.
If PL0PCTEN is set to 0, CNTFRQ is not accessible from PL0.
1 CNTVCT and CNTFRQ are accessible from PL0.
For more information, see Accessing the virtual counter on page B8-1949.
PL0PCTEN, bit[0] Controls whether the physical counter, CNTPCT, and the frequency register CNTFRQ, are
accessible from PL0 modes:
0 CNTPCT is not accessible from PL0 modes.
If PL0VCTEN is set to 0, CNTFRQ is not accessible from PL0.
1 CNTPCT and CNTFRQ are accessible from PL0.
For more information, see Accessing the physical counter on page B8-1948.
Note
CNTFRQ is accessible from PL0 modes if either PL0VCTEN or PL0PCTEN is set to 1.
Accessing CNTKCTL
To access CNTKCTL, software reads or writes the CP15 registers with <opc1> set to 0, <CRn> set to c14, <CRm> set to
MRC p15, 0, <Rt>, c14, c1, 0 ; Read CNTKCTL to Rt

MCR p15, 0, <Rt>, c14, c1, 0 ; Write Rt to CNTKCTL
B4.1.27 CNTP_CTL, PL1 Physical Timer Control register, VMSA

The CNTP_CTL characteristics are:
Purpose The control register for the physical timer.

Usage constraints In an implementation that does not include the Virtualization Extensions, accessible in PL1
modes.
• The Secure copy of the register is accessible in Secure PL1 modes.
• The Non-secure copy of the register is accessible in Non-secure Hyp mode, and when
CNTHCTL.PL1PCEN is set to 1, in Non-secure PL1 modes.
When the register is accessible in PL1 modes, in the current security state,
CNTKCTL.PL0PTEN determines whether the register is accessible from the PL0 mode.

If the implementation includes the Security Extensions, this register is Banked.

In an ARMv7 implementation, the CNTP_CTL bit assignments are:

31 3 2 1 0
Reserved, UNK/SBZP
ISTATUS
IMASK
ENABLE
ISTATUS, bit[2] The status of the timer. This bit indicates whether the timer condition is asserted:
0 Timer condition is not asserted.
1 Timer condition is asserted.
When the ENABLE bit is set to 1, ISTATUS indicates whether the timer value meets the
condition for the timer output to be asserted, see Operation of the CompareValue views of
the timers on page B8-1952 and Operation of the TimerValue views of the timers on
page B8-1953. ISTATUS takes no account of the value of the IMASK bit. If ISTATUS is set
to 1 and IMASK is set to 0 then the timer output signal is asserted.
This bit is read-only.
IMASK, bit[1] Timer output signal mask bit. Permitted values are:
0 Timer output signal is not masked.
1 Timer output signal is masked.
For more information, see the description of the ISTATUS bit and Operation of the timer
output signal on page B8-1954.
ENABLE, bit[0] Enables the timer. Permitted values are:

0 Timer disabled.
1 Timer enabled.
Setting this bit to 0 disables the timer output signal, but the timer value accessible from
CNTP_TVAL continues to count down.
Note
Disabling the output signal might be a power-saving option.
Accessing CNTP_CTL
To access CNTP_CTL, software reads or writes the CP15 registers with <opc1> set to 0, <CRn> set to c14, <CRm> set
MRC p15, 0, <Rt>, c14, c2, 1 ; Read CNTP_CTL into Rt

MCR p15, 0, <Rt>, c14, c2, 1 ; Write Rt to CNTP_CTL
B4.1.28 CNTP_CVAL, PL1 Physical Timer CompareValue register, VMSA

The CNTP_CVAL characteristics are:
Purpose Holds the 64-bit compare value for the PL1 physical timer.
modes.


In an ARMv7 implementation, the CNTP_CVAL bit assignments are:
63 0
CompareValue[63:0]
CompareValue, bits[63:0]
Indicates the compare value for the PL1 physical timer.
For more information about the timer see Timers on page B8-1951.
Accessing CNTP_CVAL
To access CNTP_CVAL, software performs a 64-bit read or write of the CP15 registers with <CRm> set to c14 and
MRRC p15, 2, <Rt>, <Rt2>, c14 ; Read 64-bit CNTP_CVAL into Rt (low word) and Rt2 (high word)
MCRR p15, 2, <Rt>, <Rt2>, c14 ; Write Rt (low word) and Rt2 (high word) to 64-bit CNTP_CVAL
In these MRRC and MCRR instructions, Rt holds the least-significant word of CNTP_CVAL, and Rt2 holds the
B4.1.29 CNTP_TVAL, PL1 Physical TimerValue register, VMSA

The CNTP_TVAL characteristics are:
Purpose Holds the timer value for the PL1 physical timer. This provides a 32-bit downcounter, see
Operation of the TimerValue views of the timers on page B8-1953.
modes.
When CNTP_CTL.ENABLE is set to 0:


In an ARMv7 implementation, the CNTP_TVAL bit assignments are:

31 0
TimerValue
TimerValue, bits[31:0]
Indicates the timer value.
Accessing CNTP_TVAL
To access CNTP_TVAL, software reads or writes the CP15 registers with <opc1> set to 0, <CRn> set to c14, <CRm> set
MRC p15, 0, <Rt>, c14, c2, 0 ; Read CNTP_TVAL into Rt

MCR p15, 0, <Rt>, c14, c2, 0 ; Write Rt to CNTP_TVAL
B4.1.30 CNTPCT, Physical Count register, VMSA

The CNTPCT register characteristics are:
Purpose The CNTPCT register holds the 64-bit physical count value.
Usage constraints In an implementation that does not include the Virtualization Extensions, always accessible
from PL1 modes, in both security states.
In an implementation that includes the Virtualization Extensions, CNTPCT is:
• Always accessible Secure PL1 modes and from Non-secure Hyp mode.
• Accessible from Non-secure PL1 modes only when CNTHCTL.PL1PCTEN is set
to 1.
When CNTKCTL.PL0PCTEN is set to 1, CNTPCT is also accessible from PL0 modes.
Fore more information about the CNTPCT access controls see Accessing the physical
counter on page B8-1948.

Attributes A 64-bit RO register with an UNKNOWN reset value.

The CNTPCT bit assignments are:
63 0
PhysicalCount[63:0]
PhysicalCount, bits[63:0]
Indicates the physical count.
Accessing CNTPCT
To access CNTPCT, software performs a 64-bit read of the CP15 registers with <CRm> set to c14 and <opc1> set to 0.
For example:
MRRC p15, 0, <Rt>, <Rt2>, c14 ; Read 64-bit CNTPCT into Rt (low word) and Rt2 (high word)
In the MRRC instruction, Rt holds the least-significant word of CNTPCT, and Rt2 holds the most-significant word.
B4.1.31 CNTV_CTL, Virtual Timer Control register, VMSA

The CNTV_CTL register characteristics are:
Purpose The control register for the virtual timer.

Usage constraints Accessible from Secure PL1 modes and Non-secure PL1 and PL2 modes. When
CNTKCTL.PL0VTEN is set to 1, also accessible from PL0 modes.


The bit assignments of the CNTV_CTL register are identical to those of CNTP_CTL.
Accessing CNTV_CTL
To access CNTV_CTL, software reads or writes the CP15 registers with <opc1> set to 0, <CRn> set to c14, <CRm> set
MRC p15, 0, <Rt>, c14, c3, 1 ; Read CNTV_CTL into Rt

MCR p15, 0, <Rt>, c14, c3, 1 ; Write Rt to CNTV_CTL
B4.1.32 CNTV_CVAL, Virtual Timer CompareValue register, VMSA

The CNTV_CVAL characteristics are:
Purpose Holds the compare value for the virtual timer.



The bit assignments of CNTV_CVAL are identical to those of CNTP_CVAL.
Accessing CNTV_CVAL
To access CNTV_CVAL, software performs a 64-bit read or write of the CP15 registers with <CRm> set to c14 and
MRRC p15, 3, <Rt>, <Rt2>, c14 ; Read 64-bit CNTV_CVAL into Rt (low word) and Rt2 (high word)
MCRR p15, 3, <Rt>, <Rt2>, c14 ; Write 64-bit Rt (low word) and Rt2 (high word) to CNTV_CVAL
In these MRRC and MCRR instructions, Rt holds the least-significant word of CNTV_CVAL, and Rt2 holds the
B4.1.33 CNTV_TVAL, Virtual TimerValue register, VMSA

The CNTV_TVAL characteristics are:
Purpose Holds the timer value for the virtual timer. This provides a 32-bit downcounter, see
Operation of the TimerValue views of the timers on page B8-1953.
When CNTV_CTL.ENABLE is set to 0:


The bit assignments of CNTV_TVAL are identical to those of CNTP_TVAL.
Accessing CNTV_TVAL
To access CNTV_TVAL, software reads or writes the CP15 registers with <opc1> set to 0, <CRn> set to c14, <CRm> set
MRC p15, 0, <Rt>, c14, c3, 0 ; Read CNTV_TVAL into Rt

MCR p15, 0, <Rt>, c14, c3, 0 ; Write Rt to CNTV_TVAL
B4.1.34 CNTVCT, Virtual Count register, VMSA

The CNTVCT characteristics are:
Purpose Holds the 64-bit virtual count.
Note
The virtual count is obtained by subtracting the virtual offset from the physical count, see
The virtual counter on page B8-1949.
Usage constraints Always accessible from Secure PL1 modes and Non-secure PL1 and PL2 modes.
When CNTKCTL.PL0VCTEN is set to 1, is also accessible from Secure and Non-secure
PL0 modes. For more information about the CNTVCT access controls see Accessing the
virtual counter on page B8-1949.

Attributes A 64-bit RO register with an UNKNOWN reset value.

In an ARMv7 implementation, the CNTVCT bit assignments are:
63 0
VirtualCount[63:0]
VirtualCount, bits[63:0]
Indicates the virtual count.
Accessing CNTVCT
To access CNTVCT, software performs a 64-bit read of the CP15 registers with <CRm> set to c14 and <opc1> set to
1. For example:
MRRC p15, 1, <Rt>, <Rt2>, c14 ; Read 64-bit CNTVCT into Rt (low word) and Rt2 (high word)
In the MRRC instruction, Rt holds the least-significant word of CNTVCT, and Rt2 holds the most-significant word.
B4.1.35 CNTVOFF, Virtual Offset register, VMSA

The CNTVOFF characteristics are:
Purpose Holds the 64-bit virtual offset.


page B3-1450.
The implementation of this register depends on whether the implementation includes the
Virtualization Extensions:
• If the implementation includes the Virtualization Extensions this is a RW register,
accessible from Hyp mode, and from Monitor mode when SCR.NS is set to 1.
• If the implementation includes the Security Extensions but not the Virtualization
Extensions, an MCRR or MRRC to the CNTVOFF encoding is UNPREDICTABLE if
executed in Monitor mode, regardless of the value of SCR.NS.
For more information, see Status of the CNTVOFF register on page B8-1955.
The VMSA and system level definitions of the register fields are identical.
Attributes If the Virtualization Extensions are implemented, this is a 64-bit RW register with an
UNKNOWN reset value. If the Virtualization Extensions are not implemented, for all purposes
other than direct reads and writes this register behaves as if it contains the value 0.
In an ARMv7 implementation that also includes the Virtualization Extensions, the CNTVOFF bit assignments are:
63 0
VirtualOffset[63:0]
VirtualOffset, bits[63:0]
Indicates the virtual offset.
Accessing CNTVOFF
To access CNTVOFF, software performs a 64-bit read or write of the CP15 registers with <CRm> set to c14 and <opc1>
set to 4. For example:
MRRC p15, 4, <Rt>, <Rt2>, c14 ; Read 64-bit CNTVOFF into Rt (low word) and Rt2 (high word)
MCRR p15, 4, <Rt>, <Rt2>, c14 ; Write Rt (low word) and Rt2 (high word) to 64-bit CNTVOFF
In these MRRC and MCRR instructions, Rt holds the least-significant word of CNTVOFF, and Rt2 holds the
B4.1.36 CONTEXTIDR, Context ID Register, VMSA

The CONTEXTIDR characteristics are:
Purpose CONTEXTIDR identifies the current Process Identifier (PROCID) and, when using the
Short-descriptor translation table format, the Address Space Identifier (ASID).
This register is part of the Virtual memory control registers functional group.
Configurations The register format depends on whether address translation is using the Long-descriptor or
the Short-descriptor translation table format.
In an implementation that includes the Security Extensions, this register is Banked.
Attributes A 32-bit RW register with an UNKNOWN reset value. See also Reset behavior of CP14 and
CP15 registers on page B3-1446.
In a VMSA implementation, the CONTEXTIDR bit assignments are:
31 8 7 0
Short-descriptor† PROCID ASID
Long-descriptor† PROCID
† Current translation table format
PROCID, bits[31:0], when using the Long-descriptor translation table format
PROCID, bits[31:8], when using the Short-descriptor translation table format

Process Identifier. This field must be programmed with a unique value that identifies the current
process. See also Using the CONTEXTIDR.
ASID, bits[7:0], when using the Short-descriptor translation table format

Address Space Identifier. This field is programmed with the value of the current ASID.
Note
When using the Long-descriptor translation table format, either TTBR0 or TTBR1 holds the current
ASID.
Using the CONTEXTIDR

The value of the whole of this register is called the Context ID and is used by:
• The debug logic, for Linked and Unlinked Context ID matching, see Breakpoint debug events on
page C3-2027 and Watchpoint debug events on page C3-2045.
• The trace logic, to identify the current process.
The ASID field value is an identifier for a particular process. In the translation tables it identifies entries associated
with a process, and distinguishes them from global entries. This means many cache and TLB maintenance
operations take an ASID argument.
For information about the synchronization of changes to the CONTEXTIDR see Synchronization of changes to
system control registers on page B3-1457. There are particular synchronization requirements when changing the
ASID and Translation Table Base Registers, see Synchronization of changes of ASID and TTBR on page B3-1382.
Accessing the CONTEXTIDR

To access the CONTEXTIDR, software reads or writes the CP15 registers with <opc1> set to 0, <CRn> set to c13,
<CRm> set to c0, and <opc2> set to 1. For example:
MRC p15, 0, <Rt>, c13, c0, 1 ; Read CONTEXTIDR into Rt

MCR p15, 0, <Rt>, c13, c0, 1 ; Write Rt to CONTEXTIDR
B4.1.37 CP15DMB, CP15 Data Memory Barrier operation, VMSA

Data and instruction barrier operations, VMSA on page B4-1744 describes this deprecated CP15 barrier operation.
B4.1.38 CP15DSB, CP15 Data Synchronization Barrier operation, VMSA

B4.1.39 CP15ISB, CP15 Instruction Synchronization Barrier operation, VMSA

B4.1.40 CPACR, Coprocessor Access Control Register, VMSA

The CPACR characteristics are:
Purpose The CPACR:

• Controls access to coprocessors CP0 to CP13 from PL0 and PL1.
• Is used to determine which, if any, of coprocessors CP0 to CP13 are implemented.

In an implementation that includes the Virtualization Extensions, the CPACR has no effect
on instructions executed in Hyp mode.
Note
In an implementation that includes the Virtualization Extensions, accesses to coprocessors
other than CP14 and CP15, and to floating-point and Advanced SIMD functionality, from
Hyp mode, are controlled by settings in the NSACR and HCPTR. The NSACR settings take
precedence over the HCPTR settings.
Configurations If the implementation includes the Security Extensions, this is a Configurable access
register, see Configurable access system control registers on page B3-1449. Bits in the
NSACR control Non-secure access to the CPACR fields. See the field descriptions for more
information.
Attributes A 32-bit RW register. See the field descriptions for the reset values. See also Reset behavior
of CP14 and CP15 registers on page B3-1446.
The CPACR bit assignments are:

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
(0) cp13 cp12 cp11 cp10 cp9 cp8 cp7 cp6 cp5 cp4 cp3 cp2 cp1 cp0
TRCDIS
D32DIS
ASEDIS
ASEDIS, bit[31]
Disable Advanced SIMD functionality:
0 This bit does not cause any instructions to be UNDEFINED.
1 All instruction encodings identified in the Alphabetical list of instructions on
page A8-298 as being Advanced SIMD instructions, but that are not VFPv3 or VFPv4
instructions, are UNDEFINED when accessed from PL1 and PL0 modes.
Note
On an implementation that includes the Virtualization Extensions, when the HCPTR.TASE bit is set
to 1, any use of these instructions from a Non-secure PL1 or PL0 mode, that is not UNDEFINED, is
On an implementation that:
• Implements the Floating-point Extension and does not implement the Advanced SIMD
Extension, this bit is RAO/WI.
• Does not implement the Floating-point Extension or the Advanced SIMD Extension, this bit
is UNK/SBZP.
• Implements both the Floating-point Extension and the Advanced SIMD Extension, it is
IMPLEMENTATION DEFINED whether this bit is supported. If it is not supported it is RAZ/WI.
If this bit is implemented as an RW bit:

• It resets to 0.
• When NSACR.NSASEDIS is set to 1, it behaves as RAO/WI when accessed from
Non-secure state.
D32DIS, bit[30]
Disable use of D16-D31 of the Floating-point Extension register file:
1 All instruction encodings identified in the Alphabetical list of instructions on
page A8-298 as being VFPv3 or VFPv4 instructions are UNDEFINED if they access any
of registers D16-D31 when executed from a PL1 or PL0 mode.
If this bit is 1 when CPACR.ASEDIS == 0, the result is UNPREDICTABLE.
• Does not implement the Floating-point Extension, this bit is UNK/SBZP.
• Implements the Floating-point Extension and does not implement D16-D31, this bit is
RAO/WI.
• Implements the Floating-point Extension and implements D16-D31, it is IMPLEMENTATION
DEFINED whether this bit is supported. If it is not supported it is RAZ/WI.

• It resets to 0.
• When NSACR.NSD32DIS is set to 1, it behaves as RAO/WI when accessed from
Non-secure state.
Bit[29] Reserved, UNK/SBZP.
TRCDIS, bit[28]
Disable CP14 access to trace registers:
1 Any MRC or MCR instruction with coproc set to 0b1110 and opc1 set to 0b001 is UNDEFINED
when executed from a PL1 or PL0 mode.
Note
On an implementation that includes the Virtualization Extensions, when the HCPTR.TTA bit is set
to 1, any use of these instructions from a Non-secure PL1 or PL0 mode, that is not UNDEFINED, is
• Does not include a trace macrocell, or does not include a CP14 interface to the trace
macrocell registers, this bit is RAZ/WI.
• Includes a CP14 interface to trace macrocell registers, it is IMPLEMENTATION DEFINED
whether this bit is supported. If it is not supported it is RAZ/WI.
• Its reset value is UNKNOWN.
• When NSACR.NSTRCDIS is set to 1, it behaves as RAO/WI when accessed from
Non-secure state.
cpn, bits[2n+1, 2n], for values of n from 0 to 13

Defines the access rights for coprocessor n, for accesses from PL1 and PL0. The possible values of
the field are:
0b00 Access denied. Any attempt to access the coprocessor generates an Undefined
0b01 Access at PL1 only. Any attempt to access the coprocessor from software executing at
PL0 generates an Undefined Instruction exception.
0b10 Reserved. The effect of this value is UNPREDICTABLE.
0b11 Full access. The meaning of full access is defined by the appropriate coprocessor.
Note
On an implementation that includes the Virtualization Extensions:
• The Full access setting for a cpn field, 0b11, cannot permit any accesses from PL2.
• When the corresponding HCPTR.TCPn bit is set to 1, any access to the coprocessor from a
Non-secure PL1 or PL0 mode, that is not UNDEFINED, is trapped to Hyp mode.
For a coprocessor that is not implemented this field is RAZ/WI. Coprocessors 8, 9, 12, and 13 are
reserved for future use by ARM, and therefore cp8, cp9, cp12, and cp13 are RAZ/WI.
If CPACR.cpn is implemented as RW, when NSACR.cpn is set to 0, CPACR.cpn behaves as
RAZ/WI when accessed from Non-secure state.
When implemented as an RW field, cpn resets to zero.
In an implementation that includes the Security Extensions, the NSACR controls whether each coprocessor can be
accessed from the Non-secure state. When the NSACR permits Non-secure access to a coprocessor, the CPACR
determines the level of access permitted. Because the CPACR is not Banked, the options for Non-secure state access
to a coprocessor are:
• No access.
• Identical access rights to the Secure state.
If more than one coprocessor is required to provide a particular set of functionality, then having different values for
the CPACR fields for those coprocessors can lead to UNPREDICTABLE behavior. An example where this must be
considered is with the Floating-point Extension. This uses CP10 and CP11.
In addition, in an implementation that includes the Security Extensions, the implementation of the
NSACR{NSTRCDIS, NSASEDIS, NSD32DIS} bits must correspond to the implementation of the
CPACR{TRCDIS, ASEDIS, D32DIS} bit, and implemented NSACR bits control Non-secure access to the
associated functionality. For more information see the NSACR bit descriptions.
Typically, an operating system uses this register to control coprocessor resource sharing among applications:
• Initially all applications are denied access to the shared coprocessor-based resources.
• When an application attempts to use a resource it results in an Undefined Instruction exception.
• The Undefined Instruction exception handler can then grant access to the resource by setting the appropriate
field in the CPACR.
Sharing resources among applications requires a state saving mechanism. Two possibilities are:
• During a context switch, if the last executing process or thread had access rights to a coprocessor then the
operating system saves the state of that coprocessor.
• On receiving a request for access to a coprocessor, the operating system saves the old state for that
coprocessor with the last process or thread that accessed it.
For details of how software can use this register to check for implemented coprocessors see Access controls on CP0
to CP13 on page B1-1226.
Accessing the CPACR

To access the CPACR, software reads or writes the CP15 registers with <opc1> set to 0, <CRn> set to c1, <CRm> set to
MRC p15, 0, <Rt>, c1, c0, 2 ; Read CPACR into Rt

MCR p15, 0, <Rt>, c1, c0, 2 ; Write Rt to CPACR
Normally, software uses a read, modify, write sequence to update the CPACR, to avoid unwanted changes to the
access settings for other coprocessors.
B4.1.41 CSSELR, Cache Size Selection Register, VMSA

The CSSELR characteristics are:
Purpose The CSSELR selects the current CCSIDR, by specifying:

• The required cache level.
• The cache type, either:
— Instruction cache, if the memory system implements separate instruction and
data caches.
— Data cache. The data cache argument must be used for a unified cache.

The CSSELR bit assignments are:

31 4 3 1 0
Reserved, UNK/SBZP Level
InD
Level, bits[3:1]
Cache level of required cache. Permitted values are from 0b000, indicating Level 1 cache, to 0b110
indicating Level 7 cache.
If this field is set to an unimplemented level of cache, the effect is UNPREDICTABLE.
InD, bit[0] Instruction not Data bit. Permitted values are:

0 Data or unified cache
1 Instruction cache.
See the Note in Access to registers from Monitor mode on page B3-1455 for a description of how SCR.NS controls
whether Monitor mode accesses are to the Secure or Non-secure copy of the selected CCSIDR.
Accessing CSSELR
To access CSSELR, software reads or writes the CP15 registers with <opc1> set to 2, <CRn> set to c0, <CRm> set to c0,
and <opc2> set to 0. For example:
MRC p15, 2, <Rt>, c0, c0, 0 ; Read CSSELR into Rt

MCR p15, 2, <Rt>, c0, c0, 0 ; Write Rt to CSSELR
B4.1.42 CTR, Cache Type Register, VMSA

The CTR characteristics are:
Purpose The CTR provides information about the architecture of the caches.
Configurations If the implementation includes the Security Extensions, this register is Common.
ARMv7 changes the format of the CTR, This section describes only the ARMv7 format. For
more information see the description of the Format field, bits[31:29].
In an ARMv7 VMSA implementation, the CTR bit assignments are:

31 29 28 27 24 23 20 19 16 15 14 13 4 3 0
1 0 0 0 CWG ERG DminLine L1Ip 0 0 0 0 0 0 0 0 0 0 IminLine
Format
Format, bits[31:29]
Indicates the implemented CTR format. The possible values of this are:
0b000 ARMv6 format, see CP15 c0, Cache Type Register, CTR, ARMv4 and ARMv5 on
page D15-2601.
0b100 ARMv7 format. This is the format described in this section.
Bit[28] RAZ.
CWG, bits[27:24]
Cache Write-back Granule. The maximum size of memory that can be overwritten as a result of the
eviction of a cache entry that has had a memory location in it modified, encoded as Log2 of the
number of words.
A value of 0b0000 indicates that the CTR does not provide Cache Write-back Granule information
and either:
• The architectural maximum of 512 words (2Kbytes) must be assumed.
• The Cache Write-back Granule can be determined from maximum cache line size encoded in
the Cache Size ID Registers.
Values greater than 0b1001 are reserved.
ERG, bits[23:20]
Exclusives Reservation Granule. The maximum size of the reservation granule that has been
implemented for the Load-Exclusive and Store-Exclusive instructions, encoded as Log2 of the
number of words. For more information, see Tagging and the size of the tagged memory block on
page A3-119.
A value of 0b0000 indicates that the CTR does not provide Exclusives Reservation Granule
information and the architectural maximum of 512 words (2Kbytes) must be assumed.
Values greater than 0b1001 are reserved.
DminLine, bits[19:16]
Log2 of the number of words in the smallest cache line of all the data caches and unified caches that
are controlled by the processor.
L1Ip, bits[15:14]
Level 1 instruction cache policy. Indicates the indexing and tagging policy for the L1 instruction
cache. Table B4-3 shows the possible values for this field.
Table B4-3 Level 1 instruction cache policy field values
L1Ip bits L1 instruction cache indexing and tagging policy
00 Reserved
01 ASID-tagged Virtual Index, Virtual Tag (AIVIVT)
10 Virtual Index, Physical Tag (VIPT)
11 Physical Index, Physical Tag (PIPT)
Bits[13:4] RAZ.
IminLine, bits[3:0]
Log2 of the number of words in the smallest cache line of all the instruction caches that are
controlled by the processor.
Accessing the CTR

To access the CTR, software reads the CP15 registers with <opc1> set to 0, <CRn> set to c0, <CRm> set to c0, and <opc2>
set to 1. For example
MRC p15, 0, <Rt>, c0, c0, 1 ; Read CTR into Rt
B4.1.43 DACR, Domain Access Control Register, VMSA

The DACR characteristics are:
Purpose DACR defines the access permission for each of the sixteen memory domains.
Configurations If the implementation includes the Security Extensions, this register:

• Is Banked.
• Has write access to the Secure copy of the register disabled when the
In an implementation that includes the Large Physical Address Extension, this register has
no function when TTBCR.EAE is set to 1, to select the Long-descriptor translation table
format.
Attributes A 32-bit RW register with an UNKNOWN reset value. For more information see Reset
behavior of CP14 and CP15 registers on page B3-1446.
The DACR bit assignments are:

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
D15 D14 D13 D12 D11 D10 D9 D8 D7 D6 D5 D4 D3 D2 D1 D0
Dn, bits[(2n+1):2n]
Domain n access permission, where n = 0 to 15. Permitted values are:
0b00 No access. Any access to the domain generates a Domain fault.
0b01 Client. Accesses are checked against the permission bits in the translation tables.
0b10 Reserved, effect is UNPREDICTABLE.
0b11 Manager. Accesses are not checked against the permission bits in the translation tables.
For more information, see Domains, Short-descriptor format only on page B3-1358.
Accessing the DACR

To access the DACR, software reads or writes the CP15 registers with <opc1> set to 0, <CRn> set to c3, <CRm> set to
MRC p15, 0, <Rt>, c3, c0, 0 ; Read DACR into Rt

MCR p15, 0, <Rt>, c3, c0, 0 ; Write Rt to DACR
B4.1.44 DCCIMVAC, Data Cache Clean and Invalidate by MVA to PoC, VMSA
Cache and branch predictor maintenance operations, VMSA on page B4-1735 describes this cache maintenance
operation.
B4.1.45 DCCISW, Data Cache Clean and Invalidate by Set/Way, VMSA

operation.
B4.1.46 DCCMVAC, Data Cache Clean by MVA to PoC, VMSA

operation.
B4.1.47 DCCMVAU, Data Cache Clean by MVA to PoU, VMSA

operation.
B4.1.48 DCCSW, Data Cache Clean by Set/Way, VMSA

operation.
B4.1.49 DCIMVAC, Data Cache Invalidate by MVA to PoC, VMSA

operation.
B4.1.50 DCISW, Data Cache Invalidate by Set/Way, VMSA

operation.
B4.1.51 DFAR, Data Fault Address Register, VMSA

The DFAR characteristics are:
Purpose The DFAR holds the VA of the faulting address that caused a synchronous Data Abort
exception.
This register is part of the PL1 Fault handling registers functional group.
Configurations If the implementation includes the Security Extensions, this register is Banked.
Before ARMv7 the DFAR was called the Fault Address Register (FAR).
The DFAR bit assignments are:

31 0
VA of faulting address of synchronous Data Abort exception
For information about using the DFAR, and when the value in the DFAR is valid, see Exception reporting in a VMSA
implementation on page B3-1406.
A debugger can write to the DFAR to restore its value.
Accessing the DFAR

To access the DFAR, software reads or writes the CP15 registers with <opc1> set to 0, <CRn> set to c6, <CRm> set to
MRC p15, 0, <Rt>, c6, c0, 0 ; Read DFAR into Rt

MCR p15, 0, <Rt>, c6, c0, 0 ; Write Rt to DFAR
B4.1.52 DFSR, Data Fault Status Register, VMSA

The DFSR characteristics are:
Purpose The DFSR holds status information about the last data fault.
Configurations The Large Physical Address Extension adds an alternative format for the register. If an
implementation includes the Large Physical Address Extension then the current translation
table format determines which format of the register is used.
For information about using the DFSR see Exception reporting in a VMSA implementation on page B3-1406.
The following sections describe the alternative DFSR formats:

• DFSR format when using the Short-descriptor translation table format.
• DFSR format when using the Long-descriptor translation table format on page B4-1559.
DFSR format when using the Short-descriptor translation table format

In a VMSAv7 implementation that does not include the Large Physical Address Extension, or in an implementation
that includes the Large Physical Address Extension when TTBCR.EAE is 0, indicating that address translation uses
the Short-descriptor translation table format.
Note
In an implementation that includes the Large Physical Address Extension, TTBCR.EAE resets to 0 in both the
Secure and the Non-secure copies of the register.
The DFSR bit assignments are:

31 14 13 12 11 10 9 8 7 4 3 0
Reserved, UNK/SBZP 0* (0) Domain FS[3:0]
CM†
ExT
WnR
FS[4]
LPAE†
† Only on an implementation that includes the Large Physical Address Extension.
For more information, see the field description.
* Returned value, but might be overwritten, because the bit is RW.
CM, bit[13], if implementation includes the Large Physical Address Extension

Cache maintenance fault. For synchronous faults, this bit indicates whether a cache maintenance
operation generated the fault. The possible values of this bit are:
0 Abort not caused by a cache maintenance operation.
1 Abort caused by a cache maintenance operation.
On a asynchronous Data Abort on a translation table walk, this bit is UNKNOWN.
On an asynchronous fault, this bit is UNKNOWN.
Bit[13], if implementation does not include the Large Physical Address Extension
Reserved, UNK/SBZP.
ExT, bit[12] External abort type. This bit can provide an IMPLEMENTATION DEFINED classification of external
aborts.
For aborts other than external aborts this bit always returns 0.
In an implementation that does not provide any classification of external aborts, this bit is
UNK/SBZP.
WnR, bit[11] Write not Read bit. On a synchronous exception, indicates whether the abort was caused by a write
instruction or by a read instruction. The possible values of this bit are:
For synchronous faults on CP15 cache maintenance operations, including the address translation
operations, this bit always returns a value of 1.
This bit is UNKNOWN on:
• An asynchronous Data Abort exception.
• A Data Abort exception caused by a debug exception.
FS, bits[10, 3:0]

Fault status bits. For the valid encodings of these bits when using the Short-descriptor translation
table format, see Table B3-23 on page B3-1412. All encodings not shown in the table are reserved.
LPAE, bit[9], if the implementation includes the Large Physical Address Extension
On taking a Data Abort exception, this bit is set to 0 to indicate use of the Short-descriptor
Hardware does not interpret this bit to determine the behavior of the memory system, and therefore
software can set this bit to 0 or 1 without affecting operation. Unless the register has been updated
to report a fault, a subsequent read of the register returns the value written to it.
Bit[9], if the implementation does not include the Large Physical Address Extension
Reserved, UNK/SBZP.
Domain, bits[7:4]
The domain of the fault address.
ARM deprecates any use of this field, see The Domain field in the DFSR on page B3-1412.
This field is UNKNOWN on a Data Abort exception:
• Caused by a debug exception.
• Caused by a Permission fault in an implementation includes the Large Physical Address
Extension.
DFSR format when using the Long-descriptor translation table format

In a VMSAv7 implementation that includes the Large Physical Address Extension, when TTBCR.EAE is 1, the
DFSR bit assignments are:
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 6 5 0
UNK/
Reserved, UNK/SBZP (0) 1* STATUS
SBZP
CM
ExT
WnR
LPAE
CM, bit[13] Cache maintenance fault. For synchronous faults, this bit indicates whether a cache maintenance
operation generated the fault. The possible values of this bit are:
0 Abort not caused by a cache maintenance operation.
1 Abort caused by a cache maintenance operation.
On an asynchronous fault, this bit is UNKNOWN.
aborts.
UNK/SBZP.
WnR, bit[11] Write not Read bit. On a synchronous exception, indicates whether the abort was caused by a write
instruction or by a read instruction. The possible values of this bit are:
For synchronous faults on CP15 cache maintenance operations, including the address translation
operations, this bit always returns a value of 1.
This bit is UNKNOWN on:
• An asynchronous Data Abort exception.
• A Data Abort exception caused by a debug exception.
LPAE, bit[9] On taking a Data Abort exception, this bit is set to 1 to indicate use of the Long-descriptor
STATUS, bits[5:0]
Fault status bits. For the valid encodings of these bits when using the Long-descriptor translation
Accessing the DFSR

To access the DFSR, software reads or writes the CP15 registers with <opc1> set to 0, <CRn> set to c5, <CRm> set to
MRC p15, 0, <Rt>, c5, c0, 0 ; Read DFSR into Rt
MCR p15, 0, <Rt>, c5, c0, 0 ; Write Rt to DFSR
B4.1.53 DTLBIALL, Data TLB Invalidate All, VMSA only

TLB maintenance operations, not in Hyp mode on page B4-1738 describes this TLB maintenance operation.
This operation is part of the TLB maintenance operations functional group. Table B3-50 on page B3-1492 shows
B4.1.54 DTLBIASID, Data TLB Invalidate by ASID, VMSA only

B4.1.55 DTLBIMVA, Data TLB Invalidate by MVA, VMSA only

B4.1.56 FCSEIDR, FCSE Process ID Register, VMSA

The FCSEIDR characteristics are:
Purpose The FCSEIDR identifies the current Process ID (PID) for the Fast Context Switch Extension
(FCSE).

Access depends on whether the implementation includes the FCSE, see the Attributes
description.
In an implementation that includes the Security Extensions, software must program the
Non-secure copy of the register with the required initial value, as part of the processor boot
sequence.
Configurations In an implementation that includes the Security Extensions:

• This register is Banked.
• If the implementation includes the FCSE, write access to the Secure copy of the
FCSEIDR is disabled when the CP15SDISABLE signal is asserted HIGH.
Attributes A 32-bit register that:

• In an implementation that includes the FCSE, is RW and resets to zero. If the
implementation also includes the Security Extensions, this reset value applies only to
the Secure copy of the register.
• In an implementation that does not include the FCSE, the register is RAZ/WI.
See also Reset behavior of CP14 and CP15 registers on page B3-1446.
In an implementation that includes the FCSE, the FCSEIDR bit assignments are:
31 25 24 0
PID Reserved, UNK/SBZP
PID, bits[31:25]
The current Process ID, for the FCSE. If the FCSE is not implemented this field is RAZ/WI.
Bits[24:0] Reserved:
• In an implementation that includes the FCSE, this field is UNK/SBZP.
• If the FCSE is not implemented this field is RAZ/WI.
In ARMv7, the FCSE is OPTIONAL and deprecated, but the FCSEIDR must be implemented regardless of whether
the implementation includes the FCSE. Software can access this register to determine whether the implementation
includes the FCSE.
Note
• Changing the PID changes the overall virtual-to-physical address mapping. Because of this, software must
ensure that instructions that might have been speculatively fetched are not affected by the address mapping
change.
• From ARMv6, ARM deprecates any use of the FCSE. The FCSE is:
— OPTIONAL and deprecated in an ARMv7 implementation that does not include the Multiprocessing
Extensions.
— Obsolete from the addition of the Multiprocessing Extensions.
Accessing the FCSEIDR

To access the FCSEIDR, software reads or writes the CP15 registers with <opc1> set to 0, <CRn> set to c13, <CRm> set
MRC p15, 0, <Rt>, c13, c0, 0 ; Read FCSEIDR into Rt

MCR p15, 0, <Rt>, c13, c0, 0 ; Write Rt to FCSEIDR
B4.1.57 FPEXC, Floating-Point Exception Control register, VMSA

The FPEXC register characteristics are:
Purpose Provides a global enable for the Advanced SIMD and Floating-point (VFP) Extensions, and
indicates how the state of these extensions is recorded.
Usage constraints Only accessible by software executing at PL1 or higher. See Enabling Advanced SIMD and
floating-point support on page B1-1228 for more information.
Configurations Implemented only if the implementation includes one or both of:

• The Floating-point Extension.
• The Advanced SIMD Extension.
In an implementation that includes the Security Extensions, FPEXC is a Configurable
access register. When the settings in the CPACR permit access to the register:
• It is accessible in Non-secure state only if the NSACR.{CP11, CP10} bits are both
set to 1.
• If the implementation also includes the Virtualization Extensions then bits in the
HCPTR also control Non-secure access to the register.
For more information, see Access controls on CP0 to CP13 on page B1-1226.
The VFP subarchitecture might define additional bits in the FPEXC, see Additions to the
Floating-Point Exception Register, FPEXC on page D6-2427.
Attributes A 32-bit RW register. See the register field descriptions for information about the reset
value.
Table B1-24 on page B1-1235 shows the encodings of all of the Advanced SIMD and
Floating-point Extension system registers.
The FPEXC bit assignments are:

31 30 29 0
SUBARCHITECTURE DEFINED
EX
EN
EX, bit[31] Exception bit. A status bit that specifies how much information must be saved to record the state of
the Advanced SIMD and Floating-point system:
0 The only significant state is the contents of the registers:
• D0 - D15.
• D16 - D31, if implemented.
• FPSCR.
• FPEXC.
A context switch can be performed by saving and restoring the values of these registers.
1 There is additional state that must be handled by any context switch system.
The reset value of this bit is UNKNOWN.
The behavior of the EX bit on writes is SUBARCHITECTURE DEFINED, except that in any
implementation a write of 0 to this bit must be a valid operation, and must return a value of 0 if read
back before any subsequent write to the register.
EN, bit[30] Enable bit. A global enable for the Advanced SIMD and Floating-point Extensions:
0 The Advanced SIMD and Floating-point Extensions are disabled. For details of how the
system operates when EN == 0 see Enabling Advanced SIMD and floating-point
support on page B1-1228.
1 The Advanced SIMD and Floating-point Extensions are enabled and operate normally.
This bit is always a normal read/write bit. It has a reset value of 0.
Bits[29:0] SUBARCHITECTURE DEFINED. An implementation can use these bits to communicate exception
information between the floating-point hardware and the support code. The subarchitectural
definition of these bits includes their read/write access. This can be defined on a bit by bit basis. This
means that the reset value of these bits is SUBARCHITECTURE DEFINED.
A constraint on these bits is that if EX == 0 it must be possible to save and restore all significant
state for the floating-point system by saving and restoring only the two Advanced SIMD and
Floating-point Extension registers FPSCR and FPEXC.
Accessing the FPEXC register

Software reads or writes the FPEXC register using the VMRS and VMSR instructions. For more information, see VMRS
on page A8-955 and VMSR on page A8-957. For example:
VMRS <Rt>, FPEXC ; Read Floating-point Exception Control Register

VMSR FPEXC, <Rt> ; Write Floating-point Exception Control Register
Writes to the FPEXC can have side-effects on various aspects of processor operation. All of these side-effects are
synchronous to the FPEXC write. This means they are guaranteed not to be visible to earlier instructions in the
B4.1.58 FPSCR, Floating-point Status and Control Register, VMSA

The FPSCR characteristics are:
Purpose Provides floating-point system status information and control.
Usage constraints There are no usage constraints, but see Enabling Advanced SIMD and floating-point
support on page B1-1228 for information about enabling access to this register.

In an implementation that includes the Security Extensions, FPSCR is a Configurable
set to 1.
Attributes A 32-bit RW register. The reset value of the register fields are UNKNOWN except where the
field descriptions indicate otherwise.
The FPSCR bit assignments are:

31 30 29 28 27 26 25 24 23 22 21 20 19 18 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
N Z C V (0) Len (0) (0) (0) (0)
QC IDE IOC
AHP Reserved DZC
DN IXE OFC
FZ UFE UFC
RMode OFE IXC
Stride DZE Reserved
Reserved IOE IDC
See the field descriptions for implementation differences in different VFP versions
Bits[31:28] Condition flags. These are updated by floating-point comparison operations, as shown in Effect of
a Floating-point comparison on the condition flags on page A2-79.
N, bit[31] Negative condition flag.
Z, bit[30] Zero condition flag.
C, bit[29] Carry condition flag.
V, bit[28] Overflow condition flag.
Note
Advanced SIMD operations never update these bits.
QC, bit[27] Cumulative saturation bit, Advanced SIMD only. This bit is set to 1 to indicate that an Advanced
SIMD integer operation has saturated since 0 was last written to this bit. For details of saturation,
see Pseudocode details of saturation on page A2-44.
If the implementation does not include the Advanced SIMD Extension, this bit is UNK/SBZP.
AHP, bit[26] Alternative half-precision control bit:

0 IEEE half-precision format selected.
1 Alternative half-precision format selected.

For more information see Advanced SIMD and Floating-point half-precision formats on
page A2-65.
If the implementation does not include the Half-precision Extension, this bit is UNK/SBZP.
DN, bit[25] Default NaN mode control bit:

0 NaN operands propagate through to the output of a floating-point operation.
1 Any operation involving one or more NaNs returns the Default NaN.
For more information, see NaN handling and the Default NaN on page A2-68.
The value of this bit only controls Floating-point arithmetic. Advanced SIMD arithmetic always
uses the Default NaN setting, regardless of the value of the DN bit.
FZ, bit[24] Flush-to-zero mode control bit:

0 Flush-to-zero mode disabled. Behavior of the floating-point system is fully compliant
with the IEEE 754 standard.
1 Flush-to-zero mode enabled.
For more information, see Flush-to-zero on page A2-67.
The value of this bit only controls Floating-point arithmetic. Advanced SIMD arithmetic always
uses the Flush-to-zero setting, regardless of the value of the FZ bit.
RMode, bits[23:22]
Rounding Mode control field. The encoding of this field is:
0b00 Round to Nearest (RN) mode.
0b01 Round towards Plus Infinity (RP) mode.
0b10 Round towards Minus Infinity (RM) mode.
0b11 Round towards Zero (RZ) mode.
The specified rounding mode is used by almost all floating-point instructions that are part of the
Floating-point Extension. Advanced SIMD arithmetic always uses the Round to Nearest setting,
regardless of the value of the RMode bits.
Note
The rounding mode names are based on the IEEE 754-1985 terminology. See Floating-point
standards, and terminology on page A2-55 for the corresponding terms in the IEEE 754-2008
revision of the standard.
Stride, bits[21:20] and Len, bits[18:16]

ARM deprecates use of nonzero values of these fields. For details of their use in previous versions
of the ARM architecture see Appendix D11 VFP Vector Operation Support.
The values of these fields are ignored by the Advanced SIMD Extension.
Bits[19, 14:13, 6:5]

Reserved, UNK/SBZP.
Bits[15, 12:8] Floating-point exception trap enable bits. These bits are supported only in VFPv2, VFPv3U, and
VFPv4U. They are reserved, RAZ/WI, on a system that implements VFPv3 or VFPv4.
The possible values of each bit are:
0 Untrapped exception handling selected. If the floating-point exception occurs then the
corresponding cumulative exception bit is set to 1.
1 Trapped exception handling selected. If the floating-point exception occurs, hardware
does not update the corresponding cumulative exception bit. The trap-handling software
can decide whether to set the cumulative exception bit to 1.
The values of these bits control only Floating-point arithmetic. Advanced SIMD arithmetic always
uses untrapped exception handling, regardless of the values of these bits.
For more information, see Floating-point exceptions on page A2-69.

The floating-point trap enable bits are:
IDE, bit[15] Input Denormal exception trap enable.
Note
Denormal corresponds to the term denormalized number in the
IEEE 754-1985 standard. Floating-point standards, and terminology on
page A2-55 describes the terminology changes in the IEEE 754-2008
revision of the standard.
IXE, bit[12] Inexact exception trap enable.

UFE, bit[11] Underflow exception trap enable.
OFE, bit[10] Overflow exception trap enable.
DZE, bit[9] Division by Zero exception trap enable.
IOE, bit[8] Invalid Operation exception trap enable.
Bits[7, 4:0] Cumulative exception bits for floating-point exceptions. Each of these bits is set to 1 to indicate that
the corresponding exception has occurred since 0 was last written to it. How floating-point
instructions update these bits depends on the value of the corresponding exception trap enable bits,
see the description of bits[15, 12:8].
Advanced SIMD instructions set each cumulative exception bit if the corresponding exception
occurs in one or more of the floating-point calculations performed by the instruction, regardless of
the setting of the trap enable bits.
For more information, see Floating-point exceptions on page A2-69.
IDC, bit[7] Input Denormal cumulative exception bit. Updated by hardware only when
IDE, bit[15], is set to 0.
IXC, bit[4] Inexact cumulative exception bit. Updated by hardware only when IXE,
bit[12], is set to 0.
UFC, bit[3] Underflow cumulative exception bit. Updated by hardware only when UFE,
OFC, bit[2] Overflow cumulative exception bit. Updated by hardware only when OFE,
DZC, bit[1] Division by Zero cumulative exception bit. Updated by hardware only when
DZE, bit[9], is set to 0.
IOC, bit[0] Invalid Operation cumulative exception bit. Updated by hardware only
when IOE, bit[8], is set to 0.
If the implementation includes the integer-only Advanced SIMD Extension and does not include the Floating-point
Extension, all of these bits except QC are UNK/SBZP.
Writes to the FPSCR can have side-effects on various aspects of processor operation. All of these side-effects are
synchronous to the FPSCR write. This means they are guaranteed not to be visible to earlier instructions in the
Accessing the FPSCR

Software reads or writes the FPSCR, or transfers the FPSCR.{N, Z, C, V} flags to the APSR, using the VMRS and
VMSR instructions. For more information, see VMRS on page A8-955 and VMSR on page A8-957. For example:
VMRS <Rt>, FPSCR ; Read Floating-point System Control Register

VMSR FPSCR, <Rt> ; Write Floating-point System Control Register
VMRS APSR_nzcv, FPSCR ; Write FPSCR.{N, Z, C, V} flags to APSR.{N, Z, C, V}
B4.1.59 FPSID, Floating-point System ID Register, VMSA

The FPSID register characteristics are:
Purpose Provides top-level information about the floating-point implementation.
Usage constraints Only accessible from PL1 or higher. See Enabling Advanced SIMD and floating-point
support on page B1-1228 for more information.
This register complements the information provided by the CPUID scheme described in
Chapter B7 The CPUID Identification Scheme.
Configurations FPSID can be implemented in a system that provides only software emulation of the ARM
floating-point instructions, and must be implemented if the implementation includes one or
both of:
In an implementation that includes the Security Extensions, FPSID is a Configurable access
register. When the settings in the CPACR permit access to the register:
set to 1.
Attributes A 32-bit RO register.
Note
Although the FPSID is a RO register, a write using the FPSID encoding is a valid serializing
operation, see Asynchronous bounces, serialization, and Floating-point exception barriers
on page B1-1237. Such a write does not access the register.
In ARMv7, the FPSID bit assignments are:

31 24 23 22 16 15 8 7 4 3 0
Implementer Subarchitecture Part number Variant Revision
SW
Implementer, bits[31:24]
Implementer codes are the same as those used for the MIDR.
For an implementation by ARM this field is 0x41, the ASCII code for A.
SW, bit[23] Software bit. This bit indicates whether a system provides only software emulation of the
floating-point instructions that are provided by the Floating-point Extension:
0 The system includes hardware support for the floating-point instructions provided by
the Floating-point Extension.
1 The system provides only software emulation of the floating-point instructions provided
by the Floating-point Extension.
Subarchitecture, bits[22:16]
Subarchitecture version number. For an implementation by ARM, permitted values are:
0b0000000 VFPv1 architecture with an IMPLEMENTATION DEFINED subarchitecture.
Not permitted in an ARMv7 implementation.

0b0000001 VFPv2 architecture with Common VFP subarchitecture v1.
Not permitted in an ARMv7 implementation.
0b0000010 VFPv3 architecture, or later, with Common VFP subarchitecture v2. The VFP
architecture version is indicated by the MVFR0 and MVFR1 registers.
0b0000011 VFPv3 architecture, or later, with no subarchitecture. The entire floating-point
implementation is in hardware, and no software support code is required. The VFP
This value can be used only by an implementation that does not support the trap enable
bits in the FPSCR.
0b0000100 VFPv3 architecture, or later, with Common VFP subarchitecture v3. The VFP
For a subarchitecture designed by ARM the most significant bit of this field, register bit[22], is 0.
Values with a most significant bit of 0 that are not listed here are reserved.
When the subarchitecture designer is not ARM, the most significant bit of this field, register bit[22],
must be 1. Each implementer must maintain its own list of subarchitectures it has designed, starting
at subarchitecture version number 0x40.
Part number, bits[15:8]

An IMPLEMENTATION DEFINED part number for the floating-point implementation, assigned by the
implementer.
Variant, bits[7:4]
An IMPLEMENTATION DEFINED variant number. Typically, this field distinguishes between different
production variants of a single product.
Revision, bits[3:0]
An IMPLEMENTATION DEFINED revision number for the floating-point implementation.
Accessing the FPSID register

Software accesses the FPSID register using the VMRS instruction, see VMRS on page B9-2000. For example:
VMRS <Rt>, FPSID ; Read FPSID into Rt
B4.1.60 HACR, Hyp Auxiliary Configuration Register, Virtualization Extensions

The HACR characteristics are:
Purpose The HACR controls the trapping to Hyp mode of IMPLEMENTATION DEFINED aspects of
Non-secure PL1 or PL0 operation.
This register is part of the Virtualization Extensions registers functional group.
Configurations Implemented only as part of the Virtualization Extensions.

This is Banked PL2-mode register, see Banked PL2-mode CP15 read/write registers on
page B3-1450.
Attributes A 32-bit RW register with an IMPLEMENTATION DEFINED reset value. See also Reset
Table B3-55 on page B3-1496 shows the encoding of all of the Virtualization Extensions
registers.
The HACR bit assignments are IMPLEMENTATION DEFINED.
Accessing the HACR

To access the HACR, software reads or writes the CP15 registers with <opc1> set to 4, <CRn> set to c1, <CRm> set to
MRC p15, 4, <Rt>, c1, c1, 7 ; Read HACR into Rt

MCR p15, 4, <Rt>, c1, c1, 7 ; Write Rt to HACR
B4.1.61 HACTLR, Hyp Auxiliary Control Register, Virtualization Extensions

The HACTLR characteristics are:
Purpose The HACTLR controls IMPLEMENTATION DEFINED features of Hyp mode operation.

This is PL2-mode register, see Banked PL2-mode CP15 read/write registers on
page B3-1450.
Attributes A 32-bit RW register with an IMPLEMENTATION DEFINED reset value. See also Reset
registers.
The HACTLR bit assignments are IMPLEMENTATION DEFINED.
Accessing the HACTLR

To access the HACTLR, software reads or writes the CP15 registers with <opc1> set to 4, <CRn> set to c1, <CRm> set
MRC p15, 4, <Rt>, c1, c0, 1 ; Read HACTLR into Rt

MCR p15, 4, <Rt>, c1, c0, 1 ; Write Rt to HACTLR
B4.1.62 HADFSR and HAIFSR, Hyp Auxiliary Fault Syndrome Registers, Virtualization Extensions
The Hyp Auxiliary Data Fault Syndrome Register, HADFSR, and Hyp Auxiliary Instruction Fault Syndrome
Register, HAIFSR, characteristics are:
Purpose The HAxFSR contain additional IMPLEMENTATION DEFINED syndrome information for:
• Data Abort exceptions taken to Hyp mode, for the HADFSR.
• Prefetch Abort exceptions taken to Hyp mode, for the HAIFSR.
These registers are part of the Virtualization Extensions registers functional group.
Configurations Implemented only as part of the Virtualization Extensions. These are optional registers. An
implementation that does not require one or both of these registers can implement the
registers that are not required as UNK/SBZP.
These are Banked PL2-mode register, see Banked PL2-mode CP15 read/write registers on
page B3-1450.
registers.
The HADFSR and HAIFSR bit assignments are IMPLEMENTATION DEFINED.
Accessing the HADFSR and HAIFSR

To access the HADFSR or HAIFSR, software reads or writes the CP15 registers with <opc1> set to 4, <CRn> set to
c5, <CRm> set to c1, and <opc2> set to 0 for the HADFSR, or to 1 for the HAIFSR. For example:
MRC p15, 4, <Rt>, c5, c1, 0 ; Read HADFSR into Rt

MCR p15, 4, <Rt>, c5, c1, 0 ; Write Rt to HADFSR
MRC p15, 4, <Rt>, c5, c1, 1 ; Read HAIFSR into Rt
MCR p15, 4, <Rt>, c5, c1, 1 ; Write Rt to HAIFSR
B4.1.63 HAMAIR0 and HAMAIR1, Hyp Auxiliary Memory Attribute Indirection Registers 0 and 1
The HAMAIR0 and HAMAIR1 characteristics are
Purpose The HAMAIR0 and HAMAIR1 registers provide IMPLEMENTATION DEFINED memory
attributes for the memory attribute encodings defined by the HMAIR0 and HMAIR1
registers.
These IMPLEMENTATION DEFINED attributes can only provide additional qualifiers for the
memory attribute encodings, and cannot change the memory attributes defined in the
HMAIR0 and HMAIR1 registers.
If an implementation does not provide any IMPLEMENTATION DEFINED memory attributes
these registers are UNK/SBZP.

These are Banked PL2-mode registers, see Banked PL2-mode CP15 read/write registers on
page B3-1450.
Attributes 32-bit RW registers with an UNKNOWN reset values. See also Reset behavior of CP14 and
registers.
The HAMAIRn registers bit assignments are IMPLEMENTATION DEFINED.
Note
Although all aspects of the HAMAIRn register bit assignments are IMPLEMENTATION DEFINED, a likely usage model
is that the two HAMAIRn registers provide eight 8-bit fields, indexed by the AttrIndx[2:0] value from the
translation table descriptor, as described for the HMAIR registers.
Accessing the HAMAIR0 or HAMAIR1

To access the HAMAIR0 or HAMAIR1, software reads or writes the CP15 registers with <opc1> set to 4, <CRn> set
to c10, <CRm> set to c3, and <opc2> set to 0 for HAMAIR0, or to 1 for HAMAIR1. For example:
MRC p15, 4, <Rt>, c10, c3, 0 ; Read HAMAIR0 into Rt

MCR p15, 4, <Rt>, c10, c3, 1 ; Write Rt to HAMAIR1
B4.1.64 HCPTR, Hyp Coprocessor Trap Register, Virtualization Extensions

The HCPTR characteristics are:
Purpose The HCPTR controls the trapping to Hyp mode of Non-secure accesses, at PL1 or lower, to
coprocessors other than CP14 and CP15, and to floating-point and Advanced SIMD
functionality. It also controls the access to coprocessors other than CP14 and CP15, and to
floating-point and Advanced SIMD functionality, from Hyp mode.
Note
Accesses to coprocessors other than CP14 and CP15, and to floating-point and Advanced
SIMD functionality, from Hyp mode:
• Are not affected by settings in the CPACR.
• Are affected by settings in the NSACR, and the NSACR settings take precedence
over the HCPTR settings. See the Usage Constraints for more information.
If a bit in the NSACR prohibits a Non-secure access, then the corresponding bit in the
HCPTR behaves as RAO/WI for Non-secure accesses. See the bit descriptions for more
information.

page B3-1450.
Attributes A 32-bit RW register that resets to zero. See also Reset behavior of CP14 and CP15 registers
on page B3-1446.
registers.
The HCPTR bit assignments are:
31 30 21 20 19 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved,
Reserved, UNK/SBZP (0)
UNK/SBZP
TCPAC TTA TASE

TCP13 to TCP0, see text
In the descriptions of the HCPTR fields, an otherwise-valid Non-secure access means an access that, if the bit was
set to 0, would not be UNDEFINED or UNPREDICTABLE.
For more information about all of these bits see Trapping accesses to coprocessors on page B1-1255.
For more information about control of access to functionality provided by the Advanced SIMD and Floating-point
Extensions, see Enabling Advanced SIMD and floating-point support on page B1-1228.
TCPAC, bit[31]
Trap CPACR accesses. The possible values of this bit are:
0 Has no effect on accesses to the CPACR.
1 Any access to the CPACR from a Non-secure PL1 mode generates an exception that is
taken to Hyp mode. For more information, see Trapping CPACR accesses on
page B1-1256.
TTA, bit[20] Trap Trace Access. The possible values of this bit are:
0 Has no effect on accesses to the CP14 trace registers from Non-secure PL1 and PL2
modes.
1 Any otherwise-valid access to the CP14 trace registers from a Non-secure PL1 mode
generates an exception that is taken to Hyp mode. For more information see Trapping
CP14 accesses to trace registers on page B1-1259.
Any access to the CP14 trace registers from Non-secure Hyp mode is UNDEFINED.
Note
The NSACR.NSTRCDIS bit can make this bit behave as RAO/WI, regardless of its actual value.
In an implementation that does not include a trace macrocell, or does not include a CP14 interface
to the trace macrocell registers, it is IMPLEMENTATION DEFINED whether this bit:
• Is RAO/WI.
• Is RAZ/WI.
• Can be written from Hyp mode, and from Secure Monitor mode when the value of SCR.NS
is 1.
TASE, bit[15] Trap Advanced SIMD Extension use. The possible values of this bit are:
0 Has no effect on accesses to Advanced SIMD functionality from Non-secure PL2, PL1
and PL0 modes.
1 Any otherwise-valid access to Advanced SIMD functionality from a Non-secure PL1 or
PL0 mode generates an exception that is taken to Hyp mode. For more information, see
Trapping of Advanced SIMD functionality on page B1-1255.
Any access to Advanced SIMD functionality from Hyp mode is UNDEFINED. This means
that any instruction encoding that Alphabetical list of instructions on page A8-298
identifies as being an Advanced SIMD instruction but does not also identify as being a
VFPv3 or VFPv4 instruction, is UNDEFINED if executed in Hyp mode.
Note
• If TCP10 and TCP11 are set to 1 then all otherwise-valid Advanced SIMD use by Non-secure
PL1 and PL0 modes is trapped to Hyp mode, regardless of the value of this field.
• The NSACR.NSASEDIS bit can make this bit behave as RAO/WI, regardless of its actual
value.
For more information, see Summary of access controls for Advanced SIMD functionality on
page B1-1232.
• Implements the Floating-point Extension but does not implement the Advanced SIMD
• Does not implement the Floating-point Extension or the Advanced SIMD Extension, this bit
is RAO/WI.
• Implements both the Floating-point Extension and the Advanced SIMD Extension, it is
IMPLEMENTATION DEFINED whether this bit is supported. If it is not supported, it is RAZ/WI.
TCPn, bit[n], for values of n from 0 to 13

Trap coprocessor n (CPn). For each bit, the possible values are:
0 Has no effect on accesses to coprocessor CPn from Non-secure PL2, PL1 and PL0
modes.
1 Any otherwise-valid Non-secure access to CPn generates an exception that is taken to

Hyp mode. For more information, see General trapping of coprocessor accesses on
page B1-1256.
Any access to the coprocessor from Hyp mode is UNDEFINED.
For more information, see Summary of general controls of CP10 and CP11 functionality on
page B1-1230.
Note
Each NSACR.cpn bit can make the corresponding HCPTR.TCPn bit behave as RAO/WI, regardless
of its actual value.
For values of n that correspond to coprocessors that are not implemented, it is IMPLEMENTATION
DEFINED whether TCPn:
• Is RAO/WI.
• Can be written by software that has write access to HCPTR.
Coprocessors 8, 9, 12, and 13 are reserved for possible use by ARM, and therefore are never
implemented.
If a set of functionality requires the use of more than one coprocessor, then setting the TCPn bits
corresponding to those coprocessors to different values can cause UNPREDICTABLE behavior. For
example, since CP10 and CP11 provide the Floating-point Extension and Advanced SIMD
Extension functionality, TCP10 and TCP11 must be set to the same value.
Accessing the HCPTR

To access the HCPTR, software reads or writes the CP15 registers with <opc1> set to 4, <CRn> set to c1, <CRm> set to
MRC p15, 4, <Rt>, c1, c1, 2 ; Read HCPTR into Rt

MCR p15, 4, <Rt>, c1, c1, 2 ; Write Rt to HCPTR
B4.1.65 HCR, Hyp Configuration Register, Virtualization Extensions

The HCR characteristics are:
Purpose The HCR provides configuration controls for virtualization, including defining whether
various Non-secure operations are trapped to Hyp mode.

page B3-1450.
on page B3-1446.
registers.
The HCR bit assignments are:

31 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved,
BSU
UNK/SBZP
TGE FB
TVM VA
TTLB VI
TPU VF
TPC AMO
TSW IMO
TAC FMO
TIDCP PTW
TSC SWIO
TID3 VM
TID2
TID1
TID0
TWE
TWI
DC
In the descriptions of the HCR fields:
• Descriptions of bits describe the effect of setting the bit to 1. If the bit is set to 0 it has no effect on the
operation of the processor.
• A valid Non-secure PL1 or PL0 access means an access from a Non-secure PL1 or PL0 mode that, if the bit
was set to 0, would not be UNDEFINED or UNPREDICTABLE.
TGE, bit[27] Trap general exceptions. When this bit is set to 1, and the processor is executing at PL0 in
Non-secure state, Undefined Instruction exceptions, Supervisor Call exceptions, synchronous
External aborts, and some Alignment faults, are taken to Hyp mode. For more information see
Routing general exceptions to Hyp mode on page B1-1190.
TVM, bit[26] Trap virtual memory controls. When this bit is set to 1, any valid Non-secure PL1 or PL0 write to a
virtual memory control register is trapped to Hyp mode. For more information see Trapping writes
to virtual memory control registers on page B1-1256.
TTLB, bit[25] Trap TLB maintenance operations. When this bit is set to 1, any valid Non-secure PL1 or PL0 access
to a TLB maintenance operation is trapped to Hyp mode. For more information see Trapping
accesses to TLB maintenance operations on page B1-1252.
TPU, bit[24] Trap cache maintenance to point of unification operations. When this bit is set to 1, any valid
Non-secure PL1 or PL0 access to a cache maintenance operation that operates to the point of
unification is trapped to Hyp mode. For more information see Trapping accesses to cache
TPC, bit[23] Trap cache maintenance to point of coherency operations. When this bit is set to 1, any valid
Non-secure PL1 or PL0 access to a cache maintenance operation that operates to the point of
coherency is trapped to Hyp mode. For more information see Trapping accesses to cache
maintenance operations on page B1-1252.…
TSW, bit[22] Trap set/way cache maintenance operations. When this bit is set to 1, any valid Non-secure PL1 or
PL0 access to a cache maintenance operation that operates by set/way is trapped to Hyp mode. For
more information see Trapping accesses to cache maintenance operations on page B1-1252.
TAC, bit[21] Trap ACTLR accesses. When this bit is set to 1, any valid Non-secure PL1 or PL0 access to the
ACTLR is trapped to Hyp mode. For more information see Trapping accesses to the Auxiliary
Control Register on page B1-1252.
TIDCP, bit[20]
Trap lockdown. When this bit is set to 1, any valid Non-secure PL1 or PL0 access to a CP15
lockdown, DMA, or TCM operation, is trapped to Hyp mode. For more information, including the
handling of Non-secure accesses at PL0, see Trapping accesses to lockdown, DMA, and TCM
operations on page B1-1251.
TSC, bit[19] Trap SMC instruction.When this bit is set to 1, attempts to execute SMC instructions in Non-secure PL1
modes are trapped to Hyp mode. For more information, including the interaction with the SCR.SCD
bit, see Trapping use of the SMC instruction on page B1-1253.
TIDn, for values of n from 3 to 0, bits[18:15]

Trap ID register groups. When one of these bits is set to 1, any valid Non-secure read of a register
in the corresponding group is trapped to Hyp mode. For more information, including the registers
in each group, see Trapping ID mechanisms on page B1-1249.
TID3 is bit[18], TID2 is bit[17], TID1 is bit[16], and TID0 is bit[15].
TWE, bit[14] Trap WFE instruction. When this bit is set to 1, any attempt, from a Non-secure PL1or PL0 mode, to
execute an WFE instruction that might otherwise cause the processor to suspend execution is trapped
to Hyp mode. For more information see Trapping use of the WFI and WFE instructions on
page B1-1253.
TW1, bit[13] Trap WFI instruction. When this bit is set to 1, any attempt, from a Non-secure PL1 or PL0 mode, to
execute an WFI instruction that might otherwise cause the processor to suspend execution is trapped
to Hyp mode. For more information see Trapping use of the WFI and WFE instructions on
page B1-1253
DC, bit[12] Default cacheable. When the Non-secure PL1&0 stage 1 MMU is disabled, this bit affects the
memory type and attributes determined by a Non-secure PL1&0 stage 1 translation. For more
information see VMSA behavior when a stage 1 MMU is disabled on page B3-1312.
BSU, bits[11:10]
Barrier shareability upgrade. When this field is nonzero, it upgrades the required shareability of DMB
and DSB barrier instructions executed in a Non-secure PL1 or PL0 mode, beyond the effect specified
in the instruction. For more information, including the encoding of this field, see Shareability and
access limitations on the data barrier operations on page A3-150.
FB, bit[9] Force broadcast. When this bit is set to 1, TLB maintenance operations, branch predictor invalidate
all operations, and instruction cache invalidate all operations performed in Non-secure PL1 modes,
are broadcast across the Inner Shareable domain. For more information see Virtualization
Extensions upgrading of maintenance operations on page B2-1284 and Virtualization Extensions
upgrading of TLB maintenance operations on page B3-1388.
Virtual asynchronous exception bits, bits[8:6]

Subject to other controls, when one of these bits is set to 1 the corresponding virtual asynchronous
exception is generated when the processor is executing in Non-secure state at PL1 or PL0. For more
information see Virtual exceptions in the Virtualization Extensions on page B1-1196.
The virtual asynchronous exception bits are:
VA, bit[8] Virtual asynchronous abort.
VI, bit[7] Virtual IRQ.
VF, bit[6] Virtual FIQ.
Mask override bits, bits[5:3]

Setting one of these bits to 1 can modify the effect of the corresponding CPSR exception mask bit
when the processor is in Non-secure state. For more information see Asynchronous exception
masking on page B1-1183.
The mask override bits are:
AMO, bit[5] Overrides the CPSR.A bit, and enables signaling by the VA bit.
IMO, bit[4] Overrides the CPSR.I bit, and enables signaling by the VI bit.
FMO, bit[3] Overrides the CPSR.F bit, and enables signaling by the VF bit.
Note
These bits also affect the signaling of virtual asynchronous exceptions.
PTW, bit[2] Protected table walk. When this bit is set to 1 it enables the generation of a stage 2 Permission fault
on a memory access made as part of a stage 1 translation table lookup in the Non-secure PL1&0
translation regime if the stage 2 translation of the access address assigns the Device or
Strongly-ordered attribute. For more information see Stage 2 fault on a stage 1 translation table
walk, Virtualization Extensions on page B3-1399.
SWIO, bit[1] Set/way invalidation override. When this bit is set to 1, it forces invalidate by set/way operations
executed in a Non-secure PL1 mode to be treated as clean and invalidate by set/way operations. For
more information see Virtualization Extensions upgrading of maintenance operations on
page B2-1284.
VM, bit[0] Virtualization MMU enable bit. This is a global enable bit for the PL1&0 stage 2 MMU. The
possible values of this bit are:
0 PL1&0 stage 2 MMU disabled.
For more information see The effects of disabling MMUs on VMSA behavior on
page B3-1312.
1 PL1&0 stage 2 MMU enabled.
Accessing the HCR

To access the HCR, software reads or writes the CP15 registers with <opc1> set to 4, <CRn> set to c1, <CRm> set to c1,
MRC p15, 4, <Rt>, c1, c1, 0 ; Read HCR into Rt

MCR p15, 4, <Rt>, c1, c1, 0 ; Write Rt to HCR
B4.1.66 HDCR, Hyp Debug Configuration Register, Virtualization Extensions

The HDCR characteristics are:
Purpose The HDCR controls the trapping to Hyp mode of Non-secure accesses, at PL1 or lower, to
functions provided by the debug and trace architectures.

page B3-1450.
Attributes A 32-bit RW register. See the field descriptions for the reset value of the register. See also
Reset behavior of CP14 and CP15 registers on page B3-1446.
registers.
The HDCR bit assignments are:

31 12 11 10 9 8 7 6 5 4 0
Reserved, UNK/SBZP HPMN†
TDRA
TDOSA
TDA
TDE
HPME†
TPM†
TPMCR†
† Only on an implementation that includes the Performance Monitors Extension.
In the descriptions of the HDCR fields, a valid Non-secure access means an access from a Non-secure PL1 or PL0
mode that, if the bit was set to 0, would not be UNDEFINED or UNPREDICTABLE.
TDRA, bit[11] Trap Debug ROM access. When this bit is set to 1, any valid Non-secure access to the
DBGDRAR or DBGDSAR is trapped to Hyp mode. For more information, including
dependencies on the values of other HDCR bits, see Trapping CP14 accesses to Debug
ROM registers on page B1-1258.
TDOSA, bit[10] Trap debug OS-related register access. When this bit is set to 1, any valid Non-secure CP14
access to the OS-related registers is trapped to Hyp mode. For more information, including
dependencies on the values of other HDCR bits and a summary of the OS-related registers,
see Trapping CP14 accesses to OS-related debug registers on page B1-1258.
TDA, bit[9] Trap debug access. When this bit is set to 1, any valid Non-secure access to the CP14 Debug
registers, other than the registers trapped by the TDRA and TDOSA bits, is trapped to Hyp
mode. For more information, including dependencies on the values of other HDCR bits, see
Trapping general CP14 accesses to debug registers on page B1-1258.
TDE, bit[8] Trap Debug exceptions. When this bit is set to 1, any Debug exception taken to Non-secure
state is routed to Hyp mode. For more information, including dependencies on the values of
other HDCR bits, see Routing Debug exceptions to Hyp mode on page B1-1193.
Bits[7:0], on an implementation that does not include the Performance Monitors Extension
Reserved, UNK/SBZP.
HPME, bit[7], on an implementation that includes the Performance Monitors Extension

Hypervisor Performance Monitors Enable. The possible values of this bit are:
0 Hyp mode Performance Monitors counters disabled.
1 Hyp mode Performance Monitors counters enabled.
When this bit is set to 1, the Performance Monitors counters that are reserved for use from
Hyp mode are enabled. For more information see the description of the HPMN field and
Counter enables on page C12-2299.
The reset value of this bit is UNKNOWN.
TPM, bit[6], on an implementation that includes the Performance Monitors Extension

Trap Performance Monitors accesses. The possible values of this bit are:
0 Has no effect on Performance Monitors accesses.
1 Trap valid Non-secure Performance Monitors accesses to Hyp mode.
When this bit is set to 1, any valid Non-secure access to the Performance Monitors registers
is trapped to Hyp mode. For more information see Trapping accesses to the Performance
Monitors Extension on page B1-1253.
TPMCR, bit[5], on an implementation that includes the Performance Monitors Extension

Trap PMCR accesses. The possible values of this bit are:
0 Has no effect on PMCR accesses.
1 Trap valid Non-secure PMCR accesses to Hyp mode.
When this bit is set to 1, any valid Non-secure access to the PMCR is trapped to Hyp mode.
For more information see Trapping accesses to the Performance Monitors Extension on
page B1-1253.
HPMN, bits[4:0], on an implementation that includes the Performance Monitors Extension

Defines the number of Performance Monitors counters that are accessible from Non-secure
PL1 modes, and from Non-secure PL0 modes if unprivileged access is enabled.
In Non-secure state, HPMN divides the Performance Monitors counters as follows. If
PMXEVCNTR is accessing Performance Monitors counter n then, in Non-secure state:
• If n is in the range 0≤n<HPMN, the counter is accessible from PL1 and PL2, and
from PL0 if unprivileged access to the counters is enabled.
• If n is in the range HPMN≤n<PMCR.N, the counter is accessible only from PL2.
The HPME bit enables the operation of the counters in this range.
The behavior of the Performance Monitors counters is UNPREDICTABLE if this field is set
zero, or to a value greater than PMCR.N.
For more information see Counter access on page C12-2300.
This field resets to the value of PMCR.N.
Permitted combinations of {TDRA, TDOSA, TDA, TDE} bits

The permitted values of the HDCR.{TDRA, TDOSA, TDA, TDE} bits are 0b0000, 0b0100, 0b1000, 0b1100, 0b1110,
and 0b1111. If these bits are set to any other values, behavior is UNPREDICTABLE.
Accessing the HDCR

To access the HDCR, software reads or writes the CP15 registers with <opc1> set to 4, <CRn> set to c1, <CRm> set to
MRC p15, 4, <Rt>, c1, c1, 1 ; Read HDCR into Rt

MCR p15, 4, <Rt>, c1, c1, 1 ; Write Rt to HDCR
B4.1.67 HDFAR, Hyp Data Fault Address Register, Virtualization Extensions

The HDFAR characteristics are:
Purpose The HDFAR holds the VA of the faulting address that caused a synchronous Data Abort
exception that is taken to Hyp mode.
Any execution in a Non-secure PL1 mode, or in Secure state, makes the HDFAR UNKNOWN.

page B3-1450.
This register is shared with the Secure copy of the DFAR, and the CP15 encoding for the
HDFAR provides Hyp mode access to an alias of the Secure DFAR, see PL2-mode
encodings for shared CP15 registers on page B3-1451.
registers.
The HDFAR bit assignments are:

31 0
VA of faulting address of synchronous Data Abort exception
VA, bits[31:0] The VA of the address used in the access that faulted, generating a synchronous Data Abort
exception.
Accessing the HDFAR

To access the HDFAR, software reads or writes the CP15 registers with <opc1> set to 4, <CRn> set to c6, <CRm> set to
MRC p15, 4, <Rt>, c6, c0, 0 ; Read HDFAR into Rt

MCR p15, 4, <Rt>, c6, c0, 0 ; Write Rt to HDFAR
B4.1.68 HIFAR, Hyp Instruction Fault Address Register, Virtualization Extensions

The HIFAR characteristics are:
Purpose The HIFAR holds the VA of the faulting address that caused a synchronous Prefetch Abort
exception that is taken to Hyp mode.
Any execution in a Non-secure PL1 mode, or in Secure state, makes the HIFAR UNKNOWN.

page B3-1450.
This register is shared with the Secure copy of the IFAR, and the CP15 encoding for the
HIFAR provides Hyp mode access to an alias of the Secure IFAR, see PL2-mode encodings
for shared CP15 registers on page B3-1451.
registers.
The HIFAR bit assignments are:

31 0
VA of faulting address of synchronous Prefetch Abort exception
VA, bits[31:0] The VA of the instruction address used in the instruction fetch that faulted, generating a synchronous
Prefetch Abort exception.
Accessing the HIFAR

To access the HIFAR, software reads or writes the CP15 registers with <opc1> set to 4, <CRn> set to c6, <CRm> set to
MRC p15, 4, <Rt>, c6, c0, 2 ; Read HIFAR into Rt

MCR p15, 4, <Rt>, c6, c0, 2 ; Write Rt to HIFAR
B4.1.69 HMAIRn, Hyp Memory Attribute Indirection Registers 0 and 1, Virtualization Extensions
The HMAIR0 and HMAIR1 characteristics are:
Purpose The HMAIR0 and HMAIR1 registers provide the memory attribute encodings
corresponding to the possible AttrIndx values in a translation table entry for stage 1
translations for memory accesses from Hyp mode. For more information about the AttrIndx
field, see Long-descriptor format memory region attributes on page B3-1368.
Note
Memory accesses from Hyp mode always use the Long-descriptor translation table format.
AttrIndx[2], from the translation table descriptor, selects the appropriate HMAIR:
• Setting AttrIndx[2] to 0 selects HMAIR0.
• Setting AttrIndx[2] to 1 selects HMAIR1.

These are Banked PL2-mode registers, see Banked PL2-mode CP15 read/write registers on
page B3-1450.
Attributes 32-bit RW registers with an UNKNOWN reset values. See also Reset behavior of CP14 and
registers.
The HMAIRn bit assignments and encodings are identical to those for MAIRn.
Accessing the HMAIR0 or HMAIR1

To access the HMAIR0 or HMAIR1, software reads or writes the CP15 registers with <opc1> set to 4, <CRn> set to
c10, <CRm> set to c2, and <opc2> set to 0 for HMAIR0, or to 1 for HMAIR1. For example:
MRC p15, 4, <Rt>, c10, c2, 0 ; Read HMAIR0 into Rt

MCR p15, 4, <Rt>, c10, c2, 1 ; Write Rt to HMAIR1
B4.1.70 HPFAR, Hyp IPA Fault Address Register, Virtualization Extensions

The HPFAR characteristics are:
Purpose For some aborts on a stage 2 translation, taken to Hyp mode, HPFAR holds the faulting IPA.
Execution in any Non-secure mode other than Hyp mode makes this register UNKNOWN.

page B3-1450.
registers.
The HPFAR bit assignments are:

31 4 3 0
Reserved,
FIPA[39:12]
UNK/SBZP
FIPA, bits[31:4]
Bits[39:12] of the faulting IPA.
Accessing the HPFAR

To access the HPFAR, software reads or writes the CP15 registers with <opc1> set to 4, <CRn> set to c6, <CRm> set to
MRC p15, 4, <Rt>, c6, c0, 4 ; Read HPFAR into Rt

MCR p15, 4, <Rt>, c6, c0, 4 ; Write Rt to HPFAR
B4.1.71 HSCTLR, Hyp System Control Register, Virtualization Extensions

The HSCTLR characteristics are:
Purpose The HSCTLR provides top level control of the system operation in Hyp mode. This register
provides Hyp mode control of features controlled by the Banked SCTLR bits, and shows
the values of the non-Banked SCTLR bits.

page B3-1450.
registers.
The HSCTLR bit assignments are:

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
(0) (1) (1) (0) (0) (0) (1) (1) FI (0) (1) (0) (1) (0) (0) (0) I (1) (0) (0) (0) (0) (1) (1) (1) C A M
TE EE WXN CP15BEN
TE, bit[30] Thumb Exception enable. This bit controls whether exceptions taken to Hyp mode are taken in
ARM or Thumb state. The possible values of this bit are:
0 Exceptions taken in ARM state.
1 Exceptions taken in Thumb state.
For more information about the use of this bit see Instruction set state on exception entry on
page B1-1181.
Bits[29:28] Reserved, UNK/SBOP.
EE, bit[25] Exception Endianness bit. The value of this bit defines the value of the CPSR.E bit on entry to an
exception vector in Hyp mode. This value also indicates the endianness of the translation table data
for translation table lookups for the Non-secure PL1&0 stage 2 and PL2 stage 1 address translations.
The possible values of this bit are:
0 Little-endian.
1 Big-endian.
FI, bit[21] Fast interrupts configuration enable bit. The possible values of this bit are:
0 All performance features enabled.
1 Low interrupt latency configuration. Some performance features disabled.
Setting this bit to 1 can reduce interrupt latency in an implementation by disabling
IMPLEMENTATION DEFINED performance features.
This is a read-only bit that takes the value of the SCTLR.FI bit.
For more information, see Low interrupt latency configuration on page B1-1197.
WXN, bit[19] Write permission implies XN. The possible values of this bit are:
0 Hyp translations that permit write are not forced to XN.
1 Hyp translations that permit write are forced to XN.
For more information see Preventing execution from writable locations on page B3-1357.
Bit[18] Reserved, UNK/SBOP.
I, bit[12] Instruction cache enable bit: This is a global enable bit for instruction caches, for memory accesses
made in Hyp mode. The possible values of this bit are:
0 Instruction caches disabled.
1 Instruction caches enabled.
If the system does not implement any instruction caches that can be accessed by the processor, at
any level of the memory hierarchy, this bit is RAZ/WI.
If the system implements any instruction caches that can be accessed by the processor then it must
be possible to disable them by setting this bit to 0.
For more information see Cache enabling and disabling on page B2-1268.
CP15BEN, bit[5]
CP15 barrier enable. If implemented, this is an enable bit for use of the CP15 DMB, DSB, and ISB
barrier operations from Hyp mode:
0 CP15 barrier operations disabled. Their encodings are UNDEFINED.
1 CP15 barrier operations enabled.
This bit is optional. If not implemented, bit[5] is RAO/WI. However, it must be implemented if
SCTLR.CP15BEN is implemented.
Note
SCTLR.CP15BEN controls the use of these operations from PL1 and PL0 modes.
For more information about these operations see Data and instruction barrier operations, VMSA on
page B4-1744.
C, bit[2] Cache enable bit. This is a global enable bit for data and unified caches, for memory accesses made
in Hyp mode. The possible values of this bit are:
0 Data or unified caches disabled.
1 Data or unified caches enabled.
If the system does not implement any data or unified caches that can be accessed by the processor,
at any level of the memory hierarchy, this bit is RAZ/WI.
If the system implements any data or unified caches that can be accessed by the processor then it
must be possible to disable them by setting this bit to 0.
For more information see Cache enabling and disabling on page B2-1268.
A, bit[1] Alignment bit. This is the enable bit for Alignment fault checking, for memory accesses made in
Hyp mode. The possible values of this bit are:
0 Alignment fault checking disabled.
1 Alignment fault checking enabled.
For more information, see Unaligned data access on page A3-106.
M, bit[0] MMU enable bit. This is a global enable bit for the PL2 stage 1 MMU. The possible values of this
bit are:
0 PL2 stage 1 MMU disabled.
1 PL2 stage 1 MMU enabled.
For more information, see The effects of disabling MMUs on VMSA behavior on page B3-1312.
Accessing the HSCTLR

To access the HSCTLR, software reads or writes the CP15 registers with <opc1> set to 4, <CRn> set to c1, <CRm> set
MRC p15, 4, <Rt>, c1, c0, 0 ; Read HSCTLR into Rt

MCR p15, 4, <Rt>, c1, c0, 0 ; Write Rt to HSCTLR
B4.1.72 HSR, Hyp Syndrome Register, Virtualization Extensions

The HSR characteristics are:
Purpose The HSR holds syndrome information for an exception taken to Hyp mode.
Execution in any Non-secure mode other than Hyp mode makes this register UNKNOWN.

page B3-1450.
registers.
The HSR bit assignments are:

31 26 25 24 0
EC ISS
IL
EC, bits[31:26]
Exception class. The exception class for the exception that is taken to Hyp mode:
• When zero, this field indicates that the reason for the exception is not known. In this case, the
other fields in the register are UNKNOWN.
• Otherwise, the field holds the Exception class for the exception, and the ISS field holds a
syndrome for the exception.
IL, bit[25] Instruction length. Indicates the size of the instruction that has been trapped to Hyp mode. The
0 16-bit instruction.
1 32-bit instruction.
For information about the validity of the IL field see Use of the HSR on page B3-1421. When the
field is not valid it is UNK/SBZP.
ISS, bits[24:0] Instruction-specific syndrome. The interpretation of this field depends on the value of the EC field.
Accessing the HSR

To access the HSR, software reads or writes the CP15 registers with <opc1> set to 4, <CRn> set to c5, <CRm> set to c2,
MRC p15, 4, <Rt>, c5, c2, 0 ; Read HSR into Rt

MCR p15, 4, <Rt>, c5, c2, 0 ; Write Rt to HSR
B4.1.73 HSTR, Hyp System Trap Register, Virtualization Extensions

The HSTR characteristics are:
Purpose The HSTR controls the trapping to Hyp mode of Non-secure accesses, at PL1 or lower, of:
• Use of Jazelle or ThumbEE.
• Access to each of the CP15 primary coprocessor registers, {c0-c3, c5-c13, c15}.

page B3-1450.
on page B3-1446.
registers.
The HSTR bit assignments are:

31 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved, UNK/SBZP (0) T9 T8 T7 T6 T5 (0) T3 T2 T1 T0
TJDBX T10
TTEE T11
T15 T12
T13
In the descriptions of the HSTR fields, a valid Non-secure access means an access that, if the bit was set to 0, would
not be UNDEFINED or UNPREDICTABLE.
Bits[31:18, 14, 4]
Reserved, UNK/SBZP.
TJDBX, bit[17]
Trap Jazelle operations. When this bit is set to 1, any valid Non-secure access to Jazelle functionality
is trapped to Hyp mode. For more information see Trapping accesses to Jazelle functionality on
page B1-1254.
TTEE, bit[16] Trap ThumbEE operations. When this bit is set to 1, any valid Non-secure access to the ThumbEE
configuration registers is trapped to Hyp mode. For more information see Trapping accesses to the
ThumbEE configuration registers on page B1-1254.
Tx, bit[x], for values of x in the set {0-3, 5-13, 15}

Trap coprocessor primary register. When Tx is set to 1, Non-secure accesses from PL1 and PL0
modes to CP15 primary coprocessor register cx are trapped to Hyp mode. This means that, when Tx
is set to 1, the following accesses are trapped to Hyp mode:
• An access using an MCR or MRC instruction with CRn set to cx:
— From a Non-secure PL1 mode.
— From the Non-secure PL0 mode, if the access would not be UNDEFINED if Tx was set
to 0.
• Any access using an MCRR or MRRC instruction with CRm set to cx:
— From a Non-secure PL1 mode.
— From the Non-secure PL0 mode, if the access would not be UNDEFINED if Tx was set
to 0.
For more information see Generic trapping of accesses to CP15 system control registers on
page B1-1256.
Note
A Tn bit traps all accesses to the corresponding CP15 primary coprocessor register. This is unlike
most traps to Hyp mode, including the traps controlled by the TJDBX and TTEE bits, that trap only
otherwise-valid accesses.
Accessing the HSTR

To access the HSTR, software reads or writes the CP15 registers with <opc1> set to 4, <CRn> set to c1, <CRm> set to
MRC p15, 4, <Rt>, c1, c1, 3 ; Read HSTR into Rt

MCR p15, 4, <Rt>, c1, c1, 3 ; Write Rt to HSTR
B4.1.74 HTCR, Hyp Translation Control Register, Virtualization Extensions

The HTCR characteristics are:
Purpose The HTCR controls the translation table walks required for the stage 1 translation of
memory accesses from Hyp mode, and holds cacheability and shareability information for
the accesses.
Usage constraints Used in conjunction with HTTBR, that defines the translation table base address for the
translations.
Only accessible from Hyp mode, or from Monitor mode when SCR.NS is set to 1, see

page B3-1450.
registers.
Note
For other address translations, the following registers are equivalent to the HTCR and HTTBR:
• For stage 1 translations for accesses from modes other than Hyp mode, the TTBCR, TTBR0, and TTBR1.
• For stage 2 translations, the VTCR and VTTBR.
The HTCR bit assignments are:
31 30 29 24 23 22 14 13 12 11 10 9 8 7 3 2 0
Reserved, Reserved,
(1) (1) Reserved, UNK/SBZP SH0 T0SZ
UNK/SBZP UNK/SBZP
IMPLEMENTATION DEFINED ORGN0

IRGN0
IMPLEMENTATION DEFINED, bit[30]

An IMPLEMENTATION DEFINED bit.
Bits[23] Reserved, UNK/SBOP.
SH0, bits[13:12]
Shareability attribute for memory associated with translation table walks using HTTBR. This field
is encoded as described in Shareability, Long-descriptor format on page B3-1369.
ORGN0, bits[11:10]
Outer cacheability attribute for memory associated with translation table walks using HTTBR.
Table B4-4 shows the encoding of this field.
Table B4-4 HTCR.ORGN0 field encoding
ORGN0 Meaning
00 Normal memory, Outer Non-cacheable
01 Normal memory, Outer Write-Back Write-Allocate Cacheable
10 Normal memory, Outer Write-Through Cacheable
11 Normal memory, Outer Write-Back no Write-Allocate Cacheable
IRGN0, bits[9:8]
Inner cacheability attribute for memory associated with translation table walks using HTTBR.
Table B4-5 shows the encoding of this field.
Table B4-5 HTCR.IRGN0 field encoding
IRGN0 Meaning
00 Normal memory, Inner Non-cacheable
01 Normal memory, Inner Write-Back Write-Allocate Cacheable
10 Normal memory, Inner Write-Through Cacheable
11 Normal memory, Inner Write-Back no Write-Allocate Cacheable
T0SZ, bits[2:0]
The size offset of the memory region addressed by HTTBR. This field is encoded as a three-bit
unsigned integer, and the region size is 2(32-T0SZ) bytes.
HTTBR, Hyp Translation Table Base Register, Virtualization Extensions on page B4-1596 describes
how the value of this field determines the width of the translation table base address defined by
HTTBR.
Accessing the HTCR

To access the HTCR, software reads or writes the CP15 registers with <opc1> set to 4, <CRn> set to c2, <CRm> set to
MRC p15, 4, <Rt>, c2, c0, 2 ; Read HTCR into Rt

MCR p15, 4, <Rt>, c2, c0, 2 ; Write Rt to HTCR
B4.1.75 HTPIDR, Hyp Software Thread ID Register, Virtualization Extensions

The HTPIDR characteristics are:
Purpose The HTPIDR provides a location where software running in Hyp mode can store thread
identifying information that is not visible to Non-secure software executing at PL0 or PL1,
for hypervisor management purposes.
This register is part of the Miscellaneous operations functional group.
Processor hardware never updates this register.

This is a Banked PL2-mode register, see Banked PL2-mode CP15 read/write registers on
page B3-1450.
Miscellaneous operations functional group.
Accessing the HTPIDR

To access the HTPIDR, software executing in Hyp mode reads or writes the CP15 registers with <opc1> set to 4,
<CRn> set to c13, <CRm> set to c0, and <opc2> set to 2.
For example:
MRC p15, 4, <Rt>, c13, c0, 2 ; Read HTPIDR into Rt

MCR p15, 4, <Rt>, c13, c0, 2 ; Write Rt to HTPIDR
B4.1.76 HTTBR, Hyp Translation Table Base Register, Virtualization Extensions

The HTTBR characteristics are:
Purpose The HTTBR holds the base address of the translation table for the stage 1 translation of
memory accesses from Hyp mode.
Note
These translations are always defined using the Long-descriptor format translation tables.
Usage constraints Used in conjunction with the HTCR.

Only accessible from Hyp mode, or from Monitor mode when SCR.NS is set to 1, see

This is a Banked PL2-mode register, see Banked PL2-mode CP15 read/write registers on
page B3-1450.
registers.
Note
See HTCR, Hyp Translation Control Register, Virtualization Extensions on page B4-1593 for a summary of the
registers that define the translation tables for other address translations.
The HTTBR bit assignments are:
63 40 39 x x-1 0
Reserved, UNK/SBZP BADDR[39:x] Reserved, UNK/SBZP
BADDR, bits[39:x]
Translation table base address, bits[39:x]. See the text in this section for a description of how x is
defined.
The value of x determines the required alignment of the translation table, which must be aligned to
2x bytes.
Bits[x-1:0] Reserved, UNK/SBZP.
The HTCR.T0SZ field determines the width of the defined translation table base address, indicated by the value of
x in the HTTBR description. The following pseudocode calculates the value of x:
T0Size = UInt(HTCR.T0SZ);
if T0Size > 1 then
x = 14 - T0Size;
else
x = 5 - T0Size;
Accessing the HTTBR

To access HTTBR, software performs a 64-bit read or write of the CP15 registers with <CRm> set to c2 and <opc1>
MRRC p15, 4, <Rt>, <Rt2>, c2 ; Read 64-bit HTTBR into Rt (low word) and Rt2 (high word)
MCRR p15, 4, <Rt>, <Rt2>, c2 ; Write Rt (low word) and Rt2 (high word) to 64-bit HTTBR
In these MRRC and MCRR instructions, Rt holds the least-significant word of HTTBR, and Rt2 holds the
B4.1.77 HVBAR, Hyp Vector Base Address Register, Virtualization Extensions

The HVBAR characteristics are:
Purpose The HVBAR holds the exception base address for any exception that is taken to Hyp mode,
see Exception vectors and the exception base address on page B1-1164.

page B3-1450.
registers.
The HVBAR bit assignments are:
31 5 4 0
Reserved,
Hyp_Vector_Base_Address
UNK/SBZP
Hyp_Vector_Base_Address, bits[31:5]
Bits[31:5] of the base address of the exception vectors for exceptions that are taken to Hyp mode.
Bits[4:0] of an exception vector is the exception offset, see Table B1-3 on page B1-1166.
For details of how the HVBAR determines the exception addresses see Exception vectors and the exception base
address on page B1-1164.
Accessing the HVBAR

To access the HVBAR, software reads or writes the CP15 registers with <opc1> set to 4, <CRn> set to c12, <CRm> set
MRC p15, 4, <Rt>, c12, c0, 0 ; Read HVBAR into Rt

MCR p15, 4, <Rt>, c12, c0, 0 ; Write Rt to HVBAR
B4.1.78 ICIALLU, Instruction Cache Invalidate All to PoU, VMSA

operation.
B4.1.79 ICIALLUIS, Instruction Cache Invalidate All to PoU, Inner Shareable, VMSA
operation.
B4.1.80 ICIMVAU, Instruction Cache Invalidate by MVA to PoU, VMSA

operation.
B4.1.81 ID_AFR0, Auxiliary Feature Register 0, VMSA

The ID_AFR0 characteristics are:
Purpose ID_AFR0 provides information about the IMPLEMENTATION DEFINED features of the
processor.
This register is a CPUID register, and is part of the Identification registers functional group.

Must be interpreted with the Main ID Register, see MIDR, Main ID Register, VMSA on
page B4-1642.
Configurations The VMSA and PMSA definitions of the register fields are identical.
In a VMSA implementation that includes the Security Extensions, this is a Common
register.
Attributes A 32-bit RO register with an IMPLEMENTATION DEFINED value:

• Table B7-1 on page B7-1940 shows the encodings of all of the CPUID registers.
• Table B3-44 on page B3-1487 shows the encodings of all of the registers in the
The ID_AFR0 bit assignments are:

31 16 15 12 11 8 7 4 3 0
Reserved, UNK
IMPLEMENTATION DEFINED, bits[15:12]
The Auxiliary Feature Register 0 has four 4-bit IMPLEMENTATION FIELDS. These fields are defined by the
implementer of the design. The implementer is identified by the Implementer field of the MIDR.
The Auxiliary Feature Register 0 enables implementers to include additional design features in the CPUID scheme.
Field definitions for the Auxiliary Feature Register 0 might:
• Differ between different implementers.
• Be subject to change.
• Migrate over time, for example if they are incorporated into the main architecture.
Accessing ID_AFR0
To access ID_AFR0, software reads the CP15 registers with <opc1> set to 0, <CRn> set to c0, <CRm> set to c1, and
MRC p15, 0, <Rt>, c0, c1, 3 ; Read ID_AFR0 into Rt
B4.1.82 ID_DFR0, Debug Feature Register 0, VMSA

The ID_DFR0 characteristics are:
Purpose ID_DFR0 provides top level information about the debug system.
register.

All field values not shown in the field descriptions are reserved.
The ID_DFR0 bit assignments are:
31 28 27 24 23 20 19 16 15 12 11 8 7 4 3 0
Reserved,
UNK
Performance Monitors
Extension, A and R profiles
Debug model, M profile
Memory-mapped trace model
Coprocessor trace model
Memory-mapped debug model, A and R profiles
Coprocessor Secure debug model, A profile only
Coprocessor debug model, A and R profiles
Performance Monitors Extension, A and R profiles, bits[27:24]

Support for coprocessor-based ARM Performance Monitors Extension, for A and R profile
processors. Permitted values are:
0b0000 PMUv2 not supported.
0b0001 Support for Performance Monitors Extension, PMUv1.
0b0010 Support for Performance Monitors Extension, PMUv2.
0b1111 No ARM Performance Monitors Extension support.
Note
A value of 0b0000 gives no indication of whether PMUv1 monitors are supported.
Debug model, M profile, bits[23:20]

Support for memory-mapped debug model for M profile processors. Permitted values are:
0b0000 Not supported.
0b0001 Support for M profile Debug architecture, with memory-mapped access.
Memory-mapped trace model, bits[19:16]

Support for memory-mapped trace model. Permitted values are:
0b0001 Support for ARM trace architecture, with memory-mapped access.
The ID register, register 0x079, gives more information about the implementation. See
also Trace on page C1-2010.
Coprocessor trace model, bits[15:12]

Support for coprocessor-based trace model. Permitted values are:
0b0001 Support for ARM trace architecture, with CP14 access.
The ID register, register 0x079, gives more information about the implementation. See
also Trace on page C1-2010.
Memory-mapped debug model, A and R profiles, bits[11:8]

Support for memory-mapped debug model, for A and R profile processors. Permitted values are:
0b0000 Not supported, or pre-ARMv6 implementation.
0b0100 Support for v7 Debug architecture, with memory-mapped access.
0b0101 Support for v7.1 Debug architecture, with memory-mapped access.
Note
The permitted field values are not continuous, and values 0b0001, 0b0010, and 0b0011 are reserved.
Coprocessor Secure debug model, bits[7:4]

Support for coprocessor-based Secure debug model, for an A profile processor that includes the
Security Extensions. Permitted values are:
0b0011 Support for v6.1 Debug architecture, with CP14 access.
0b0100 Support for v7 Debug architecture, with CP14 access.
Note
The permitted field values are not continuous, and values 0b0001 and 0b0010 are reserved.
Coprocessor debug model, bits[3:0]

Support for coprocessor based debug model, for A and R profile processors. Permitted values are:
Note
The permitted field values are not continuous, and value 0b0001 is reserved.
Note
Software can obtain more information about the debug implementation from the debug infrastructure, see Debug
identification registers on page C11-2184.
Accessing ID_DFR0
To access ID_DFR0, software reads the CP15 registers with <opc1> set to 0, <CRn> set to c0, <CRm> set to c1, and
MRC p15, 0, <Rt>, c0, c1, 2 ; Read ID_DFR0 into Rt
B4.1.83 ID_ISAR0, Instruction Set Attribute Register 0, VMSA

The ID_ISAR0 characteristics are:
Purpose ID_ISAR0 provides information about the instruction sets implemented by the processor.
For more information see About the Instruction Set Attribute registers on page B7-1940.

Must be interpreted with ID_ISAR1, ID_ISAR2, ID_ISAR3, and ID_ISAR4. For more
information see About the Instruction Set Attribute registers on page B7-1940.
register.

The ID_ISAR0 bit assignments are:

31 28 27 24 23 20 19 16 15 12 11 8 7 4 3 0
Reserved,
UNK
Debug_instrs CmpBranch_instrs BitCount_instrs

Divide_instrs Coproc_instrs Bitfield_instrs Swap_instrs
Divide_instrs, bits[27:24]
Indicates the implemented Divide instructions. Permitted values are:
0b0000 None implemented.
0b0001 Adds SDIV and UDIV in the Thumb instruction set.
0b0010 As for 0b0001, and adds SDIV and UDIV in the ARM instruction set.
Debug_instrs, bits[23:20]
Indicates the implemented Debug instructions. Permitted values are:
0b0001 Adds BKPT.
Coproc_instrs, bits[19:16]
Indicates the implemented Coprocessor instructions. Permitted values are:
0b0000 None implemented, except for instructions separately attributed by the architecture,
including CP15, CP14, Advanced SIMD Extension and the Floating-point Extension.
0b0001 Adds generic CDP, LDC, MCR, MRC, and STC.
0b0010 As for 0b0001, and adds generic CDP2, LDC2, MCR2, MRC2, and STC2.
0b0011 As for 0b0010, and adds generic MCRR and MRRC.
0b0100 As for 0b0011, and adds generic MCRR2 and MRRC2.
CmpBranch_instrs, bits[15:12]
Indicates the implemented combined Compare and Branch instructions in the Thumb instruction
set. Permitted values are:
0b0001 Adds CBNZ and CBZ.
Bitfield_instrs, bits[11:8]
Indicates the implemented BitField instructions. Permitted values are:
0b0001 Adds BFC, BFI, SBFX, and UBFX.
BitCount_instrs, bits[7:4]
Indicates the implemented Bit Counting instructions. Permitted values are:
0b0001 Adds CLZ.
Swap_instrs, bits[3:0]
Indicates the implemented Swap instructions in the ARM instruction set. Permitted values are:
0b0001 Adds SWP and SWPB.
Accessing ID_ISAR0
To access ID_ISAR0, software reads the CP15 registers with <opc1> set to 0, <CRn> set to c0, <CRm> set to c2, and
MRC p15, 0, <Rt>, c0, c2, 0 ; Read ID_ISAR0 into Rt


register.


31 28 27 24 23 20 19 16 15 12 11 8 7 4 3 0
Jazelle_instrs Immediate_instrs Extend_instrs Except_instrs

Interwork_instrs IfThen_instrs Except_AR_instrs Endian_instrs
Jazelle_instrs, bits[31:28]
Indicates the implemented Jazelle extension instructions. Permitted values are:
0b0000 No support for Jazelle.
0b0001 Adds the BXJ instruction, and the J bit in the PSR.
This setting might indicate a trivial implementation of the Jazelle extension.
Interwork_instrs, bits[27:24]
Indicates the implemented Interworking instructions. Permitted values are:
0b0001 Adds the BX instruction, and the T bit in the PSR.
0b0010 As for 0b0001, and adds the BLX instruction. PC loads have BX-like behavior.
0b0011 As for 0b0010, and guarantees that data-processing instructions in the ARM instruction
set with the PC as the destination and the S bit clear have BX-like behavior.
Note
A value of 0b0000, 0b0001, or 0b0010 in this field does not guarantee that an ARM data-processing
instruction with the PC as the destination and the S bit clear behaves like an old MOV PC instruction,
ignoring bits[1:0] of the result. With these values of this field:
• If bits[1:0] of the result value are 0b00 then the processor remains in ARM state.
• If bits[1:0] are 0b01, 0b10 or 0b11, the result must be treated as UNPREDICTABLE.
Immediate_instrs, bits[23:20]
Indicates the implemented data-processing instructions with long immediates. Permitted values are:
0b0001 Adds:
• The MOVT instruction.
• The MOV instruction encodings with zero-extended 16-bit immediates.
• The Thumb ADD and SUB instruction encodings with zero-extended 12-bit
immediates, and the other ADD, ADR and SUB encodings cross-referenced by the
pseudocode for those encodings.
IfThen_instrs, bits[19:16]
Indicates the implemented If-Then instructions in the Thumb instruction set. Permitted values are:
0b0001 Adds the IT instructions, and the IT bits in the PSRs.
Extend_instrs, bits[15:12]
Indicates the implemented Extend instructions. Permitted values are:
0b0000 No scalar sign-extend or zero-extend instructions are implemented, where scalar
instructions means non-Advanced SIMD instructions.
0b0001 Adds the SXTB, SXTH, UXTB, and UXTH instructions.
0b0010 As for 0b0001, and adds the SXTB16, SXTAB, SXTAB16, SXTAH, UXTB16, UXTAB, UXTAB16, and
UXTAH instructions.
Note
In addition:
• The shift options on these instructions are available only if the WithShifts_instrs attribute is
0b0011 or greater.
• The SXTAB16, SXTB16, UXTAB16, and UXTB16 instructions are implemented only if both:
— The Extend_instrs attribute is 0b0010 or greater.
— The SIMD_instrs attribute is 0b0011 or greater.
Except_AR_instrs, bits[11:8]
Indicates the implemented A and R profile exception-handling instructions. Permitted values are:
0b0001 Adds the SRS and RFE instructions, and the A and R profile forms of the CPS instruction.
Except_instrs, bits[7:4]
Indicates the implemented exception-handling instructions in the ARM instruction set. Permitted
values are:
0b0000 Not implemented. This indicates that the User registers and exception return forms of
the LDM and STM instructions are not implemented.
0b0001 Adds the LDM (exception return), LDM (User registers) and STM (User registers) instruction
versions.
Endian_instrs, bits[3:0]
Indicates the implemented Endian instructions. Permitted values are:
0b0001 Adds the SETEND instruction, and the E bit in the PSRs.
Accessing ID_ISAR1


register.


31 28 27 24 23 20 19 16 15 12 11 8 7 4 3 0
Reversal_instrs MultU_instrs Mult_instrs MemHint_instrs

PSR_AR_instrs MultS_instrs MultiAccessInt_instrs LoadStore_instrs
Reversal_instrs, bits[31:28]
Indicates the implemented Reversal instructions. Permitted values are:
0b0001 Adds the REV, REV16, and REVSH instructions.
0b0010 As for 0b0001, and adds the RBIT instruction.
PSR_AR_instrs, bits[27:24]
Indicates the implemented A and R profile instructions to manipulate the PSR. Permitted values are:
0b0001 Adds the MRS and MSR instructions, and the exception return forms of data-processing
instructions described in SUBS PC, LR (Thumb) on page B9-1996 and SUBS PC, LR
and related instructions (ARM) on page B9-1998.
Note
The exception return forms of the data-processing instructions are:
• In the ARM instruction set, data-processing instructions with the PC as the destination and
the S bit set. These instructions might be affected by the WithShifts attribute.
• In the Thumb instruction set, the SUBS PC, LR, #N instruction.
MultU_instrs, bits[23:20]
Indicates the implemented advanced unsigned Multiply instructions. Permitted values are:
0b0001 Adds the UMULL and UMLAL instructions.
0b0010 As for 0b0001, and adds the UMAAL instruction.
MultS_instrs, bits[19:16]
Indicates the implemented advanced signed Multiply instructions. Permitted values are:
0b0001 Adds the SMULL and SMLAL instructions.
0b0010 As for 0b0001, and adds the SMLABB, SMLABT, SMLALBB, SMLALBT, SMLALTB, SMLALTT, SMLATB,
SMLATT, SMLAWB, SMLAWT, SMULBB, SMULBT, SMULTB, SMULTT, SMULWB, and SMULWT instructions.
Also adds the Q bit in the PSRs.
0b0011 As for 0b0010, and adds the SMLAD, SMLADX, SMLALD, SMLALDX, SMLSD, SMLSDX, SMLSLD,
SMLSLDX, SMMLA, SMMLAR, SMMLS, SMMLSR, SMMUL, SMMULR, SMUAD, SMUADX, SMUSD, and SMUSDX
instructions.
Mult_instrs, bits[15:12]
Indicates the implemented additional Multiply instructions. Permitted values are:
0b0000 No additional instructions implemented. This means only MUL is implemented.
0b0001 Adds the MLA instruction.
0b0010 As for 0b0001, and adds the MLS instruction.
MultiAccessInt_instrs, bits[11:8]
Indicates the support for interruptible multi-access instructions. Permitted values are:
0b0000 No support. This means the LDM and STM instructions are not interruptible.
0b0001 LDM and STM instructions are restartable.
0b0010 LDM and STM instructions are continuable. Not permitted in ARMv7-A or ARMv7-R.
MemHint_instrs, bits[7:4]
Indicates the implemented Memory Hint instructions. Permitted values are:
0b0001 Adds the PLD instruction.
0b0010 Adds the PLD instruction.
In the MemHint_instrs field, entries of 0b0001 and 0b0010 have identical meanings.
0b0011 As for 0b0001 (or 0b0010), and adds the PLI instruction.
0b0100 As for 0b0011, and adds the PLDW instruction.
LoadStore_instrs, bits[3:0]
Indicates the implemented additional load/store instructions. Permitted values are:
0b0000 No additional load/store instructions implemented.
0b0001 Adds the LDRD and STRD instructions.
Accessing ID_ISAR2


register.

31 28 27 24 23 20 19 16 15 12 11 8 7 4 3 0
ThumbEE_extn_instrs ThumbCopy_instrs SynchPrim_instrs SIMD_instrs

TrueNOP_instrs TabBranch_instrs SVC_instrs Saturate_instrs
ThumbEE_extn_instrs, bits[31:28]
Indicates the implemented Thumb Execution Environment (ThumbEE) Extension instructions.
Permitted values are:
0b0001 Adds the ENTERX and LEAVEX instructions, and modifies the load behavior to include null
checking.
Note
This field can only have a value other than 0b0000 when the ID_PFR0.State3 field has a value of
0b0001.
TrueNOP_instrs, bits[27:24]
Indicates the implemented True NOP instructions. Permitted values are:
0b0000 None implemented. This means there are no NOP instructions that do not have any
register dependencies.
0b0001 Adds true NOP instructions in both the Thumb and ARM instruction sets. This also
permits additional NOP-compatible hints.
ThumbCopy_instrs, bits[23:20]
Indicates the support for Thumb non flag-setting MOV instructions. Permitted values are:
0b0000 Not supported. This means that in the Thumb instruction set, encoding T1 of the MOV
(register) instruction does not support a copy from a low register to a low register.
0b0001 Adds support for Thumb instruction set encoding T1 of the MOV (register) instruction,
copying from a low register to a low register.
TabBranch_instrs, bits[19:16]
Indicates the implemented Table Branch instructions in the Thumb instruction set. Permitted values
are:
0b0001 Adds the TBB and TBH instructions.
SynchPrim_instrs, bits[15:12]
This field is used with the ID_ISAR4.SynchPrim_instrs_frac field to indicate the implemented
Synchronization Primitive instructions. Table B4-6 shows the permitted values of these fields:
Table B4-6 Implemented Synchronization Primitive instructions
SynchPrim_instrs SynchPrim_instrs_frac Implemented Synchronization Primitives
0000 0000 None implemented
0001 0000 Adds the LDREX and STREX instructions
0001 0011 As for [0001, 0000], and adds the CLREX, LDREXB, LDREXH, STREXB, and STREXH
instructions
0010 0000 As for [0001, 0011], and adds the LDREXD and STREXD instructions
All combinations of SynchPrim_instrs and SynchPrim_instrs_frac not shown in Table B4-6 are
reserved.
SVC_instrs, bits[11:8]
Indicates the implemented SVC instructions. Permitted values are:
0b0000 Not implemented.
0b0001 Adds the SVC instruction.
Note
The SVC instruction was called the SWI instruction in previous versions of the ARM architecture.
SIMD_instrs, bits[7:4]
Indicates the implemented SIMD instructions. Permitted values are:
0b0001 Adds the SSAT and USAT instructions, and the Q bit in the PSRs.
0b0011 As for 0b0001, and adds the PKHBT, PKHTB, QADD16, QADD8, QASX, QSUB16, QSUB8, QSAX, SADD16,
SADD8, SASX, SEL, SHADD16, SHADD8, SHASX, SHSUB16, SHSUB8, SHSAX, SSAT16, SSUB16, SSUB8,
SSAX, SXTAB16, SXTB16, UADD16, UADD8, UASX, UHADD16, UHADD8, UHASX, UHSUB16, UHSUB8, UHSAX,
UQADD16, UQADD8, UQASX, UQSUB16, UQSUB8, UQSAX, USAD8, USADA8, USAT16, USUB16, USUB8, USAX,
UXTAB16, and UXTB16 instructions.
Also adds support for the GE[3:0] bits in the PSRs.
Note
• In the SIMD_instrs field, the permitted values are not continuous, and the value 0b0010 is
reserved.
• The SXTAB16, SXTB16, UXTAB16, and UXTB16 instructions are implemented only if both:
— The Extend_instrs attribute is 0b0010 or greater.
— The SIMD_instrs attribute is 0b0011 or greater.
• The SIMD_instrs field relates only to implemented instructions that perform SIMD
operations on the ARM core registers. MVFR0 and MVFR1 give information about the
SIMD instructions implemented by the optional Advanced SIMD Extension.
Saturate_instrs, bits[3:0]
Indicates the implemented Saturate instructions. Permitted values are:
0b0000 None implemented. This means no non-Advanced SIMD saturate instructions are
implemented.
0b0001 Adds the QADD, QDADD, QDSUB, and QSUB instructions, and the Q bit in the PSRs.
Accessing ID_ISAR3


register.


31 28 27 24 23 20 19 16 15 12 11 8 7 4 3 0
SWP_frac SynchPrim_instrs_frac SMC_instrs WithShifts_instrs

PSR_M_instrs Barrier_instrs Writeback_instrs Unpriv_instrs
SWP_frac, bits[31:28]
Indicates support for the memory system locking the bus for SWP or SWPB instructions. Permitted
values are:
0b0000 SWP or SWPB instructions not implemented.
0b0001 SWP or SWPB implemented but only in a uniprocessor context. SWP and SWPB do not
guarantee whether memory accesses from other masters can come between the load
memory access and the store memory access of the SWP or SWPB.
This field is valid only if the ID_ISAR0.Swap_instrs field is zero.
PSR_M_instrs, bits[27:24]
Indicates the implemented M profile instructions to modify the PSRs. Permitted values are:
0b0001 Adds the M profile forms of the CPS, MRS and MSR instructions.
SynchPrim_instrs_frac, bits[23:20]
This field is used with the ID_ISAR3.SynchPrim_instrs field to indicate the implemented
Synchronization Primitive instructions. Table B4-6 on page B4-1610 shows the permitted values of
these fields.
All combinations of SynchPrim_instrs and SynchPrim_instrs_frac not shown in Table B4-6 on
page B4-1610 are reserved.
Barrier_instrs, bits[19:16]
Indicates the implemented Barrier instructions in the ARM and Thumb instruction sets. Permitted
values are:
0b0000 None implemented. Barrier operations are provided only as CP15 operations.
0b0001 Adds the DMB, DSB, and ISB barrier instructions.
SMC_instrs, bits[15:12]
Indicates the implemented SMC instructions. Permitted values are:
0b0001 Adds the SMC instruction.
Note
The SMC instruction was called the SMI instruction in previous versions of the ARM architecture.
Writeback_instrs, bits[11:8]
Indicates the support for Writeback addressing modes. Permitted values are:
0b0000 Basic support. Only the LDM, STM, PUSH, POP, SRS, and RFE instructions support writeback
addressing modes. These instructions support all of their writeback addressing modes.
0b0001 Adds support for all of the writeback addressing modes defined in ARMv7.
WithShifts_instrs, bits[7:4]
Indicates the support for instructions with shifts. Permitted values are:
0b0000 Nonzero shifts supported only in MOV and shift instructions.
0b0001 Adds support for shifts of loads and stores over the range LSL 0-3.
0b0011 As for 0b0001, and adds support for other constant shift options, both on load/store and
other instructions.
0b0100 As for 0b0011, and adds support for register-controlled shift options.
Note
• In this field, the permitted values are not continuous, and the value 0b0010 is reserved.
• Additions to the basic support indicated by the 0b0000 field value only apply when the
encoding supports them. In particular, in the Thumb instruction set there is no difference
between the 0b0011 and 0b0100 levels of support.
• MOV instructions with shift options are treated as ASR, LSL, LSR, ROR or RRX instructions, as
described in Data-processing instructions on page B7-1941.
Unpriv_instrs, bits[3:0]
Indicates the implemented unprivileged instructions. Permitted values are:
0b0000 None implemented. No T variant instructions are implemented.
0b0001 Adds the LDRBT, LDRT, STRBT, and STRT instructions.
0b0010 As for 0b0001, and adds the LDRHT, LDRSBT, LDRSHT, and STRHT instructions.
Accessing ID_ISAR4

Purpose ID_ISAR5 is reserved for future expansion of the information about the instruction sets
implemented by the processor.
register.
Attributes A 32-bit RO register:


31 0
Reserved, UNK
Accessing ID_ISAR5
B4.1.89 ID_MMFR0, Memory Model Feature Register 0, VMSA

The ID_MMFR0 characteristics are:
Purpose ID_MMFR0 provides information about the implemented memory model and memory
management support.

Must be interpreted with ID_MMFR1, ID_MMFR2, and ID_MMFR3.
register.

The ID_MMFR0 bit assignments are:

31 28 27 24 23 20 19 16 15 12 11 8 7 4 3 0
Innermost FCSE Auxiliary TCM Shareability Outermost PMSA VMSA
shareability support registers support levels shareability support support
Innermost shareability, bits[31:28]

Indicates the innermost shareability domain implemented. Permitted values are:
0b0000 Implemented as Non-cacheable.
0b0001 Implemented with hardware coherency support.
0b1111 Shareability ignored.
This field is valid only if the implementation distinguishes between Inner Shareable and Outer
Shareable, by implementing two levels of shareability, as indicated by the value of the Shareability
levels field, bits[15:12].
When the Shareability levels field is zero, this field is reserved, UNK.
FCSE support, bits[27:24]

Indicates whether the implementation includes the FCSE. Permitted values are:
0b0001 Support for FCSE.
The value of 0b0001 is only permitted when the VMSA_support field has a value greater than 0b0010.
Auxiliary registers, bits[23:20]

Indicates support for Auxiliary registers. Permitted values are:
0b0000 None supported.
0b0001 Support for Auxiliary Control Register only.
0b0010 Support for Auxiliary Fault Status Registers (AIFSR and ADFSR) and Auxiliary
Control Register.
TCM support, bits[19:16]

Indicates support for TCMs and associated DMAs. Permitted values are:
0b0001 Support is IMPLEMENTATION DEFINED. ARMv7 requires this setting.
0b0010 Support for TCM only, ARMv6 implementation.
0b0011 Support for TCM and DMA, ARMv6 implementation.
Note
An ARMv7 implementation might include an ARMv6 model for TCM support. However, in
ARMv7 this is an IMPLEMENTATION DEFINED option, and therefore it must be represented by the
0b0001 encoding in this field.
Shareability levels, bits[15:12]

Indicates the number of shareability levels implemented. Permitted values are:
0b0000 One level of shareability implemented.
0b0001 Two levels of shareability implemented.
Outermost shareability, bits[11:8]

Indicates the outermost shareability domain implemented. Permitted values are:
0b0000 Implemented as Non-cacheable.
0b0001 Implemented with hardware coherency support.
0b1111 Shareability ignored.
PMSA support, bits[7:4]

Indicates support for a PMSA. Permitted values are:
0b0001 Support for IMPLEMENTATION DEFINED PMSA.
0b0010 Support for PMSAv6, with a Cache Type Register implemented.
0b0011 Support for PMSAv7, with support for memory subsections. ARMv7-R profile.
When the PMSA support field is set to a value other than 0b0000 the VMSA support field must be
set to 0b0000.
VMSA support, bits[3:0]

Indicates support for a VMSA. Permitted values are:
0b0001 Support for IMPLEMENTATION DEFINED VMSA.
0b0010 Support for VMSAv6, with Cache and TLB Type Registers implemented.
0b0011 Support for VMSAv7, with support for remapping and the Access flag. ARMv7-A
profile.
0b0100 As for 0b0011, and adds support for the PXN bit in the Short-descriptor translation table
format descriptors.
0b0101 As for 0b0100, and adds support for the Long-descriptor translation table format.
When the VMSA support field is set to a value other than 0b0000 the PMSA support field must be
set to 0b0000.
Accessing ID_MMFR0
To access ID_MMFR0, software reads the CP15 registers with <opc1> set to 0, <CRn> set to c0, <CRm> set to c1, and
MRC p15, 0, <Rt>, c0, c1, 4 ; Read ID_MMFR0 into Rt

management support.

register.


31 28 27 24 23 20 19 16 15 12 11 8 7 4 3 0
L1 cache L1 unified L1 Harvard
Branch L1 unified L1 Harvard L1 unified L1 Harvard
test and cache cache
predictor cache cache cache VA cache VA
clean set/way set/way
Branch predictor, bits[31:28]

Indicates branch predictor management requirements. Permitted values are:
0b0000 No branch predictor, or no MMU present. Implies a fixed MPU configuration.
0b0001 Branch predictor requires flushing on:
• Writing new data to instruction locations.
• Any change to the TTBR0, TTBR1, or TTBCR registers.
• Changes of FCSE ProcessID or ContextID.
0b0010 Branch predictor requires flushing on:
• Writing new data to instruction locations.
• Any change to the TTBR0, TTBR1, or TTBCR registers without a corresponding
change to the FCSE ProcessID or ContextID.
0b0011 Branch predictor requires flushing only on writing new data to instruction locations.
0b0100 For execution correctness, branch predictor requires no flushing at any time.
Note
The branch predictor is described in some documentation as the Branch Target Buffer.
L1 cache test and clean, bits[27:24]

Indicates the supported Level 1 data cache test and clean operations, for Harvard or unified cache
implementations. Permitted values are:
0b0000 None supported. This is the required setting for ARMv7.
0b0001 Supported Level 1 data cache test and clean operations are:
• Test and clean data cache.
0b0010 As for 0b0001, and adds:
• Test, clean, and invalidate data cache.
L1 unified cache, bits[23:20]

Indicates the supported entire Level 1 cache maintenance operations, for a unified cache
implementation. Permitted values are:
0b0000 None supported. This is the required setting for ARMv7, because ARMv7 requires a
hierarchical cache implementation.
0b0001 Supported entire Level 1 cache operations are:
• Invalidate cache, including branch predictor if appropriate.
• Invalidate branch predictor, if appropriate.
• Clean cache. Uses a recursive model, using the cache dirty status bit.
• Clean and invalidate cache. Uses a recursive model, using the cache dirty status
bit.
If this field is set to a value other than 0b0000 then the L1 Harvard cache field, bits[19:16], must be
set to 0b0000.
L1 Harvard cache, bits[19:16]

Indicates the supported entire Level 1 cache maintenance operations, for a Harvard cache
0b0001 Supported entire Level 1 cache operations are:
• Invalidate instruction cache, including branch predictor if appropriate.
• Invalidate branch predictor, if appropriate.
• Invalidate data cache.
• Invalidate data cache and instruction cache, including branch predictor if
appropriate.
• Clean data cache. Uses a recursive model, using the cache dirty status bit.
• Clean and invalidate data cache. Uses a recursive model, using the cache dirty
status bit.
If this field is set to a value other than 0b0000 then the L1 unified cache field, bits[23:20], must be
set to 0b0000.
L1 unified cache set/way, bits[15:12]

Indicates the supported Level 1 cache line maintenance operations by set/way, for a unified cache
0b0001 Supported Level 1 unified cache line maintenance operations by set/way are:
• Clean cache line by set/way.
• Clean and invalidate cache line by set/way.
• Invalidate cache line by set/way.
If this field is set to a value other than 0b0000 then the L1 Harvard cache s/w field, bits[11:8], must
be set to 0b0000.
L1 Harvard cache set/way, bits[11:8]

Indicates the supported Level 1 cache line maintenance operations by set/way, for a Harvard cache
0b0001 Supported Level 1 Harvard cache line maintenance operations by set/way are:
• Clean data cache line by set/way.
• Clean and invalidate data cache line by set/way.
• Invalidate data cache line by set/way.
• Invalidate instruction cache line by set/way.
If this field is set to a value other than 0b0000 then the L1 unified cache s/w field, bits[15:12], must
be set to 0b0000.
L1 unified cache VA, bits[7:4]

Indicates the supported Level 1 cache line maintenance operations by MVA, for a unified cache
0b0001 Supported Level 1 unified cache line maintenance operations by MVA are:
• Clean cache line by MVA.
• Invalidate cache line by MVA.
• Clean and invalidate cache line by MVA.
• Invalidate branch predictor by MVA, if branch predictor is implemented.
If this field is set to a value other than 0b0000 then the L1 Harvard cache VA field, bits[3:0], must be
set to 0b0000.
L1 Harvard cache VA, bits[3:0]

Indicates the supported Level 1 cache line maintenance operations by MVA, for a Harvard cache
0b0001 Supported Level 1 Harvard cache line maintenance operations by MVA are:
• Clean data cache line by MVA.
• Invalidate data cache line by MVA.
• Clean and invalidate data cache line by MVA.
• Clean instruction cache line by MVA.
• Invalidate branch predictor by MVA, if branch predictor is implemented.
If this field is set to a value other than 0b0000 then the L1 unified cache VA field, bits[7:4], must be
set to 0b0000.
Accessing ID_MMFR1

management support.

register.


31 28 27 24 23 20 19 16 15 12 11 8 7 4 3 0
HW WFI Mem Unified Harvard L1 Harvard L1 Harvard L1 Harvard
Access flag stall barrier TLB TLB range bg fetch fg fetch
HW Access flag, bits[31:28]

Indicates support for a Hardware Access flag, as part of the VMSAv7 implementation. Permitted
values are:
0b0001 Support for VMSAv7 Access flag, updated in hardware.
On an ARMv7-R implementation this field must be 0b0000.
WFI stall, bits[27:24]

Indicates the support for Wait For Interrupt (WFI) stalling. Permitted values are:
0b0001 Support for WFI stalling.
Mem barrier, bits[23:20]

Indicates the supported CP15 memory barrier operations:
0b0001 Supported CP15 Memory barrier operations are:
• Data Synchronization Barrier (DSB). In previous versions of the ARM
architecture, DSB was named Data Write Barrier (DWB).
• Instruction Synchronization Barrier (ISB). In previous versions of the ARM
architecture, the ISB operation was called Prefetch Flush.
• Data Memory Barrier (DMB).
Note
ARM deprecates the use of these operations. ID_ISAR4.Barrier_instrs indicates the level of support
for the preferred barrier instructions.
Unified TLB, bits[19:16]

Indicates the supported TLB maintenance operations, for a unified or Harvard TLB implementation.
0b0001 Supported unified TLB maintenance operations are:
• Invalidate all entries in the TLB.
• Invalidate TLB entry by MVA.
• Invalidate TLB entries by ASID match.
0b0011 As for 0b0010 and adds:
• Invalidate instruction TLB and data TLB entries by MVA All ASID. This is a
shared unified TLB operation.
0b0100 As for 0b0011 and adds:
• Invalidate Hyp mode unified TLB entry by MVA.
• Invalidate entire Non-secure PL1&0 unified TLB.
• Invalidate entire Hyp mode unified TLB.
Harvard TLB, bits[15:12]

Indicates the supported TLB maintenance operations, for a Harvard TLB implementation. Permitted
values are:
0b0000 If the Unified TLB field is not 0b0000, then the meaning of this field is IMPLEMENTATION
DEFINED, and must be ignored by software.
0b0001 Supported Harvard TLB maintenance operations are:
• Invalidate all entries in the ITLB and the DTLB.
This is a shared unified TLB operation.
• Invalidate all ITLB entries.
• Invalidate all DTLB entries.
• Invalidate ITLB entry by MVA.
• Invalidate DTLB entry by MVA.
• Invalidate ITLB and DTLB entries by ASID match.
This is a shared unified TLB operation.
• Invalidate ITLB entries by ASID match
• Invalidate DTLB entries by ASID match.
Note
This field is defined only for legacy reasons. It is replaced by the Unified TLB field, bits19:16], and
it must be ignored by software if the Unified TLB field is not 0b0000.
L1 Harvard range, bits[11:8]

Indicates the supported Level 1 cache maintenance range operations, for a Harvard cache
0b0001 Supported Level 1 Harvard cache maintenance range operations are:
• Invalidate data cache range by VA.
• Invalidate instruction cache range by VA.
• Clean data cache range by VA.
• Clean and invalidate data cache range by VA.
L1 Harvard bg fetch, bits[7:4]

Indicates the supported Level 1 cache background fetch operations, for a Harvard cache
implementation. When supported, background fetch operations are non-blocking operations.
0b0001 Supported Level 1 Harvard cache background fetch operations are:
• Fetch instruction cache range by VA.
• Fetch data cache range by VA.
L1 Harvard fg fetch, bits[3:0]

Indicates the supported Level 1 cache foreground fetch operations, for a Harvard cache
implementation. When supported, foreground fetch operations are blocking operations. Permitted
values are:
0b0001 Supported Level 1 Harvard cache foreground fetch operations are:
• Fetch instruction cache range by VA.
• Fetch data cache range by VA.
Accessing ID_MMFR2

management support.

register.

31 28 27 24 23 20 19 16 15 12 11 8 7 4 3 0
Reserved,
UNK
Supersection support
Cached memory size†
Coherent walk
Maintenance broadcast
BP maintain
Cache maintenance set/way
Cache maintenance MVA
† Only on an implementation that includes the Large Physical Address Extension, otherwise reserved.
Supersection support, bits[31:28]

On a VMSA implementation, indicates whether Supersections are supported. Permitted values are:
0b0000 Supersections supported.
0b1111 Supersections not supported.
Note
The sense of this identification is reversed from the normal usage in the CPUID mechanism, with
the value of zero indicating that the feature is supported.
Cached memory size, bits[27:24]

Indicates the physical memory size supported by the processor caches. Permitted values are:
0b0000 4GBbyte, corresponding to a 32-bit physical address range.
0b0001 64GBbyte, corresponding to a 36-bit physical address range.
0b0010 1TBbyte, corresponding to a 40-bit physical address range.
Coherent walk, bits[23:20]

Indicates whether translation table updates require a clean to the point of unification. Permitted
values are:
0b0000 Updates to the translation tables require a clean to the point of unification to ensure
visibility by subsequent translation table walks.
0b0001 Updates to the translation tables do not require a clean to the point of unification to
ensure visibility by subsequent translation table walks.
Maintenance broadcast, bits[15:12]

Indicates whether Cache, TLB and branch predictor operations are broadcast. Permitted values are:
0b0000 Cache, TLB and branch predictor operations only affect local structures.
0b0001 Cache and branch predictor operations affect structures according to shareability and
defined behavior of instructions. TLB operations only affect local structures.
0b0010 Cache, TLB and branch predictor operations affect structures according to shareability
and defined behavior of instructions.
BP maintain, bits[11:8]
Indicates the supported branch predictor maintenance operations in an implementation with
hierarchical cache maintenance operations. Permitted values are:
0b0001 Supported branch predictor maintenance operations are:
• Invalidate all branch predictors.
• Invalidate branch predictors by MVA.
Cache maintain set/way, bits[7:4]

Indicates the supported cache maintenance operations by set/way, in an implementation with
hierarchical caches. Permitted values are:
0b0001 Supported hierarchical cache maintenance operations by set/way are:
• Invalidate data cache by set/way.
• Clean data cache by set/way.
• Clean and invalidate data cache by set/way.
In a unified cache implementation, the data cache operations apply to the unified caches.
Cache maintain MVA, bits[3:0]

Indicates the supported cache maintenance operations by MVA, in an implementation with
hierarchical caches. Permitted values are:
0b0001 Supported hierarchical cache maintenance operations by MVA are:
• Invalidate data cache by MVA.
• Clean data cache by MVA.
• Clean and invalidate data cache by MVA.
• Invalidate instruction cache by MVA.
• Invalidate all instruction cache entries.
In a unified cache implementation, the data cache operations apply to the unified caches, and the
instruction cache operations are not implemented.
Accessing ID_MMFR3
<opc2> set to7. For example:
B4.1.93 ID_PFR0, Processor Feature Register 0, VMSA

The ID_PFR0 characteristics are:
Purpose ID_PFR0 gives information about the programmers’ model and top-level information about
the instruction sets supported by the processor.

Must be interpreted with ID_PFR1.
register.

The ID_PFR0 bit assignments are:

31 16 15 12 11 8 7 4 3 0
Reserved, UNK State3 State2 State1 State0
State3, bits[15:12]
ThumbEE instruction set support. Permitted values are:
0b0001 ThumbEE instruction set implemented.
The value of 0b0001 is only permitted when State1 == 0b0011.
State2, bits[11:8]
Jazelle extension support. Permitted values are:
0b0001 Jazelle extension implemented, without clearing of JOSCR.CV on exception entry.
0b0010 Jazelle extension implemented, with clearing of JOSCR.CV on exception entry.
A trivial implementation of the Jazelle extension is indicated by the value 0b0001.
State1, bits[7:4]
Thumb instruction set support. Permitted values are:
0b0000 Thumb instruction set not implemented.
0b0001 Thumb encodings before the introduction of Thumb-2 technology implemented:
• All instructions are 16-bit.
• A BL or BLX is a pair of 16-bit instructions.
• 32-bit instructions other than BL and BLX cannot be encoded.
0b0010 Reserved.
0b0011 Thumb encodings after the introduction of Thumb-2 technology implemented, for all
16-bit and 32-bit Thumb basic instructions.
State0, bits[3:0]
ARM instruction set support. Permitted values are:
0b0000 ARM instruction set not implemented.
0b0001 ARM instruction set implemented.
Accessing ID_PFR0
To access ID_PFR0, software reads the CP15 registers with <opc1> set to 0, <CRn> set to c0, <CRm> set to c1, and <opc2>
MRC p15, 0, <Rt>, c0, c1, 0 ; Read ID_PFR0 into Rt
B4.1.94 ID_PFR1, Processor Feature Register 1, VMSA

The ID_PFR1 characteristics are:
Purpose ID_PFR1 gives information about the programmers’ model and Security Extensions
support.

Must be interpreted with ID_PFR0.
register.

The ID_PFR1 bit assignments are:

31 20 19 16 15 12 11 8 7 4 3 0
Reserved, UNK
Generic Timer
Virtualization Extensions
M profile programmers’ model
Security Extensions
Programmers’ model
Generic Timer Extension, bits[19:16]

0b0001 Generic Timer Extension implemented.
Virtualization Extensions, bits[15:12]

0b0001 Virtualization Extensions implemented.
Note
A value of 0b0001 implies implementation of the HVC, ERET, MRS (Banked register), and MSR (Banked
register) instructions. The ID_ISARs do not identify whether these instructions are implemented.
M profile programmers’ model, bits[11:8]

0b0010 Support for two-stack programmers’ model.
Note
In this field, the permitted values are not continuous, and the value of 0b0001 is reserved.
Security Extensions, bits[7:4]

0b0001 Security Extensions implemented.
This includes support for Monitor mode and the SMC instruction.
0b0010 As for 0b0001, and adds the ability to set the NSACR.RFR bit.
Programmers’ model, bits[3:0]

Support for the standard programmers’ model for ARMv4 and later. Model must support User, FIQ,
IRQ, Supervisor, Abort, Undefined and System modes. Permitted values are:
0b0001 Supported.
Accessing ID_PFR1
To access ID_PFR1, software reads the CP15 registers with <opc1> set to 0, <CRn> set to c0, <CRm> set to c1, and <opc2>
MRC p15, 0, <Rt>, c0, c1, 1 ; Read ID_PFR1 into Rt
B4.1.95 IFAR, Instruction Fault Address Register, VMSA

The IFAR characteristics are:
Purpose The IFAR holds the VA of the faulting access that caused a synchronous Prefetch Abort
exception.
Configurations If the implementation includes the Security Extensions, this register is Banked.
The IFAR bit assignments are:

31 0
VA of faulting address of synchronous Prefetch Abort exception
For information about using the IFAR see Exception reporting in a VMSA implementation on page B3-1406.
A debugger can write to the IFAR to restore its value.
Accessing the IFAR

To access the IFAR, software reads or writes the CP15 registers with <opc1> set to 0, <CRn> set to c6, <CRm> set to c0,
MRC p15, 0, <Rt>, c6, c0, 2 ; Read IFAR into Rt

MCR p15, 0, <Rt>, c6, c0, 2 ; Write Rt to IFAR
B4.1.96 IFSR, Instruction Fault Status Register, VMSA

The IFSR characteristics are:
Purpose The IFSR holds status information about the last instruction fault.
Configurations The Large Physical Address Extension adds an alternative format for the register. If an
implementation includes the Large Physical Address Extension then the current translation
table format determines which format of the register is used.
For information about using the IFSR see Exception reporting in a VMSA implementation on page B3-1406.
The following sections describe the alternative IFSR formats:

• IFSR format when using the Short-descriptor translation table format.
• IFSR format when using the Long-descriptor translation table format on page B4-1632.
IFSR format when using the Short-descriptor translation table format

In a VMSAv7 implementation that does not include the Large Physical Address Extension, or in an implementation
that includes the Large Physical Address Extension when address translation is using the Short-descriptor
translation table format, the IFSR bit assignments are:
31 13 12 11 10 9 8 4 3 0
Reserved,
Reserved, UNK/SBZP (0) 0* FS[3:0]
UNK/SBZP
ExT
FS[4]
LPAE†
† Only on an implementation that includes the Large Physical Address Extension.
aborts.
UNK/SBZP.
FS, bits[10, 3:0]

Fault status bits. For the valid encodings of these bits when using the Short-descriptor translation
LPAE, bit[9], if the implementation includes the Large Physical Address Extension
On taking an exception, this bit is set to 0 to indicate use of the Short-descriptor translation table
format.
Bits[9], if the implementation does not include the Large Physical Address Extension
Reserved, UNK/SBZP.
IFSR format when using the Long-descriptor translation table format

In a VMSAv7 implementation that includes the Large Physical Address Extension, when address translation is using
the Long-descriptor translation table format, the IFSR bit assignments are:
31 13 12 11 10 9 8 6 5 0
Reserved, UNK/SBZP (0) (0) 1* (0) (0) (0) STATUS
ExT
LPAE
aborts.
UNK/SBZP.
LPAE, bit[9] On taking an exception, this bit is set to 1 to indicate use of the Long-descriptor translation table
format.
STATUS, bits[5:0]
Fault status bits. For the valid encodings of these bits when using the Long-descriptor translation
Accessing the IFSR

To access the IFSR, software reads or writes the CP15 registers with <opc1> set to 0, <CRn> set to c5, <CRm> set to c0,
MRC p15, 0, <Rt>, c5, c0, 1 ; Read IFSR into Rt

MCR p15, 0, <Rt>, c5, c0, 1 ; Write Rt to IFSR
B4.1.97 ISR, Interrupt Status Register, Security Extensions

The ISR characteristics are:
Purpose The ISR shows whether an IRQ, FIQ, or external abort is pending. In an implementation
that includes the Virtualization Extensions, an indicated pending abort or interrupt might be
a physical abort or a virtual abort.
This register is part of the Security Extensions registers functional group.
Configurations Only present in an implementation that includes the Security Extensions.

A Common register, meaning it is available in the Secure and Non-secure states.
Attributes A 32-bit RO register with an UNKNOWN reset value. See also Reset behavior of CP14 and
Table B3-54 on page B3-1495 shows the encoding of all of the Security Extensions
registers.
The ISR bit assignments are:

31 9 8 7 6 5 0
Reserved, UNK A I F Reserved, UNK
A, bit[8] External abort pending bit:

0 No pending external abort.
1 An external abort is pending.
I, bit[7] IRQ pending bit. Indicates whether an IRQ interrupt is pending:

0 No pending IRQ.
1 An IRQ interrupt is pending.
F, bit[6] FIQ pending bit. Indicates whether an FIQ interrupt is pending:

0 No pending FIQ.
1 An FIQ interrupt is pending.
On an implementation that includes the Virtualization Extensions, and is in a Non-secure PL1 mode, the
HCR.AMO, HCR.IMO, and HCR.FMO mask override bits determine whether the corresponding ISR bit shows the
status of the physical or the virtual abort or interrupt. When an HCR mask override bit:
• Is set to 0, the ISR bit shows the status of the corresponding physical abort or interrupt.
• Is set to 1, the ISR bit shows the status of the corresponding virtual abort or interrupt.
Note
Non-secure software executing at PL1 cannot access the HCR. When an ISR bit is set to 1 this software cannot
determine whether the reported abort or interrupt is physical or virtual.
Otherwise, the ISR indicates the status of physical external aborts, IRQs, and FIQs.
When the ISR is indicating the status of physical external aborts, IRQs, and FIQs, then:
• The ISR.F and ISR.I bits directly reflect the state of the FIQ and IRQ inputs.
• The signalling of physical external aborts to the processor can be edge triggered or level triggered. If this
signalling is edge triggered, the ISR.A bit is set to 1 when a physical asynchronous abort is recognized, and
automatically cleared to 0 when the abort is taken.
The bit positions of the A, I and F bits in the ISR match the A, I and F bits in the CPSR. This means software can
use the same masks to extract the bits from the register value.
Accessing the ISR

To access the ISR, software reads the CP15 registers with <opc1> set to 0, <CRn> set to c12, <CRm> set to c1, and <opc2>
MRC p15, 0, <Rt>, c12, c1, 0 ; Read ISR into Rt
B4.1.98 ITLBIALL, Instruction TLB Invalidate All, VMSA only

B4.1.99 ITLBIASID, Instruction TLB Invalidate by ASID, VMSA only

B4.1.100 ITLBIMVA, Instruction TLB Invalidate by MVA, VMSA only

B4.1.101 JIDR, Jazelle ID Register, VMSA

The JIDR characteristics are:
Purpose Identifies the Jazelle architecture and subarchitecture versions.

This register is a Jazelle register.
Usage constraints Read access rights depend on the execution privilege and the value of the JOSCR.CD bit.
Write accesses are UNPREDICTABLE at PL1 or higher, and UNDEFINED at PL0. See Access to
Jazelle registers on page A2-99.
Always implemented, but can be implemented as RAZ on a processor with a trivial
Note
An implementation that includes the Virtualization Extensions must implement a trivial
In an implementation that includes the Security Extensions, JIDR is a Common register.

Table A2-17 on page A2-99 shows the encodings of all the Jazelle registers.
The JIDR bit assignments are:

31 28 27 20 19 12 11 0
Architecture Implementer Subarchitecture SUBARCHITECTURE DEFINED
Architecture, bits[31:28]
Architecture code. This uses the same Architecture code that appears in the MIDR.
On a trivial implementation of the Jazelle extension this field must be RAZ.
Implementer code of the designer of the subarchitecture. This uses the same Implementer code that
appears in the MIDR.
Subarchitecture, bits[19:12]
Contain the subarchitecture code. The following subarchitecture code is defined:
0x00 Jazelle v1 subarchitecture, or trivial implementation of Jazelle extension if the
Implementer field is RAZ.
Bits[11:0] Can contain additional SUBARCHITECTURE DEFINED information.
Accessing the JIDR

To access the JIDR, software reads the CP14 registers with <opc1> set to 7, <CRn> set to c0, <CRm> set to c0, and <opc2>
MRC p14, 7, <Rt>, c0, c0, 0 ; Read JIDR into Rt
B4.1.102 JMCR, Jazelle Main Configuration Register, VMSA

The JMCR characteristics are:
Purpose Provides control of the Jazelle extension.

Usage constraints Access rights depend on the execution privilege and the value of the JOSCR.CD bit, see
Access to Jazelle registers on page A2-99.
Always implemented. A processor with a trivial implementation of the Jazelle extension
must implement JMCR as RAZ/WI.
In an implementation that includes the Security Extensions, JMCR is a Common register.
Attributes A 32-bit RW register. See the field descriptions for details about the reset value.
The JMCR bit assignments are:

31 1 0
SUBARCHITECTURE DEFINED JE
Bits[31:1] SUBARCHITECTURE DEFINED information. This means the reset value of this field is also
SUBARCHITECTURE DEFINED.
JE, bit[0] Jazelle Enable bit:

0 Jazelle extension disabled. The BXJ instruction does not cause Jazelle state execution.
BXJ behaves exactly as a BX instruction, see Jazelle state entry instruction, BXJ on
page A2-97.
1 Jazelle extension enabled.
The reset value of this bit is 0.
Accessing the JMCR

To access the JMCR, read or write the CP14 registers with <opc1> set to 7, <CRn> set to c2, <CRm> set to c0, and <opc2>
MRC p14, 7, <Rt>, c2, c0, 0 ; Read JMCR into Rt

MCR p14, 7, <Rt>, c2, c0, 0 ; Write Rt to JMCR
B4.1.103 JOSCR, Jazelle OS Control Register, VMSA

The JOSCR characteristics are:
Purpose Provides operating system control of the use of the Jazelle extension by processes and
threads.
Usage constraints Accessible only from PL1 or higher.

Normally used in conjunction with the JMCR.JE bit.
Always implemented. A processor with a trivial implementation of the Jazelle extension
must implement JOSCR either:
• As RAZ/WI.
• So that it can be read or written, but the processor ignores the effect of any read or
write.
In an implementation that includes the Security Extensions, JOSCR is a Common register.
Attributes A 32-bit RW register that resets to zero.

The JOSCR bit assignments are:

31 2 1 0
Reserved, UNK/SBZP
CV
CD
CV, bit[1] Configuration Valid bit. This bit is used by an operating system to signal to the EJVM that it must
rewrite its configuration to the configuration registers. The possible values are:
0 Configuration not valid. The EJVM must rewrite its configuration to the configuration
registers before it executes another bytecode instruction.
1 Configuration valid. The EJVM does not need to update the configuration registers.
When the JMCR.JE bit is set to 1, the CV bit also controls entry to Jazelle state, see Controlling
entry to Jazelle state on page B1-1242.
CD, bit[0] Configuration Disabled bit. This bit is used by an operating system to disable User mode access to
the JIDR and configuration registers:
0 Configuration enabled. Access to the Jazelle registers, including User mode accesses,
operate normally. For more information, see the register descriptions in Application
level configuration and control of the Jazelle extension on page A2-98.
1 Configuration disabled in User mode. User mode access to the Jazelle registers are
UNDEFINED, and all User mode accesses to the Jazelle registers cause an Undefined
For more information about the use of this bit see Monitoring and controlling User mode access to
the Jazelle extension on page B1-1243.
The JOSCR provides a control mechanism that is independent of the subarchitecture of the Jazelle extension. An
operating system can use this mechanism to control access to the Jazelle extension, see Jazelle state configuration
and control on page B1-1242.
Accessing the JOSCR

To access the JOSCR, read or write the CP14 registers with <opc1> set to 7, <CRn> set to c1, <CRm> set to c0, and <opc2>
MRC p14, 7, <Rt>, c1, c0, 0 ; Read JOSCR into Rt

MCR p14, 7, <Rt>, c1, c0, 0 ; Write Rt to JOSCR
B4.1.104 MAIR0 and MAIR1, Memory Attribute Indirection Registers 0 and 1, VMSA
The MAIR0 and MAIR1 characteristics are:
Purpose MAIR0 and MAIR1 provide the memory attribute encodings corresponding to the possible
AttrIndx values in a Long-descriptor format translation table entry for stage 1 translations.
For more information about the AttrIndx field see Long-descriptor format memory region
These registers are part of the Virtual memory control registers functional group.

Only accessible when using the Long-descriptor translation table format. When using the
Short-descriptor format see PRRR, Primary Region Remap Register, VMSA on
page B4-1693 and NMRR, Normal Memory Remap Register, VMSA on page B4-1653.
AttrIndx[2] selects the appropriate MAIR:
• Setting AttrIndx[2] to 0 selects MAIR0.
• Setting AttrIndx[2] to 1 selects MAIR1.
In the implementation includes the Security Extensions:
• The Secure copies of the registers give the values for memory accesses from Secure
state.
• The Non-secure copies of the registers give the values for memory accesses from
Non-secure modes other than Hyp mode.
Configurations MAIR0 and MAIR1 are implemented only as part of the Large Physical Address Extension.
In an implementation that includes the Security Extensions they:
• Are Banked.
• Have write access to the Secure copy of the register disabled when the
The MAIR0 and MAIR1 bit assignments are:
31 24 23 16 15 8 7 0
MAIR0 Attr3 Attr2 Attr1 Attr0
MAIR1 Attr7 Attr6 Attr5 Attr4
Attrm[7:0], for values of m from 0 to 7

The memory attribute encoding for an AttrIndx[2:0] entry in a Long descriptor format translation
table entry, where:
• AttrIndx[2] defines which MAIR to access.
• AttrIndx[2:0] gives the value of m in Attrm.
Table B4-7 on page B4-1640 shows the encoding of Attrn[7:4].
Table B4-7 MAIRn.Attrm[7:4] encoding
Attrm[7:4] Meaning
0000 Strongly-ordered or Device memory, see encoding of Attrm[3:0].
00RW, RW not 00 It is IMPLEMENTATION DEFINED whether the encoding is:

• UNPREDICTABLE
• Normal memory, Outer Write-Through b Transient.
0100 Normal memory, Outer a Non-cacheable.
01RW, RW not 00 It is IMPLEMENTATION DEFINED whether the encoding is:

• UNPREDICTABLE
• Normal memory, Outer Write-Back b Transient.
10RW Normal memory, Outer a Write-Through Cacheable b, Non-transient c.
11RW Normal memory, Outer a Write-Back Cacheable b, Non-transient c .
a. See encoding of Attrm[3:0], shown in Table B4-8, for Inner cacheability policies.
b. R defines the Outer Read-Allocate policy, and W defined the Outer Write-Allocate policy, see
Table B4-9 on page B4-1641.
c. Non-transient if the implementation includes support for the Transient attribute.
The encoding of Attrn[3:0] depends on the value of Attrn[7:4], as Table B4-8 shows.
Table B4-8 MAIRn.Attrm[3:0] encoding
Attrm[3:0] Meaning when Attrm[7:4] is 0b0000 Meaning when Attrm[7:4] is not 0b0000
0000 Strongly-ordered memory UNPREDICTABLE.
00RW, UNPREDICTABLE It is IMPLEMENTATION DEFINED whether the encoding is:

RW not 00 • UNPREDICTABLE
• Normal memory, Inner Write-Through a Transient.
0100 Device memory Normal memory, Inner Non-cacheable.
01RW, UNPREDICTABLE It is IMPLEMENTATION DEFINED whether the encoding is:

RW not 00 • UNPREDICTABLE
• Normal memory, Inner Write-Back a Transient.
10RW UNPREDICTABLE Normal memory, Inner Write-Through Cacheable a, Non-transient b.
11RW UNPREDICTABLE Normal memory, Inner Write-Back Cacheable a, Non-transient b.
a. R defines the Inner Read-Allocate policy, and W defines the Inner Write-Allocate policy, see Table B4-9 on page B4-1641.
b. Non-transient if the implementation includes support for the Transient attribute.
Table B4-9 shows the encoding of the R and W bits that are used, in some Attrm encodings in
Table B4-7 on page B4-1640 and Table B4-8 on page B4-1640, to define the read-allocate and
write-allocate policies:
Table B4-9 Encoding of R and W bits in some Attrm fields
R or W Meaning
0 Do not allocate
1 Allocate
The IMPLEMENTATION DEFINED meanings of the Attrm[7:4] Attrm[3:0] 0b0xyy encodings must be
consistent. This means that the IMPLEMENTATION DEFINED choice is that either:
• All of these encodings are UNPREDICTABLE.
• This set of encodings provides the Normal memory Write-Through transient and Write-Back
transient encodings.
See Transient cacheability attribute, Large Physical Address Extension on page A3-132 for more
information about the Transient attribute.
Accessing MAIR0 or MAIR1

To access MAIR0 or MAIR1, software reads or writes the CP15 registers with <opc1> set to 0, <CRn> set to c10, <CRm>
set to c2, and <opc2> set to 0 for MAIR0, or to 1 for MAIR1. For example:
MRC p15, 0, <Rt>, c10, c2, 0 ; Read MAIR0 into Rt

MCR p15, 0, <Rt>, c10, c2, 1 ; Write Rt to MAIR1
B4.1.105 MIDR, Main ID Register, VMSA

The MIDR characteristics are:
Purpose The MIDR provides identification information for the processor, including an implementer
code for the device and a device ID number.
Configurations If the implementation includes the Security Extensions, this register is Common.
Some fields of the MIDR are IMPLEMENTATION DEFINED. For details of the values of these
fields for a particular ARMv7 implementation, and any implementation-specific
significance of these values, see the product documentation.
The MIDR bit assignments are:
31 24 23 20 19 16 15 4 3 0
Implementer Variant Architecture Primary part number Revision
The Implementer code. Table B4-10 shows the permitted values for this field:
Table B4-10 Implementer codes
Bits[31:24] ASCII character Implementer
0x41 A ARM Limited
0x44 D Digital Equipment Corporation
0x4D M Motorola, Freescale Semiconductor Inc.
0x51 Q Qualcomm Inc.
0x56 V Marvell Semiconductor Inc.
0x69 i Intel Corporation
All other values are reserved by ARM and must not be used.
Variant, bits[23:20]
An IMPLEMENTATION DEFINED variant number. Typically, this field distinguishes between different
product variants, or major revisions of a product.
Architecture, bits[19:16]
Table B4-11 shows the permitted values for this field:
Table B4-11 Architecture codes
Bits[19:16] Architecture
0x1 ARMv4
0x2 ARMv4T
0x3 ARMv5 (obsolete)
0x4 ARMv5T
0x5 ARMv5TE
0x6 ARMv5TEJ
0x7 ARMv6
0xF Defined by CPUID scheme
All other values are reserved by ARM and must not be used.
Primary part number, bits[15:4]

An IMPLEMENTATION DEFINED primary part number for the device.
Note
• On processors implemented by ARM, if the top four bits of the primary part number are 0x0
or 0x7, the variant and architecture are encoded differently, see the description of the MIDR
in Appendix D15 ARMv4 and ARMv5 Differences.
• Processors implemented by ARM have an Implementer code of 0x41.
Revision, bits[3:0]
An IMPLEMENTATION DEFINED revision number for the device.
ARMv7 requires all implementations to use the CPUID scheme, described in Chapter B7 The CPUID Identification
Scheme, and an implementation is described by the MIDR with the CPUID registers.
Note
For an ARMv7 implementation by ARM, the MIDR is interpreted as:
Bits[31:24] Implementer code, must be 0x41.
Bits[23:20] Major revision number, rX.
Bits[19:16] Architecture code, must be 0xF.
Bits[15:4] ARM part number.
Bits[3:0] Minor revision number, pY.
Accessing the MIDR

To access the MIDR, software reads the CP15 registers with <opc1> set to 0, <CRn> set to c0, <CRm> set to c0, and
MRC p15, 0, <Rt>, c0, c0, 0 ; Read MIDR into Rt
B4.1.106 MPIDR, Multiprocessor Affinity Register, VMSA

The MPIDR characteristics are:
Purpose In a multiprocessor system, the MPIDR provides an additional processor identification

mechanism for scheduling purposes, and indicates whether the implementation includes the
Multiprocessing Extensions.

In a uniprocessor system ARM recommends that each Affn field of this register returns a
value of 0.
If the implementation includes the Security Extensions, the register is Common.
In an implementation that does not include the Multiprocessing Extensions, the MPIDR bit assignments are:
31 24 23 16 15 8 7 0
Reserved, RAZ Aff2 Aff1 Aff0
In an implementation that includes the Multiprocessing Extensions, the MPIDR bit assignments are:
31 30 29 25 24 23 16 15 8 7 0
Reserved,
1 U Aff2 Aff1 Aff0
UNK
MT
Note
In the MPIDR bit definitions, a processor in the system can be a physical processor or a virtual machine.
Bits[31:24], ARMv7 without Multiprocessing Extensions

Reserved, RAZ.
Bits[31], in an implementation that includes the Multiprocessing Extensions

RAO. Indicates that the implementation uses the Multiprocessing Extensions register format.
U, bit[30], in an implementation that includes the Multiprocessing Extensions

Indicates a Uniprocessor system, as distinct from processor 0 in a multiprocessor system. The
0 Processor is part of a multiprocessor system.
1 Processor is part of a uniprocessor system.
Bits[29:25], in an implementation that includes the Multiprocessing Extensions

Reserved, UNK.
MT, bit[24], in an implementation that includes the Multiprocessing Extensions

Indicates whether the lowest level of affinity consists of logical processors that are implemented
using a multi-threading type approach. The possible values of this bit are:
0 Performance of processors at the lowest affinity level is largely independent.
1 Performance of processors at the lowest affinity level is very interdependent.

For more information about the meaning of this bit see Multi-threading approach to lowest affinity
levels, Multiprocessing Extensions.
Aff2, bits[23:16]
Affinity level 2. The least significant affinity level field, for this processor in the system.
Aff1, bits[15:8]
Affinity level 1. The intermediate affinity level field, for this processor in the system.
Aff0, bits[7:0]
Affinity level 0. The most significant affinity level field, for this processor in the system.
See Recommended use of the MPIDR for clarification of the meaning of most significant and least significant
affinity levels.
The assigned value of the MPIDR.{Aff0, Aff1, Aff2} set of fields must be unique for each processor in the system
as a whole.
When matching against an affinity level field, scheduler software checks for a value equal to or greater than a
required value.
Recommended use of the MPIDR includes a description of an example multiprocessor system and the affinity level
field values it might use.
The interpretation of these fields is IMPLEMENTATION DEFINED, and must be documented as part of the
documentation of the multiprocessor system. ARM recommends that this register might be used as described in
Recommended use of the MPIDR.
The software mechanism to discover the total number of affinity numbers used at each level is IMPLEMENTATION
DEFINED, and is part of the general system identification task.
Multi-threading approach to lowest affinity levels, Multiprocessing Extensions

In an implementation that includes the Multiprocessing Extensions, if the MPIDR.MT bit is set to 1, this indicates
that the processors at affinity level 0 are logical processors, implemented using a multi-threading type approach. In
such an approach, there can be a significant performance impact if a new thread is assigned the processor with:
• A different affinity level 0 value to some other thread, referred to as the original thread.
• A pair of values for affinity levels 1 and 2 that are the same as the pair of values of the original thread.
In this situation, the performance of the original thread might be significantly reduced.
Note
In this description, thread always refers to a thread or a process.
Recommended use of the MPIDR

In a multiprocessor system the register might provide two important functions:
• Identifying special functionality of a particular processor in the system. In general, the actual meaning of the
affinity level fields is not important. In a small number of situations, an affinity level field value might have
a special IMPLEMENTATION DEFINED significance. Possible examples include booting from reset and
powerdown events.
• Providing affinity information for the scheduling software, to help the scheduler run an individual thread or
process on either:
— The same processor, or as similar a processor as possible, as the processor it was running on
previously.
— A processor on which a related thread or process was run.
MPIDR provides a mechanism with up to three levels of affinity information, but the meaning of those levels of
affinity is entirely IMPLEMENTATION DEFINED. The levels of affinity provided can have different meanings.
Table B4-12 shows two possible implementations:
Table B4-12 Possible implementations of the affinity levels
Affinity level Example system 1 Example system 2
0 Virtual CPUs in a multi-threaded processor Processors in an SMP cluster
1 Processors in an Symmetric Multi Processor (SMP) cluster Clusters with a system
2 Clusters in a system No meaning, fixed as 0
The scheduler maintains affinity level information for all threads and processes. When it has to reschedule a thread
or process, the scheduler:
1. Looks for an available processor that matches at all three affinity levels.
2. If step 1 fails, the scheduler might look for a processor that matches at levels 1 and 2 only.
3. If the scheduler still cannot find an available processor it might look for a match at level 2 only.
A multiprocessor system corresponding to Example system 1 in Table B4-12 might implement affinity values as
shown in Table B4-13:
Table B4-13 Example of possible affinity values at different affinity levels
Aff2, Cluster level, values Aff1, Processor level, values Aff0, Virtual CPU level, values
0 0 0, 1
0 1 0, 1
0 2 0, 1
0 3 0, 1
1 0 0, 1
1 1 0, 1
1 2 0, 1
1 3 0, 1
Accessing the MPIDR

To access MPIDR, software reads the CP15 registers with <opc1> set to 0, <CRn> set to c0, <CRm> set to c0, and <opc2>
MRC p15, 0, <Rt>, c0, c0, 5 ; Read MPIDR into Rt
B4.1.107 MVBAR, Monitor Vector Base Address Register, Security Extensions

The MVBAR characteristics are:
Purpose The MVBAR holds the exception base address for all exceptions that are taken to Monitor
mode, see Exception vectors and the exception base address on page B1-1164.
Usage constraints Only accessible from Secure PL1 modes.

Secure software must program the MVBAR with the required initial value as part of the
processor boot sequence.
Configurations Only present in an implementation that includes the Security Extensions.

A Restricted access register, meaning it exists only in the Secure state.
registers.
The MVBAR bit assignments are:

31 5 4 0
Reserved,
Monitor_Vector_Base_Address
UNK/SBZP
Monitor_Vector_Base_Address, bits[31:5]
Bits[31:5] of the base address of the exception vectors for exceptions that are taken to Monitor
mode. Bits[4:0] of an exception vector is the exception offset, see Table B1-3 on page B1-1166.
For details of how the MVBAR determines the exception addresses see Exception vectors and the exception base
address on page B1-1164.
Accessing the MVBAR

To access the MVBAR, software reads or writes the CP15 registers with <opc1> set to 0, <CRn> set to c12, <CRm> set
MRC p15, 0, <Rt>, c12, c0, 1 ; Read MVBAR into Rt

MCR p15, 0, <Rt>, c12, c0, 1 ; Write Rt to MVBAR
B4.1.108 MVFR0, Media and VFP Feature Register 0, VMSA

The MVFR0 characteristics are:
Purpose Describes the features provided by the Advanced SIMD and Floating-point Extensions.
Usage constraints Only accessible from PL1 or higher. See Accessing the Advanced SIMD and Floating-point
Extension system registers on page B1-1236 for more information.
Must be interpreted with MVFR1. This register complements the information provided by
the CPUID scheme described in Chapter B7 The CPUID Identification Scheme.

In an implementation that includes the Security Extensions, MVFR0 is a Configurable
set to 1.

Floating-point Extension system registers
The MVFR0 bit assignments are:

31 28 27 24 23 20 19 16 15 12 11 8 7 4 3 0
VFP VFP
Short Square Double- Single- A_SIMD
rounding Divide exception
vectors root precision precision registers
modes trapping
VFP rounding modes, bits[31:28]

Indicates the rounding modes supported by the Floating-point Extension hardware. Permitted values
are:
0b0000 Only Round to Nearest mode supported, except that Round towards Zero mode is
supported for VCVT instructions that always use that rounding mode regardless of the
FPSCR setting.
0b0001 All rounding modes supported.
Short vectors, bits[27:24]

Indicates the hardware support for VFP short vectors. Permitted values are:
0b0001 Short vector operation supported.
Square root, bits[23:20]

Indicates the hardware support for the Floating-point Extension square root operations. Permitted
values are:
0b0000 Not supported in hardware.
0b0001 Supported.
Note
• The VSQRT.F32 instruction also requires the single-precision Floating-point attribute,
bits[7:4].
• The VSQRT.F64 instruction also requires the double-precision Floating-point attribute,

bits[11:8].
Divide, bits[19:16]
Indicates the hardware support for Floating-point Extension divide operations. Permitted values are:
0b0001 Supported.
Note
• The VDIV.F32 instruction also requires the single-precision Floating-point attribute, bits[7:4].
• The VDIV.F64 instruction also requires the double-precision Floating-point attribute,
bits[11:8].
VFP exception trapping, bits[15:12]

Indicates whether the Floating-point Extension hardware implementation supports exception
trapping. Permitted values are:
0b0000 Not supported. This is the value for VFPv3 and VFPv4.
0b0001 Supported by the hardware. This is the value for VFPv2, and for VFPv3U and VFPv4U.
When exception trapping is supported, support code is required to handle the trapped
exceptions.
Note
This value does not indicate that trapped exception handling is available. Because
trapped exception handling requires support code, only the support code can provide
this information.
Double-precision, bits[11:8]
Indicates the hardware support for the Floating-point Extension double-precision operations.
0b0001 Supported, VFPv2.
0b0010 Supported, VFPv3 or VFPv4.
VFPv3 adds an instruction to load a double-precision floating-point constant, and
conversions between double-precision and fixed-point values.
A value of 0b0001 or 0b0010 indicates support for all the floating-point double-precision instructions
in the supported version of the Floating-point Extension, except that, in addition to this field being
nonzero:
• VSQRT.F64 is available only if the Square root field is 0b0001.
• VDIV.F64 is available only if the Divide field is 0b0001.
• Conversion between double-precision and single-precision is available only if the
single-precision field is nonzero.
Single-precision, bits[7:4]
Indicates the hardware support for the Floating-point Extension single-precision operations.
0b0001 Supported, VFPv2.
0b0010 Supported, VFPv3 or VFPv4.
VFPv3 adds an instruction to load a single-precision floating-point constant, and
conversions between single-precision and fixed-point values.
A value of 0b0001 or 0b0010 indicates support for all floating-point single-precision instructions in
the supported version of the Floating-point Extension, except that, in addition to this field being
nonzero:
• VSQRT.F32 is only available if the Square root field is 0b0001.
• VDIV.F32 is only available if the Divide field is 0b0001.
• Conversion between double-precision and single-precision is only available if the
double-precision field is nonzero.
A_SIMD registers, bits[3:0]

Indicates support for the Advanced SIMD register bank. Permitted values are:
0b0001 Supported, 16 × 64-bit registers.
0b0010 Supported, 32 × 64-bit registers.
If this field is nonzero:
• All Floating-point Extension LDC, STC, MCR, and MRC instructions are supported.
• If the CPUID register shows that the MCRR and MRRC instructions are supported then the
corresponding Floating-point Extension instructions are supported.
Accessing MVFR0
Software accesses MVFR0 using the VMRS instruction, see VMRS on page B9-2000. For example:
VMRS <Rt>, MVFR0 ; Read MVFR0 into Rt
B4.1.109 MVFR1, Media and VFP Feature Register 1, VMSA

The MVFR1 characteristics are:
Purpose Describes the features provided by the Advanced SIMD and Floating-point Extensions.
Usage constraints Only accessible from PL1 or higher. See Accessing the Advanced SIMD and Floating-point
Extension system registers on page B1-1236 for more information.
Must be interpreted with MVFR0. These registers complement the information provided by
the CPUID scheme described in Chapter B7 The CPUID Identification Scheme.

In an implementation that includes the Security Extensions, MVFR1 is a Configurable
set to 1.

Floating-point Extension system registers
The MVFR1 bit assignments are:

31 28 27 24 23 20 19 16 15 12 11 8 7 4 3 0
A_SIMD VFP A_SIMD A_SIMD A_SIMD A_SIMD D_NaN FtZ
FMAC HPFP HPFP SPFP integer load/store mode mode
A_SIMD FMAC, bits[31:28]

Indicates whether any implemented Floating-point or Advanced SIMD Extension implements the
fused multiply accumulate instructions. Permitted values are:
0b0001 Implemented.
If an implementation includes both the Floating-point Extension and the Advanced SIMD
Extension, both extensions must provide the same level of support for these instructions.
VFP HPFP, bits[27:24]

Indicates whether the Floating-point Extension implements half-precision floating-point conversion
instructions. Permitted values are:
0b0001 Implemented.
A_SIMD HPFP, bits[23:20]

Indicates whether the Advanced SIMD Extension implements half-precision floating-point
conversion instructions. Permitted values are:
0b0001 Implemented. This value is permitted only if the A_SIMD SPFP field is 0b0001.
A_SIMD SPFP, bits[19:16]

Indicates whether the Advanced SIMD Extension implements single-precision floating-point
instructions. Permitted values are:
0b0001 Implemented. This value is permitted only if the A_SIMD integer field is 0b0001.
A_SIMD integer, bits[15:12]

Indicates whether the Advanced SIMD Extension implements integer instructions. Permitted values
are:
0b0001 Implemented.
A_SIMD load/store, bits[11:8]

Indicates whether the Advanced SIMD Extension implements load/store instructions. Permitted
values are:
0b0001 Implemented.
D_NaN mode, bits[7:4]

Indicates whether the Floating-point Extension hardware implementation supports only the Default
NaN mode. Permitted values are:
0b0000 Hardware supports only the Default NaN mode. If a VFP subarchitecture is
implemented its support code might include support for propagation of NaN values.
0b0001 Hardware supports propagation of NaN values.
FtZ mode, bits[3:0]

Indicates whether the Floating-point Extension hardware implementation supports only the
Flush-to-Zero mode of operation. Permitted values are:
0b0000 Hardware supports only the Flush-to-Zero mode of operation. If a VFP subarchitecture
is implemented its support code might include support for full denormalized number
arithmetic.
0b0001 Hardware supports full denormalized number arithmetic.
Accessing MVFR1
Software accesses MVFR1 using the VMRS instruction, see VMRS on page B9-2000. For example:
VMRS <Rt>, MVFR1 ; Read MVFR1 into Rt
B4.1.110 NMRR, Normal Memory Remap Register, VMSA

The NMRR characteristics are:
Purpose Under the conditions described in Architectural status of PRRR and NMRR on
page B4-1695, NMRR provides additional mapping controls for memory regions that are
mapped as Normal memory by their entry in the PRRR. For more information see
Short-descriptor format memory region attributes, with TEX remap on page B3-1364.

Used in conjunction with the PRRR.
In a processor that implements the Large Physical Address Extension, not accessible when
using the Long-descriptor translation table format. See, instead, MAIR0 and MAIR1,
Memory Attribute Indirection Registers 0 and 1, VMSA on page B4-1639.
See also Architectural status of PRRR and NMRR on page B4-1695.
Configurations In an implementation that includes the Security Extensions, the NMRR:

• Is Banked.
• Has write access to the Secure copy of the register disabled when the
The NMRR bit assignments are:

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
OR7 OR6 OR5 OR4 OR3 OR2 OR1 OR0 IR7 IR6 IR5 IR4 IR3 IR2 IR1 IR0
ORn, bits[2n+17:2n+16], for values of n from 0 to 7

Outer Cacheable property mapping for memory attributes n, if the region is mapped as Normal
memory by the PRRR.TRn entry. n is the value of the TEX[0], C and B bits, see Table B4-28 on
page B4-1695. The possible values of this field are:
00 Region is Non-cacheable.
01 Region is Write-Back, Write-Allocate.
10 Region is Write-Through, no Write-Allocate.
11 Region is Write-Back, no Write-Allocate.
The meaning of the field with n = 6 is IMPLEMENTATION DEFINED and might differ from the meaning
given here. This is because the meaning of the attribute combination {TEX[0] = 1, C = 1, B = 0} is
IRn, bits[2n+1:2n], for values of n from 0 to 7

Inner Cacheable property mapping for memory attributes n, if the region is mapped as Normal
memory by the PRRR.TRn entry. n is the value of the TEX[0], C and B bits, see Table B4-28 on
page B4-1695. The possible values of this field are the same as those given for the ORn field.
The meaning of the field with n = 6 is IMPLEMENTATION DEFINED and might differ from the meaning
given here. This is because the meaning of the attribute combination {TEX[0] = 1, C = 1, B = 0} is
For more information about the NMRR see Short-descriptor format memory region attributes, with TEX remap on
page B3-1364.
Accessing the NMRR

To access the NMRR, software reads or writes the CP15 registers with <opc1> set to 0, <CRn> set to c10, <CRm> set to
MRC p15, 0, <Rt>, c10, c2, 1 ; Read NMRR into Rt

MCR p15, 0, <Rt>, c10, c2, 1 ; Write Rt to NMRR
B4.1.111 NSACR, Non-Secure Access Control Register, Security Extensions

The NSACR characteristics are:
Purpose The NSACR:

• Defines the Non-secure access permissions to coprocessors CP0 to CP13.
• Can include additional IMPLEMENTATION DEFINED bits that define Non-secure access
permissions for IMPLEMENTATION DEFINED functionality.
• In an implementation that includes the Virtualization Extensions, controls Hyp mode
access to:
— Coprocessors CP0 to CP13.
— Floating-point and Advanced SIMD functionality.
Usage constraints Only accessible from PL1 or higher, with access rights that depend on the mode and security
state:
• The NSACR is read/write in Secure PL1 modes.
• The NSACR is read-only in Non-secure PL1 and PL2 modes.
Configurations The NSCAR is implemented only as part of the Security Extensions. It is a Restricted access
register, but can be read from Non-secure state.
Attributes A 32-bit RW register with a reset value that depends on the implementation. For more
information, see the register field descriptions. See also Reset behavior of CP14 and CP15
registers.
The NSACR bit assignments are:

31 21 20 19 18 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved, UNK/SBZP
NSTRCDIS cp13 cp0

RFR
IMPLEMENTATION DEFINED Coprocessor Non-secure access enables,
NSASEDIS cp13 to cp0, see text
NSD32DIS
NSTRCDIS, bit[20]
Disable Non-secure access to CP14 trace registers.
The implementation of this bit must correspond to the implementation of the CPACR.TRCDIS bit:
• If CPACR.TRCDIS is RAZ/WI then this bit is RAZ/WI.
• If CPACR.TRCDIS is RW then this bit is RW.
If NSTRCDIS is RW its possible values are:
0 This bit has no effect on the ability to write to CPACR.TRCDIS.
1 When executing in Non-secure state:
• CPACR.TRCDIS behaves as RAO/WI, regardless of its actual value.
• In an implementation that includes the Virtualization Extensions, HCPTR.TTA
behaves as RAO/WI, regardless of its actual value.
See the CPACR.TRCDIS description for more information about when this bit can be RW.
If this bit is implemented as an RW bit, it resets to 0.
RFR, bit[19] Reserve FIQ Registers:

0 FIQ mode and the FIQ Banked registers are accessible in Secure and Non-secure states.
1 FIQ mode and the FIQ Banked registers are accessible in Secure security state only. Any
attempt to access any FIQ Banked register in Non-secure security state is
UNPREDICTABLE. Any attempt to enter FIQ mode with SCR.NS set to 1 is
UNPREDICTABLE.
It is IMPLEMENTATION DEFINED whether this bit is supported. If it is not supported it is RAZ/WI.

If NSACR.RFR is set to 1 when SCR.FIQ == 0, instruction execution is UNPREDICTABLE in
Non-secure state.
From the introduction of the Virtualization Extensions, ARM deprecates any use of this bit.
Bits[18:16] IMPLEMENTATION DEFINED.
These bits can define the Non-secure access permissions for IMPLEMENTATION DEFINED features.
NSASEDIS, bit[15]
Disable Non-secure Advanced SIMD functionality.
The implementation of this bit must correspond to the implementation of the CPACR.ASEDIS bit.
This means:
• If a processor:
— Implements the Floating-point Extension but does not implement the Advanced SIMD
— Does not implement the Floating-point Extension or the Advanced SIMD Extension,
this bit is this bit is UNK/SBZP.
• If a processor implements both the Floating-point Extension and the Advanced SIMD
Extension, it is IMPLEMENTATION DEFINED whether CPACR.ASEDIS is RAZ/WI or RW, and
the NSASEDIS bit must behave in the same way.
If NSASEDIS is RW, its possible values are:
0 This bit has no effect on the ability to write to CPACR.ASEDIS.
1 When executing in Non-secure state:
• CPACR.ASEDIS behaves as RAO/WI, regardless of its actual value.
• In an implementation that includes the Virtualization Extensions, HCPTR.TASE
NSD32DIS, bit[14]
Disable Non-secure use of registers D16-D31 of the Floating-point Extension register file
The implementation of this bit must correspond to the implementation of the CPACR.D32DIS bit.
This means:
• If a processor:
— Implements the Floating-point Extension but does not implement D16-D31, this bit is
RAO/WI.
— Does not implement Floating-point Extension, this bit is UNK/SBZP.
• If a processor implements the Floating-point Extension and implements D16-D31, it is
IMPLEMENTATION DEFINED whether CPACR.D32DIS is RAZ/WI or RW, and the NSD32DIS
must behave in the same way.
If NSD32DIS is RW, its possible values are:
0 This bit has no effect on the ability to write to CPACR.D32DIS.
1 When executing in Non-secure state, CPACR.D32DIS is RAO/WI.
When this bit is RW, if it is set to 1 when NSACR.NSASEDIS is set to 0, the result is
UNPREDICTABLE.
cpn, bit[n], for values of n from 0 to 13

Non-secure access to coprocessor n enable. Each bit enables access to the corresponding
coprocessor from Non-secure state:
0 Coprocessor n can be accessed only from Secure state. Any attempt to access
coprocessor n in Non-secure state results in an Undefined Instruction exception.
If the processor is in Non-secure state:
• The corresponding field in the CPACR reads as 0b00, and ignores writes,
regardless of its actual value.
• In an implementation that includes the Virtualization Extensions, HCPTR.TCPn
1 Coprocessor n can be accessed from any security state.
If Non-secure access to a coprocessor is enabled, for accesses from Non-secure modes other than
Hyp mode, the CPACR must be checked to determine the level of access that is permitted.
If multiple coprocessors are required to control a particular feature then the Non-secure access
enable bits for those coprocessors must be set to the same value, otherwise behavior is
UNPREDICTABLE. For example, in an implementation that includes the Floating-point Extension, the
extension is controlled by coprocessors 10 and 11, and bits[10, 11] of the NSACR must be set to the
same value.
For bits that correspond to coprocessors that are not implemented, it is IMPLEMENTATION DEFINED
whether the bits:
• Behave as RAZ/WI.
• Can be written by Secure PL1 modes.
Coprocessors 8, 9, 12, and 13 are reserved for future use by

DDI0406C D Armv7ar Arm PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DDI0406C D Armv7ar Arm PDF

Uploaded by

Copyright:

Available Formats

ARM Architecture Reference Manual

ARMv7-A and ARMv7-R edition

The following changes have been made to this document.

Date Issue Confidentiality Change

24 July 2012 C.b Non-Confidential Errata release for issue C.a.

This document may include technical inaccuracies or typographical errors.

Arm Limited. Company 02557590 registered in England.

The information in this document is final, that is for a developed product.

Part A Application Level Architecture

Chapter A2 Application Level Programmers’ Model

Chapter A3 Application Level Memory Model

Chapter A4 The Instruction Sets

Chapter A5 ARM Instruction Set Encoding

Chapter A6 Thumb Instruction Set Encoding

Chapter A7 Advanced SIMD and Floating-point Instruction Encoding

Chapter A8 Instruction Descriptions

Chapter A9 The ThumbEE Instruction Set

Part B System Level Architecture

Chapter B2 Common Memory System Architecture Features

Chapter B3 Virtual Memory System Architecture (VMSA)

Chapter B4 System Control Registers in a VMSA implementation

Chapter B5 Protected Memory System Architecture (PMSA)

Chapter B6 System Control Registers in a PMSA implementation

Chapter B7 The CPUID Identification Scheme

Chapter B8 The Generic Timer

Chapter B9 System Instructions

Part C Debug Architecture

Chapter C2 Invasive Debug Authentication

Chapter C3 Debug Events

Chapter C4 Debug Exceptions

Chapter C5 Debug State

Chapter C6 Debug Register Interfaces

Chapter C7 Debug Reset and Powerdown Support

Chapter C8 The Debug Communications Channel and Instruction Transfer Register

Chapter C9 Non-invasive Debug Authentication

Chapter C10 Sample-based Profiling

Chapter C11 The Debug Registers

Chapter C12 The Performance Monitors Extension

Appendix B Recommended Memory-mapped and External Debug Interfaces for the

Appendix C Recommendations for Performance Monitors Event Numbers for

Appendix E System Level Implementation of the Generic Timer

Appendix F Common VFP Subarchitecture Specification

Appendix G Barrier Litmus Tests

Appendix H Legacy Instruction Mnemonics

Appendix I Deprecated and Obsolete Features

Appendix J Fast Context Switch Extension (FCSE)

Appendix K VFP Vector Operation Support

Appendix L ARMv6 Differences

Appendix M v6 Debug and v6.1 Debug Differences

Appendix N Secure User Halting Debug

Appendix O ARMv4 and ARMv5 Differences

Appendix P Pseudocode Definition

Appendix Q Pseudocode Index

Appendix R Registers Index

About this manual

• The processor instruction sets:

• The exception model.

This manual is organized into parts:

Using this manual

Part A, Application Level Architecture

Chapter A1 Introduction to the ARM Architecture

Chapter A2 Application Level Programmers’ Model

Chapter A3 Application Level Memory Model