From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) by sourceware.org (Postfix) with ESMTPS id 8CA9B3858D3C for ; Mon, 17 Oct 2022 22:37:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8CA9B3858D3C 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-qv1-xf2c.google.com with SMTP id i12so8306016qvs.2 for ; Mon, 17 Oct 2022 15:37:10 -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=+qxGbagTKxeQklis6HvzgzO/WDxH6D+GynHkdsQ9ckE=; b=IKTDLqUu+u8b64v/j1mBrsL4JfJAdcZkqF2FX3ZCGIk3Xy+sej4wBqB752lFgaWqP2 GJdyv4UM+n22Y6UqF7Dg3qveZXqpaZkPDF45rWk68zNRyAXColkvwjHNC68m39LAw1Zj 3bnY2ZILunGF+28THjwxRSVKVMZhtjwYoYbBopS9BkPTS/EtHFN1jtxWvloKRu1x5sKl glwdMqzQItA8mt8uG2aCQlMQhsAi9isW9Z51yR7YdzhATc1JbQ8xCA854/hCXG4UR5Al T5JOmqcm5uK9tJ9l/nghBtZipLe9OjclinaBT2rf/gDSKxjzTbmX7DPrxt/m+fyoC8j0 2u1w== 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=+qxGbagTKxeQklis6HvzgzO/WDxH6D+GynHkdsQ9ckE=; b=71oN4YBTxG1LZ471zVDUXjEt/tbjV8ZqrzRgIeL1sr6lg1r8eU2/qD9onCjjUh1iYk hN2vXLhDaw4ogDHF1d08VYl5D7dQoJyW62eV5/KZbL9uIisoNCZ2OcggXc2lX579Puia /Fp35sb/q4Z5Xm4FQ+E+xeHi3GxG/qNOUE1reTfo9hRhxhuMyoKLCiIqp+hNTjlDEpjE skLdoUiot4UDsZt7w4oMWDegb0McGJawCOGX8qB1Dd+7OIvMwnUbsPT7KDWagT/mdSEE zi/Qfna7TFMUbW5aKdyUmGiXxfoIsHI/3/XGaUMy6R/WWatu1h5vDAeA1RN9Gorre6Zt BUSA== X-Gm-Message-State: ACrzQf0WZ8oJrV8ZiEANhYP9mlO+8CiQDY5lWhJG2UiHVIOy8G/Gql+X 33qw7PiFPrAB91LxFmqjQqWmTA0jJziuCfApc4ku+oMsjVs= X-Google-Smtp-Source: AMsMyM7Z+sSNFGL2jJLuJDfYOfs/pBfu7vYQD1QlZ4NOKW+0gf7Kp6SM46rzNMkF+h+oCu0TDw+iTzedJ2rZxN6ST4U= X-Received: by 2002:a05:6214:c42:b0:4b4:2d1:c752 with SMTP id r2-20020a0562140c4200b004b402d1c752mr10029487qvj.28.1666046229975; Mon, 17 Oct 2022 15:37:09 -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: <8a1fe0ad-d5a3-cdb6-780b-6ac69123a51d@suse.com> From: "H.J. Lu" Date: Mon, 17 Oct 2022 15:36:34 -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.2 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 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. > 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.