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?
While I get your argument, I have to agree with Peter. UNDEFINED and UNPREDICTABLE (or CONSTRAINED UNPREDICTABLE) are different things, and they're intended to tell programmer's different things.
UNDEFINED = This opcode/operation/encoding is not yet allocated, but might be allocated in the future.UNPRED = Don't this, the architecture does not guarantee the behaviour AND given hardware might not give consistent behaviour.The second part of the UNPRED definition is important. If something is UNPRED a given processor is allowed to do different things each time it hits the operation.
So I was nit picking, I'd phrase it as:It is IMPLEMENTATION DEFINED whether <feature> is implemented. If <feature> is not implemented, <X> is UNDEFINED.
> UNDEFINED = This opcode/operation/encoding is not yet allocated, but might be allocated in the future.
But UNDEFINED is not defined in this manner in the Arm manual glossary. Instead it says "UNDEFINED - Indicates cases where an attempt to execute a particular encoding bit pattern generates an exception, that is taken to the current Exception level, or to the default Exception level for taking exceptions if the UNDEFINED encoding was executed at EL0." I cannot find any reference that UNDEFINED indicates that the operation might become allocated in the future (change behavior).
I think your phrasing using IMPLEMENTATION DEFINED is reasonable. I can see how using UNPREDICTABLE might go further than desired. If the manual were updated to use your phrasing for unallocated instructions I would be satisfied with that. I think there needs to be some difference between UNDEFINED (permanent definition of behavior) and unallocated.
Ultimately, I am looking for a formal assurance from the spec that things like UDF, or EOR with a certain bit pattern are guaranteed to generate an Undefined exception for all versions of the architecture. However, these instructions appear to be defined in exactly the same way as unallocated instructions -- the manual simply says that both unallocated and UDF are "UNDEFINED" but apparently one appears to have some permanence guarantee (UDF) while the other does not (unallocated). While the manual's text for UDF does say "Permanently undefined" the pseudocode just says "UNDEFINED." The text for EOR says nothing about its UNDEFINED encoding, so in that case I only have the pseudocode to rely on, which gets back to part 1 of my original question about whether the EOR UNDEFINED encoding is guaranteed to generate an exception permanently.
Thanks for reading all this and helping out, I think I have mostly gotten to the bottom of this.
Zachary Y said:While the manual's text for UDF does say "Permanently undefined" the pseudocode just says "UNDEFINED." The text for EOR says nothing about its UNDEFINED encoding, so in that case I only have the pseudocode to rely on, which gets back to part 1 of my original question about whether the EOR UNDEFINED encoding is guaranteed to generate an exception permanently.
The UDF instruction encoding being "permanently undefined" gives you the future-proof guarantee you require. The pseudocode defines the function of the hardware, so has no temporal aspect.
You have no such guarantees for the EOR encoding.