[PATCH v3 4/7] x86-64: further re-work insn/suffix recognition to also cover MOVSL

[H.J. Lu]

On Wed, Oct 12, 2022 at 12:08 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 11.10.2022 19:44, H.J. Lu wrote:
> > On Wed, Oct 5, 2022 at 12:24 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> PR gas/29524
> >> In order to make MOVSL{,Q} behave similarly to MOVSB{W,L,Q} and
> >> MOVSW{L,Q} we need to defer parse_insn()'s emitting of errors unrelated
> >> to prefix parsing. Utilize i.error just like match_template() does.
> >
> > Since movs{b,w,l,q} are string instructions, integer sign extensions
> > require a suffix to specify the destination size.  This is different from other
> > integer instructions.  Since only the new assembler allows the implicit suffix,
> > it won't be easy to use.  We should improve error messages, but allowing
> > new syntax doesn't help much.
>
> It is an earlier change making most of this consistent with MOVZ*; it is

MOVZ is different.  There are no MOVZ string instructions.  MOVS has
different meanings in ISA.   MOVS difference from MOVZ in assembly
syntax should be expected.

> only logical to extend this to the long-to-quad sign-extending insn. As
> with any fixes to prior misbehavior - of course one needs to play by the
> rules of the older assembler for a number of years. But projects raise
> their baselines, and hence at some point projects with an "avoid suffixes
> if possible" policy could switch.
>
> Jan



-- 
H.J.