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

[H.J. Lu]

On Fri, Oct 14, 2022 at 12:03 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 13.10.2022 19:00, H.J. Lu wrote:
> > On Wed, Oct 12, 2022 at 11:08 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 12.10.2022 19:10, H.J. Lu wrote:
> >>> 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.
> >>
> >> You've said so before, yes, but I continue to disagree. And as we can see
> >> from the series things can be made work consistently (and imo nothing else
> >> should have been done right from the beginning).
> >>
> >
> > There are inconsistencies in ISA.
>
> Sure. But we shouldn't add further ones in the assembler.

Assembler just follows ISA.  Programmers should learn to
deal with it or use a compiler.

> >  AT&T syntax makes things more complex.
> > People should either deal with it or leave it to compilers.   I don't think we
> > should make assembler more complex.
>
> The complexity added here isn't all that bad. You've added far more
> complexity in the past for things which arguably shouldn't even be
> dealt with by the assembler (I'm thinking of -malign-branch* and
> -mlfence-* first of all).
>
> Jan



-- 
H.J.