From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2086.outbound.protection.outlook.com [40.107.21.86]) by sourceware.org (Postfix) with ESMTPS id CF5263858D20 for ; Thu, 28 Sep 2023 11:37:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CF5263858D20 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=JVZ6oxkiCd0PiPXyYiMaog+MuxYG0JIpD7QEkeaJgjgfSKuQSGNWuidPZ5+1VPBAaQGVDP453BbdOXz+XdrFtyCUMWGzZhDsK/gWiU1N1Qmg7om5OdqltxBllKEwe/+38+GWoLebF31/hiTrJZjWY0p4rcb+7wmKvEDxJWb6TlXpsb4VQbJ4clldPBgWdvmUt8JpDF2S36+96kSMum1v4FnwKegDp67P073XJU9CwLiVcfXfAdboak1B76cr+CA5QU2B41CG7MDstrAGw2PtJ7t4gsVABWgsm6MCZKgMBHZf8IsVSUnDONBp1mQ5kRJztxzkcWsqZQOXrmYeq7irFA== 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=9/R4ZPLtJhxK+KTzTY72LQ8XH5P4Eh6rDZLItw/AiNM=; b=CDxcJWsitarXFQ5F8Q0N18GVTQmje54lnd7fP518mhfUwt2MRk8rlv1gcnMv5Uq8KEAiUC12z3fRRSFaMsCGksJBUnRqwXdnIK30DZhjyUgDLmzXFwwsstDt94SAWWhlO23gXfze3Q4prslipEE8fGj9+V0pqK5/CW7UgnAsC2lPIqH3kXAazT9x90lcih8TXFGpeEcd/rvEAe8/Prtt5q07b5XITkBHZSyvw01ZNpjk1ORutDEVWnrXBeMPtwoF0K2BkyjYGYOe/1uZsvE+fISo5xwrbPMqp1yb9U+yZGziww3mi7/GMbNL0kCkA5CDvW46E8N8xBTboi363Ni7uA== 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=9/R4ZPLtJhxK+KTzTY72LQ8XH5P4Eh6rDZLItw/AiNM=; b=5fvcRcFKmkzYoDRK+8Mb34rybTPC9YfxYccKggAdsv4ZRZ+OwYLKRq1XTFZ3b+F55VFALQEwAvANOw+M82rx8r9wAzgEjAXpppYumwyHu+EUReCs6D5NeyMiHvy/iJyCXULHEeV3L/NpXh+wfqBC3MhJZUbpLwjc/zx0wJHHItfJA7KyFajdyN62mSvPgkZBer9b3d/4Bn5mJdKE+YHjonUWHc8h0gCYB5epMDApAMZdmZvbD6xRgE0JZaC97jAcbbrKeGOpasfkmIW6QGvZlQ/eqokHszzynMjm1X5Qi+zylsYiR8YSvBMmKrra8ZcLHL3WaukvhgWJAdjL9tXAcQ== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com; Received: from DU2PR04MB8790.eurprd04.prod.outlook.com (2603:10a6:10:2e1::23) by DB8PR04MB7036.eurprd04.prod.outlook.com (2603:10a6:10:12f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6813.28; Thu, 28 Sep 2023 11:37:40 +0000 Received: from DU2PR04MB8790.eurprd04.prod.outlook.com ([fe80::9f5d:8bed:7a5b:e75a]) by DU2PR04MB8790.eurprd04.prod.outlook.com ([fe80::9f5d:8bed:7a5b:e75a%6]) with mapi id 15.20.6838.016; Thu, 28 Sep 2023 11:37:40 +0000 Message-ID: <153e1263-bbc9-1af6-a11e-58489153d95f@suse.com> Date: Thu, 28 Sep 2023 13:37:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH 6/8] Support APX Push2/Pop2 Content-Language: en-US To: "Cui, Lili" Cc: hongjiu.lu@intel.com, "Mo, Zewei" , binutils@sourceware.org References: <20230919152527.497773-1-lili.cui@intel.com> <20230919152527.497773-7-lili.cui@intel.com> From: Jan Beulich In-Reply-To: <20230919152527.497773-7-lili.cui@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR2P281CA0175.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:9f::12) To DU2PR04MB8790.eurprd04.prod.outlook.com (2603:10a6:10:2e1::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DU2PR04MB8790:EE_|DB8PR04MB7036:EE_ X-MS-Office365-Filtering-Correlation-Id: 8688537e-b9fd-4290-9630-08dbc017526a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Tot0WXNnvl3UuJAd01qk95/6zELpJhulY4jZRZgx3bvcI4PlQ2pPm8fJ47BuQm7SDnVMEYGHhjDYR8GVm7+pFqrFY+J4meNBi4u+xflqzud6o28SeM1bGQqv5uUbwKKV+Irb+lWYv+Lo25YkmJBSS3bkLYIchnBlL2yrI8lPdKrKclmD7YbK4sjeQjh3TEr/kd3ukd7+unl+SqC3IifSCdclDqeXtn/l5lix5q4FQPtdJW3q78YsrSU9OyKQETb36tn05IYefYYMCQWhPqe82bXPDjU+pgQ4bNmCIgw1wLuSujnsOEDB7RaYGf9KXguivo5O/zpsrxxNb0Akf4Whd8r993KloARL2NpZjNYy14RXwVHzNzY1yQNE7clG4S/g1bFnGfkjNJhVGE+KJVXzTf6N36810D+OaKTykSSCx4dDZhdSb+88OdW+0hA/XljsngAz8hWtTbs+NErklSgok06uGpa7Ldojhpj9Un+flsZvT3QIQAHnS/xEePIijVh5+e/FLEhi/5vh1hSsXQ8LA1c3LjMTJyedHUDJVnePb5GJU6lOo7R6D1MPH6WKurKFOMsodhl4y4ZMmz4ArwXbsZJH04y6k4cNtNB3lx8z4ZBFf5mfg0CyVXF/FM7LG7A2XIf56gF3MTSLc10nW+xscw== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU2PR04MB8790.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(376002)(366004)(136003)(346002)(39860400002)(396003)(230922051799003)(64100799003)(451199024)(1800799009)(186009)(41300700001)(31686004)(66899024)(6916009)(316002)(83380400001)(8676002)(66946007)(36756003)(8936002)(4326008)(5660300002)(2616005)(6486002)(31696002)(6512007)(53546011)(86362001)(6506007)(66476007)(26005)(66556008)(38100700002)(2906002)(478600001)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YWhoeTJaR0FIUTR1bVprdlRKNC9YaDJPZHVPZzY5WlRsc1JBWU10Q3dNTTg2?= =?utf-8?B?VU9idVJmYjMxT0d1b3M4dE14K2pidHJHNFlxN3dUNDVrWmtGV0lZOVAzdTQw?= =?utf-8?B?ZUFyV24vUGZ5Zk1TVVBGdHVpdm1wMUZZRXRmUENUdjVOTGJHS1VuUGExY0kw?= =?utf-8?B?TzAra29kajdMUlJyb3M2YnlCV2dkdytZSWJ6NnhsRVhzOXQ3aURBMXJ2c29v?= =?utf-8?B?cWNvZmtZa096VjBKVHpXMlNReXR5ZDZzdmVRMkJuUGZKKzEwQzBrbE85Qk5S?= =?utf-8?B?K1Nvb2ZhY2hGUklpaHE4WmQwSjI3bUk1ekFOdTJOaW5nRjA5RmRGUDA5Snln?= =?utf-8?B?V2tXTFgxNHJtcVQ3QkRKTW5EY0VHczhrZUUwellMbjY1QWVITlJwZUpJaUtn?= =?utf-8?B?T2JZZWp1d1dJSURocFUwWnpmeDdWYW9Ib3k1K2hHZ20zSkdLOWx0MFdPOFRx?= =?utf-8?B?a0R4UVpxcU1tV3FoaXFJdVJXa3B0QTFZalRUNjIrQjVQdzdvcEQrTXVsWXU4?= =?utf-8?B?eFNYaWJXSktVR2NBUEZ4NExWZkNkc1E5Vi9OaVYwZXhBSFVIbGJhYmRoTGpF?= =?utf-8?B?dzB5Y25YaGNQam1uMGMxR09kWmhqOUJUbG5wc1lDTGI1Y3E1M29JU3VrUmxP?= =?utf-8?B?VGJjdEh1UUdRQmFTOXZnYkx5WVYyb2xybVhodkJGTElPVGhzNzRsTzZaeGF5?= =?utf-8?B?VnQ2NUQvaWR1OWZYTVErMytPTDJnN0pyaU54b3g3Y2dHOGZjMFh1V2l3WkJI?= =?utf-8?B?WXpUckJJVUZqblRYNjR6aXZEM081L3dqU3R2b09zRzJLM0FBK1dsNmxRa0VW?= =?utf-8?B?enBMNWV0dzM1QmVPYTNrTXJSWmlvNzMrdWtDNTV2Y0o0YXJHYUg4cmtJZjFm?= =?utf-8?B?SnljY0p1QUkrOTlCdDNpaVZjcElhN2NKQW5tYXhuVW9tSDBmZENmOUMzWk90?= =?utf-8?B?MnpqenY0NFJVZjJqOUtnVExVNFd6a0JyeVFLWVhQTURTV3kxS3R0aHZQcnZ4?= =?utf-8?B?SWg1TTIwWUMvUFpIZXkzdXMzV0lCRi9PWk0vd2RkTzZybW9tdjRBR0dvMHF5?= =?utf-8?B?Sm1KenF1c2FCeG5OYm1VakVGR0VJSGtSSVFoV0ZxOWtYYU5NTHd0eFRqVng4?= =?utf-8?B?OWZlalNpMTVIdDRMNmI1VVIySzBxekVXU1U5OXJBYWNMMURNY3VGVDYzdGxX?= =?utf-8?B?dXpQT2RlZ2xvN2ZaYzRWZVAxRlkwVFRtRVJpVklTNDRueDg0S1BXNDlCcWZl?= =?utf-8?B?MkZxYXdyeE1LdUgrTHBzN1FscW1UeHg4VkllaTFNYUxtTkxNVzJlY2pxVklu?= =?utf-8?B?QXNNdzVidGhaZitsUnV2WkdhM0lJOVJLa2JKSC9OZmZXV0N1RWhjWHNUa3lH?= =?utf-8?B?NFFtTnptRTRXNFJUK2xuQXByTjhWc1p1T25nYXFUQnMzY1pZd2hOMmp1aFR3?= =?utf-8?B?Nnh5NGVMcnBTcWNMcWFUbDJaSHJNa0wvckgrNzZkbHgxR2gyZXo5TU9xTE82?= =?utf-8?B?ZlRjamFiMVRjZjVFdHc1UG9NVEJvZTNhbkQ5RmJqV2t3Q1NiVklKazlHU0lY?= =?utf-8?B?K3hqanZWZUY1bjRqSkRZSWJ2YWZ4S0QybzZBTER1Qnp5czRCWWtCblRkeTY5?= =?utf-8?B?c2tyQ3lOdXBTM2pac1lyN1pTZ0sxTFl2dWgyMG9NZU10OEJmLzB3L1dyNEhG?= =?utf-8?B?RWZSaS8wL3k5MEpJakdHWlVvOWVtbk1vMHp4UnYrSnZ6azlaaTZsa3lhWEY4?= =?utf-8?B?ZmFveUdiU2xtR1dKRWVwTmQwTHR4N3RWNzJ5K2xydktFNE9jbGRpbkxaMS9u?= =?utf-8?B?a2Q3K1p5R0dmWnNQUEhDYVdRMVA1aGZaNnFoaUdNa1Y1M25OT3V6ZkVML3FC?= =?utf-8?B?UGhLbTJ1Q3FLai8wbEFVZU9ORlQxYTlDYlI5cUNtS1NaaTZvZzRKNm9wU3Js?= =?utf-8?B?TDRoUjVLd0hkdEU3YmtaTld3ZkJWQmhobUlRVkZqTDY4K25aU3ROVk5zNHNx?= =?utf-8?B?eUpvVUdPV3NoM3pybmlOOUNYeGd3cXNKcUg1Q2RSUHVMMENXdGZZOTdJTlhB?= =?utf-8?B?cHVxcFFnejVpK005YnVQZGRYZ0tnQys2dXgwZ2dyNHByMCtjK3IrLzlFQVhm?= =?utf-8?Q?sVzeezKIixDiEONq2wNQjIJJA?= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8688537e-b9fd-4290-9630-08dbc017526a X-MS-Exchange-CrossTenant-AuthSource: DU2PR04MB8790.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Sep 2023 11:37:40.3643 (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: V2p66w3TfyrfkdTZMVswBCzFhr1hedSLZ1chNI/PUCtT6egCwNAqxehpcYTQiFJaOV2F6tAUb6SB8tpqu/kQbQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR04MB7036 X-Spam-Status: No, score=-3027.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,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.09.2023 17:25, Cui, Lili wrote: > --- a/gas/config/tc-i386.c > +++ b/gas/config/tc-i386.c > @@ -5667,6 +5667,22 @@ md_assemble (char *line) > i.rex &= REX_OPCODE; > } > > + if (i.tm.opcode_modifier.push2pop2) > + { > + i.imm_operands = 0; Why? > + unsigned int reg1 = register_number (i.op[0].regs); > + unsigned int reg2 = register_number (i.op[1].regs); > + > + /* Push2/Pop2 cannot use RSP and Pop2 cannot pop two same registers. */ > + if (reg1 == 0x4 || reg2 == 0x4) > + as_bad (_("%s for `%s'"), _("invalid register operand"), > + insn_name (current_templates->start)); > + > + if ((i.tm.mnem_off == MN_pop2 || i.tm.mnem_off == MN_pop2p) && reg1 == reg2) This would be easier with a single opcode check on the lhs of the &&. > + as_bad (_("%s for `%s'"), _("invalid register operand"), > + insn_name (current_templates->start)); > + } Both error messages want to be more specific, such that it's clear what exactly is wrong. Also a string literal for %s is slightly odd, and may pose issues to translators. Furthermore there are pre-existing insns with restrictions on register operands. I wonder whether these new checks wouldn't better be put close to those. > @@ -7100,7 +7116,11 @@ optimize_NDD_to_nonNDD (const insn_template *t) > && t->opcode_space == SPACE_EVEXMAP4 > && i.reg_operands >= 2 > && (i.types[i.operands - 1].bitfield.dword > - || i.types[i.operands - 1].bitfield.qword)) > + || i.types[i.operands - 1].bitfield.qword) > + && (t->mnem_off != MN_pop2 > + && t->mnem_off != MN_pop2p > + && t->mnem_off != MN_push2 > + && t->mnem_off != MN_push2p)) If an explicit check is needed here, why not use the push2pop2 attribute? > @@ -8912,7 +8932,13 @@ build_modrm_byte (void) > dest = ~0; This already sets dest ... > } > gas_assert (source < dest); > - if (i.tm.opcode_modifier.operandconstraint == SWAP_SOURCES > + if (i.tm.opcode_modifier.push2pop2) > + { > + v = 1; > + dest = (unsigned int) ~0; ... to the intended value. Furthermore, doesn't ... > + source = 0; > + } > + else if (i.tm.opcode_modifier.operandconstraint == SWAP_SOURCES > && source != op) > { > unsigned int tmp = source; ... this logic already take care of the wanted swapping, provided the templates get SwapSources added? Hmm, odd - you already have that attribute on the two POP2 templates, but not the two PUSH2 ones. Yet both use identical operand (encoding) order. > --- /dev/null > +++ b/gas/testsuite/gas/i386/x86-64-apx-push2pop2-decode-inval.d > @@ -0,0 +1,29 @@ > +#as: --64 > +#objdump: -dw > +#name: illegal decoding of APX-push2pop2 insns Decoding cannot be illegal. Either you mean encoding, or you mean "decoding of illegal APX-push2pop2 insn forms". > --- /dev/null > +++ b/gas/testsuite/gas/i386/x86-64-apx-push2pop2-decode-inval.s > @@ -0,0 +1,19 @@ > +# Check illegal bytecode of APX-Push2Pop2 instructions > +# pop2 %rax, %rbx What's illegal here? From ... > +# pop2 %rax, %rsp > +# push2 %rsp, %r17 > +# pop2 %r12, %r12 > +# pop2 %r31, %r31 > + > + .allow_index_reg > + .text > +popnd0: > + .byte 0x62,0xF4,0x64,0x08,0x8F,0xC0 ... the label name I guess EVEX.nd=0, but that needs saying. (As mentioned earlier, the comments want moving next to the code emission anyway, and .byte wants avoiding it at all possible.) > --- /dev/null > +++ b/gas/testsuite/gas/i386/x86-64-apx-push2pop2-inval.s > @@ -0,0 +1,13 @@ > +# Check illegal APX-Push2Pop2 instructions > + > + .allow_index_reg > + .text > +_start: > + push2 %eax, %ebx > + pop2 %rax, %rsp > + push2 %rsp, %r17 > + pop2 %r12, %r12 > + push2p %eax, %ebx > + pop2p %rax, %rsp > + push2p %rsp, %r17 > + pop2p %r12, %r12 Please make sure that at least one of the forms uses %rsp once as first and once as second operand for both push and pop. > --- a/opcodes/i386-dis-evex-x86.h > +++ b/opcodes/i386-dis-evex-x86.h > @@ -138,3 +138,13 @@ > { Bad_Opcode }, > { VEX_LEN_TABLE (VEX_LEN_0F3AF0) }, > }, > + /* X86_64_EVEX_MAP4_8F*/ Nit: Please make well-formed comments (... > + { > + { Bad_Opcode }, > + { EVEX_LEN_TABLE (EVEX_LEN_MAP4_8F_X86_64) }, > + }, > + /* X86_64_EVEX_MAP4_FF_R_6*/ ... i.e. also here and possibly elsewhere). > @@ -1341,6 +1354,9 @@ enum > X86_64_EVEX_0F38F6, > X86_64_EVEX_0F38F7, > X86_64_EVEX_0F3AF0, > + > + X86_64_EVEX_MAP4_8F, > + X86_64_EVEX_MAP4_FF_R_6, > }; This might indicate a problem in patch 4: Why is the x86-64 decode step entirely missing there? Or, if correct there, why is it needed here? For push and pop here I'd expect decode order and hence enumerators to be entirely consistent. > @@ -1537,7 +1553,10 @@ enum > EVEX_LEN_0F3A39, > EVEX_LEN_0F3A3A, > EVEX_LEN_0F3A3B, > - EVEX_LEN_0F3A43 > + EVEX_LEN_0F3A43, > + > + EVEX_LEN_MAP4_8F_X86_64, > + EVEX_LEN_MAP4_FF_R_6_X86_64, > }; Prior changes didn't find it necessary to handle EVEX.l through a table lookup - why is this needed here? Map4 has uniform requirements, and an earlier patch added respective checking, iirc. > @@ -8757,10 +8779,24 @@ get_valid_dis386 (const struct dis386 *dp, instr_info *ins) > dp = &prefix_table[dp->op[1].bytemode][vindex]; > break; > > + case USE_X86_64_EVEX_PUSH2_TABLE: > + case USE_X86_64_EVEX_POP2_TABLE: > + ins->evex_type = evex_push2_pop2; > + unsigned int vvvv_reg = ins->vex.register_specifier > + | !ins->vex.v << 4; > + unsigned int rm_reg = ins->modrm.rm + (ins->rex & REX_B ? 8 : 0) > + + (ins->rex2 & REX_B ? 16 : 0); > + if (!ins->vex.b || vvvv_reg == 0x4 || rm_reg == 0x4 > + || (dp->op[0].bytemode == USE_X86_64_EVEX_POP2_TABLE > + && vvvv_reg == rm_reg)) > + return &bad_opcode; > + goto use_x86_64_table; I don't think this is the way to handle such restrictions. Since this likely can't very well be handled in existing operand handlers, so far the approach was to introduce new ...Fixup() ones. That'll also produce more helpful output, e.g. "push2 (bad)", rather than ".byte ..." with no hint at approximately what insn this was. New USE_..._TABLE should imo really only appear when truly new tables are introduced. > case USE_X86_64_EVEX_FROM_VEX_TABLE: > ins->evex_type = evex_from_vex; > /* Fall through. */ > case USE_X86_64_TABLE: > +use_x86_64_table: While this is going to go away with the comment above, as a general remark: Within a switch(), please align labels used by "goto" from one case to another with the adjacent case label(s). Elsewhere, for "diff -p", please indent labels by at least one blank. > @@ -9570,7 +9606,8 @@ print_insn (bfd_vma pc, disassemble_info *info, int intel_syntax) > /* Check whether rounding control was enabled for an insn not > supporting it. */ > if (ins.modrm.mod == 3 && ins.vex.b > - && !(ins.evex_used & EVEX_b_used)) > + && !(ins.evex_used & EVEX_b_used) > + && ins.evex_type != evex_push2_pop2) > { Looks like addressing a comment on an earlier patch will render this change (and hence the new evex_push2_pop2 enumerator) unnecessary. If not, I'd ask whether you wouldn't better set EVEX_b_used at an appropriate point. > --- a/opcodes/i386-opc.tbl > +++ b/opcodes/i386-opc.tbl > @@ -3555,3 +3555,9 @@ eretu, 0xf30f01ca, FRED|x64, NoSuf, {} > > // FRED instructions end. > > +// APX Push2/Pop2 instruction. > + > +push2, 0xff/6, APX_F|x64, Modrm|VexW0|EVex128|Push2Pop2|EVexMap4|VexVVVV|No_bSuf|No_lSuf|No_sSuf, { Reg64, Reg64 } > +push2p, 0xff/6, APX_F|x64, Modrm|VexW1|EVex128|Push2Pop2|EVexMap4|VexVVVV|No_bSuf|No_lSuf|No_sSuf, { Reg64, Reg64 } > +pop2, 0x8f/0, APX_F|x64, Modrm|VexW0|EVex128|Push2Pop2|SwapSources|EVexMap4|VexVVVV|No_bSuf|No_lSuf|No_sSuf, { Reg64, Reg64 } > +pop2p, 0x8f/0, APX_F|x64, Modrm|VexW1|EVex128|Push2Pop2|SwapSources|EVexMap4|VexVVVV|No_bSuf|No_lSuf|No_sSuf, { Reg64, Reg64 } Missing No_wSuf in all 4 entries? As to the suffixing 'p' - may I ask in how far that's aligned with other assemblers? The doc doesn't even give a hint as to what mnemonic representation should be used (personally I had been taking .x into consideration). Furthermore the earlier REX2 patch also didn't deal with the PPX functionality for PUSH/POP, unless I missed something. Jan