From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) by sourceware.org (Postfix) with ESMTPS id 743533858D32 for ; Tue, 18 Oct 2022 21:48:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 743533858D32 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-qk1-x72f.google.com with SMTP id f8so9592588qkg.3 for ; Tue, 18 Oct 2022 14:48:46 -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=pB2THv934zTJJPDurKnE/mqPBoza+dtw1ib9gwAjwEw=; b=FZe4Si7aYovRDDKXd59od54mhLC+RcbghhffTobd4KChQCwKBHLLGpCGYKa1JezOS2 8udFJlLNkjlSpOFo9E0VOWbRahdZSjlWl5EJpXO2TJ0ukCow8HkVjrJwgIVSkMMifegj Wb/90eByGwOtHsdHGZtgZ1YQ+MxKcDuwk633giy6QuppTu6U6BQZIi1cYkxEefVtVDx6 17EG/a/RRMBYttMsU8UAJL3j3yBLoB9F8z7yf+qGs+LD/bNYI57ybPyOR+FHVO3VlvMJ bjOzAeZ/NAK7t1vNe3X4332eWxQ/UKdGbdXG6iaGN2s1oLgko+35hIU5A0ymarNa0cMT u6OA== 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=pB2THv934zTJJPDurKnE/mqPBoza+dtw1ib9gwAjwEw=; b=1/xVGhlaZAfOcscqiA7dOAvRgXctrOQKoEwGwUUQnou2+KdaEcFVkrKrS3iHbcqDm+ IPyVfOQj4WV3e+0KTlDcBIzhjY3w87p9LpMclEq9d5NE5iqlKfTJqOBa5o0RdCLLswBF 1zTsNdeJE0wMaoUwW+RgYP7IVqIRRKj4gH47UXOrAFojf3mNk5df/EZDAOKjSRuxnfk6 DutfGwRjDfVePa7nbKrOhp8/zkjk8RIz/6wEVATlUYS9DHhfuWc4QLDof8rFaW9AN41T 6Pd3UBAsc7jN1aLzbTr3eGnuEhzua8omnruX+7PAcwvbrh661b8HO3GouKEAa/Z20/y6 cMDQ== X-Gm-Message-State: ACrzQf1z28ilAz3Cw4gj/G6XWYvIhTkLeK+Qyto5mNj2zS1TQoV1XacK BgwuIUzEr1yADW26NGpKw/oixApD0nFupzieCIFnCVyJrIo= X-Google-Smtp-Source: AMsMyM4tPRt6g6FeojbCIqbJVgBtdR/NO0I0FbAfYpp1FuSyiTcbt1xrbs3we5eM3p9GGeKHIGdkOBqAjOIRQQv6kFw= X-Received: by 2002:a37:c83:0:b0:6ee:d487:6d25 with SMTP id 125-20020a370c83000000b006eed4876d25mr3367592qkm.670.1666129725760; Tue, 18 Oct 2022 14:48:45 -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> In-Reply-To: From: "H.J. Lu" Date: Tue, 18 Oct 2022 14:48:09 -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=-3018.1 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 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. -- H.J.