ARM AArch64 Undefined and Unallocated Instruction Encodings: Guarantees and Implications

ARM AArch64 Instruction Encodings: UNDEFINED vs. Unallocated Behavior

The ARM AArch64 architecture defines specific behaviors for instruction encodings that are either UNDEFINED or unallocated. These terms are critical for understanding how the processor handles invalid or reserved instruction patterns, and they have significant implications for software compatibility and forward compatibility across different versions of the ARM architecture.

UNDEFINED instructions are those that are explicitly defined in the architecture specification to generate an Undefined Instruction exception when executed. For example, the EOR (Exclusive OR) instruction includes a condition in its pseudocode that specifies certain bit patterns as UNDEFINED, such as when the sf field is 0 and the N field is not 0. When such an encoding is encountered, the processor must raise an exception, ensuring predictable behavior for software that relies on this behavior.

Unallocated instructions, on the other hand, are encodings that are not currently defined in the architecture but may be allocated in future versions. The ARM architecture manual states that unallocated instructions are treated as UNDEFINED in the current version, meaning they will generate an Undefined Instruction exception. However, this behavior is not guaranteed to remain consistent in future versions of the architecture, as unallocated encodings may be repurposed for new instructions.

The distinction between UNDEFINED and unallocated encodings is crucial for software developers. UNDEFINED encodings are permanently reserved to generate exceptions, ensuring that software relying on this behavior will continue to function predictably across all versions of the architecture. Unallocated encodings, however, are subject to change, and software that relies on them generating exceptions may break when running on future processors that implement new versions of the architecture.

For example, consider the EOR instruction with an encoding that is currently UNDEFINED. If a developer writes software that relies on this encoding generating an exception, they can be confident that this behavior will remain consistent across all ARMv8.0-compliant processors. However, if the same encoding is repurposed in ARMv8.1 to implement a new instruction, the software may no longer function as intended on ARMv8.1 processors. This highlights the importance of understanding the guarantees provided by the architecture specification and the potential risks of relying on unallocated encodings.

Forward Compatibility Risks with Unallocated Instruction Encodings

The treatment of unallocated instruction encodings as UNDEFINED in the current version of the ARM architecture introduces potential risks for forward compatibility. While this approach ensures that unallocated encodings generate exceptions on current hardware, it does not provide a guarantee that these encodings will remain unused in future versions of the architecture. This creates a conflict between the behavior defined in the current specification and the need for forward compatibility.

For instance, if an unallocated encoding is defined as UNDEFINED in ARMv8.0, software that relies on this encoding generating an exception may fail when running on an ARMv8.1 processor that repurposes the encoding for a new instruction. This violates the principle of forward compatibility, as the behavior of the software changes in a way that was not anticipated by the developer.

To address this issue, the ARM architecture could define unallocated encodings as UNPREDICTABLE rather than UNDEFINED. UNPREDICTABLE behavior means that the architecture does not guarantee any specific outcome, and the processor may exhibit inconsistent behavior when encountering such encodings. This would make it clear to developers that unallocated encodings are subject to change and should not be relied upon for any specific behavior.

However, the current specification defines unallocated encodings as UNDEFINED, which provides a predictable behavior for the current version of the architecture but does not account for future changes. This creates a tension between the need for predictable behavior in the current version and the need for forward compatibility across future versions.

One possible solution is to introduce a new category of encodings that are explicitly marked as reserved for future use. These encodings would be treated as UNPREDICTABLE in the current version, ensuring that developers do not rely on them for any specific behavior. This approach would provide a clearer distinction between encodings that are permanently UNDEFINED and those that are subject to change in future versions.

Ensuring Predictable Behavior with Permanently UNDEFINED Encodings

To address the concerns raised by the treatment of unallocated encodings, the ARM architecture includes a specific instruction, UDF (Permanently Undefined), which is guaranteed to generate an Undefined Instruction exception on all versions of the architecture. The UDF instruction is explicitly marked as "permanently undefined" in the architecture manual, providing a formal assurance that its behavior will not change in future versions.

The UDF instruction is particularly useful for developers who need to generate an Undefined Instruction exception in a controlled manner. For example, it can be used to implement software traps or to mark sections of code that should not be executed. By using UDF, developers can ensure that their software will behave predictably across all versions of the ARM architecture.

In contrast, other UNDEFINED encodings, such as those in the EOR instruction, do not have the same guarantee of permanence. While these encodings are defined as UNDEFINED in the current version of the architecture, they may be repurposed in future versions, leading to potential compatibility issues. This highlights the importance of using UDF for cases where a permanently UNDEFINED encoding is required.

The pseudocode for UDF simply states that the instruction is UNDEFINED, but the accompanying text in the architecture manual clarifies that it is permanently undefined. This distinction is critical for developers who need to rely on the behavior of UNDEFINED encodings. For other instructions, such as EOR, the lack of explicit text about the permanence of UNDEFINED encodings means that developers cannot assume the same level of guarantee.

To summarize, the ARM architecture provides a clear mechanism for ensuring predictable behavior with permanently UNDEFINED encodings through the UDF instruction. For other UNDEFINED encodings, developers must be aware that the behavior may change in future versions of the architecture, and they should avoid relying on these encodings for critical functionality.

Best Practices for Handling UNDEFINED and Unallocated Encodings

To minimize the risks associated with UNDEFINED and unallocated encodings, developers should follow several best practices when writing software for the ARM architecture:

1. Avoid Relying on Unallocated Encodings: Since unallocated encodings may be repurposed in future versions of the architecture, developers should avoid relying on them for any specific behavior. This includes avoiding the use of unallocated encodings for generating exceptions or other critical functionality.

2. Use UDF for Permanently UNDEFINED Behavior: When a permanently UNDEFINED encoding is required, developers should use the UDF instruction. This ensures that the behavior will remain consistent across all versions of the architecture.

3. Check Architecture Version: If software needs to be compatible with multiple versions of the ARM architecture, developers should check the architecture version at runtime and adjust behavior accordingly. This can help avoid issues caused by changes in the treatment of unallocated encodings.

4. Follow Architecture Specifications: Developers should carefully read and follow the architecture specifications for the version of the ARM architecture they are targeting. This includes understanding the treatment of UNDEFINED and unallocated encodings and avoiding any behavior that is not explicitly guaranteed by the specification.

By following these best practices, developers can ensure that their software behaves predictably across different versions of the ARM architecture and avoids potential compatibility issues caused by changes in the treatment of UNDEFINED and unallocated encodings.

Conclusion

The treatment of UNDEFINED and unallocated instruction encodings in the ARM AArch64 architecture has important implications for software compatibility and forward compatibility. While UNDEFINED encodings provide predictable behavior in the current version of the architecture, unallocated encodings are subject to change in future versions, creating potential risks for software that relies on their behavior.

To address these risks, developers should avoid relying on unallocated encodings and use the UDF instruction for cases where a permanently UNDEFINED encoding is required. By following best practices and carefully reading the architecture specifications, developers can ensure that their software behaves predictably across different versions of the ARM architecture and avoids potential compatibility issues.