On 6/28/21 9:54 AM, Richard Henderson wrote:
On 6/28/21 6:58 AM, Peter Maydell wrote:{ + # The v8.1M MVE shift insns overlap in encoding with MOVS/ORRS + # and are distinguished by having Rm==13 or 15. Those are UNPREDICTABLE + # cases for MOVS/ORRS. We decode the MVE cases first, ensuring that + # they explicitly call unallocated_encoding() for cases that must UNDEF + # (eg "using a new shift insn on a v8.1M CPU without MVE"), and letting + # the rest fall through (where ORR_rrri and MOV_rxri will end up + # handling them as r13 and r15 accesses with the same semantics as A32). + LSLL_ri 1110101 0010 1 ... 0 0 ... ... 1 .. 00 1111 @mve_shl_ri + LSRL_ri 1110101 0010 1 ... 0 0 ... ... 1 .. 01 1111 @mve_shl_ri + ASRL_ri 1110101 0010 1 ... 0 0 ... ... 1 .. 10 1111 @mve_shl_ri + + UQSHLL_ri 1110101 0010 1 ... 1 0 ... ... 1 .. 00 1111 @mve_shl_ri + URSHRL_ri 1110101 0010 1 ... 1 0 ... ... 1 .. 01 1111 @mve_shl_ri + SRSHRL_ri 1110101 0010 1 ... 1 0 ... ... 1 .. 10 1111 @mve_shl_ri + SQSHLL_ri 1110101 0010 1 ... 1 0 ... ... 1 .. 11 1111 @mve_shl_ri +Could perhaps usefully be nested under [ ].
Actually, it looks like there could be a couple of groups that sort [0:3] into 1111 and 1101 with { }, then further into a couple of groups with [ ].
Anyway, none of that is required for function. r~
