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

["H.J. Lu" <hjl.tools@gmail.com>]

On Mon, Oct 17, 2022 at 12:02 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 14.10.2022 19:07, H.J. Lu wrote:
> > 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.
>
> This is entirely non-constructive. Assembler writers should get things into
> usable (read: consistent) shape. Plus what ISA are you talking about here?

GNU assembler has been this way for a long time and the current GNU
assembler will still be in use for the next few years.  Assembler writers
should know about all these.

> We're talking of mnemonics which aren't spelled out in any ISA document
> anyway. The only halfway official AT&T doc I'm aware of doesn't provide
> room for omitting size suffixes [1]. Yet that's a fundamental feature of gas,
> and elsewhere (recently: CMPccXADD) you're even suggesting to force people
> to omit suffixes (plus you've previously objected to the disassembler to
> consistently emit them in suffix-always mode).
>
> That same document was also only updated to cover 64-bit code in a half-
> hearted way, so can't necessarily be used for 64-bit only insns (it doesn't
> list any form of MOVSXD at all afaics, for example). Where not explicitly
> mentioned, their intended handling can only be inferred by using analogies.
> Nor do we support some of the odd (quirky I would say) mnemonics that are
> listed there, like xchglA or movabsbA (which is even wrongly described as
> moving an immediate value into the register).
>
> Bottom line: May I please ask that you take another (constructive) look at
> the v4 submission?
>
> Jan
>
> [1] Really it does, by saying "long" is then implied, which has never been
> the behavior of gas when a register saying otherwise is also in use.



-- 
H.J.