From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00072.outbound.protection.outlook.com [40.107.0.72]) by sourceware.org (Postfix) with ESMTPS id CC7213856197 for ; Thu, 20 Oct 2022 10:12:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CC7213856197 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VFFj1qemggDZnNgjseRELoPDwH6S6rJETxbr3/X9mL40sxQWsvu8C1RC+47TZX6g8j34aEW1jDxhKAw0ybr6OtAGK5YjBPc570Ae5DJ5EWRJiqOniOq/FCxWWeYTh2REv9mKWz6SmDgM271MYLk09JpvaYM7UoTmY2Rsku/M9vdPmYPmT+4VTLRCQDgeiPTvm7VyZwA9Gd2Ja+UJBh5re83Tf2Y9MNAhu3LEA8eJepW94spixrArg8uKU6K08sUdwk0Q2+daXnnUVuP8IhFu5PlawQKaU9w6FUWQPXs5GwyJCwivyxF8wktTYirglW1xy97dtT9eBd4rCw/AHCCOdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0pUUGnrlvJ4R+zklRFL2lyASTVO76uZvHb9QGiJmawg=; b=htBBpvCP//BxzV2y3onwLhrBTMaLbSeyqoXsFG0NHEp+YE2hKf4j+9t/oF5auFXHz5WzM3apAnJ/VXAyOgIFqSh/Ru/QXHTZfFOtLi6Z3BkWSVScFAeYGzyWx5zkYNsmvufvKWqOli6kXkM2zuFws+rhk66SkWO2EvCbaEIdM1IEcxqTYbZ1onzEvrLHzl+M3PT9Mno9oPqDrVLeaH9zuX0zoZU3Kfm57wQzkNrDIYzE/Xxq9HU0L7qjEBwSq6qiH24CWiGYi2SAPWi8/CnSO+c5+IM0gJUwUchISP7qK49ZX8gMc1kIKzbUSy8qfgmf/5K69YpUUiTtYnKeC+VRXA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0pUUGnrlvJ4R+zklRFL2lyASTVO76uZvHb9QGiJmawg=; b=CWXKQfbHiJWLCU52Ok1b92izIYGvGP8QaspbBEjHlzDoDI8Fu/NeUGwnbssm/MW4vixhyNYd9B3Ipq+B4ZA70Rqs3MC6rCdhdO8lLciC3CYJucuBf4aeO49qdr7WKnOU+uoFpNMgN4V7/96nnuYc4FtgidGkLNlqbEQZDmA9tz2894chUaMwHuZG7x8UAktemLple3RPnRz+SDVAJJtsfdac6z+/QpjTEWfX4jIj52Igt9LFCcHkc7JmlvuZfvMxRHSVq4iQlMqIc9A9nyl/bixOpnBRJ+KWkt1JWJPrGrP6WSz4DIEtwKdjLLzaDu6RC/qV70qlr5jOyddUzptLqA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com; Received: from VE1PR04MB6560.eurprd04.prod.outlook.com (2603:10a6:803:122::25) by AS8PR04MB7864.eurprd04.prod.outlook.com (2603:10a6:20b:2a4::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5723.30; Thu, 20 Oct 2022 10:12:11 +0000 Received: from VE1PR04MB6560.eurprd04.prod.outlook.com ([fe80::2459:15ae:e6cb:218a]) by VE1PR04MB6560.eurprd04.prod.outlook.com ([fe80::2459:15ae:e6cb:218a%7]) with mapi id 15.20.5723.035; Thu, 20 Oct 2022 10:12:11 +0000 Message-ID: <8198714c-c98c-7632-2549-eb3d557a5afb@suse.com> Date: Thu, 20 Oct 2022 12:12:09 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.3 Subject: Re: [PATCH v3 4/7] x86-64: further re-work insn/suffix recognition to also cover MOVSL Content-Language: en-US To: "H.J. Lu" Cc: Binutils 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> From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: AM5PR0101CA0036.eurprd01.prod.exchangelabs.com (2603:10a6:206:16::49) To VE1PR04MB6560.eurprd04.prod.outlook.com (2603:10a6:803:122::25) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VE1PR04MB6560:EE_|AS8PR04MB7864:EE_ X-MS-Office365-Filtering-Correlation-Id: 498c5a52-e179-492c-dd3f-08dab2838d62 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: bO3kWWC5X6MLOK9stPMGPh3GML8RJoNR3LeEMsuCKNhuRtpM1cmcO9RkrV5HN5g5bKwEztTQnCD3ubR+zq6UwLHDCb6lCz0o8wmN0hUhq84dWadYWA5a3mMrgjLNO05r5SBlEZ3Wjpwy2Vk/ynWR3JRIZ9oc5GYoQJdPvydM8r5D4UOPj7eiXdKv9aYEZmR8B/D+52Oey3nD7VbPDjy7p+XjiLwmooqrkC66O2buT0QPRdUQNSkF/Vwblz9BP3/6e09/RKWfZ0c8Mv3faPw4U8DdgJlwoVhfrS3leZsw6g2H9AR7gWtUoE70H5WGlhtFfidOerE0Qyi2+O094HzkWPLZ6XW/QwHpT6hVrjUaVq8ylHzn0ThLzv4Hb2srMfKwewf/Zwtx9l4U1g6Y92qH4miAuxj6txAZfax69DdH7sZEqi+GON1+gxv2JiTkv64AH+qDlk5hWZAYnd5NiSJm0cSSdDY87+691WPglGVBEBs1cwZrp2H4UArq38lZBPdEGZzwXTDZ96eserW3fu1Zu8If6WhEwz2aadocYSVz7H1eh6wp4mua/A3m0/vtyjL5VUuor8/F45aBRZWZxktQ5RuYlHP8sAw3sSJ3oJKlHvu9aYgz4KqGTlEjbyrpxGjvYHp49vw0iB+WWINnjtErARJjvQpzQtS8MrR+Ag3+W/Rv803kQhmXNFmTOgqj7dllamEeQhBLa2rSiGHeL/2+1uokd/hGruhUrrLDEa+STwzsr9YDckzDQDL6kzKpJ0dng+99kIjW4C72aigxYZFI+tLyOZFoq/r6xTKsjPE5Mck= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR04MB6560.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(136003)(376002)(39860400002)(396003)(366004)(346002)(451199015)(478600001)(86362001)(31696002)(66556008)(66899015)(66946007)(4326008)(8676002)(66476007)(8936002)(41300700001)(316002)(6486002)(6916009)(38100700002)(6512007)(186003)(2616005)(26005)(53546011)(6506007)(83380400001)(31686004)(36756003)(5660300002)(2906002)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UEJvejJGaHNic2FZdDgwN2pkUkxhdDNOeXNRWGw0UW5OMHJOTElTMlZTZU50?= =?utf-8?B?Q2gyVkZKSEJQMFdkQ0JNcjR2ZFhLQ3hBRWJObHZwbDk1OUpxamthdFFkN2JS?= =?utf-8?B?NzVKVzUvQytDcDRBdmd1MHhYNnRoNWZBNWRMUlErYmdDNkdzQTREZytuaFdK?= =?utf-8?B?cHFMZXNoMTZMSStaZHVLNkJGbWlQcmdycWREeEFKOUF1RVFmeThrK09xbXNX?= =?utf-8?B?YisyVGlmVlFMTVJsKzA5NlY0QTc0Q0FscVNLWC9HWDh6dGsxaThzWVdSbUtM?= =?utf-8?B?WUdwYWh4bzJremZJY0tUMTRySXNEeVNOZGJBZ3Z0dmhiZ3Qxb2hnRUZXV2Fk?= =?utf-8?B?N2c1NFV4S2k1TjI4WUxmS3h3NWtva0lVeDBlbVYwd2xXdHdNQ2pacThuWk9t?= =?utf-8?B?cU9NUE5la1BibXNiM0U3TFE2TFFjTVh0V1FCTEsxam1jL2tabkNZd3JzUzQ5?= =?utf-8?B?RDZtSWlSc2c2Tk94YzVXNXlaMlFKSXdrcExWMVNQOVBQYmpLRm84aGh5TlNm?= =?utf-8?B?cTVhcklGUmtHRDZCVENUMlArOWl4UkpIZ0R4SzdDbW44czBHV2cvaXpZRWJS?= =?utf-8?B?VU1aUENDckE4YW41QUNsaEIwYlVWNnBJU1RYWHdJWkR3MHZLOTRlYnFweFNJ?= =?utf-8?B?cHpXUlEwTE5DOHBKUkZiNWU0R1A2bmVZTVpmMDdBSE9nbThybERlVlhpU2w3?= =?utf-8?B?cUNmRFkydnRXZEVxVzB2Tm5TWXhaWkVOR1I4VktkS0pZU0dDemhVNTlsK2tT?= =?utf-8?B?SzNGZERrQ0pRQm96Y3lVaWRQQ3R6WW5aL3NjYVFBRFBuZEY0TkdnSmk5ZWRu?= =?utf-8?B?Nmp5SHR1Z1dLNkZMZTVWaFpQMmpDRTN4ckUwdi8yUFBwTXdBVU40Rk1UT1BX?= =?utf-8?B?aWZsclRrWkNHaDRQZmk4cXNidGdTRVhFSWM2SWdaZ3RTYVdGdTJ0YXFHb0pq?= =?utf-8?B?WWNMM2FQRkJIV2tHVHlLTksyOThvdmo5cm9PeDFLRWRQYU8xcWRBMmUyT2FT?= =?utf-8?B?Wkk3UnVFU08rbmw3ZjROdU9wemZIWVgybGlVem1SdjVhb2ZYZnVsdEpnZjFZ?= =?utf-8?B?L0ZPY05lWjVPaFpGdXAra2dqdExMSnlqNVRSVjNoOWUxUjNNQmJCWXNDQXNt?= =?utf-8?B?Y0NISGpxdmtmRXFtdFNRcU5BRjhYbGkxTHBIdS9ESDJYNnNzVjVZWXhLQWhO?= =?utf-8?B?ZWNTaVBncm5QOUEzc1hxaWp5bGpnKzZIMmIzMWxOSitvMDZFa0R2WkdxbjNl?= =?utf-8?B?elB2M205dVR5NFA0STI2cG9oc0ZwenhodlBtZlZoRHpCdUV0YzhKOUdjaitI?= =?utf-8?B?TitDbEJGT2VVbmdLbml6R0NJUiszbGlucHZmN2JBbEI2QnRpTEF1dUNVNWxT?= =?utf-8?B?MURNR2VLVHJhOFlJbmlBTGdhTUpyY2RhYllpOUVDZkNWb2VITjkzOUltT2Nw?= =?utf-8?B?b0R0KzFudlFnWXUyVGpsVHVFTndtQ0U5cWJJelFWSG1zMmN4WS9wdzV0dnln?= =?utf-8?B?ek41MUlVQzc5V2J1NkJKenpvblhYSDVaMENzY0swNGUxSGVzRmVqWE1yamJL?= =?utf-8?B?S3gwZlFZSGFKeFAveHdjUytBK2RrOExKWHlqem5uZFhSVnphRkFTampvcnlO?= =?utf-8?B?VE1WWWp5YllLVVBPVDlsazd1SVRmQmx0ajJxWU9VU0xwd3ZRWERmd1g0WWNa?= =?utf-8?B?Nng0UWxaZVNYaGxEWVdhSTczTTBXbUtUQnR6NTdIV2xCZzVCbTNsSGpDTTQy?= =?utf-8?B?dGdZK3pJaHQxODlacGRwZXE1U1FLVnBpWklEVHI4azFyM2hPanZPVmtHVW1R?= =?utf-8?B?WmQydWc0UUNNN2ZtSWovQXdGUyt1c0xiUTBaMG5hK2dHdGRwVXFKWW5SQWVW?= =?utf-8?B?WXhFOFU4MTdwdUgwWURvb25KMHhrcUczTHYzUG9hMURGQU5uczZ1VkxZRmQ4?= =?utf-8?B?TWZYaUYwM2lXbGZ4SkhLY2J5MUp4eEcrWk9uYStLMDRZUGNROTl1aXhQc1Nq?= =?utf-8?B?VnZCT3NJL0JxWjVsbk1mSmVGTnFsMDRqU0VVZnVjZWRXc0xWbUVIOUVaMzVm?= =?utf-8?B?VURtZitPYytuQ0xxYlc5OWpTTi94NmNrUmZOcEhaWjJCTldNcnVaQTBDMFhw?= =?utf-8?Q?ErKclH097GGVDhc32zBf+QgoA?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 498c5a52-e179-492c-dd3f-08dab2838d62 X-MS-Exchange-CrossTenant-AuthSource: VE1PR04MB6560.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2022 10:12:11.1216 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: CwE6ZbldCCntmwevtbWt9sW6hBNQBSSNWuRa4WmBX3KbsbqsWVK++IatnhxwJopZWpfIp0JE20DKH8iEwwx8bA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR04MB7864 X-Spam-Status: No, score=-3029.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,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 19.10.2022 23:46, H.J. Lu wrote: > 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. As said - I'll put those in a separate patch at the end of the series. Not the least because you'll be a little disappointed: The changes to tc-i386.c simply need to move to another patch then. Hence there's not going to be much left to make move-with-sign-extend consistent in that final patch (most of it is then testsuite adjustments/additions). Jan