Re: [PATCH 15/18] target/arm: Implement MVE long shifts by immediate

[Richard Henderson]

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~