From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) by sourceware.org (Postfix) with ESMTPS id 08ED03858D37 for ; Mon, 26 Sep 2022 23:53:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 08ED03858D37 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-x831.google.com with SMTP id a20so5119973qtw.10 for ; Mon, 26 Sep 2022 16:53:36 -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; bh=8LeGDv9b50+SKDy1qEg1POmRp7fN8Z72PavnAVJOl2Y=; b=mJkcE0JxK36BEPt7QJrZiMr07VbrgsNBnUh7d+9lRt5vYx9be3JzHjr4vzUxwMKdV6 gt5/pNKGbu8YqZvxvGK3fBFofDvYWv5tFYuyaZsJYhRM4Tl6Rxyk8P05Z+27Psuv8eVA 7njeNnF39J2CMcia9unppIvJBEk8T2x1wmrXUP9/SQJWO5uK2xxUc4XCH28ISLoSezLM KUvONZQL4vPqis2YvY1+9+NbPVQM4rmj9Nuke0MSQZLsCSHDmy55XZo8Byf4JHPKpKkS /+dx0WhOkQbjvfx6+QTGN2bFKr30CrJxy6Mbjjv6tr40VKF0dK6CrMecaBm+AF8tJKnQ pq/A== 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; bh=8LeGDv9b50+SKDy1qEg1POmRp7fN8Z72PavnAVJOl2Y=; b=mqPoUZ6F2nVZMVT2hsnROT7ANt/U5/6zcVfnxDDOjiGOtDxrd9yJ//Tdrfn2YXpjZd DOVNmnL/3Ib/LCIaSD8PDQz0SgMOx3Zi8ZE7jEpClzun5kQJY6l7eh0/zZxagLTQ6XBE hd7mgaItw7Ad4gZnbE3Y4cb3mB+MqeuB8k0pcSesoBK5crXA3FAdSrWVI6MyVuClqwaX OcyS7+H6/VEq1W4T4oUbR/GXNO3eIIbcZDRl6j7I8o253UKT3AlMnP6KvLSvXTCb3jIx Ktci2ZnQNk9xquKnELJNPxU2JHSjPIdzZltS7M1tGAvVcwEkkj+YXPBEs6O2opS+xjAW gWZQ== X-Gm-Message-State: ACrzQf2A5uS7WKg89+P2Nnqny1eYV9IFeJ0E4Ss8L3F5k5zM40zW4JHT WubKStmaUEB/qoz64pXlT777kM9O0PCrBAnj3mE= X-Google-Smtp-Source: AMsMyM50HWKApEJScpFGvmy6JMk7WTJ3x3The3JgtpodLlGcyeEUU0YQ0UKCwk+I7wpTTBHZ2BXYnDpwVEjeXLpg348= X-Received: by 2002:ac8:5f09:0:b0:35c:bf70:6a63 with SMTP id x9-20020ac85f09000000b0035cbf706a63mr20329087qta.500.1664236415347; Mon, 26 Sep 2022 16:53:35 -0700 (PDT) MIME-Version: 1.0 References: <32216291-fd1f-4579-87de-d24cb7190894@suse.com> <995353db-27f3-ea60-8e69-32bcc44dfd49@suse.com> <162c053b-7c68-67b8-1443-926f2ebb321d@suse.com> <892afda8-0e6a-cc7c-df95-f5581e831fff@suse.com> In-Reply-To: <892afda8-0e6a-cc7c-df95-f5581e831fff@suse.com> From: "H.J. Lu" Date: Mon, 26 Sep 2022 16:52:59 -0700 Message-ID: Subject: Re: [PATCH 5/7] x86: re-work insn/suffix recognition To: Jan Beulich Cc: Binutils , Nick Clifton Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3018.4 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 Wed, Sep 7, 2022 at 12:17 AM Jan Beulich wrote: > > On 06.09.2022 23:53, H.J. Lu wrote: > > On Mon, Sep 5, 2022 at 11:40 PM Jan Beulich wrote: > >> > >> On 26.08.2022 20:46, H.J. Lu wrote: > >>> On Fri, Aug 26, 2022 at 2:26 AM Jan Beulich wrote: > >>>> > >>>> On 23.08.2022 04:00, H.J. Lu wrote: > >>>>> On Fri, Aug 19, 2022 at 1:28 AM Jan Beulich wrote: > >>>>>> > >>>>>> On 18.08.2022 17:14, H.J. Lu wrote: > >>>>>>> On Wed, Aug 17, 2022 at 11:24 PM Jan Beulich wrote: > >>>>>>>> > >>>>>>>> On 17.08.2022 22:29, H.J. Lu wrote: > >>>>>>>>> On Tue, Aug 16, 2022 at 12:32 AM Jan Beulich wrote: > >>>>>>>>>> > >>>>>>>>>> x86: re-work insn/suffix recognition > >>>>>>>>>> > >>>>>>>>>> Having templates with a suffix explicitly present has always been > >>>>>>>>>> quirky. Introduce a 2nd matching pass in case the 1st one couldn't find > >>>>>>>>> > >>>>>>>>> I don't like the second pass. What problem does it solve? > >>>>>>>> > >>>>>>>> It addresses the reasons we have various pretty odd (and confusing by > >>>>>>>> their mere presence) insn templates which better would never have been > >>>>>>>> there. If you have a better suggestion to eliminate those, I'm all ears. > >>>>>>>> > >>>>>>>> You can also easily see the issues this solves by looking at the > >>>>>>>> testsuite changes. Among other things this once again is a matter of > >>>>>>>> providing consistent and hence predictable behavior. > >>>>>>> > >>>>>>> Did you mean the error reporting behavior? I don't think we should add > >>>>>>> a second pass just for it. > >>>>>> > >>>>>> No. Certain insns simply were not accepted previously (this is actually > >>>>>> what finally made me think of a solution here; prior observations > >>>>>> weren't severe enough to try to get past your possible opposition which > >>>>>> was to be expected based on past discussions). And certain other ones > >>>>>> were wrongly accepted. > >>>>> > >>>>> Please open bug reports for these cases. > >>>> > >>>> PR gas/29524 > >>>> PR gas/29525 > >>>> PR gas/29526 > >>>> > >>>> But really - what's the point of making me waste time on creating bug > >>>> reports when fixes are already available? > >>> > >>> I don't see them as real issues and we shouldn't make assembler > >>> more complex because of them. > >> > >> I sincerely disagree. As said many times - first and foremost the assembler > >> should behave _consistently_. People should be able to predict behavior for > >> one insn by knowing what the behavior is for sufficiently similar insns, > >> without - as is the case twice here - having to further consider anomalies > >> resulting from _dissimilar_ insns. > > > > Assembler should be consistent with x86 SDM and the existing usage. > > Due to the history/nature of AT&T syntax and x86 instructions, there are > > existing inconsistencies. I don't think we should issue a warning for cmpsd. > > It is inconsistent with the 'd' suffix instead of 'l'. But it is > > consistent with SDM. > > What I'd like to see in mnemonics: > > > > 1. They are as close to SDM as possible. > > I.e. you want to add support for SCASD and alike? I doubt that was ever > intended with AT&T syntax; instead divergence from Intel documentation > was intentional from all I can tell. > > > 2. Allow prefix when there is an ambiguity. > > 3. Intel syntax shouldn't depend on prefixes > > DYM "suffix" instead of "prefix" in these two? Assuming so, for 2) it > ought to be "require", not "allow", and for 3) you certainly mean to > allow for exceptions where the SDM has such (e.g. IRETD) or implies > such (e.g. RETD) for there not being other ways to express operand > size (within SDM nomenclature). > > As to IRETD - note how the SDM unhelpfully implies IRET to mean IRETW. > We can't follow that doc to the word because of its own inconsistencies > and/or shortcomings. > Sorry for the delay. I was on vacation. My main concern is to call strdup and free for each instruction. I prefer to add new entries to deal with rare cases instead of penalizing all instructions. -- H.J.