Introduction

This is the 2025-12 release of the A64 ISA Data release for A-profile Architecture.

The Proprietary Notice gives details of the terms and conditions under which this package is provided.

If you have comments on the content of this package, create a ticket at https://support.developer.arm.com. As part of the ticket, include:

• The title, "A64 ISA XML for A-profile Architecture".
• The version, "2025-12".
• The section name to which your comments refer.
• A concise explanation of your comments.

Contents

Arm Architecture publications

Arm welcomes and fosters engagement with academics and third parties. However, the Arm published Architecture Reference Manual is the only authoritative definition of the Arm Architecture.

Product Status

The information relating to the MPAMv2 features, GICv5 features, FEAT_TLBID, FEAT_SRMASK2, and FEAT_NV3 is at Alpha quality. Alpha quality means that most major features of the specification are described in this release, but some features and details might be missing.

The information relating to the rest of the A-profile Architecture is at Beta quality. Beta quality means that all major features of the specification are described, but some details might be missing.

Change history

Arm has published this release in ASL1 format. Please see https://developer.arm.com/architectures/architecture%20specification%20language for details on this language.

The following changes are made to instruction descriptions:

• The SME SEL instruction description is corrected to define vector predicate elements as true/false rather than active/inactive elements. In addition, the 'PNg' encoding field name, assembly syntax, and assembler symbols are changed to 'PNv'.
• The lock-free sequence when <Ws> or <Xs> specify the same register as <Wt> or <Xt> is clarified in the following CAS* instructions:
  • CAS, CASA, CASAL, CASL.
  • CASB, CASAB, CASALB, CASLB.
  • CASH, CASAH, CASALH, CASLH.
  • CASP, CASPA, CASPAL, CASPL.
  • CAST, CASAT, CASALT, CASLT.
  • CASPT, CASPAT, CASPALT, CASPLT.
• The description of the following instructions are corrected to remove instances of "complement":
  • RCWSET, RCWSETA, RCWSETAL, RCWSETL.
  • RCWSSET, RCWSSETA, RCWSSETAL, RCWSSETL.
• The values of Xd and Xs on completion of the instruction are relaxed in the following Memory Copy instructions:
  • CPYP, CPYM, CPYE.
  • CPYPN, CPYMN, CPYEN.
  • CPYPRN, CPYMRN, CPYERN.
  • CPYPRT, CPYMRT, CPYERT.
  • CPYPRTN, CPYMRTN, CPYERTN.
  • CPYPRTRN, CPYMRTRN, CPYERTRN.
  • CPYPRTWN, CPYMRTWN, CPYERTWN.
  • CPYPT, CPYMT, CPYET.
  • CPYPTN, CPYMTN, CPYETN.
  • CPYPTRN, CPYMTRN, CPYETRN.
  • CPYPTWN, CPYMTWN, CPYETWN.
  • CPYPWN, CPYMWN, CPYEWN.
  • CPYPWT, CPYMWT, CPYEWT.
  • CPYPWTN, CPYMWTN, CPYEWTN.
  • CPYPWTRN, CPYMWTRN, CPYEWTRN.
  • CPYPWTWN, CPYMWTWN, CPYEWTWN.
• In the Index by encoding, multiple rows for the same instruction are used in tables to remove encoding overlaps.

The following changes are made to the pseudocode:

• The decode pseudocode for LUTI6 instructions is updated to use MaxImplementedSVL() instead of MaxImplementedAnyVL() when checking the required minimum vector length.
• The accessibility pseudocode for AT, DC, IC, and TLBI system instructions is refactored to focus on trapping functionality. The non-trapping functionality is moved into the shared pseudocode functions.
• The function GPTTableDescriptorValid() is updated to avoid incorrectly checking bits [55:52] when PPS=56 under FEAT_RME_GPC3.
• The function IsContiguousSVEAccess() is corrected to include SVE contiguous vector load/store instructions in Streaming SVE mode and Z-targeting SME multi-vector load/store instructions.
• The function DecodeGPTTable() is updated to use the configured L0GPTSZ via GPTL0Size() when decoding GPT table descriptors.
• The vaddress parameter is removed from the function AArch64.WriteTagMem() and the vaddress is computed by aligning the regval parameter inside the function.
• The function AArch64.TLBI_RPA() is updated to support 56-bit physical addresses by incorporating the top bits [55:52] when FEAT_D128 is implemented and PAMax() == 56.
• In the function GPTLBIMatch(), the logic for TLBI RPALOS is corrected to identify cached GPT entries fetched from the final level of the GPT walk.
• The function CreateAccDescDCZero() is updated to set accdesc.tagaccess for CacheType_TagWrite and CacheType_TagZero.
• The function ExitDebugState() is updated so that BRBEDebugStateExit() receives the branch target address with Top Byte Ignore applied, using AArch64.BranchAddr().
• The function AArch64.CheckTag() is updated to return a FaultRecord.
• Pseudocode support is added for generating Unsupported atomic hardware update faults (Fault_HWUpdateAccessFlag) when translation table updates are not performed with Write-Back Shareable memory. This includes new fault cases in S1Translate(), S2Translate(), S1Walk(), and S2Walk(), using a new unpredictable enumeration item, Unpredictable_Unsupported_Atomic_HW_Update.
• The function AArch64.S1IndirectBasePermissions() is updated with FEAT_EPAN IMPLEMENTATION DEFINED behavior.
• The LDR (predicate), LDR (vector), LDR (array vector), STR (predicate), STR (vector), and STR (array vector) instructions now check alignment only on the base address, instead of on the address calculated with base plus offset.

