public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Binutils <binutils@sourceware.org>
Subject: Re: [PATCH v3 4/7] x86-64: further re-work insn/suffix recognition to also cover MOVSL
Date: Fri, 14 Oct 2022 09:03:19 +0200	[thread overview]
Message-ID: <32052f49-9789-36c6-fc26-a7e24f248435@suse.com> (raw)
In-Reply-To: <CAMe9rOqD5avMEwc8c8Ek8bXoic_ywTiJhzQK8H7Wr0PKDbAwmg@mail.gmail.com>

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.

>  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

  reply	other threads:[~2022-10-14  7:03 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-05  7:19 [PATCH v3 0/7] x86: suffix handling changes Jan Beulich
2022-10-05  7:20 ` [PATCH v3 1/7] x86: constify parse_insn()'s input Jan Beulich
2022-10-05  7:22 ` [PATCH v3 2/7] x86: introduce Pass2 insn attribute Jan Beulich
2022-10-05  7:23 ` [PATCH v3 3/7] x86: re-work insn/suffix recognition Jan Beulich
2022-10-05 23:52   ` H.J. Lu
2022-10-06  6:15     ` Jan Beulich
2022-10-06  6:58       ` Jan Beulich
2022-10-06 15:28         ` H.J. Lu
2022-10-06 16:12           ` Jan Beulich
2022-10-06 18:41             ` H.J. Lu
2022-10-07 13:03               ` Jan Beulich
2022-10-05  7:24 ` [PATCH v3 4/7] x86-64: further re-work insn/suffix recognition to also cover MOVSL Jan Beulich
2022-10-11 17:44   ` H.J. Lu
2022-10-12  7:08     ` Jan Beulich
2022-10-12 17:10       ` H.J. Lu
2022-10-13  6:08         ` Jan Beulich
2022-10-13 17:00           ` H.J. Lu
2022-10-14  7:03             ` Jan Beulich [this message]
2022-10-14 17:07               ` H.J. Lu
2022-10-17  7:02                 ` Jan Beulich
2022-10-17 22:36                   ` H.J. Lu
2022-10-18  6:31                     ` Jan Beulich
2022-10-18 21:48                       ` H.J. Lu
2022-10-19  6:08                         ` Jan Beulich
2022-10-19 21:46                           ` H.J. Lu
2022-10-20 10:12                             ` Jan Beulich
2022-10-05  7:24 ` [PATCH v3 5/7] ix86: don't recognize/derive Q suffix in the common case Jan Beulich
2022-10-11 17:49   ` H.J. Lu
2022-10-05  7:25 ` [PATCH v3 6/7] x86-64: allow HLE store of accumulator to absolute 32-bit address Jan Beulich
2022-10-11 17:50   ` H.J. Lu
2022-10-05  7:25 ` [PATCH v3 7/7] x86: move bad-use-of-TLS-reloc check Jan Beulich
2022-10-11 17:57   ` H.J. Lu
2022-10-12  7:13     ` Jan Beulich
2022-10-12 17:02       ` H.J. Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=32052f49-9789-36c6-fc26-a7e24f248435@suse.com \
    --to=jbeulich@suse.com \
    --cc=binutils@sourceware.org \
    --cc=hjl.tools@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).