From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) by sourceware.org (Postfix) with ESMTPS id DF7E53858D32 for ; Wed, 19 Oct 2022 21:46:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DF7E53858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-qt1-x836.google.com with SMTP id z8so12610385qtv.5 for ; Wed, 19 Oct 2022 14:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ZJHMZwmPslGobhVcR8LmjLEvc8f3oPRBOeKioscQZjI=; b=LEcYMRaeTLQPm1t8gd60Q5mhq9kyFcJuxPUVDXYh28m6ZOXMdjxJRyHKt3u0AAraZN wcnsFRar7OGxM6vNCS5aWbB+MgLR4eh8mu+ei1vuDSKBU6tAUqZv2bIS3GUBm3YgGazU SFeVbsOufhuldzK7JzoHnT2rL0P1u65MCIRzLazvKXHu+zhFqutRjsLXtRWs7DUb8faq 2A8sRC8ShFP6CEMzl0a91rQ69QwZLxpfxokRuLzEaUHkwHmADbtLKQfct/2uiQwpyfN0 kj9DNwSQoX7KOARR8VKyaQqW97H+7+c+KeyKzsQyDmuAsP3koxUn6BXzx39NT5Na0t88 iCag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ZJHMZwmPslGobhVcR8LmjLEvc8f3oPRBOeKioscQZjI=; b=udhhUdsVgulz8UraPho8dXfGUhPoSc4G7nlUIkdEetl6IoO50IW6mbgF39zM8Ci6F9 CIfLJsXHQjmvGE0zdIPsv94e+asf+5GxzjkD3UrH3HfC1qjl4UySF9qS+CJyqDSD/pQp 9KPRzM5NBE4DP+gy+/tFPPXlAdixQRvexx8oh7m30O6HBTR5qPvZFx2hWeUN/Lz7oKah A5PHSpTUCIJKTsWR+mj1lDFrrjmobIbg7KyHbBmd9ERcBZV8xExnbSDJdn30D+SGDRVt iSSbQRd53RSBBA6soO5I6o/6YtES9zheWOgH4F74W0mU/qNrWX8W9K+dChCKttcV0C9w vaoA== X-Gm-Message-State: ACrzQf3m2/WQ3OfLMc+W+s0CUzan4iXWjt6XEIG3Z46jfO0uNanyPBvv e8DhuxZL3BmIfHBeIT39OyUEUr26HOi0/n0bcl1vzBCt X-Google-Smtp-Source: AMsMyM4+sl/ki1Kuko/wv6hx3icOVRaRKj35YS4eCcc4ebrNISqGfSMjZ6h3e4KWoEAfgfu5PFA6cKhXfKm8WGdQRWM= X-Received: by 2002:ac8:4e53:0:b0:39c:eec4:373f with SMTP id e19-20020ac84e53000000b0039ceec4373fmr8190098qtw.617.1666216000145; Wed, 19 Oct 2022 14:46:40 -0700 (PDT) MIME-Version: 1.0 References: <20e2773a-2e47-869b-1900-709f8ad4cd6b@suse.com> <2981100a-17bf-623c-27fc-0da08279c3ff@suse.com> <32052f49-9789-36c6-fc26-a7e24f248435@suse.com> <8a1fe0ad-d5a3-cdb6-780b-6ac69123a51d@suse.com> <8c7a9008-64cc-54a6-6124-4517f31d8d5c@suse.com> In-Reply-To: <8c7a9008-64cc-54a6-6124-4517f31d8d5c@suse.com> From: "H.J. Lu" Date: Wed, 19 Oct 2022 14:46:04 -0700 Message-ID: Subject: Re: [PATCH v3 4/7] x86-64: further re-work insn/suffix recognition to also cover MOVSL To: Jan Beulich Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3017.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, Oct 18, 2022 at 11:08 PM Jan Beulich wrote: > > On 18.10.2022 23:48, H.J. Lu wrote: > > On Mon, Oct 17, 2022 at 11:31 PM Jan Beulich wrote: > >> > >> On 18.10.2022 00:36, H.J. Lu wrote: > >>> On Mon, Oct 17, 2022 at 12:02 AM Jan Beulich wrote: > >>>> > >>>> On 14.10.2022 19:07, H.J. Lu wrote: > >>>>> On Fri, Oct 14, 2022 at 12:03 AM Jan Beulich wrote: > >>>>>> > >>>>>> On 13.10.2022 19:00, H.J. Lu wrote: > >>>>>>> On Wed, Oct 12, 2022 at 11:08 PM Jan Beulich wrote: > >>>>>>>> > >>>>>>>> On 12.10.2022 19:10, H.J. Lu wrote: > >>>>>>>>> On Wed, Oct 12, 2022 at 12:08 AM Jan Beulich wrote: > >>>>>>>>>> > >>>>>>>>>> On 11.10.2022 19:44, H.J. Lu wrote: > >>>>>>>>>>> On Wed, Oct 5, 2022 at 12:24 AM Jan Beulich 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. > >> > >> Hmm, so after all not any ISA to follow? Plus do you suggest there's > >> only people having written x86 assembler code for many years? And > >> there's no people who would prefer to get their code into more > >> consistent shape, but who are limited by assembler shortcomings? > > > > I prefer consistency with existing assemblers and ISA specs. > > For new instructions, suffixes should be used only when there is > > an ambiguity. For existing instructions, to support existing assembly > > codes, suffixes may be optional even when there is an ambiguity. > > But for integer MOVS instructions, suffixes have always been required. > > I don't think we should change them now. We can improve documentation > > if needed. > > > >> In any event, ... > >> > >>>> 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? > >> > >> ... this request continues to stand. > > > > I think we should improve diagnostics and documentation, not add new > > syntaxes to existing instructions. > > I continue to disagree, but to make at least some forward progress: Which > parts of this series can I expect an okay for (patches 5-7 already have > one, but can't go in ahead)? I would try to re-order the series then to > put the controversial patch(es) at the end, such that at least parts can > go in and I can make further progress with other work. But there's no > promise this re-ordering actually is going to work out if it's more than > just this one patch which you continue to object to. > Please submit a new patch set without MOVS changes. Thanks. -- H.J.