Known issues

All issues identified in the below list will be fixed in a future release.

• In the following SME instructions, the feature conditions stated in the pseudocode are correct, but the feature conditions stated above the encoding diagrams are incomplete:
  • SMLALL (multiple vectors), SMLALL (multiple and single vector).
  • SMLSLL (multiple vectors), SMLSLL (multiple and single vector).
  • UMLALL (multiple vectors), UMLALL (multiple and single vector).
  • UMLSLL (multiple vectors), UMLSLL (multiple and single vector).
  • SDOT (4-way, multiple and single vector), SDOT (4-way, multiple vectors).
  • UDOT (4-way, multiple and single vector), UDOT (4-way, multiple vectors).
  • FMLA (multiple and single vector), FMLA (multiple vectors).
  • FMLS (multiple and single vector), FMLS (multiple vectors).
  • ADD (array results, multiple and single vector), ADD (array results, multiple vectors), ADD (array accumulators).
  • SUB (array results, multiple and single vector), SUB (array results, multiple vectors), SUB (array accumulators).
  • FADD.
  • FSUB.
• The assembler syntax for MRS and MSR instructions with unnamed registers will be clarified.
• The behavior of Default MPAM PARTID/PMG by TRBE and PARTID in TRBE external mode will be corrected.
• The changes clarifying that load-acquire instructions lose acquire semantics when the destination register is WZR/XZR, and that ESR_ELx.AR and SCTLR_ELx.nAA behavior is IMPLEMENTATION SPECIFIC will be incorporated into the pseudocode.
• The functions NumContextAwareBreakpointsImplemented() and ContextAwareBreakpointRange() will be updated to align with the new definition of the BRPs/CTX_CMPs in the BRPs and CTX_CMPs fields in the ID_AA64DFR0_EL1 and ID_AA64DFR1_EL1 registers.
• The reporting mechanism for GPCF and External aborts on MPAM lookups will be implemented.
• The functions AArch64.ExceptionReturn() and AArch32.ExceptionReturn() will update EDSCR.
• Pseudocode will be updated to show the split of FEAT_HAFDBS.

Many simple clarifications and corrections are also present, but are too small to be listed here. Some minor formatting changes are suppressed and not highlighted in the diff output.

Limitations of Arm pseudocode

The pseudocode statements IMPLEMENTATION_DEFINED, SEE, UNDEFINED, and UNPREDICTABLE indicate behavior that differs from that indicated by the pseudocode being executed. If one of them is encountered:

• Earlier behavior indicated by the pseudocode is only specified as occurring to the extent required to determine that the statement is executed.
• No subsequent behavior indicated by the pseudocode occurs.

For more information, see Special statements in the Arm® Architecture Reference Manual for A-profile architecture (ARM DDI 0487).

The pseudocode descriptions have several limitations. These are mainly since, for clarity and brevity, the pseudocode is a sequential and mostly deterministic language.

These limitations include:

• Pseudocode does not describe the ordering requirements when an instruction generates multiple memory accesses. For a description of the ordering requirements on memory accesses, see External ordering constraints in the Arm® Architecture Reference Manual for A-profile architecture (ARM DDI 0487).
• Pseudocode does not describe the exact ordering requirements when a single floating-point instruction generates more than one floating-point exception and one or more of those floating-point exceptions is trapped. Combinations of floating-point exceptions in the Arm® Architecture Reference Manual for A-profile architecture (ARM DDI 0487) describes the exact rules.
  Note: There is no limitation in the case where all the floating-point exceptions are untrapped, because the pseudocode specifies the same behavior as the referenced section.
