On Mon, 28 Jun 2021 at 18:45, Richard Henderson <richard.hender...@linaro.org> wrote: > > 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 [ ].
I added the groupings, and the final result is: { # 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). [ { UQSHL_ri 1110101 0010 1 .... 0 ... 1111 .. 00 1111 @mve_sh_ri LSLL_ri 1110101 0010 1 ... 0 0 ... ... 1 .. 00 1111 @mve_shl_ri UQSHLL_ri 1110101 0010 1 ... 1 0 ... ... 1 .. 00 1111 @mve_shl_ri } { URSHR_ri 1110101 0010 1 .... 0 ... 1111 .. 01 1111 @mve_sh_ri LSRL_ri 1110101 0010 1 ... 0 0 ... ... 1 .. 01 1111 @mve_shl_ri URSHRL_ri 1110101 0010 1 ... 1 0 ... ... 1 .. 01 1111 @mve_shl_ri } { SRSHR_ri 1110101 0010 1 .... 0 ... 1111 .. 10 1111 @mve_sh_ri ASRL_ri 1110101 0010 1 ... 0 0 ... ... 1 .. 10 1111 @mve_shl_ri SRSHRL_ri 1110101 0010 1 ... 1 0 ... ... 1 .. 10 1111 @mve_shl_ri } { SQSHL_ri 1110101 0010 1 .... 0 ... 1111 .. 11 1111 @mve_sh_ri SQSHLL_ri 1110101 0010 1 ... 1 0 ... ... 1 .. 11 1111 @mve_shl_ri } { UQRSHL_rr 1110101 0010 1 .... .... 1111 0000 1101 @mve_sh_rr LSLL_rr 1110101 0010 1 ... 0 .... ... 1 0000 1101 @mve_shl_rr UQRSHLL64_rr 1110101 0010 1 ... 1 .... ... 1 0000 1101 @mve_shl_rr } { SQRSHR_rr 1110101 0010 1 .... .... 1111 0010 1101 @mve_sh_rr ASRL_rr 1110101 0010 1 ... 0 .... ... 1 0010 1101 @mve_shl_rr SQRSHRL64_rr 1110101 0010 1 ... 1 .... ... 1 0010 1101 @mve_shl_rr } UQRSHLL48_rr 1110101 0010 1 ... 1 .... ... 1 1000 1101 @mve_shl_rr SQRSHRL48_rr 1110101 0010 1 ... 1 .... ... 1 1010 1101 @mve_shl_rr ] MOV_rxri 1110101 0010 . 1111 0 ... .... .... .... @s_rxr_shi ORR_rrri 1110101 0010 . .... 0 ... .... .... .... @s_rrr_shi # v8.1M CSEL and friends CSEL 1110101 0010 1 rn:4 10 op:2 rd:4 fcond:4 rm:4 } Unless you would prefer otherwise, I plan to put the adjusted patches into a pullreq later this week, without resending a v2. thanks -- PMM