Although aarch32 (ARMv8 32-bit) is meant to be backwards compatible with ARMv7, there is a mismatch in mask for the STC instruction.
In this instruction, bit 22 defines the 'D' field in ARMv7 (either 1 or 0), while in ARMv8 bit 22 is a mandatory '0' bit.
ARMv7:
ARMv8:
As it turn out, in ARMv7 the 'D' field doesn't actually change the behavior of the instruction. Indeed it is simply part of the implicit negative mask of the instruction (i.e. having 'P' 'U' 'W' and 'D' set redirects to the MCRR instruction).
So an STC instruction which sets 'D' but not 'P', 'U' and 'W' is exactly equivalent to the same to one which does not set 'D' (according to the ARMv7 spec) but both instructions are valid.
Following the ARMv8 spec precisely, however, results in a disassembly error for such an instruction.
In general there may be other small inconsistencies between ARMv7 and ARMv8, so there is a larger question around whether or not these can be determined automatically or simply dealt with as they come up.
Although aarch32 (ARMv8 32-bit) is meant to be backwards compatible with ARMv7, there is a mismatch in mask for the STC instruction.
In this instruction, bit 22 defines the 'D' field in ARMv7 (either 1 or 0), while in ARMv8 bit 22 is a mandatory '0' bit.
ARMv7:
ARMv8:
As it turn out, in ARMv7 the 'D' field doesn't actually change the behavior of the instruction. Indeed it is simply part of the implicit negative mask of the instruction (i.e. having 'P' 'U' 'W' and 'D' set redirects to the MCRR instruction).
So an STC instruction which sets 'D' but not 'P', 'U' and 'W' is exactly equivalent to the same to one which does not set 'D' (according to the ARMv7 spec) but both instructions are valid.
Following the ARMv8 spec precisely, however, results in a disassembly error for such an instruction.
In general there may be other small inconsistencies between ARMv7 and ARMv8, so there is a larger question around whether or not these can be determined automatically or simply dealt with as they come up.