• When the architectural behavior of an instruction could be performed as a concurrent set of operations that are not architecturally ordered, the pseudocode represents it as a sequential set of operations.
• An exception can be taken during execution of the pseudocode for an instruction, either explicitly as a result of the execution of a pseudocode function such as Abort(), or implicitly, for example if an interrupt is taken during execution of an LDM instruction, load-store pair instructions, SVE vector instructions, Memory copy and memory set instructions etc.. If this happens, the pseudocode does not describe the extent to which the normal behavior of the instruction occurs. To determine that, see the descriptions of the exceptions in Handling exceptions that are taken to an Exception level using AArch32 and Definition of a precise exception and imprecise exception in the Arm® Architecture Reference Manual for A-profile architecture (ARM DDI 0487).
• Pseudocode does not describe the exact rules when an AArch32 instruction that fails its condition code check generates any of the following::
  • UNDEFINED instruction.
  • Hyp trap.
  • Monitor trap.
  • Trap to AArch64 exception.
  In such cases, the UNDEFINED pseudocode statement or call to the applicable trap function lies inside the if ConditionPassed() then ... structure, either directly or in the EncodingSpecificOperations() function call, and so the pseudocode indicates that the instruction executes as a NOP. For the exact rules, see ARM DDI 0487 sections:
  • Conditional execution of undefined instructions.
  • EL2 configurable controls.
  • EL3 configurable controls.
  • Configurable instruction controls.
• Where a significant aspect of the behavior is IMPLEMENTATION DEFINED, pseudocode may present only the declarations of the functions - the details of these functions is provided by each implementation of the architecture.
• Pseudocode does not present the possible observability due to speculative execution.
• Pseudocode presents various details of the architecture - but does not show how the details can be combined to form a single definition. There are various aspects of such a detail that are also not presented. Notably:
  • Pseudocode does not show the details of fetching, decoding, and linking to instruction execution.
  • Pseudocode for combining the instruction shared decode, decode, and operation is not shown.
• Pseudocode presents all the architectural state as global state. The possible implications of multiple PEs or other components is not shown.
• The following details are either not shown or have noted limitations in the pseudocode:
  • Self-hosted trace and external trace.
  • Modeling the System register state or side effects. The accessibility details of a direct or external access such as traps etc are shown.
  • Generation of all architectural and micro-architectural Performance Monitoring Events. Note: Some architectural event generation is shown.
  • Construction of Statistical Profiling Extension records.
  • Statistical Profiling functionality for 2023 features.
  • Behavior of instructions in Debug state when the behavior is UNPREDICTABLE is presented as if the instruction is executed identically to how it is when not in Debug state.
  • Activity Monitor Events and Counters.
  • Generic Interrupt Controller functionality.
  • External memory system.
  • External agents such as a debugger.
  • PE behaviors that would lead to unrecoverable or uncontainable errors.
  • Where the behavior is IMPLEMENTATION DEFINED or CONSTRAINED UNPREDICTABLE, not all possibilities may be shown. Sometimes the pseudocode may present a simplified, but architecturally compatible view. In some situations, the possible behaviors may be outlined in a comment.
• The following architectural features are at Alpha quality and are above the limitations described below due to recency and completion of validation:
  • Halting Debug
  • Statistical Profiling Extension.
  • Performance Monitoring Events.

Upcoming Changes

The details of the architecture are presented in pseudocode in Architecture Specification Language (ASL). Arm has defined a new version of the Architecture Specification Language, ASL1, to improve and expand the capabilities of the language. Please see https://developer.arm.com/architectures/architecture%20specification%20language for details on this language.

Intention and quality statements for all ArmARM architecture releases

The intention and scope of the Architecture releases is to describe changes from the existing architecture to the next release. The quality of the architecture releases refers to the accuracy and completeness of the changes described in the specifications.

The intention and scope of the AARCHMRS and Data releases is to describe the content and behavior of the registers, system registers, instructions, pseudocode and features of the architecture in full, for human readers in a way that enables correct information for the current or any previous release can be deduced. The quality of the XML releases refers to the accuracy and completeness of the content to a human reader.

The intention and scope of the JSON releases is to describe aspects of the AARCHMRS and Data releases in a structured, machine readable format. The content of the AARCHMRS and Data architectural content will be approximately equivalent to the corresponding XML release. However there are some aspects of the architecture which cannot yet be represented in a machine readable format. The content of the AARCHMRS architectural content will be approximately equivalent to the corresponding Data release.

The intention and scope of the Schema for the JSON releases is to describe the syntax and format of the json files used in the json releases. The schema is still under development and is subject to change.