I have a couple questions about the AArch64 encoding.Some instructions are defined to be UNDEFINED if fields are set in a certain way (where UNDEFINED means that the instruction generates an Undefined Instruction exception). For example, EOR contains the following decode pseudocode:```if sf == '0' && N != '0' then UNDEFINED;```I just want to confirm that this means that an EOR instruction encoded with `sf == '0'` and `N != '0'` is guaranteed to generate an Undefined Instruction exception. Therefore this encoding will never be reused in the future for a different operation, since it must generate an exception.Also, the AArch64 manual states this at the end of Section C1.1 "About the A64 instruction set":> All encodings that are not fully defined are described as unallocated. An attempt to execute an unallocated instruction is UNDEFINED, unless the behavior is otherwise defined in this Manual.It seems like unallocated instructions should actually be defined as UNPREDICTABLE, since they may be allocated in a future version of AArch64 in which case they can no longer be relied upon to generate an undefined exception. For example, if unallocated instructions were defined in Armv8.0 as UNDEFINED, then if Armv8.1 allocated new instructions it would be incompatible with Armv8.0 (i.e., an Armv8.1 processor would not be Armv8.0 compliant and therefore could not run Armv8.0 binaries). Is this statement in the manual a mistake, or am I misunderstanding the guarantees that are being provided?
Zachary Y said:It seems like unallocated instructions should actually be defined as UNPREDICTABLE
... but they are not "UNPREDICTABLE" (i.e. unpredictable behaviour is not specified as predictably generating an undefined instruction exception).
Zachary Y said:For example, if unallocated instructions were defined in Armv8.0 as UNDEFINED, then if Armv8.1 allocated new instructions it would be incompatible with Armv8.0
Specifications are versioned and applied as written to the current version of the architecture. If you want to write software that is compatible with e.g. 8.1 then you have to confirm to the 8.1 architecture specification, at which point the instructions in question will be allocated and will not be UNDEFINED.
TLDR: Software written for 8.0 should not be relying on specific unallocated instructions generating an undefined exception if it wants to be forward-compatible.
I'm saying the unallocated instructions should be defined as UNPREDICTABLE, so that they cannot be relied upon as predictably generating an undefined instruction definition. Currently they appear to be defined as UNDEFINED by the manual, which seems incorrect because it is not forward-compatible (my understanding is that this would define them all to predictably generate an exception, which seems in conflict with forward-compatibility).
Your TLDR makes perfect sense, but I think it implies that the manual should say unallocated instructions are UNPREDICTABLE, not UNDEFINED (since UNDEFINED assigns them a particular behavior).