From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2052.outbound.protection.outlook.com [40.107.20.52]) by sourceware.org (Postfix) with ESMTPS id D4CA33858428 for ; Wed, 7 Sep 2022 07:17:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D4CA33858428 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=ECS7s7qqYq2TABaMjoiP2J4QGQeYaQW6ptIBIasZP4K/kUet5yho8X6T0OtqtixkOW3qYa+Eb/NLjn4wD/Bg7Jc4Vf15ziOpfR+8+X1lSE79XUMmsuBAv8YWO2z+0yFBmt3zgnEUz69JY6GI8KWUQNWxQ1uI1fYMMBfR4Pwpp0e0j2AYw+7eBpbKMAowb9zuPlqywArEiTRZcB/iN9Jyj7HI4yPL6+kRP5V/61rLGOoj6cWocNrL2fV5rhIpTX5Ix4ux0HP4cM4cNtPvM7qo4rLS1ewwrMZC/d1QYsNPqY/7HZD+aF3E1mza5tCtc//URi4nkzp0YS5c/XweRnkm5Q== 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=Qg0B6weJr6uDSkUSWU8DYtggbwXCJLwxFeJGNkVMTSA=; b=lDD0ONlVqu4toQvtZbK7z6OmXENGwQSlATx7iVy76Vb7M01YHpqb0Saf+YC6KvCkURupOvbZlLBKUB2pugMA7zuq+NHdztA/t0HU5gCL3+azhyMbweyhTFMta2OShtb4aUgAN60QnXirqOqibuiuuyHtwWa81Y5iN9MH7gCGXmUcWum01TsVzjnNNGmxr5plQg0KH0N89lg68Y4QwHMGTlNN/MOo6uJ0JYgoJ0iPXsgHtR+8iyi6qOuDDRoMZ1TPhMfQJFsqsfaMLVJgSaLAz8pZ7Hn7jJebwOV7inZ7AjlC5Di69T+2T70VDmz62BYFGmuBCmNUcrZjL8yabQjuQQ== 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=Qg0B6weJr6uDSkUSWU8DYtggbwXCJLwxFeJGNkVMTSA=; b=ivPtWClubPfJeyKPi3DgMPjeuPkVrNwc6JCl0rc9YfGF4iYqOYtgIsY0NJWYIvGya/mM7UBzQriUQLjRDDFKKD+VcH8hAOzW0VEJNnwOfQxh1/ydnp3pbgHxqJ04/2/wdDw1+bd6PVGM2Bla/Tg+ri9fmIRgS1Cn/qhqxbpTe+0VqvsMQZwewF+ZULLYqJxsARhgMUAjaAnrpQvjJEAZbtkq8a5y1q3a1omwkE4HxmzE4JJF440rrpNqYlUFFsdeiw4ppsIQO9dcW8mh/zcN7O+70KnW0k0B6eEQCnI7JHQELkXu1H+evYW3hyA41CKD5KdmngKcBb/6Bc1ihUh1iw== 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 PA4PR04MB9223.eurprd04.prod.outlook.com (2603:10a6:102:2a2::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5588.18; Wed, 7 Sep 2022 07:17:57 +0000 Received: from VE1PR04MB6560.eurprd04.prod.outlook.com ([fe80::59bc:901a:98a7:76d4]) by VE1PR04MB6560.eurprd04.prod.outlook.com ([fe80::59bc:901a:98a7:76d4%5]) with mapi id 15.20.5612.014; Wed, 7 Sep 2022 07:17:56 +0000 Message-ID: <892afda8-0e6a-cc7c-df95-f5581e831fff@suse.com> Date: Wed, 7 Sep 2022 09:17:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Subject: Re: [PATCH 5/7] x86: re-work insn/suffix recognition Content-Language: en-US To: "H.J. Lu" Cc: Binutils , Nick Clifton References: <32216291-fd1f-4579-87de-d24cb7190894@suse.com> <995353db-27f3-ea60-8e69-32bcc44dfd49@suse.com> <162c053b-7c68-67b8-1443-926f2ebb321d@suse.com> From: Jan Beulich In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR3P281CA0049.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:4a::22) To VE1PR04MB6560.eurprd04.prod.outlook.com (2603:10a6:803:122::25) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VE1PR04MB6560:EE_|PA4PR04MB9223:EE_ X-MS-Office365-Filtering-Correlation-Id: 4486666b-8289-41e3-2617-08da90a1163e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: fUD8L8e6VqsLBxWgMApuo5c+Udnct+HW7TAYnFR71JjPz9KpCmpdYyCwIGwh/UASs7asDsxKbfc6Zi1xR7o7hdCYoKfvQjVYCKcY4wzWiJZ0yjXcTBSUXmkuPrsfgWmDyqFSg9ZYplSiPyN54eKcL5scT/pnguuqOhU9FFGg9wm9Oo2R0cHqnL8k4EWqXD+YjPkWZAorrTw9jz7/79qBPLaSABxZo9F1Ic8PUoBtWoLEK0T+yHgWZfvQBgd0cEz6sQ41DqgvbFbxxswGUQpvm1/U7g0z9ef6TBMGew1jADd/M0Rc1VhtH4u/t/mX8s8+H8/NVeLxF7LMPugh/RiMhaRqKTxCbt++FnS+G4ouLsNAgWhb6g1cCSmZZWjzB2LVMvwv2Cqa98EfRSFII7MfNR+eWJXjWf3FeTkotUXv2byb7PbFRMBwsViEmCgCOcrVy2GkTfkvUP76yOrb6z2JQNVZZB/fX6VjGKx5cDNMNMkHnsXMIPxhObg5RW/ekbykhglcJzv/51rUs+/wmyqjnER/xkDtkw8PR3LkmrOMtH51Qox/IHvQiVW3icghIKTSOFiGfxRrqAuGwzSAGZyS4nP8ArpYiBSv0mtgnbZibb2CR0HhX+b3XWodcd0p+0iwrOtC34hl8imwujlfIm2JNVMJ09ptpIhTQYdGJiLidjCJR8ZG4rjh8cWpMwaWOxyd46n+X7MnJzM4mlpOTlmq5IOQcwXDDitLwk7+Oqe8psvfsHlSqoSkvqfE7wZOKEQybmgazJtGqIINTggD2rIU/HndFJPO7aY4ONLWRIlmfH0= 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:(13230016)(136003)(39860400002)(396003)(366004)(346002)(376002)(83380400001)(31686004)(6916009)(26005)(6506007)(6512007)(53546011)(54906003)(31696002)(36756003)(478600001)(8936002)(5660300002)(86362001)(2906002)(4326008)(66476007)(8676002)(66946007)(316002)(66556008)(186003)(41300700001)(6486002)(2616005)(38100700002)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bFIyRGRYSW14N1h3Tk5vQ2VacFh0OERiVlE1VE9HOXNxQlpsd1ZPNHI5UEVZ?= =?utf-8?B?NjNlaW0wc00vQ0R3Ym1Icm5FSG1WUzFtalpRSnVrdlc4aUFDM2JXYW12Z2Z2?= =?utf-8?B?U25SZ20rMUpUeHhjRFVoY3J2NzRTZnBFUy9TY1NnREFuSm8vVVowVUhzbkE2?= =?utf-8?B?UDRVSFIwbHVsQVdrS3NtelByeFhOUkZUMzZLVjNGUjRUSjNJYmRWWThBZnJM?= =?utf-8?B?bkU4Y3ZtOGw4Yyt5a1pVTjE3b1JsWjJ1aldVQnJQUEQwNWRONmJoT0cwbmdW?= =?utf-8?B?NlJ4Z2pIMzYxWTNWUXBraFhuRC9OaFo1MTNTZG5Dam9jamFUT0ZNVlhPRVRN?= =?utf-8?B?bkJGdmwvNVRTdlg0RVZPQVhGUFRvNytiVitWL0duNjJpVXM1L3d1dUViNmRB?= =?utf-8?B?UXB5YkE2K1dqK1crVXJXMW9jU0RWdFlpcTRUdkltU0dCcXhIay96TzJvdzYw?= =?utf-8?B?bjczdEZ2ekRSZ0VNT2ZIYWorME1BWWZxNldvNmtBbEdKbFhDa1RBYUptQk1y?= =?utf-8?B?SGwyRjZ1enF6cmVHd1pUN2J4L0RiK1U0SzRNSy9IanlNZk82N241TVAzeDZu?= =?utf-8?B?UTFEcVlLNCsxQXRwNGtxamVmM09ITXQxSGRzZW9SWkxEYWRDdGcvTjJhRXBj?= =?utf-8?B?VEZlLzIrdDIyNVNRZHlDMGFVckZXNlpWZURMMmN6UzZqa1JrdHBGWXE5ekMx?= =?utf-8?B?OVRYNENuSWxuM1RjR1RqRkpRTlFmd2RiK0tmWjRKSFh3K1pPVlFHYWs5bG5C?= =?utf-8?B?dGtQcmh2VmU0VXplb1ZnbHJ1em1EZWVLSThnN3dEV01UMm5lTnF0eTlxTmQv?= =?utf-8?B?WVhoaThEa1dzTkZhdjduNlVQd1g1WEVlbEJCT3R3ak8rMks3QTZ5bDBGWFVq?= =?utf-8?B?R1RDTi9HN1ZYNE9BWHhyNHhqY1hkV1ZoNW9pejhib1QvT01KMnVlNjhwbTVj?= =?utf-8?B?a1J2NHl0Q2RtNVdyQ1RGNm4zc1NIc2NZRnk5ZUM2TDlXcmFiK2tGK3BESXV4?= =?utf-8?B?N20zQ1VrRWtTWWVqSVRiYTFWMk8wTGpWaDhzbGExUEs2Z2FRRVMydkg0dk4y?= =?utf-8?B?NGl2V0NvNStXaE8xQjdhaGZmajMxaDc1RzBsbmorMU02a3o2R2diUmgzQkJ2?= =?utf-8?B?ODgwbzhOS09QVHhscG9KeVNTeUFQRWdEWGhLZTlVTmtsdkZmMFRPY1dNdjZr?= =?utf-8?B?aVRzY3QyMStYbDNvZ2VtNHhPTXNFMXNwZzNiNTdUeHIwWEt6WWNRUkRUTmxW?= =?utf-8?B?MHo1SlBmWHZxMFlpSnlqeVpKV2F0bGo3YzVIU2VvdjFGSUZyZTl5WU9Td0RW?= =?utf-8?B?WXU4MjJUNkRqb0d0b1VvSFFUaXNjclBwckhYbGVZVzJzTTJ4M3RNeTFRUk9B?= =?utf-8?B?cEhENG5VWkNvOTJXSnhwMmJKWmJkR3dHOU0yVi9rWjNkQ05ObTFSSnorYnlH?= =?utf-8?B?Wm11MHJyU3NBZlNmVFdPcEhGcEl4dGJTNHR3OGpyN3E0N1ZEeXdRKzQydTBN?= =?utf-8?B?bFAvcFdnOEVCWXlaSVJKUWVjMFRzRzhGWUZIYUlDcTEvTGlZVVBzL3V0NnJV?= =?utf-8?B?VXpwRmtRaWptVWlDVkhEdmtnbTgwMkhOWWpaei9ZdTVoUmhHdWtOT0tIc3JR?= =?utf-8?B?TEpEWndOb1VDMkNFM1ZtbDc5dEhNQnQ1VHU5UUFWMHNEdjc0TWtkUVhheiti?= =?utf-8?B?YmhORSt6bmdtc09ISVF0c0toZzBmUmxvdldqbmllYUQ3Z3dRTklIME1Bb2N1?= =?utf-8?B?RUdxaWlkK1Q3YmFCdGZjVU5hUEJrY3BYV2lMa2Rla2FFSmhsbGR1YXhoVlli?= =?utf-8?B?UFdIdzE1MVZPaE5RMGNBL2RBcFF4R2pvMmxHR2ZDTXhBN0UyNHh4UG10Zy9s?= =?utf-8?B?VjNIT1RCR3laTk9jOVd2anZaNzRqZVJPblRibkw2UVYvWUx0MGJ6YnNFdzBM?= =?utf-8?B?WUkyVDVOWi92eVZRYjJ5dDNGWHYzTnBiajlNSFJZOHpEOE5FSHhQSmhMa1Vk?= =?utf-8?B?NDJTaERZY3U2YzRIckV6d0kwUkVpWm9pSExWbVZNNmc5ejMrQko2L1FTN1pz?= =?utf-8?B?SldNbjhEZVVDeFg5ZlRUUXFLMzRuSnhKRWpWb2VVb25tZy9MSWhXV005Um5L?= =?utf-8?Q?GRXXPPS6XSlE0w+nVq+kb/S8L?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4486666b-8289-41e3-2617-08da90a1163e X-MS-Exchange-CrossTenant-AuthSource: VE1PR04MB6560.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Sep 2022 07:17:56.5215 (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: e95K57nrNpNa39mRjiceHjBL83woF+giz9kKm9fVKKlKbQBaFnlsg4/3HszDFaWCW+XqAOL25zZsQCVvK2sNWA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR04MB9223 X-Spam-Status: No, score=-3032.2 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,T_SCC_BODY_TEXT_LINE 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 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. Jan