From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2044.outbound.protection.outlook.com [40.107.20.44]) by sourceware.org (Postfix) with ESMTPS id 2D8103858C5F for ; Fri, 3 Feb 2023 11:39:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2D8103858C5F 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=VbcnTcsCcIP/lN0JZiryU4VtArcOAwOvtMZN+cw2miYJwfH9Y0qbz68kBPB3AXvRFFKK/715ELJmceTOVomGX/ryR9MGDvO3rh+KU1kI5QyFkPekHnKfIU7NESwkMRPzvs/fmgOeLHFKbkqfXLPu37f81/GCUTNUXvrvvmghnFBBQh5eOh52bhjfOitsVKWL1OIpJvNIWTXjKSwPrUeX3DFivy5pcaLRR44lCKLL+lLx0gMb0IWp0mSAmwkCPdt9NzZboD9v0CADz9OtsL1hMP9ChsAvGceck3VMtdGptu0Pyt2hw3K3prSoBiMqZE2T4rQ7zAUpX/0RHEwABmPZIA== 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=hwKfAiTyQib5T3erm0v+c3/TkonyWQmU7cBTlrNs9kY=; b=UhbanPXVzY7Dtqvvtv9UFZIXLZEyjK3MIWes+syvIxe5jhzKIU9twWozj9aXsjlmJzI/qrX8WbnWKpY1DzRBjvq33xmaUgXmd89zG3YEGOYBTcZg7yCktHQyS7Oi8zGXrq/6XwAU6WMHjxXnfccHZyo36TWkzVhiygKYMsaNd05jNW5kF51KNp9nRwAk4xv5MlDe6C9HJJlUFNW+0a/tYnujz3iug0Iur+udYhour7mMo2D6HRk97pSp5BRap70cnswZ3kJkQfxgcNnJPkWUPACbDJ/YxeLVmmdFe9laEAlnV9NEGRbnj6lWYH6d5pXUt0rZ5SOVyaoANNv/mf/3eg== 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=hwKfAiTyQib5T3erm0v+c3/TkonyWQmU7cBTlrNs9kY=; b=uklMNBgVTbfXEIW6nd3Emgx26dSicUPM3lH6FGDH7LFr425EaggWW+PxEfRHs1nInFD4ELMynajs8HuCGilyQNNGC9AMxz5ntHDh7sBOxDM1R76ofVMG2cHzLRFUf8QjRuavq4NPYyKtO/Eo8Z6rhclghPKKUHZQA77IbWXlPug60yLeVF6s+fdUIZR7F1P0KM5H7j/7Ioa+MHfxFskt2n3Z6qgyk/5qmF/3KDhmJ1GN0JXaGdqaSgHz9kULj0Y6brB+JRvNH+bVXq0RdMSYgXLLD4AX8xXw9F+il7k7c16KYVha7meQE+OW53lGtlw/nUoW3P3Gj/BCroLG00ZUJQ== 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 AM9PR04MB7668.eurprd04.prod.outlook.com (2603:10a6:20b:2dd::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6064.24; Fri, 3 Feb 2023 11:39:42 +0000 Received: from VE1PR04MB6560.eurprd04.prod.outlook.com ([fe80::e138:4fc3:705c:d178]) by VE1PR04MB6560.eurprd04.prod.outlook.com ([fe80::e138:4fc3:705c:d178%6]) with mapi id 15.20.6064.024; Fri, 3 Feb 2023 11:39:42 +0000 Message-ID: <05989195-cca9-f334-4287-a1bdbadf0352@suse.com> Date: Fri, 3 Feb 2023 12:39:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [RFC] x86: proposal for a new .insn directive Content-Language: en-US To: Binutils Cc: "H.J. Lu" , "Jiang, Haochen" References: <7166b647-c3a3-6103-c4d2-7c59a1520518@suse.com> From: Jan Beulich In-Reply-To: <7166b647-c3a3-6103-c4d2-7c59a1520518@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR2P281CA0103.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:9c::13) To VE1PR04MB6560.eurprd04.prod.outlook.com (2603:10a6:803:122::25) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VE1PR04MB6560:EE_|AM9PR04MB7668:EE_ X-MS-Office365-Filtering-Correlation-Id: 55f62054-047a-4780-7979-08db05db56fc X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: zjtOXJ9/zjzCeIr5KvcLl799XSdRWMlpScF8SDtK/Lfbji+GVBxE2/p3WqqJiDhCzl51mAFsBzthMJzIXgHbnq2mZtobqxKKjopUzZxYPupGMJJwdGXVGjjOB876dZdIpcX3fyulwFOOUWFqFgUdKuV8p8XWjWOFu5O40tzOhvuMiORIws1V6O5yKz5f1pcmmh1tG5dEBGXTNyKPpyHOiST2Y/IxcRV87k+TYScnYlkU5zdpovo6Dn2x30y1bdZv6fDGtiMGZNgpHSnSKccl5nMu8RJw0mtTMasmAjv/u6fu/BAEawtOoiGGKFbpaBSxjhxSRpPZPHZkvEt3bQmG0suzNUDknyzvnoUYD+B1Qs3rcyUNqIO8+l6eI/3J2KYWYCAVkJ9lrs694t2vqb7U9se8//lK04O0UofXmHwfUtWpwDAYo8OfHEy+0zPBIWPDwjIawfSuZMTnV6FiY/qE+FBI94QKn6lsfAJCGYsG4E8fvTc/GD3xnFNnYebE8/SuLYWIC56N4UXwD9KnfRuN30WQNJHnisugUOH+Qn+si+Iz3spTaMfrWKhaJvauAifYExG3JlasNXy2f6CjXx1Day1zpcen1zsVeIIvKpoKlgF8fMAMLO8oRoOKI8zSB1YHci7iw/OeQyOIP2jnCaczg1GO+mKM9DttTwAD+50MY7rQlvmVZeaaBXwYPjjCxqb2XaJUSnp3SAYmITLVF+KWKP9/Ynxh5nd/dBxSWF4ifKetFOpA7LfVBYbAo0khSIoHk4xnqlDqnSMXgQt1ypBaug== 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:(13230025)(39860400002)(136003)(366004)(396003)(376002)(346002)(451199018)(316002)(54906003)(2906002)(53546011)(6506007)(6486002)(478600001)(66899018)(41300700001)(8936002)(66946007)(66556008)(66476007)(6916009)(5660300002)(8676002)(4326008)(2616005)(83380400001)(36756003)(38100700002)(31696002)(86362001)(31686004)(26005)(186003)(6512007)(142923001)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NnhQV1lMRWZ3SEk5NmVCOTQrb1dGcFhzV1FyaXRzcUsvK3E4Nitja3NKL09j?= =?utf-8?B?UGRmdVg5NzhYOGRBUlVtUkdDYlUvdDRVRTBWZXdZM3ovRnZwRGF6cWU1eW9K?= =?utf-8?B?M2RRVGoyeVdiZ0FlRXMxUFJlM1ljditCZ05ZYzFRUnB2dHNlTm9BeWdDSEVq?= =?utf-8?B?cWhGbktrZFFseDNOajNWaG9pLy8zU09vOWpSelZwZTFzNDhYUkx3VmtBSXVB?= =?utf-8?B?RzNoSUUxbzIvOVZ3VjJ6dVVuS3NFeEEyczdwTE5RMTdIS2FGTEtxRUpTU1I2?= =?utf-8?B?Y0pTbXAvZFBDYy9sdTlCaFkyZXBSSFRFVHUyOVVCUVVPUHRTZnE4Q2Z4Z3Ix?= =?utf-8?B?ekppbzhGMHZHamNUdEt3ZFFrL0FFZjhCbHZqYjRWQncybEFmVnBGWXN4SzFh?= =?utf-8?B?eG1MeFgxMHVRbzdZZVNuYlMzTVBhbVh4dVF5M2ZES2ZwU0Q5MCs1RzBmcHhL?= =?utf-8?B?VEIwOVR0ampRak5IVEV0eS9jNzhpdjk3dVhoNzQ5MkpnREZ3YUE0anZqODd2?= =?utf-8?B?dmNNMHZlbllESnF5SXFaTGZ5aDByR1REbmloL1pyV3F1ZUxjclovWWdtOWd2?= =?utf-8?B?TWFlREUyaUJaWEpKYmt1U2lXRmVrQTh3ZXRMMXIxOFVFNTlkWEZvZmJ3S2dP?= =?utf-8?B?eDh2ZDlrNDNqM01hY2ZqQndTaEd3USsyZDcrcnAxbW14bUw3Y05yaktaTWlm?= =?utf-8?B?cUl0NnF1OWV0ays0Mk1PSnQydi9FeGtGUjJUY291dHhLYURJeEFIVHdTd1Zx?= =?utf-8?B?aUZMemgrMUx1dGd2a3h1dnV3aE5Gb3kzYTc2OWhuMytFb0pWR0pGbkx3RkhP?= =?utf-8?B?dEM4T1J5RGpGeG43R0FTUGJjc0JxQmlpSmtad0g0N0ZyRG9nNU1Hc1R5MFlU?= =?utf-8?B?ZmlwMVBQSXpVbXJtdnVrM002ZHQxbVQ5Y0Z2Q1hUM1lkWU5taVptQ09lTnV5?= =?utf-8?B?TVNLamlnRU9nYTMyUWt0bXpqdDlsK0dIZmRCRitUUDlWMFd2NjAwTXg1eXB2?= =?utf-8?B?aHNDNWZLZEFQNkpiSnQ5ckdyeTNZUG4wTFJoQk9XcFJ3QStKc3EyeGFJdHBo?= =?utf-8?B?Zm80OTRNdy9rcDIvTEQvaHpRa2FUQ2xvQW5ZZUdsbUJyaTl0SU9wVE82cmFG?= =?utf-8?B?UGpGUGZPVlg5Z0txeVE0S1lqazlQY1Yxb0d4NldRc1VvTUVyZmNzZllGOENX?= =?utf-8?B?bnluWlc1VEtkdmVrWVpTTi9mQWVNSGFTNW1CeFlQRG5FbFRCeEV6SmNmQ1ll?= =?utf-8?B?VS91VnRHM3IzUkhEaFE2QmFMTnFZL1lDY20yUWNlYnJqelcrWVdYSjZHNEVp?= =?utf-8?B?eTBsUmRzVXMyU1dIbXlEdDZjODY4NW43SXl3ZXpvWWs5WDRra0FTcERCdm55?= =?utf-8?B?alFVMzJvYUJFKzdUTUZldXIwbTV6aEpIQ2FzL2lhbjI5MW5nbkdoUVo1bHpN?= =?utf-8?B?dXZzYVE5MTNlNzhVVmNYcVJweTdSRzZFYzNNVE1CRHFyNVpleFQ1andDMDcy?= =?utf-8?B?YS9xbkg1a0hhSzZOSEFKSUpDWmE0N05JcUtKTkJvUitXSjF4VFFXTmtWWC9G?= =?utf-8?B?a2FwSy9HVWd6TlhSRHc1R2htUHh5VkozUHJQRFAwSTN6a0FUTmt0cG0ySDEw?= =?utf-8?B?akFJVnNSNlpFME1ad05YMERQRGh4RGZ4WlBvWWJSaFVHNU5UN0M5Skc2Visw?= =?utf-8?B?QWNSbkcvam52YkpPdzVSNHg4YnJHSlA3WWc0THZsWWZiUktwK0NaTHpJMFRk?= =?utf-8?B?YmVzM3BIZDZKRk9XTllPUkQ4cnkwUnlyZjB6b0g5L3ZkSHY5WTJ2bU1JRTVl?= =?utf-8?B?UDJndGx2VWwxanNIUlFobCtqQTFweE4vV1FDVHNZSEV1MjFyK1doM0pFUXlZ?= =?utf-8?B?alFrSGpXZU83Vmg0RkFUbVlXT0drNXlIVGppUm85d3M3K2lXZXVoVitjQVlv?= =?utf-8?B?M05jbE9MV3dOdGhUQWdhK21kOE42NzRQTzNlL0JGUnl0SWpyNktJZzVzV1NZ?= =?utf-8?B?YzJ2MVRObGtSVkFDREFXNGo1Y1Fhc3VqU2d0anJYbnV6Z1pYU0V2aUR4NEZ0?= =?utf-8?B?SzhrcEZVVzZVRHJzaWVTY05VTDRJR0tCaCtvZXd0SlAwUjEzTGhsbG5FTXhi?= =?utf-8?Q?xa3ptK3MF0qAd6MKOdkrMM42f?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 55f62054-047a-4780-7979-08db05db56fc X-MS-Exchange-CrossTenant-AuthSource: VE1PR04MB6560.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Feb 2023 11:39:42.1389 (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: Lyh8Zp+aXYl4ospLUo4r6pBn7uLcNvPxsQzgjTEbma1RWkgHL5lt7je5XsiDT/JEEXX8DrW4cahnWcIQ2xQR5Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR04MB7668 X-Spam-Status: No, score=-3028.6 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 13.01.2023 12:58, Jan Beulich via Binutils wrote: > certain other architectures (Arm, RISC-V) have such, and x86 would imo > benefit from such even more: It is notoriously difficult to encode new > insns with operands which a certain version of gas doesn't support yet. > This is in particular related to the building of the ModR/M and SIB > bytes as well the VEX/XOP/EVEX prefixes. > > I would appreciate feedback on the proposal (in form of an assembly > source file, providing examples at the same time). Besides pointing > out issues / oversights, thoughts on the various TBDs would be helpful. Some updates below, resulting from first steps taken. (There are other more mechanical ones, which will be covered by the doc addition yet to be written.) > # .insn [] [] [+r|/] [,[,...]] > > # Legacy encoding prefixes altering encoding space (0x0f, 0x0f38, 0x0f3a) > # have to be specified as high byte(s) of . This also extends > # to certain FPU opcodes or sub-spaces like that of major opcode 0x0f01. > > # Legacy encoding prefixes altering meaning (0x66, 0xF2, 0xF3) may be > # specified as high byte of (perhaps already including an > # encoding space prefix). Other prefixes should be spelled out as usual > # ahead of or, for segment overrides, with the memory > # operand. > > # Operand order may not match that of the instruction actually being > # expressed: While for a memory operand (of which there can be only one) it > # is clear how to encode it in the resulting ModR/M byte, register operands > # are encoded strictly in the order # - {E,}VEX.vvvv for 1-register-operand VEX/XOP/EVEX insns, > # - ModR/M.rm, ModR/M.reg for 2-operand insns, > # - ModR/M.rm, {E,}VEX.vvvv, ModR/M.reg for 3-operand insns, and > # - Imm{4,5}, ModR/M.rm, {E,}VEX.vvvv, ModR/M.reg for 4-operand insns, > # obviously with the ModR/M.rm slot skipped when there is a memory operand, > # and obviously with the ModR/M.reg slot skipped when there is an extension > # opcode. (For Intel syntax of course all in the opposite order.) > > # Immediate operands (including immediate-like displacements, i.e. when not > # part of ModR/M addressing) should be specified by separate .byte / .word / > # .long / .quad (or alike) directives. > # TBD: How to deal with this for RIP-relative addressing? > # TBD: How to deal with this for 4-operand insns? The earlier two proposals how to address these two issues were # Proposal 1: $({u,s}) # Proposal 2: $:{u,s} Neither will easily fit within the way operands are currently parsed. To avoid further fragility, I'm therefore considering to extend what we currently use for vector operations: Prefix or suffix the size specifier enclosed in curly braces (using [] instead to represent alternatives): # Proposal 3: ${[u,s]} # Proposal 4: ${[u,s]} The former would be easiest to deal with from what I can tell right now. > # When register operand size varies for an actual insn (like e.g. for MOVZX or > # VPMOVZX*), registers nevertheless need spelling out in a uniform manner, such > # that any of them could be used to derive operand size attributes (e.g. > # operand size prefix, REX.W, VEX.W, or VEX.L) as well as the EVEX Disp8 > # scaling factor. > # TBD: Could also go from largest operand size, albeit that may end up confusing > # in AT&T mode, where memory operands don't have size, yet the memory > # operand may have larger size than the register one(s) (and would hence be > # the one which the attribute - see below - needs deriving from). Using largest operand size has turned out to be preferable. The AT&T syntax concern is easy to address: Respective attributes can simply be specified explicitly in the {VEX,XOP,EVEX}... construct when operands don't allow correctly deriving one or more of them. > # For VEX / XOP / EVEX is arranged like this: > # {VEX,XOP,EVEX}[.][.][.][.] I've changed this for XOP, as being more natural this way: # {,E}VEX[.][.][.][.] # XOP[.][.][.] > # where > # - can be LIG, 128, 256, or (EVEX only) 512 as well as L0/L1 for > # VEX / XOP and L0-L3 for EVEX, > # - can be NP, 66, F3, or F2, > # - can be > # - 0f, 0f38, 0f3a, or M0...M31 for VEX, > # - 08...3f (hex) for XOP, This ranges only from 08 through to 1f. > # - 0f, 0f38, 0f3a, or M0...M15 for EVEX, > # - can be WIG, W0, or W1. > # Omitted means "infer from operand size" if there is at least one > # sized operand, or LIG otherwise. > # Omitted means NP. > # Omitted implies encoding is taken from . > # Omitted means "infer from GPR operand size" if there is at least > # one GPR operand, or WIG otherwise. >[...] > # TBD: How to specify the Disp8 scaling factor here? (In Intel syntax we can simply > # use memory operand size.) Proposal: 4(%eax):4 or 4(%eax):d4. Like for immediates, the proposals present parsing challenges (and here there's also a [mild] forward compatibility concern, as we don't know what may further be added to the architecture). Hence, like there I'm now considering to instead put the size specifiers inside (potentially already present) curly braces, e.g. .insn EVEX.M5.W0 0x5a, 16(%eax){:d16}, %zmm0 # vcvtph2pd 16(%eax), %zmm0 .insn EVEX.M5.W0 0x5a, 2(%eax){1to8,:d2}, %zmm0 # vcvtph2pd 2(%eax){1to8}, %zmm0 I'd like to keep the colons to reduce the risk of issues which, as said, might result from future additions to the spec. Whether the comma as a separator is also wanted is secondary at this point. In particular if it turned out to cause problems to the parsing code, I wouldn't be worried to drop it. We could also follow the masking syntax and use .insn EVEX.M5.W0 0x5a, 2(%eax){1to8}{:d2}, %zmm0 # vcvtph2pd 2(%eax){1to8}, %zmm0 Once again - input appreciated especially on all still open aspects. Jan