Home Original page

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

Jan Beulich jbeulich@suse.com
Mon Oct 17 07:02:15 GMT 2022 
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?
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.
More information about the Binutils mailing list