* [PATCH v1] x86: Support ZHAOXIN GMI instructions
@ 2024-10-14 2:03 mayshao-oc
2024-10-14 3:09 ` Jiang, Haochen
2024-10-14 6:54 ` Jan Beulich
0 siblings, 2 replies; 80+ messages in thread
From: mayshao-oc @ 2024-10-14 2:03 UTC (permalink / raw)
To: binutils; +Cc: H.J. Lu, Jan Beulich, Jiang, Haochen, timhu, louisqi, cobechen
[-- Attachment #1: Type: text/plain, Size: 171 bytes --]
Hi all:
This patch adds support for Zhaoxin GMI instructions.
The documentation is attached for your reference.
Test ok, ok for trunk?
BR
Mayshao
[-- Attachment #2: ZX_GMI_Reference.docx --]
[-- Type: application/wps-office.docx, Size: 28169 bytes --]
[-- Attachment #3: gmi_v1.patch --]
[-- Type: text/x-patch, Size: 15207 bytes --]
From 3d4ed4d9155eba670073dd06633a91df8212e809 Mon Sep 17 00:00:00 2001
From: MayShao-oc <MayShao-oc@zhaoxin.com>
Date: Sat, 12 Oct 2024 10:01:14 +0800
Subject: [PATCH v1] x86: Support ZHAOXIN GMI
Hi all:
This patch adds support for Zhaoxin GMI instructions.
Test ok, ok for trunk?
BR
Mayshao
gas/ChangeLog:
* NEWS: Support ZHAOXIN GMI instructions.
* config/tc-i386.c: Add gmi.
* doc/c-i386.texi: Document gmi.
* testsuite/gas/i386/i386.exp: Add gmi test.
* testsuite/gas/i386/gmi.d: Ditto.
* testsuite/gas/i386/gmi.s: Ditto.
opcodes/ChangeLog:
* i386-dis.c (OP_0f07_Fixup): New.
(OP_0f07_Fixup1): Ditto.
* i386-gen.c: Add gmi.
* i386-opc.h (CpuGMI): New.
* i386-opc.tbl: Add Zhaoxin GMI instructions.
* i386-tbl.h: Regenerated.
* i386-mnem.h: Ditto.
* i386-init.h: Ditto.
---
gas/NEWS | 2 +
gas/config/tc-i386.c | 1 +
gas/doc/c-i386.texi | 6 +-
gas/testsuite/gas/i386/gmi.d | 12 ++
gas/testsuite/gas/i386/gmi.s | 8 +
gas/testsuite/gas/i386/i386.exp | 1 +
opcodes/i386-dis.c | 336 +++++++++++++++++++++++++++++++-
opcodes/i386-gen.c | 1 +
opcodes/i386-opc.h | 3 +
opcodes/i386-opc.tbl | 5 +
10 files changed, 364 insertions(+), 11 deletions(-)
create mode 100644 gas/testsuite/gas/i386/gmi.d
create mode 100644 gas/testsuite/gas/i386/gmi.s
diff --git a/gas/NEWS b/gas/NEWS
index d64330143b0..25ca7677567 100644
--- a/gas/NEWS
+++ b/gas/NEWS
@@ -82,6 +82,8 @@ Changes in 2.43:
* Add support for the AArch64 Lookup Table Extension v2 (LUTv2).
+* Add support for the Zhaoxin GMI instructions.
+
Changes in 2.42:
* Add support for AMD znver5 processor.
diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c
index cdefde03717..735154ee721 100644
--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -1219,6 +1219,7 @@ static const arch_entry cpu_arch[] =
SUBARCH (user_msr, USER_MSR, USER_MSR, false),
SUBARCH (apx_f, APX_F, APX_F, false),
VECARCH (avx10.2, AVX10_2, ANY_AVX10_2, set),
+ SUBARCH (gmi, GMI, GMI, false),
};
#undef SUBARCH
diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi
index 9667061752d..952ddbc7377 100644
--- a/gas/doc/c-i386.texi
+++ b/gas/doc/c-i386.texi
@@ -274,7 +274,8 @@ accept various extension mnemonics. For example,
@code{snp},
@code{invlpgb},
@code{tlbsync},
-@code{svme} and
+@code{svme},
+@code{gmi} and
@code{padlock}.
Note that these extension mnemonics can be prefixed with @code{no} to revoke
the respective (and any dependent) functionality. Note further that the
@@ -1705,7 +1706,8 @@ supported on the CPU specified. The choices for @var{cpu_type} are:
@item @samp{.lwp} @tab @samp{.fma4} @tab @samp{.xop} @tab @samp{.cx16}
@item @samp{.padlock} @tab @samp{.clzero} @tab @samp{.mwaitx} @tab @samp{.rdpru}
@item @samp{.mcommit} @tab @samp{.sev_es} @tab @samp{.snp} @tab @samp{.invlpgb}
-@item @samp{.tlbsync} @tab @samp{.apx_f}
+@item @samp{.tlbsync} @tab @samp{.apx_f} @tab @samp{.gmi}
+
@end multitable
Apart from the warning, there are only two other effects on
diff --git a/gas/testsuite/gas/i386/gmi.d b/gas/testsuite/gas/i386/gmi.d
new file mode 100644
index 00000000000..063da8e120a
--- /dev/null
+++ b/gas/testsuite/gas/i386/gmi.d
@@ -0,0 +1,12 @@
+#objdump: -dw
+#name: zhaoxin gmi
+
+.*: +file format .*
+
+Disassembly of section .text:
+
+0+000 <foo>:
+ 0:[ ]*f2 0f a6 c0 [ ]*sm2
+ 4:[ ]*f3 0f a6 e8 [ ]*sm3
+ 8:[ ]*f3 0f a7 f0 [ ]*sm4
+#pass
diff --git a/gas/testsuite/gas/i386/gmi.s b/gas/testsuite/gas/i386/gmi.s
new file mode 100644
index 00000000000..c412de55d31
--- /dev/null
+++ b/gas/testsuite/gas/i386/gmi.s
@@ -0,0 +1,8 @@
+# ZHAOXIN GMI instructions
+
+ .text
+foo:
+ sm2
+ sm3
+ sm4
+ .p2align 4,0
diff --git a/gas/testsuite/gas/i386/i386.exp b/gas/testsuite/gas/i386/i386.exp
index 699e2004bef..4aaa2239069 100644
--- a/gas/testsuite/gas/i386/i386.exp
+++ b/gas/testsuite/gas/i386/i386.exp
@@ -114,6 +114,7 @@ if [gas_32_check] then {
run_dump_test "quoted2"
run_dump_test "unary"
run_dump_test "padlock"
+ run_dump_test "gmi"
run_dump_test "crx"
run_list_test "cr-err" ""
run_dump_test "cdr"
diff --git a/opcodes/i386-dis.c b/opcodes/i386-dis.c
index 3a4af4d61a3..67eb1d5b41e 100644
--- a/opcodes/i386-dis.c
+++ b/opcodes/i386-dis.c
@@ -83,6 +83,8 @@ static bool OP_Rounding (instr_info *, int, int);
static bool OP_REG_VexI4 (instr_info *, int, int);
static bool OP_VexI4 (instr_info *, int, int);
static bool OP_0f07 (instr_info *, int, int);
+static bool OP_0f07_Fixup (instr_info *, int, int);
+static bool OP_0f07_Fixup1 (instr_info *, int, int);
static bool OP_Monitor (instr_info *, int, int);
static bool OP_Mwait (instr_info *, int, int);
@@ -890,7 +892,6 @@ enum
REG_0F71,
REG_0F72,
REG_0F73,
- REG_0FA6,
REG_0FA7,
REG_0FAE,
REG_0FBA,
@@ -1050,6 +1051,10 @@ enum
PREFIX_0F7D,
PREFIX_0F7E,
PREFIX_0F7F,
+ PREFIX_0FA6C0,
+ PREFIX_0FA6C8,
+ PREFIX_0FA6D0,
+ PREFIX_0FA6E8,
PREFIX_0FAE_REG_0_MOD_3,
PREFIX_0FAE_REG_1_MOD_3,
PREFIX_0FAE_REG_2_MOD_3,
@@ -1315,7 +1320,8 @@ enum
enum
{
THREE_BYTE_0F38 = 0,
- THREE_BYTE_0F3A
+ THREE_BYTE_0F3A,
+ THREE_BYTE_0FA6
};
enum
@@ -2311,7 +2317,7 @@ static const struct dis386 dis386_twobyte[] = {
{ "btS", { Ev, Gv }, 0 },
{ "shldS", { Ev, Gv, Ib }, 0 },
{ "shldS", { Ev, Gv, CL }, 0 },
- { REG_TABLE (REG_0FA6) },
+ { THREE_BYTE_TABLE (THREE_BYTE_0FA6) },
{ REG_TABLE (REG_0FA7) },
/* a8 */
{ "pushP", { gs }, 0 },
@@ -2848,12 +2854,6 @@ static const struct dis386 reg_table[][8] = {
{ "psllq", { Nq, Ib }, PREFIX_OPCODE },
{ "pslldq", { Ux, Ib }, PREFIX_DATA },
},
- /* REG_0FA6 */
- {
- { "montmul", { { OP_0f07, 0 } }, 0 },
- { "xsha1", { { OP_0f07, 0 } }, 0 },
- { "xsha256", { { OP_0f07, 0 } }, 0 },
- },
/* REG_0FA7 */
{
{ "xstore-rng", { { OP_0f07, 0 } }, 0 },
@@ -2862,6 +2862,7 @@ static const struct dis386 reg_table[][8] = {
{ "xcrypt-ctr", { { OP_0f07, 0 } }, 0 },
{ "xcrypt-cfb", { { OP_0f07, 0 } }, 0 },
{ "xcrypt-ofb", { { OP_0f07, 0 } }, 0 },
+ { "sm4", { { OP_0f07_Fixup1, 0 } }, 0 },
},
/* REG_0FAE */
{
@@ -3438,6 +3439,35 @@ static const struct dis386 prefix_table[][4] = {
{ "movdqa", { EXxS, XM }, PREFIX_OPCODE },
},
+ /* PREFIX_0FA6C0 */
+ {
+ { Bad_Opcode },
+ { "montmul", { { OP_0f07_Fixup, 0 } }, 0 },
+ { Bad_Opcode },
+ { "sm2", { { 0, 0 } }, 0 },
+ },
+ /* PREFIX_0FA6C8 */
+ {
+ { Bad_Opcode },
+ { "xsha1", { { OP_0f07_Fixup, 0 } }, 0 },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ },
+ /* PREFIX_0FA6D0 */
+ {
+ { Bad_Opcode },
+ { "xsha256", { { OP_0f07_Fixup, 0 } }, 0 },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ },
+ /* PREFIX_0FA6E8 */
+ {
+ { Bad_Opcode },
+ { "sm3", { { 0, 0 } }, 0 },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ },
+
/* PREFIX_0FAE_REG_0_MOD_3 */
{
{ Bad_Opcode },
@@ -5088,6 +5118,272 @@ static const struct dis386 three_byte_table[][256] = {
{ Bad_Opcode },
{ Bad_Opcode },
},
+ /* THREE_BYTE_0FA6 */
+ {
+ /* 00 */
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* 08 */
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* 10 */
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* 18 */
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* 20 */
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* 28 */
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* 30 */
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* 38 */
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* 40 */
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* 48 */
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* 50 */
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* 58 */
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* 60 */
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* 68 */
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* 70 */
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* 78 */
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* 80 */
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* 88 */
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* 90 */
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* 98 */
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* a0 */
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* a8 */
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* b0 */
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* b8 */
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* c0 */
+ { PREFIX_TABLE (PREFIX_0FA6C0) },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* c8 */
+ { PREFIX_TABLE (PREFIX_0FA6C8) },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* d0 */
+ { PREFIX_TABLE (PREFIX_0FA6D0) },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* d8 */
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* e0 */
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ /* e8 */
+ { PREFIX_TABLE (PREFIX_0FA6E8) },
+ }
};
static const struct dis386 xop_table[][256] = {
@@ -13086,6 +13382,28 @@ OP_0f07 (instr_info *ins, int bytemode, int sizeflag)
return OP_E (ins, bytemode, sizeflag);
}
+/* repz is printed before some instructions,eg:montmul,xsha1,xsha256. */
+static bool
+OP_0f07_Fixup (instr_info *ins, int bytemode, int sizeflag)
+{
+ (void) bytemode;
+ (void) sizeflag;
+ /* The 0xf3 prefix should be displayed as "repz" for montmul, xsha1,xsha256. */
+ if (ins->prefixes & PREFIX_REPZ)
+ ins->all_prefixes[ins->last_repz_prefix] = 0xf3;
+ return true;
+}
+
+/* repz is removed before some instruction, eg: sm4. */
+static bool
+OP_0f07_Fixup1 (instr_info *ins, int bytemode, int sizeflag)
+{
+ /* Remove REPZ prefix. */
+ if (ins->prefixes & PREFIX_REPZ)
+ ins->all_prefixes[ins->last_repz_prefix] = 0;
+ return OP_E (ins, bytemode, sizeflag);
+}
+
/* NOP is an alias of "xchg %ax,%ax" in 16bit mode, "xchg %eax,%eax" in
32bit mode and "xchg %rax,%rax" in 64bit mode. */
diff --git a/opcodes/i386-gen.c b/opcodes/i386-gen.c
index 565aae722f8..0f7ab4c6a56 100644
--- a/opcodes/i386-gen.c
+++ b/opcodes/i386-gen.c
@@ -334,6 +334,7 @@ static bitfield cpu_flags[] =
BITFIELD (3dnow),
BITFIELD (3dnowA),
BITFIELD (PadLock),
+ BITFIELD (GMI),
BITFIELD (SVME),
BITFIELD (VMX),
BITFIELD (SMX),
diff --git a/opcodes/i386-opc.h b/opcodes/i386-opc.h
index c0d5e44d461..d404fbc6b05 100644
--- a/opcodes/i386-opc.h
+++ b/opcodes/i386-opc.h
@@ -66,6 +66,8 @@ enum i386_cpu
CpuSSE3,
/* VIA PadLock required */
CpuPadLock,
+ /* ZHAOXIN GMI required */
+ CpuGMI,
/* AMD Secure Virtual Machine Ext-s required */
CpuSVME,
/* VMX Instructions required */
@@ -400,6 +402,7 @@ typedef union i386_cpu_flags
unsigned int cpusse2:1;
unsigned int cpusse3:1;
unsigned int cpupadlock:1;
+ unsigned int cpugmi:1;
unsigned int cpusvme:1;
unsigned int cpuvmx:1;
unsigned int cpusmx:1;
diff --git a/opcodes/i386-opc.tbl b/opcodes/i386-opc.tbl
index 9a14a4d1819..7ded4e64133 100644
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -2131,6 +2131,11 @@ xcryptofb, 0xf30fa7e8, PadLock, NoSuf|RepPrefixOk, {}
// Alias for xstore-rng.
xstore, 0xfa7c0, PadLock, NoSuf|RepPrefixOk, {}
+// ZHAOXIN GMI instructions
+sm2, 0xf20fa6c0, GMI, NoSuf, {}
+sm3, 0xf30fa6e8, GMI, NoSuf, {}
+sm4, 0xf30fa7f0, GMI, NoSuf, {}
+
// Multy-precision Add Carry, rdseed instructions.
<adx:pfx, c:66, o:f3>
ad<adx>x, 0x<adx:pfx>66, ADX&APX_F, C|Modrm|CheckOperandSize|No_bSuf|No_wSuf|No_sSuf|DstVVVV|EVexMap4, { Reg32|Reg64|Unspecified|BaseIndex, Reg32|Reg64, Reg32|Reg64 }
--
2.27.0
^ permalink raw reply [flat|nested] 80+ messages in thread
* RE: [PATCH v1] x86: Support ZHAOXIN GMI instructions
2024-10-14 2:03 [PATCH v1] x86: Support ZHAOXIN GMI instructions mayshao-oc
@ 2024-10-14 3:09 ` Jiang, Haochen
2024-10-14 3:28 ` mayshao-oc
2024-10-14 6:54 ` Jan Beulich
1 sibling, 1 reply; 80+ messages in thread
From: Jiang, Haochen @ 2024-10-14 3:09 UTC (permalink / raw)
To: mayshao-oc, binutils; +Cc: H.J. Lu, Beulich, Jan, timhu, louisqi, cobechen
> From: mayshao-oc <mayshao-oc@zhaoxin.com>
> Sent: Monday, October 14, 2024 10:03 AM
> To: binutils@sourceware.org
>
> This patch adds support for Zhaoxin GMI instructions.
> The documentation is attached for your reference.
> Test ok, ok for trunk?
The disassembler part looks extremely weird to me.
I suppose the adding for this is not correct:
@@ -1315,7 +1320,8 @@ enum
enum
{
THREE_BYTE_0F38 = 0,
- THREE_BYTE_0F3A
+ THREE_BYTE_0F3A,
+ THREE_BYTE_0FA6
};
My understanding comes following, correct me if I am wrong.
Let's take inst sm2 for example. The full encoding for sm2 is
0xf20fa6c0. In the encoding, a6 is opcode and c0 is modrm byte.
This means a6 should be the "index", not a6c0 in your this part
of patch:
@@ -1050,6 +1051,10 @@ enum
PREFIX_0F7D,
PREFIX_0F7E,
PREFIX_0F7F,
+ PREFIX_0FA6C0,
+ PREFIX_0FA6C8,
+ PREFIX_0FA6D0,
+ PREFIX_0FA6E8,
You can translate modrm byte c0 to 11 000 000. Therefore, the REG
is always 0. That is why montmul occupies the first row of REG_0FA6
entry, since the opcode for it is 0xf30fa6c0.
The actual change should be something like adding prefix table pass
for montmul/sm2, since one of them is f2, the other is f3.
Thx,
Haochen
>
> BR
> Mayshao
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v1] x86: Support ZHAOXIN GMI instructions
2024-10-14 3:09 ` Jiang, Haochen
@ 2024-10-14 3:28 ` mayshao-oc
2024-10-14 3:37 ` Jiang, Haochen
0 siblings, 1 reply; 80+ messages in thread
From: mayshao-oc @ 2024-10-14 3:28 UTC (permalink / raw)
To: Jiang, Haochen, binutils; +Cc: H.J. Lu, Beulich, Jan, timhu, louisqi, cobechen
Hi Haochen:
Thanks for your review, I comment below.
BR
mayshao
On 10/14/24 11:09, Jiang, Haochen wrote:
>
>
>
>> From: mayshao-oc <mayshao-oc@zhaoxin.com>
>> Sent: Monday, October 14, 2024 10:03 AM
>> To: binutils@sourceware.org
>>
>> This patch adds support for Zhaoxin GMI instructions.
>> The documentation is attached for your reference.
>> Test ok, ok for trunk?
>
> The disassembler part looks extremely weird to me.
>
> I suppose the adding for this is not correct:
>
> @@ -1315,7 +1320,8 @@ enum
> enum
> {
> THREE_BYTE_0F38 = 0,
> - THREE_BYTE_0F3A
> + THREE_BYTE_0F3A,
> + THREE_BYTE_0FA6
> };
>
> My understanding comes following, correct me if I am wrong.
>
> Let's take inst sm2 for example. The full encoding for sm2 is
> 0xf20fa6c0. In the encoding, a6 is opcode and c0 is modrm byte.
> This means a6 should be the "index", not a6c0 in your this part
> of patch:
All GMI instructions are three byte opcode, so for the inst sm2, c0 is
not modrm byte.
>
> @@ -1050,6 +1051,10 @@ enum
> PREFIX_0F7D,
> PREFIX_0F7E,
> PREFIX_0F7F,
> + PREFIX_0FA6C0,
> + PREFIX_0FA6C8,
> + PREFIX_0FA6D0,
> + PREFIX_0FA6E8,
>
> You can translate modrm byte c0 to 11 000 000. Therefore, the REG
> is always 0. That is why montmul occupies the first row of REG_0FA6
> entry, since the opcode for it is 0xf30fa6c0.
>
> The actual change should be something like adding prefix table pass
> for montmul/sm2, since one of them is f2, the other is f3.
>
> Thx,
> Haochen
>
>>
>> BR
>> Mayshao
^ permalink raw reply [flat|nested] 80+ messages in thread
* RE: [PATCH v1] x86: Support ZHAOXIN GMI instructions
2024-10-14 3:28 ` mayshao-oc
@ 2024-10-14 3:37 ` Jiang, Haochen
2024-10-14 6:13 ` Jan Beulich
0 siblings, 1 reply; 80+ messages in thread
From: Jiang, Haochen @ 2024-10-14 3:37 UTC (permalink / raw)
To: mayshao-oc, binutils; +Cc: H.J. Lu, Beulich, Jan, timhu, louisqi, cobechen
> From: mayshao-oc <mayshao-oc@zhaoxin.com>
> Sent: Monday, October 14, 2024 11:28 AM
>
> On 10/14/24 11:09, Jiang, Haochen wrote:
> >
> >
> >
> >> From: mayshao-oc <mayshao-oc@zhaoxin.com>
> >> Sent: Monday, October 14, 2024 10:03 AM
> >> To: binutils@sourceware.org
> >>
> >> This patch adds support for Zhaoxin GMI instructions.
> >> The documentation is attached for your reference.
> >> Test ok, ok for trunk?
> >
> > The disassembler part looks extremely weird to me.
> >
> > I suppose the adding for this is not correct:
> >
> > @@ -1315,7 +1320,8 @@ enum
> > enum
> > {
> > THREE_BYTE_0F38 = 0,
> > - THREE_BYTE_0F3A
> > + THREE_BYTE_0F3A,
> > + THREE_BYTE_0FA6
> > };
> >
> > My understanding comes following, correct me if I am wrong.
> >
> > Let's take inst sm2 for example. The full encoding for sm2 is
> > 0xf20fa6c0. In the encoding, a6 is opcode and c0 is modrm byte.
> > This means a6 should be the "index", not a6c0 in your this part of
> > patch:
> All GMI instructions are three byte opcode, so for the inst sm2, c0 is not
> modrm byte.
Maybe I did not make it clear here, the full opcode is f20fa6, where f2 is
mandatory prefix and 0f is the escape opcode byte. These three bytes
consist of the full opcode.
This will make c0 as modrm byte.
Thx,
Haochen
> >
> > @@ -1050,6 +1051,10 @@ enum
> > PREFIX_0F7D,
> > PREFIX_0F7E,
> > PREFIX_0F7F,
> > + PREFIX_0FA6C0,
> > + PREFIX_0FA6C8,
> > + PREFIX_0FA6D0,
> > + PREFIX_0FA6E8,
> >
> > You can translate modrm byte c0 to 11 000 000. Therefore, the REG is
> > always 0. That is why montmul occupies the first row of REG_0FA6
> > entry, since the opcode for it is 0xf30fa6c0.
> >
> > The actual change should be something like adding prefix table pass
> > for montmul/sm2, since one of them is f2, the other is f3.
> >
> > Thx,
> > Haochen
> >
> >>
> >> BR
> >> Mayshao
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v1] x86: Support ZHAOXIN GMI instructions
2024-10-14 3:37 ` Jiang, Haochen
@ 2024-10-14 6:13 ` Jan Beulich
0 siblings, 0 replies; 80+ messages in thread
From: Jan Beulich @ 2024-10-14 6:13 UTC (permalink / raw)
To: Jiang, Haochen, mayshao-oc; +Cc: H.J. Lu, timhu, louisqi, cobechen, binutils
On 14.10.2024 05:37, Jiang, Haochen wrote:
>> From: mayshao-oc <mayshao-oc@zhaoxin.com>
>> Sent: Monday, October 14, 2024 11:28 AM
>>
>> On 10/14/24 11:09, Jiang, Haochen wrote:
>>>
>>>
>>>
>>>> From: mayshao-oc <mayshao-oc@zhaoxin.com>
>>>> Sent: Monday, October 14, 2024 10:03 AM
>>>> To: binutils@sourceware.org
>>>>
>>>> This patch adds support for Zhaoxin GMI instructions.
>>>> The documentation is attached for your reference.
>>>> Test ok, ok for trunk?
>>>
>>> The disassembler part looks extremely weird to me.
>>>
>>> I suppose the adding for this is not correct:
>>>
>>> @@ -1315,7 +1320,8 @@ enum
>>> enum
>>> {
>>> THREE_BYTE_0F38 = 0,
>>> - THREE_BYTE_0F3A
>>> + THREE_BYTE_0F3A,
>>> + THREE_BYTE_0FA6
>>> };
>>>
>>> My understanding comes following, correct me if I am wrong.
>>>
>>> Let's take inst sm2 for example. The full encoding for sm2 is
>>> 0xf20fa6c0. In the encoding, a6 is opcode and c0 is modrm byte.
>>> This means a6 should be the "index", not a6c0 in your this part of
>>> patch:
>> All GMI instructions are three byte opcode, so for the inst sm2, c0 is not
>> modrm byte.
>
> Maybe I did not make it clear here, the full opcode is f20fa6, where f2 is
> mandatory prefix and 0f is the escape opcode byte. These three bytes
> consist of the full opcode.
>
> This will make c0 as modrm byte.
I agree - even if the byte isn't used as a ModR/M one, its decoding should
treat it so. That's no different from SFENCE, LFENCE, and MFENCE, to name
just a few. Plus - even the original PadLock insns match that pattern.
Nothing good will come from things being done differently here.
Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v1] x86: Support ZHAOXIN GMI instructions
2024-10-14 2:03 [PATCH v1] x86: Support ZHAOXIN GMI instructions mayshao-oc
2024-10-14 3:09 ` Jiang, Haochen
@ 2024-10-14 6:54 ` Jan Beulich
2024-10-14 8:37 ` Jiang, Haochen
2024-10-15 1:31 ` [PATCH v1] x86: Support ZHAOXIN GMI instructions mayshao-oc
1 sibling, 2 replies; 80+ messages in thread
From: Jan Beulich @ 2024-10-14 6:54 UTC (permalink / raw)
To: mayshao-oc; +Cc: H.J. Lu, Jiang, Haochen, timhu, louisqi, cobechen, binutils
On 14.10.2024 04:03, mayshao-oc wrote:
> This patch adds support for Zhaoxin GMI instructions.
> The documentation is attached for your reference.
> Test ok, ok for trunk?
In the NEWS entry, please add "x86" one way or another. Not everyone may
know that Zhaoxin is an x86 flavor. Also the entry needs to move up, into
the post-2.43 section.
For the i386-gen change I wonder whether GMI is an entirely separate
extension, or kind of an extension to PadLock. Can you clarify the
relationship please?
In i386-dis.c, if - following earlier comments - you still need some fixup
function(s), please name them suitably. The pre-existing OP_0f07() is
grossly misnamed, and that misnaming shouldn't be further extended.
Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* RE: [PATCH v1] x86: Support ZHAOXIN GMI instructions
2024-10-14 6:54 ` Jan Beulich
@ 2024-10-14 8:37 ` Jiang, Haochen
2024-10-14 9:05 ` mayshao-oc
2024-10-15 1:31 ` [PATCH v1] x86: Support ZHAOXIN GMI instructions mayshao-oc
1 sibling, 1 reply; 80+ messages in thread
From: Jiang, Haochen @ 2024-10-14 8:37 UTC (permalink / raw)
To: Beulich, Jan, mayshao-oc; +Cc: H.J. Lu, timhu, louisqi, cobechen, binutils
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Monday, October 14, 2024 2:54 PM
>
> In i386-dis.c, if - following earlier comments - you still need some fixup
> function(s), please name them suitably. The pre-existing OP_0f07() is
> grossly misnamed, and that misnaming shouldn't be further extended.
As Jan said, OP_0f07 is misnamed.
But I suppose OP_Skip_MODRM might be better here if you still believe
they are not modrm bytes, just like mentioned LFENCE and SFENCE example.
I am not sure if they should be changed to this, you could have a try on that.
Thx,
Haochen
>
> Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v1] x86: Support ZHAOXIN GMI instructions
2024-10-14 8:37 ` Jiang, Haochen
@ 2024-10-14 9:05 ` mayshao-oc
2024-10-14 10:16 ` Jan Beulich
0 siblings, 1 reply; 80+ messages in thread
From: mayshao-oc @ 2024-10-14 9:05 UTC (permalink / raw)
To: Jiang, Haochen, Beulich, Jan; +Cc: H.J. Lu, timhu, louisqi, cobechen, binutils
Hi Haochen:
Thanks for your comment. You are right, I need to use prefix to
distinguish montmul/sm2. For the sm2 instruction, 0c is modrm byte.
As to the function name, I need to skip repz display for sm3 and
sm4 instruction, and I want to use OP_Skip_REPZ as function name, do you
think its make sense.
Best Regards
Mayshao
On 10/14/24 16:37, Jiang, Haochen wrote:
>
>
>
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Monday, October 14, 2024 2:54 PM
>>
>> In i386-dis.c, if - following earlier comments - you still need some fixup
>> function(s), please name them suitably. The pre-existing OP_0f07() is
>> grossly misnamed, and that misnaming shouldn't be further extended.
>
> As Jan said, OP_0f07 is misnamed.
>
> But I suppose OP_Skip_MODRM might be better here if you still believe
> they are not modrm bytes, just like mentioned LFENCE and SFENCE example.
>
> I am not sure if they should be changed to this, you could have a try on that.
>
> Thx,
> Haochen
>
>>
>> Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v1] x86: Support ZHAOXIN GMI instructions
2024-10-14 9:05 ` mayshao-oc
@ 2024-10-14 10:16 ` Jan Beulich
2024-10-15 1:19 ` [PATCH v2] " mayshao-oc
2024-12-13 3:25 ` [PATCH v1] x86: Support ZHAOXIN padlock instructions Mayshao-oc
0 siblings, 2 replies; 80+ messages in thread
From: Jan Beulich @ 2024-10-14 10:16 UTC (permalink / raw)
To: mayshao-oc; +Cc: H.J. Lu, timhu, louisqi, cobechen, binutils, Jiang, Haochen
On 14.10.2024 11:05, mayshao-oc wrote:
> Thanks for your comment. You are right, I need to use prefix to
> distinguish montmul/sm2. For the sm2 instruction, 0c is modrm byte.
> As to the function name, I need to skip repz display for sm3 and
> sm4 instruction, and I want to use OP_Skip_REPZ as function name, do you
> think its make sense.
If you add a decoding step through prefix_table[], you shouldn't need
such a helper function.
Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* [PATCH v2] x86: Support ZHAOXIN GMI instructions
2024-10-14 10:16 ` Jan Beulich
@ 2024-10-15 1:19 ` mayshao-oc
2024-10-15 3:02 ` Jiang, Haochen
2024-12-13 3:25 ` [PATCH v1] x86: Support ZHAOXIN padlock instructions Mayshao-oc
1 sibling, 1 reply; 80+ messages in thread
From: mayshao-oc @ 2024-10-15 1:19 UTC (permalink / raw)
To: Jan Beulich; +Cc: H.J. Lu, timhu, louisqi, cobechen, binutils, Jiang, Haochen
[-- Attachment #1: Type: text/plain, Size: 142 bytes --]
Hi all:
Thanks for the very insightful comments of Jan hand haochen, I
refine the patch.
Test ok, ok for trunk?
BR
Mayshao
[-- Attachment #2: gmi_v2.patch --]
[-- Type: text/x-patch, Size: 8846 bytes --]
From 5f51e0f69c6ee4b9f5c5381a03390ce6de5f37f4 Mon Sep 17 00:00:00 2001
From: MayShao-oc <MayShao-oc@zhaoxin.com>
Date: Tue, 15 Oct 2024 08:53:54 +0800
Subject: [PATCH v2] x86: Support ZHAOXIN GMI
Hi all:
I refine the ZHAOXIN GMI patch, according to the very insightful
comments of Jan and Haochen.Thanks to Jan and Haochen.
Test ok, ok for trunk?
BR
Mayshao
gas/ChangeLog:
* NEWS: Support x86 ZHAOXIN GMI instructions.
* config/tc-i386.c: Add gmi.
* doc/c-i386.texi: Document gmi.
* testsuite/gas/i386/i386.exp: Add gmi test.
* testsuite/gas/i386/gmi.d: Ditto.
* testsuite/gas/i386/gmi.s: Ditto.
opcodes/ChangeLog:
* i386-dis.c (MONTMUL_Fixup): New fixup function to disassemble
montmul.
* i386-gen.c: Add gmi.
* i386-opc.h (CpuGMI): New.
* i386-opc.tbl: Add Zhaoxin GMI instructions.
* i386-tbl.h: Regenerated.
* i386-mnem.h: Ditto.
* i386-init.h: Ditto.
---
gas/NEWS | 2 ++
gas/config/tc-i386.c | 1 +
gas/doc/c-i386.texi | 6 ++--
gas/testsuite/gas/i386/gmi.d | 12 ++++++++
gas/testsuite/gas/i386/gmi.s | 8 ++++++
gas/testsuite/gas/i386/i386.exp | 1 +
opcodes/i386-dis.c | 49 ++++++++++++++++++++++++++++++++-
opcodes/i386-gen.c | 1 +
opcodes/i386-opc.h | 3 ++
opcodes/i386-opc.tbl | 5 ++++
10 files changed, 85 insertions(+), 3 deletions(-)
create mode 100644 gas/testsuite/gas/i386/gmi.d
create mode 100644 gas/testsuite/gas/i386/gmi.s
diff --git a/gas/NEWS b/gas/NEWS
index d64330143b0..053b2bcac87 100644
--- a/gas/NEWS
+++ b/gas/NEWS
@@ -5,6 +5,8 @@
* Add support for RISC-V Zcmp (cm.mva01s, cm.mvsa01), Smrnmi and CORE-V
(xcvbitmanip, xcvsimd) extensions with version 1.0.
+* Add support for the x86 Zhaoxin GMI instructions.
+
Changes in 2.43:
* Add support for LoongArch .option for fine-grained control of assembly
diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c
index cdefde03717..735154ee721 100644
--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -1219,6 +1219,7 @@ static const arch_entry cpu_arch[] =
SUBARCH (user_msr, USER_MSR, USER_MSR, false),
SUBARCH (apx_f, APX_F, APX_F, false),
VECARCH (avx10.2, AVX10_2, ANY_AVX10_2, set),
+ SUBARCH (gmi, GMI, GMI, false),
};
#undef SUBARCH
diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi
index 9667061752d..952ddbc7377 100644
--- a/gas/doc/c-i386.texi
+++ b/gas/doc/c-i386.texi
@@ -274,7 +274,8 @@ accept various extension mnemonics. For example,
@code{snp},
@code{invlpgb},
@code{tlbsync},
-@code{svme} and
+@code{svme},
+@code{gmi} and
@code{padlock}.
Note that these extension mnemonics can be prefixed with @code{no} to revoke
the respective (and any dependent) functionality. Note further that the
@@ -1705,7 +1706,8 @@ supported on the CPU specified. The choices for @var{cpu_type} are:
@item @samp{.lwp} @tab @samp{.fma4} @tab @samp{.xop} @tab @samp{.cx16}
@item @samp{.padlock} @tab @samp{.clzero} @tab @samp{.mwaitx} @tab @samp{.rdpru}
@item @samp{.mcommit} @tab @samp{.sev_es} @tab @samp{.snp} @tab @samp{.invlpgb}
-@item @samp{.tlbsync} @tab @samp{.apx_f}
+@item @samp{.tlbsync} @tab @samp{.apx_f} @tab @samp{.gmi}
+
@end multitable
Apart from the warning, there are only two other effects on
diff --git a/gas/testsuite/gas/i386/gmi.d b/gas/testsuite/gas/i386/gmi.d
new file mode 100644
index 00000000000..063da8e120a
--- /dev/null
+++ b/gas/testsuite/gas/i386/gmi.d
@@ -0,0 +1,12 @@
+#objdump: -dw
+#name: zhaoxin gmi
+
+.*: +file format .*
+
+Disassembly of section .text:
+
+0+000 <foo>:
+ 0:[ ]*f2 0f a6 c0 [ ]*sm2
+ 4:[ ]*f3 0f a6 e8 [ ]*sm3
+ 8:[ ]*f3 0f a7 f0 [ ]*sm4
+#pass
diff --git a/gas/testsuite/gas/i386/gmi.s b/gas/testsuite/gas/i386/gmi.s
new file mode 100644
index 00000000000..c412de55d31
--- /dev/null
+++ b/gas/testsuite/gas/i386/gmi.s
@@ -0,0 +1,8 @@
+# ZHAOXIN GMI instructions
+
+ .text
+foo:
+ sm2
+ sm3
+ sm4
+ .p2align 4,0
diff --git a/gas/testsuite/gas/i386/i386.exp b/gas/testsuite/gas/i386/i386.exp
index 699e2004bef..4aaa2239069 100644
--- a/gas/testsuite/gas/i386/i386.exp
+++ b/gas/testsuite/gas/i386/i386.exp
@@ -114,6 +114,7 @@ if [gas_32_check] then {
run_dump_test "quoted2"
run_dump_test "unary"
run_dump_test "padlock"
+ run_dump_test "gmi"
run_dump_test "crx"
run_list_test "cr-err" ""
run_dump_test "cdr"
diff --git a/opcodes/i386-dis.c b/opcodes/i386-dis.c
index 3a4af4d61a3..e012937e303 100644
--- a/opcodes/i386-dis.c
+++ b/opcodes/i386-dis.c
@@ -90,6 +90,7 @@ static bool PCLMUL_Fixup (instr_info *, int, int);
static bool VPCMP_Fixup (instr_info *, int, int);
static bool VPCOM_Fixup (instr_info *, int, int);
static bool NOP_Fixup (instr_info *, int, int);
+static bool MONTMUL_Fixup (instr_info *, int, int);
static bool OP_3DNowSuffix (instr_info *, int, int);
static bool CMP_Fixup (instr_info *, int, int);
static bool REP_Fixup (instr_info *, int, int);
@@ -1050,6 +1051,9 @@ enum
PREFIX_0F7D,
PREFIX_0F7E,
PREFIX_0F7F,
+ PREFIX_0FA6_REG_0_MOD_3,
+ PREFIX_0FA6_REG_5_MOD_3,
+ PREFIX_0FA7_REG_6_MOD_3,
PREFIX_0FAE_REG_0_MOD_3,
PREFIX_0FAE_REG_1_MOD_3,
PREFIX_0FAE_REG_2_MOD_3,
@@ -2850,9 +2854,12 @@ static const struct dis386 reg_table[][8] = {
},
/* REG_0FA6 */
{
- { "montmul", { { OP_0f07, 0 } }, 0 },
+ { PREFIX_TABLE (PREFIX_0FA6_REG_0_MOD_3) },
{ "xsha1", { { OP_0f07, 0 } }, 0 },
{ "xsha256", { { OP_0f07, 0 } }, 0 },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { PREFIX_TABLE (PREFIX_0FA6_REG_5_MOD_3) },
},
/* REG_0FA7 */
{
@@ -2862,6 +2869,7 @@ static const struct dis386 reg_table[][8] = {
{ "xcrypt-ctr", { { OP_0f07, 0 } }, 0 },
{ "xcrypt-cfb", { { OP_0f07, 0 } }, 0 },
{ "xcrypt-ofb", { { OP_0f07, 0 } }, 0 },
+ { PREFIX_TABLE (PREFIX_0FA7_REG_6_MOD_3) },
},
/* REG_0FAE */
{
@@ -3438,6 +3446,30 @@ static const struct dis386 prefix_table[][4] = {
{ "movdqa", { EXxS, XM }, PREFIX_OPCODE },
},
+ /* PREFIX_0FA6_REG_0_MOD_3 */
+ {
+ { Bad_Opcode },
+ { "montmul", { { MONTMUL_Fixup, 0 } }, 0},
+ { Bad_Opcode },
+ { "sm2", { Skip_MODRM }, 0 },
+ },
+
+ /* PREFIX_0FA6_REG_5_MOD_3 */
+ {
+ { Bad_Opcode },
+ { "sm3", { Skip_MODRM }, 0 },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ },
+
+ /* PREFIX_0FA7_REG_6_MOD_3 */
+ {
+ { Bad_Opcode },
+ { "sm4", { Skip_MODRM }, 0 },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ },
+
/* PREFIX_0FAE_REG_0_MOD_3 */
{
{ Bad_Opcode },
@@ -13086,6 +13118,21 @@ OP_0f07 (instr_info *ins, int bytemode, int sizeflag)
return OP_E (ins, bytemode, sizeflag);
}
+/* montmul instruction need display repz and skip modrm */
+
+static bool
+MONTMUL_Fixup (instr_info *ins, int bytemode, int sizeflag)
+{
+ (void) bytemode;
+ (void) sizeflag;
+ /* The 0xf3 prefix should be displayed as "repz" for montmul. */
+ if (ins->prefixes & PREFIX_REPZ)
+ ins->all_prefixes[ins->last_repz_prefix] = 0xf3;
+ ins->codep++;
+ ins->has_skipped_modrm = true;
+ return true;
+}
+
/* NOP is an alias of "xchg %ax,%ax" in 16bit mode, "xchg %eax,%eax" in
32bit mode and "xchg %rax,%rax" in 64bit mode. */
diff --git a/opcodes/i386-gen.c b/opcodes/i386-gen.c
index 565aae722f8..0f7ab4c6a56 100644
--- a/opcodes/i386-gen.c
+++ b/opcodes/i386-gen.c
@@ -334,6 +334,7 @@ static bitfield cpu_flags[] =
BITFIELD (3dnow),
BITFIELD (3dnowA),
BITFIELD (PadLock),
+ BITFIELD (GMI),
BITFIELD (SVME),
BITFIELD (VMX),
BITFIELD (SMX),
diff --git a/opcodes/i386-opc.h b/opcodes/i386-opc.h
index c0d5e44d461..d404fbc6b05 100644
--- a/opcodes/i386-opc.h
+++ b/opcodes/i386-opc.h
@@ -66,6 +66,8 @@ enum i386_cpu
CpuSSE3,
/* VIA PadLock required */
CpuPadLock,
+ /* ZHAOXIN GMI required */
+ CpuGMI,
/* AMD Secure Virtual Machine Ext-s required */
CpuSVME,
/* VMX Instructions required */
@@ -400,6 +402,7 @@ typedef union i386_cpu_flags
unsigned int cpusse2:1;
unsigned int cpusse3:1;
unsigned int cpupadlock:1;
+ unsigned int cpugmi:1;
unsigned int cpusvme:1;
unsigned int cpuvmx:1;
unsigned int cpusmx:1;
diff --git a/opcodes/i386-opc.tbl b/opcodes/i386-opc.tbl
index 9a14a4d1819..7ded4e64133 100644
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -2131,6 +2131,11 @@ xcryptofb, 0xf30fa7e8, PadLock, NoSuf|RepPrefixOk, {}
// Alias for xstore-rng.
xstore, 0xfa7c0, PadLock, NoSuf|RepPrefixOk, {}
+// ZHAOXIN GMI instructions
+sm2, 0xf20fa6c0, GMI, NoSuf, {}
+sm3, 0xf30fa6e8, GMI, NoSuf, {}
+sm4, 0xf30fa7f0, GMI, NoSuf, {}
+
// Multy-precision Add Carry, rdseed instructions.
<adx:pfx, c:66, o:f3>
ad<adx>x, 0x<adx:pfx>66, ADX&APX_F, C|Modrm|CheckOperandSize|No_bSuf|No_wSuf|No_sSuf|DstVVVV|EVexMap4, { Reg32|Reg64|Unspecified|BaseIndex, Reg32|Reg64, Reg32|Reg64 }
--
2.27.0
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v1] x86: Support ZHAOXIN GMI instructions
2024-10-14 6:54 ` Jan Beulich
2024-10-14 8:37 ` Jiang, Haochen
@ 2024-10-15 1:31 ` mayshao-oc
1 sibling, 0 replies; 80+ messages in thread
From: mayshao-oc @ 2024-10-15 1:31 UTC (permalink / raw)
To: Jan Beulich; +Cc: H.J. Lu, Jiang, Haochen, timhu, louisqi, cobechen, binutils
Hi Jan:
On 10/14/24 14:54, Jan Beulich wrote:
>
>
>
> On 14.10.2024 04:03, mayshao-oc wrote:
>> This patch adds support for Zhaoxin GMI instructions.
>> The documentation is attached for your reference.
>> Test ok, ok for trunk?
>
> In the NEWS entry, please add "x86" one way or another. Not everyone may
> know that Zhaoxin is an x86 flavor. Also the entry needs to move up, into
> the post-2.43 section.
>
Thanks for your comment, I fix it in the GMI v2 patch.
> For the i386-gen change I wonder whether GMI is an entirely separate
> extension, or kind of an extension to PadLock. Can you clarify the
> relationship please?
GMI is an entirely separate extension. GMI includes sm2, sm3, sm4
algorithms, and padlock includes RNG, AES, SHA, RSA algorithms, so they
are different.
>
> In i386-dis.c, if - following earlier comments - you still need some fixup
> function(s), please name them suitably. The pre-existing OP_0f07() is
> grossly misnamed, and that misnaming shouldn't be further extendedI will take care of the function name next time, and thanks for your
comment. From the comments and code, I learned something about
programming. I name the fixup function MONTMUL_Fixup in the GMI v2
patch, maybe there is a better idea?
> Jan
BR
Mayshao
^ permalink raw reply [flat|nested] 80+ messages in thread
* RE: [PATCH v2] x86: Support ZHAOXIN GMI instructions
2024-10-15 1:19 ` [PATCH v2] " mayshao-oc
@ 2024-10-15 3:02 ` Jiang, Haochen
2024-10-15 5:53 ` Jan Beulich
2024-10-15 6:51 ` [PATCH v2] " mayshao-oc
0 siblings, 2 replies; 80+ messages in thread
From: Jiang, Haochen @ 2024-10-15 3:02 UTC (permalink / raw)
To: mayshao-oc, Beulich, Jan; +Cc: H.J. Lu, timhu, louisqi, cobechen, binutils
> From: mayshao-oc <mayshao-oc@zhaoxin.com>
> Sent: Tuesday, October 15, 2024 9:19 AM
>
> Hi all:
>
> Thanks for the very insightful comments of Jan hand haochen, I refine the
> patch.
> Test ok, ok for trunk?
@@ -1050,6 +1051,9 @@ enum
PREFIX_0F7D,
PREFIX_0F7E,
PREFIX_0F7F,
+ PREFIX_0FA6_REG_0_MOD_3,
+ PREFIX_0FA6_REG_5_MOD_3,
+ PREFIX_0FA7_REG_6_MOD_3,
PREFIX_0FAE_REG_0_MOD_3,
PREFIX_0FAE_REG_1_MOD_3,
PREFIX_0FAE_REG_2_MOD_3,
I suppose the table entries here do not need _MOD_3 suffix since it did not use
mod_table[].
+ /* PREFIX_0FA6_REG_5_MOD_3 */
+ {
+ { Bad_Opcode },
+ { "sm3", { Skip_MODRM }, 0 },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ },
+
+ /* PREFIX_0FA7_REG_6_MOD_3 */
+ {
+ { Bad_Opcode },
+ { "sm4", { Skip_MODRM }, 0 },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ },
+
The Bad_Opcode could be omitted if they are at the end of
a table.
@@ -13086,6 +13118,21 @@ OP_0f07 (instr_info *ins, int bytemode, int sizeflag)
return OP_E (ins, bytemode, sizeflag);
}
+/* montmul instruction need display repz and skip modrm */
+
+static bool
+MONTMUL_Fixup (instr_info *ins, int bytemode, int sizeflag)
+{
+ (void) bytemode;
+ (void) sizeflag;
What are these two lines for? And you will need MODRM_CHECK;
and modrm.mod invalid check. You could take OP_Skip_MODRM
as reference.
+ /* The 0xf3 prefix should be displayed as "repz" for montmul. */
+ if (ins->prefixes & PREFIX_REPZ)
+ ins->all_prefixes[ins->last_repz_prefix] = 0xf3;
+ ins->codep++;
+ ins->has_skipped_modrm = true;
+ return true;
+}
+
I still don't know why original montmul will display repz prefix although
the testcase does show that. I checked the PadLock doc but got no clue
and even more confused. Could you explain why?
Also, in gas/NEWS, could you put the entry at the very beginning?
Thx,
Haochen
>
> BR
> Mayshao
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v2] x86: Support ZHAOXIN GMI instructions
2024-10-15 3:02 ` Jiang, Haochen
@ 2024-10-15 5:53 ` Jan Beulich
2024-10-15 7:32 ` [PATCH v3] " mayshao-oc
2024-10-15 6:51 ` [PATCH v2] " mayshao-oc
1 sibling, 1 reply; 80+ messages in thread
From: Jan Beulich @ 2024-10-15 5:53 UTC (permalink / raw)
To: Jiang, Haochen, mayshao-oc; +Cc: H.J. Lu, timhu, louisqi, cobechen, binutils
On 15.10.2024 05:02, Jiang, Haochen wrote:
>> From: mayshao-oc <mayshao-oc@zhaoxin.com>
>> Sent: Tuesday, October 15, 2024 9:19 AM
>>
> @@ -13086,6 +13118,21 @@ OP_0f07 (instr_info *ins, int bytemode, int sizeflag)
> return OP_E (ins, bytemode, sizeflag);
> }
>
> +/* montmul instruction need display repz and skip modrm */
> +
> +static bool
> +MONTMUL_Fixup (instr_info *ins, int bytemode, int sizeflag)
> +{
> + (void) bytemode;
> + (void) sizeflag;
>
> What are these two lines for?
ATTRIBUTE_UNUSED wants using instead.
> And you will need MODRM_CHECK;
> and modrm.mod invalid check. You could take OP_Skip_MODRM
> as reference.
I think OP_Skip_MODRM() simply wants invoking from here. That'll
deal with ...
> + /* The 0xf3 prefix should be displayed as "repz" for montmul. */
> + if (ins->prefixes & PREFIX_REPZ)
> + ins->all_prefixes[ins->last_repz_prefix] = 0xf3;
> + ins->codep++;
> + ins->has_skipped_modrm = true;
> + return true;
> +}
... part of the omissions: Right now both modrm.mod and modrm.rm
aren't being checked here.
> Also, in gas/NEWS, could you put the entry at the very beginning?
I don't think the placement there matters much, as long as it's in the
correct section.
Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v2] x86: Support ZHAOXIN GMI instructions
2024-10-15 3:02 ` Jiang, Haochen
2024-10-15 5:53 ` Jan Beulich
@ 2024-10-15 6:51 ` mayshao-oc
2024-10-15 11:18 ` Jan Beulich
2024-10-16 2:08 ` Jiang, Haochen
1 sibling, 2 replies; 80+ messages in thread
From: mayshao-oc @ 2024-10-15 6:51 UTC (permalink / raw)
To: Jiang, Haochen, Beulich, Jan; +Cc: H.J. Lu, timhu, louisqi, cobechen, binutils
Hi Haochen:
On 10/15/24 11:02, Jiang, Haochen wrote:
>
>
>
>> From: mayshao-oc <mayshao-oc@zhaoxin.com>
>> Sent: Tuesday, October 15, 2024 9:19 AM
>>
>> Hi all:
>>
>> Thanks for the very insightful comments of Jan hand haochen, I refine the
>> patch.
>> Test ok, ok for trunk?
>
> @@ -1050,6 +1051,9 @@ enum
> PREFIX_0F7D,
> PREFIX_0F7E,
> PREFIX_0F7F,
> + PREFIX_0FA6_REG_0_MOD_3,
> + PREFIX_0FA6_REG_5_MOD_3,
> + PREFIX_0FA7_REG_6_MOD_3,
> PREFIX_0FAE_REG_0_MOD_3,
> PREFIX_0FAE_REG_1_MOD_3,
> PREFIX_0FAE_REG_2_MOD_3,
>
> I suppose the table entries here do not need _MOD_3 suffix since it did not use
> mod_table[].
I suppose use mod_table[] is not a prerequisite to define a enum
constant, I trade readability for simplicity. I define it like this,
because it has mod value, not since it use mod_table. And there are
examples to use MOD in it's name, but don't use mod_table,
PREFIX_0FAE_REG_5_MOD_3.Correct me if I am wrong.
>
>
> + /* PREFIX_0FA6_REG_5_MOD_3 */
> + {
> + { Bad_Opcode },
> + { "sm3", { Skip_MODRM }, 0 },
> + { Bad_Opcode },
> + { Bad_Opcode },
> + },
> +
> + /* PREFIX_0FA7_REG_6_MOD_3 */
> + {
> + { Bad_Opcode },
> + { "sm4", { Skip_MODRM }, 0 },
> + { Bad_Opcode },
> + { Bad_Opcode },
> + },
> +
>
> The Bad_Opcode could be omitted if they are at the end of
> a table.
As above, I think its a code style issue, and there are some Bad_Opcode
at the end of a table, like in PREFIX_0F01_REG_1_RM_4,
PREFIX_0F01_REG_1_RM_5. And I think Bad_Opcode is a placeholder, and
there is no detrimental effect to define some Bad_Opcode at the end of a
table. Correct me if I am wrong.
>
> @@ -13086,6 +13118,21 @@ OP_0f07 (instr_info *ins, int bytemode, int sizeflag)
> return OP_E (ins, bytemode, sizeflag);
> }
>
> +/* montmul instruction need display repz and skip modrm */
> +
> +static bool
> +MONTMUL_Fixup (instr_info *ins, int bytemode, int sizeflag)
> +{
> + (void) bytemode;
> + (void) sizeflag;
>
> What are these two lines for? And you will need MODRM_CHECK;
> and modrm.mod invalid check. You could take OP_Skip_MODRM
> as reference.
>
These two lines are added to avoid the "unused parameter error",
ATTIBUTE_UNUSED is a elegant way to do this.
I don't figure out why I need MODRM_CHECK, MODRM_CHECK could prevent
what risk.
> + /* The 0xf3 prefix should be displayed as "repz" for montmul. */
> + if (ins->prefixes & PREFIX_REPZ)
> + ins->all_prefixes[ins->last_repz_prefix] = 0xf3;
> + ins->codep++;
> + ins->has_skipped_modrm = true;
> + return true;
> +}
> +
>
> I still don't know why original montmul will display repz prefix although
> the testcase does show that. I checked the PadLock doc but got no clue
> and even more confused. Could you explain why?
>
I don't know why, I just do this for the backward compatibility. From my
own perspective, there is no need to display repz, because there is no
rep related meaning for the montmul instruction in the padlock doc. But
I don't want to make the legacy padlock testsuite fail.
> Also, in gas/NEWS, could you put the entry at the very beginning?
>
> Thx,
> Haochen
>
>>
>> BR
>> Mayshao
BR
Mayshao
^ permalink raw reply [flat|nested] 80+ messages in thread
* [PATCH v3] x86: Support ZHAOXIN GMI instructions
2024-10-15 5:53 ` Jan Beulich
@ 2024-10-15 7:32 ` mayshao-oc
0 siblings, 0 replies; 80+ messages in thread
From: mayshao-oc @ 2024-10-15 7:32 UTC (permalink / raw)
To: Jan Beulich, Jiang, Haochen; +Cc: H.J. Lu, timhu, louisqi, cobechen, binutils
[-- Attachment #1: Type: text/plain, Size: 229 bytes --]
Hi all:
According to the review of haochen and Jan, I refine the patch.
Only the enum constant name is not changed, other issues are changed
accordingly.
Thanks for your comment, test ok, ok for trunk?
BR
Mayshao
[-- Attachment #2: gmi_v3.patch --]
[-- Type: text/x-patch, Size: 8497 bytes --]
From 1fe980b6da097faabe3e755d9253ad101d2a42c2 Mon Sep 17 00:00:00 2001
From: MayShao-oc <MayShao-oc@zhaoxin.com>
Date: Tue, 15 Oct 2024 15:22:49 +0800
Subject: [PATCH v3] x86: Support x86 ZHAOXIN GMI instructions
Hi all:
I refine the ZHAOXIN GMI patch, please review.
BR
Mayshao
gas/ChangeLog:
* NEWS: Support ZHAOXIN GMI instructions.
* config/tc-i386.c: Add gmi.
* doc/c-i386.texi: Document gmi.
* testsuite/gas/i386/i386.exp: Add gmi test.
* testsuite/gas/i386/gmi.d: Ditto.
* testsuite/gas/i386/gmi.s: Ditto.
opcodes/ChangeLog:
* i386-dis.c: New comment.
* i386-gen.c: Add gmi.
* i386-opc.h (CpuGMI): New.
* i386-opc.tbl: Add Zhaoxin GMI instructions.
* i386-tbl.h: Regenerated.
* i386-mnem.h: Ditto.
* i386-init.h: Ditto.
---
gas/NEWS | 2 ++
gas/config/tc-i386.c | 1 +
gas/doc/c-i386.texi | 6 +++--
gas/testsuite/gas/i386/gmi.d | 12 ++++++++++
gas/testsuite/gas/i386/gmi.s | 8 +++++++
gas/testsuite/gas/i386/i386.exp | 1 +
opcodes/i386-dis.c | 41 ++++++++++++++++++++++++++++++++-
opcodes/i386-gen.c | 1 +
opcodes/i386-opc.h | 3 +++
opcodes/i386-opc.tbl | 5 ++++
10 files changed, 77 insertions(+), 3 deletions(-)
create mode 100644 gas/testsuite/gas/i386/gmi.d
create mode 100644 gas/testsuite/gas/i386/gmi.s
diff --git a/gas/NEWS b/gas/NEWS
index d64330143b0..d4c571f3474 100644
--- a/gas/NEWS
+++ b/gas/NEWS
@@ -1,5 +1,7 @@
-*- text -*-
+* Add support for the x86 Zhaoxin GMI instructions.
+
* On x86 emulation support (for secondary targets) was dropped.
* Add support for RISC-V Zcmp (cm.mva01s, cm.mvsa01), Smrnmi and CORE-V
diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c
index cdefde03717..735154ee721 100644
--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -1219,6 +1219,7 @@ static const arch_entry cpu_arch[] =
SUBARCH (user_msr, USER_MSR, USER_MSR, false),
SUBARCH (apx_f, APX_F, APX_F, false),
VECARCH (avx10.2, AVX10_2, ANY_AVX10_2, set),
+ SUBARCH (gmi, GMI, GMI, false),
};
#undef SUBARCH
diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi
index 9667061752d..952ddbc7377 100644
--- a/gas/doc/c-i386.texi
+++ b/gas/doc/c-i386.texi
@@ -274,7 +274,8 @@ accept various extension mnemonics. For example,
@code{snp},
@code{invlpgb},
@code{tlbsync},
-@code{svme} and
+@code{svme},
+@code{gmi} and
@code{padlock}.
Note that these extension mnemonics can be prefixed with @code{no} to revoke
the respective (and any dependent) functionality. Note further that the
@@ -1705,7 +1706,8 @@ supported on the CPU specified. The choices for @var{cpu_type} are:
@item @samp{.lwp} @tab @samp{.fma4} @tab @samp{.xop} @tab @samp{.cx16}
@item @samp{.padlock} @tab @samp{.clzero} @tab @samp{.mwaitx} @tab @samp{.rdpru}
@item @samp{.mcommit} @tab @samp{.sev_es} @tab @samp{.snp} @tab @samp{.invlpgb}
-@item @samp{.tlbsync} @tab @samp{.apx_f}
+@item @samp{.tlbsync} @tab @samp{.apx_f} @tab @samp{.gmi}
+
@end multitable
Apart from the warning, there are only two other effects on
diff --git a/gas/testsuite/gas/i386/gmi.d b/gas/testsuite/gas/i386/gmi.d
new file mode 100644
index 00000000000..063da8e120a
--- /dev/null
+++ b/gas/testsuite/gas/i386/gmi.d
@@ -0,0 +1,12 @@
+#objdump: -dw
+#name: zhaoxin gmi
+
+.*: +file format .*
+
+Disassembly of section .text:
+
+0+000 <foo>:
+ 0:[ ]*f2 0f a6 c0 [ ]*sm2
+ 4:[ ]*f3 0f a6 e8 [ ]*sm3
+ 8:[ ]*f3 0f a7 f0 [ ]*sm4
+#pass
diff --git a/gas/testsuite/gas/i386/gmi.s b/gas/testsuite/gas/i386/gmi.s
new file mode 100644
index 00000000000..c412de55d31
--- /dev/null
+++ b/gas/testsuite/gas/i386/gmi.s
@@ -0,0 +1,8 @@
+# ZHAOXIN GMI instructions
+
+ .text
+foo:
+ sm2
+ sm3
+ sm4
+ .p2align 4,0
diff --git a/gas/testsuite/gas/i386/i386.exp b/gas/testsuite/gas/i386/i386.exp
index 699e2004bef..4aaa2239069 100644
--- a/gas/testsuite/gas/i386/i386.exp
+++ b/gas/testsuite/gas/i386/i386.exp
@@ -114,6 +114,7 @@ if [gas_32_check] then {
run_dump_test "quoted2"
run_dump_test "unary"
run_dump_test "padlock"
+ run_dump_test "gmi"
run_dump_test "crx"
run_list_test "cr-err" ""
run_dump_test "cdr"
diff --git a/opcodes/i386-dis.c b/opcodes/i386-dis.c
index 3a4af4d61a3..61a940e5a57 100644
--- a/opcodes/i386-dis.c
+++ b/opcodes/i386-dis.c
@@ -90,6 +90,7 @@ static bool PCLMUL_Fixup (instr_info *, int, int);
static bool VPCMP_Fixup (instr_info *, int, int);
static bool VPCOM_Fixup (instr_info *, int, int);
static bool NOP_Fixup (instr_info *, int, int);
+static bool MONTMUL_Fixup (instr_info *, int, int);
static bool OP_3DNowSuffix (instr_info *, int, int);
static bool CMP_Fixup (instr_info *, int, int);
static bool REP_Fixup (instr_info *, int, int);
@@ -1050,6 +1051,9 @@ enum
PREFIX_0F7D,
PREFIX_0F7E,
PREFIX_0F7F,
+ PREFIX_0FA6_REG_0_MOD_3,
+ PREFIX_0FA6_REG_5_MOD_3,
+ PREFIX_0FA7_REG_6_MOD_3,
PREFIX_0FAE_REG_0_MOD_3,
PREFIX_0FAE_REG_1_MOD_3,
PREFIX_0FAE_REG_2_MOD_3,
@@ -2850,9 +2854,12 @@ static const struct dis386 reg_table[][8] = {
},
/* REG_0FA6 */
{
- { "montmul", { { OP_0f07, 0 } }, 0 },
+ { PREFIX_TABLE (PREFIX_0FA6_REG_0_MOD_3) },
{ "xsha1", { { OP_0f07, 0 } }, 0 },
{ "xsha256", { { OP_0f07, 0 } }, 0 },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { PREFIX_TABLE (PREFIX_0FA6_REG_5_MOD_3) },
},
/* REG_0FA7 */
{
@@ -2862,6 +2869,7 @@ static const struct dis386 reg_table[][8] = {
{ "xcrypt-ctr", { { OP_0f07, 0 } }, 0 },
{ "xcrypt-cfb", { { OP_0f07, 0 } }, 0 },
{ "xcrypt-ofb", { { OP_0f07, 0 } }, 0 },
+ { PREFIX_TABLE (PREFIX_0FA7_REG_6_MOD_3) },
},
/* REG_0FAE */
{
@@ -3438,6 +3446,26 @@ static const struct dis386 prefix_table[][4] = {
{ "movdqa", { EXxS, XM }, PREFIX_OPCODE },
},
+ /* PREFIX_0FA6_REG_0_MOD_3 */
+ {
+ { Bad_Opcode },
+ { "montmul", { { MONTMUL_Fixup, 0 } }, 0},
+ { Bad_Opcode },
+ { "sm2", { Skip_MODRM }, 0 },
+ },
+
+ /* PREFIX_0FA6_REG_5_MOD_3 */
+ {
+ { Bad_Opcode },
+ { "sm3", { Skip_MODRM }, 0 },
+ },
+
+ /* PREFIX_0FA7_REG_6_MOD_3 */
+ {
+ { Bad_Opcode },
+ { "sm4", { Skip_MODRM }, 0 },
+ },
+
/* PREFIX_0FAE_REG_0_MOD_3 */
{
{ Bad_Opcode },
@@ -13086,6 +13114,17 @@ OP_0f07 (instr_info *ins, int bytemode, int sizeflag)
return OP_E (ins, bytemode, sizeflag);
}
+/* montmul instruction need display repz and skip modrm */
+
+static bool
+MONTMUL_Fixup (instr_info *ins, int bytemode, int sizeflag)
+{
+ /* The 0xf3 prefix should be displayed as "repz" for montmul. */
+ if (ins->prefixes & PREFIX_REPZ)
+ ins->all_prefixes[ins->last_repz_prefix] = 0xf3;
+ return OP_Skip_MODRM(ins, bytemode, sizeflag);
+}
+
/* NOP is an alias of "xchg %ax,%ax" in 16bit mode, "xchg %eax,%eax" in
32bit mode and "xchg %rax,%rax" in 64bit mode. */
diff --git a/opcodes/i386-gen.c b/opcodes/i386-gen.c
index 565aae722f8..0f7ab4c6a56 100644
--- a/opcodes/i386-gen.c
+++ b/opcodes/i386-gen.c
@@ -334,6 +334,7 @@ static bitfield cpu_flags[] =
BITFIELD (3dnow),
BITFIELD (3dnowA),
BITFIELD (PadLock),
+ BITFIELD (GMI),
BITFIELD (SVME),
BITFIELD (VMX),
BITFIELD (SMX),
diff --git a/opcodes/i386-opc.h b/opcodes/i386-opc.h
index c0d5e44d461..d404fbc6b05 100644
--- a/opcodes/i386-opc.h
+++ b/opcodes/i386-opc.h
@@ -66,6 +66,8 @@ enum i386_cpu
CpuSSE3,
/* VIA PadLock required */
CpuPadLock,
+ /* ZHAOXIN GMI required */
+ CpuGMI,
/* AMD Secure Virtual Machine Ext-s required */
CpuSVME,
/* VMX Instructions required */
@@ -400,6 +402,7 @@ typedef union i386_cpu_flags
unsigned int cpusse2:1;
unsigned int cpusse3:1;
unsigned int cpupadlock:1;
+ unsigned int cpugmi:1;
unsigned int cpusvme:1;
unsigned int cpuvmx:1;
unsigned int cpusmx:1;
diff --git a/opcodes/i386-opc.tbl b/opcodes/i386-opc.tbl
index 9a14a4d1819..7ded4e64133 100644
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -2131,6 +2131,11 @@ xcryptofb, 0xf30fa7e8, PadLock, NoSuf|RepPrefixOk, {}
// Alias for xstore-rng.
xstore, 0xfa7c0, PadLock, NoSuf|RepPrefixOk, {}
+// ZHAOXIN GMI instructions
+sm2, 0xf20fa6c0, GMI, NoSuf, {}
+sm3, 0xf30fa6e8, GMI, NoSuf, {}
+sm4, 0xf30fa7f0, GMI, NoSuf, {}
+
// Multy-precision Add Carry, rdseed instructions.
<adx:pfx, c:66, o:f3>
ad<adx>x, 0x<adx:pfx>66, ADX&APX_F, C|Modrm|CheckOperandSize|No_bSuf|No_wSuf|No_sSuf|DstVVVV|EVexMap4, { Reg32|Reg64|Unspecified|BaseIndex, Reg32|Reg64, Reg32|Reg64 }
--
2.27.0
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v2] x86: Support ZHAOXIN GMI instructions
2024-10-15 6:51 ` [PATCH v2] " mayshao-oc
@ 2024-10-15 11:18 ` Jan Beulich
2024-10-15 11:44 ` mayshao-oc
2024-10-16 2:08 ` Jiang, Haochen
1 sibling, 1 reply; 80+ messages in thread
From: Jan Beulich @ 2024-10-15 11:18 UTC (permalink / raw)
To: mayshao-oc; +Cc: H.J. Lu, timhu, louisqi, cobechen, binutils, Jiang, Haochen
On 15.10.2024 08:51, mayshao-oc wrote:
> On 10/15/24 11:02, Jiang, Haochen wrote:
>>> From: mayshao-oc <mayshao-oc@zhaoxin.com>
>>> Sent: Tuesday, October 15, 2024 9:19 AM
>>>
>> @@ -1050,6 +1051,9 @@ enum
>> PREFIX_0F7D,
>> PREFIX_0F7E,
>> PREFIX_0F7F,
>> + PREFIX_0FA6_REG_0_MOD_3,
>> + PREFIX_0FA6_REG_5_MOD_3,
>> + PREFIX_0FA7_REG_6_MOD_3,
>> PREFIX_0FAE_REG_0_MOD_3,
>> PREFIX_0FAE_REG_1_MOD_3,
>> PREFIX_0FAE_REG_2_MOD_3,
>>
>> I suppose the table entries here do not need _MOD_3 suffix since it did not use
>> mod_table[].
> I suppose use mod_table[] is not a prerequisite to define a enum
> constant, I trade readability for simplicity. I define it like this,
> because it has mod value, not since it use mod_table. And there are
> examples to use MOD in it's name, but don't use mod_table,
> PREFIX_0FAE_REG_5_MOD_3.Correct me if I am wrong.
There may be misnamed enumerators, but we shouldn't repeat prior mistakes
(and I've tried to clean up some of that earlier on). The naming here is
strictly by what earlier decode steps were taken, and in what order.
>> + /* PREFIX_0FA6_REG_5_MOD_3 */
>> + {
>> + { Bad_Opcode },
>> + { "sm3", { Skip_MODRM }, 0 },
>> + { Bad_Opcode },
>> + { Bad_Opcode },
>> + },
>> +
>> + /* PREFIX_0FA7_REG_6_MOD_3 */
>> + {
>> + { Bad_Opcode },
>> + { "sm4", { Skip_MODRM }, 0 },
>> + { Bad_Opcode },
>> + { Bad_Opcode },
>> + },
>> +
>>
>> The Bad_Opcode could be omitted if they are at the end of
>> a table.
> As above, I think its a code style issue, and there are some Bad_Opcode
> at the end of a table, like in PREFIX_0F01_REG_1_RM_4,
> PREFIX_0F01_REG_1_RM_5. And I think Bad_Opcode is a placeholder, and
> there is no detrimental effect to define some Bad_Opcode at the end of a
> table. Correct me if I am wrong.
While indeed largely a style issue, the file is too large already anyway,
so we prefer to omit from tables whatever can easily be omitted.
Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v2] x86: Support ZHAOXIN GMI instructions
2024-10-15 11:18 ` Jan Beulich
@ 2024-10-15 11:44 ` mayshao-oc
2024-10-16 6:47 ` Jan Beulich
0 siblings, 1 reply; 80+ messages in thread
From: mayshao-oc @ 2024-10-15 11:44 UTC (permalink / raw)
To: Jan Beulich; +Cc: H.J. Lu, timhu, louisqi, cobechen, binutils, Jiang, Haochen
[-- Attachment #1: Type: text/plain, Size: 2202 bytes --]
Hi Jan:
Thanks for your patience, and I refine the patch to name the
enumerators properly.
BR
Mayshao
On 10/15/24 19:18, Jan Beulich wrote:
>
>
>
> On 15.10.2024 08:51, mayshao-oc wrote:
>> On 10/15/24 11:02, Jiang, Haochen wrote:
>>>> From: mayshao-oc <mayshao-oc@zhaoxin.com>
>>>> Sent: Tuesday, October 15, 2024 9:19 AM
>>>>
>>> @@ -1050,6 +1051,9 @@ enum
>>> PREFIX_0F7D,
>>> PREFIX_0F7E,
>>> PREFIX_0F7F,
>>> + PREFIX_0FA6_REG_0_MOD_3,
>>> + PREFIX_0FA6_REG_5_MOD_3,
>>> + PREFIX_0FA7_REG_6_MOD_3,
>>> PREFIX_0FAE_REG_0_MOD_3,
>>> PREFIX_0FAE_REG_1_MOD_3,
>>> PREFIX_0FAE_REG_2_MOD_3,
>>>
>>> I suppose the table entries here do not need _MOD_3 suffix since it did not use
>>> mod_table[].
>> I suppose use mod_table[] is not a prerequisite to define a enum
>> constant, I trade readability for simplicity. I define it like this,
>> because it has mod value, not since it use mod_table. And there are
>> examples to use MOD in it's name, but don't use mod_table,
>> PREFIX_0FAE_REG_5_MOD_3.Correct me if I am wrong.
>
> There may be misnamed enumerators, but we shouldn't repeat prior mistakes
> (and I've tried to clean up some of that earlier on). The naming here is
> strictly by what earlier decode steps were taken, and in what order.
>
>>> + /* PREFIX_0FA6_REG_5_MOD_3 */
>>> + {
>>> + { Bad_Opcode },
>>> + { "sm3", { Skip_MODRM }, 0 },
>>> + { Bad_Opcode },
>>> + { Bad_Opcode },
>>> + },
>>> +
>>> + /* PREFIX_0FA7_REG_6_MOD_3 */
>>> + {
>>> + { Bad_Opcode },
>>> + { "sm4", { Skip_MODRM }, 0 },
>>> + { Bad_Opcode },
>>> + { Bad_Opcode },
>>> + },
>>> +
>>>
>>> The Bad_Opcode could be omitted if they are at the end of
>>> a table.
>> As above, I think its a code style issue, and there are some Bad_Opcode
>> at the end of a table, like in PREFIX_0F01_REG_1_RM_4,
>> PREFIX_0F01_REG_1_RM_5. And I think Bad_Opcode is a placeholder, and
>> there is no detrimental effect to define some Bad_Opcode at the end of a
>> table. Correct me if I am wrong.
>
> While indeed largely a style issue, the file is too large already anyway,
> so we prefer to omit from tables whatever can easily be omitted.
>
> Jan
[-- Attachment #2: gmi_v3_fix_mod.patch --]
[-- Type: text/x-patch, Size: 8443 bytes --]
From 1fe980b6da097faabe3e755d9253ad101d2a42c2 Mon Sep 17 00:00:00 2001
From: MayShao-oc <MayShao-oc@zhaoxin.com>
Date: Tue, 15 Oct 2024 15:22:49 +0800
Subject: [PATCH v3] x86: Support x86 ZHAOXIN GMI instructions
Hi all:
I refine the ZHAOXIN GMI patch, please review.
BR
Mayshao
gas/ChangeLog:
* NEWS: Support ZHAOXIN GMI instructions.
* config/tc-i386.c: Add gmi.
* doc/c-i386.texi: Document gmi.
* testsuite/gas/i386/i386.exp: Add gmi test.
* testsuite/gas/i386/gmi.d: Ditto.
* testsuite/gas/i386/gmi.s: Ditto.
opcodes/ChangeLog:
* i386-dis.c: New comment.
* i386-gen.c: Add gmi.
* i386-opc.h (CpuGMI): New.
* i386-opc.tbl: Add Zhaoxin GMI instructions.
* i386-tbl.h: Regenerated.
* i386-mnem.h: Ditto.
* i386-init.h: Ditto.
---
gas/NEWS | 2 ++
gas/config/tc-i386.c | 1 +
gas/doc/c-i386.texi | 6 +++--
gas/testsuite/gas/i386/gmi.d | 12 ++++++++++
gas/testsuite/gas/i386/gmi.s | 8 +++++++
gas/testsuite/gas/i386/i386.exp | 1 +
opcodes/i386-dis.c | 41 ++++++++++++++++++++++++++++++++-
opcodes/i386-gen.c | 1 +
opcodes/i386-opc.h | 3 +++
opcodes/i386-opc.tbl | 5 ++++
10 files changed, 77 insertions(+), 3 deletions(-)
create mode 100644 gas/testsuite/gas/i386/gmi.d
create mode 100644 gas/testsuite/gas/i386/gmi.s
diff --git a/gas/NEWS b/gas/NEWS
index d64330143b0..d4c571f3474 100644
--- a/gas/NEWS
+++ b/gas/NEWS
@@ -1,5 +1,7 @@
-*- text -*-
+* Add support for the x86 Zhaoxin GMI instructions.
+
* On x86 emulation support (for secondary targets) was dropped.
* Add support for RISC-V Zcmp (cm.mva01s, cm.mvsa01), Smrnmi and CORE-V
diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c
index cdefde03717..735154ee721 100644
--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -1219,6 +1219,7 @@ static const arch_entry cpu_arch[] =
SUBARCH (user_msr, USER_MSR, USER_MSR, false),
SUBARCH (apx_f, APX_F, APX_F, false),
VECARCH (avx10.2, AVX10_2, ANY_AVX10_2, set),
+ SUBARCH (gmi, GMI, GMI, false),
};
#undef SUBARCH
diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi
index 9667061752d..952ddbc7377 100644
--- a/gas/doc/c-i386.texi
+++ b/gas/doc/c-i386.texi
@@ -274,7 +274,8 @@ accept various extension mnemonics. For example,
@code{snp},
@code{invlpgb},
@code{tlbsync},
-@code{svme} and
+@code{svme},
+@code{gmi} and
@code{padlock}.
Note that these extension mnemonics can be prefixed with @code{no} to revoke
the respective (and any dependent) functionality. Note further that the
@@ -1705,7 +1706,8 @@ supported on the CPU specified. The choices for @var{cpu_type} are:
@item @samp{.lwp} @tab @samp{.fma4} @tab @samp{.xop} @tab @samp{.cx16}
@item @samp{.padlock} @tab @samp{.clzero} @tab @samp{.mwaitx} @tab @samp{.rdpru}
@item @samp{.mcommit} @tab @samp{.sev_es} @tab @samp{.snp} @tab @samp{.invlpgb}
-@item @samp{.tlbsync} @tab @samp{.apx_f}
+@item @samp{.tlbsync} @tab @samp{.apx_f} @tab @samp{.gmi}
+
@end multitable
Apart from the warning, there are only two other effects on
diff --git a/gas/testsuite/gas/i386/gmi.d b/gas/testsuite/gas/i386/gmi.d
new file mode 100644
index 00000000000..063da8e120a
--- /dev/null
+++ b/gas/testsuite/gas/i386/gmi.d
@@ -0,0 +1,12 @@
+#objdump: -dw
+#name: zhaoxin gmi
+
+.*: +file format .*
+
+Disassembly of section .text:
+
+0+000 <foo>:
+ 0:[ ]*f2 0f a6 c0 [ ]*sm2
+ 4:[ ]*f3 0f a6 e8 [ ]*sm3
+ 8:[ ]*f3 0f a7 f0 [ ]*sm4
+#pass
diff --git a/gas/testsuite/gas/i386/gmi.s b/gas/testsuite/gas/i386/gmi.s
new file mode 100644
index 00000000000..c412de55d31
--- /dev/null
+++ b/gas/testsuite/gas/i386/gmi.s
@@ -0,0 +1,8 @@
+# ZHAOXIN GMI instructions
+
+ .text
+foo:
+ sm2
+ sm3
+ sm4
+ .p2align 4,0
diff --git a/gas/testsuite/gas/i386/i386.exp b/gas/testsuite/gas/i386/i386.exp
index 699e2004bef..4aaa2239069 100644
--- a/gas/testsuite/gas/i386/i386.exp
+++ b/gas/testsuite/gas/i386/i386.exp
@@ -114,6 +114,7 @@ if [gas_32_check] then {
run_dump_test "quoted2"
run_dump_test "unary"
run_dump_test "padlock"
+ run_dump_test "gmi"
run_dump_test "crx"
run_list_test "cr-err" ""
run_dump_test "cdr"
diff --git a/opcodes/i386-dis.c b/opcodes/i386-dis.c
index 3a4af4d61a3..61a940e5a57 100644
--- a/opcodes/i386-dis.c
+++ b/opcodes/i386-dis.c
@@ -90,6 +90,7 @@ static bool PCLMUL_Fixup (instr_info *, int, int);
static bool VPCMP_Fixup (instr_info *, int, int);
static bool VPCOM_Fixup (instr_info *, int, int);
static bool NOP_Fixup (instr_info *, int, int);
+static bool MONTMUL_Fixup (instr_info *, int, int);
static bool OP_3DNowSuffix (instr_info *, int, int);
static bool CMP_Fixup (instr_info *, int, int);
static bool REP_Fixup (instr_info *, int, int);
@@ -1050,6 +1051,9 @@ enum
PREFIX_0F7D,
PREFIX_0F7E,
PREFIX_0F7F,
+ PREFIX_0FA6_REG_0,
+ PREFIX_0FA6_REG_5,
+ PREFIX_0FA7_REG_6,
PREFIX_0FAE_REG_0_MOD_3,
PREFIX_0FAE_REG_1_MOD_3,
PREFIX_0FAE_REG_2_MOD_3,
@@ -2850,9 +2854,12 @@ static const struct dis386 reg_table[][8] = {
},
/* REG_0FA6 */
{
- { "montmul", { { OP_0f07, 0 } }, 0 },
+ { PREFIX_TABLE (PREFIX_0FA6_REG_0) },
{ "xsha1", { { OP_0f07, 0 } }, 0 },
{ "xsha256", { { OP_0f07, 0 } }, 0 },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { PREFIX_TABLE (PREFIX_0FA6_REG_5) },
},
/* REG_0FA7 */
{
@@ -2862,6 +2869,7 @@ static const struct dis386 reg_table[][8] = {
{ "xcrypt-ctr", { { OP_0f07, 0 } }, 0 },
{ "xcrypt-cfb", { { OP_0f07, 0 } }, 0 },
{ "xcrypt-ofb", { { OP_0f07, 0 } }, 0 },
+ { PREFIX_TABLE (PREFIX_0FA7_REG_6) },
},
/* REG_0FAE */
{
@@ -3438,6 +3446,26 @@ static const struct dis386 prefix_table[][4] = {
{ "movdqa", { EXxS, XM }, PREFIX_OPCODE },
},
+ /* PREFIX_0FA6_REG_0 */
+ {
+ { Bad_Opcode },
+ { "montmul", { { MONTMUL_Fixup, 0 } }, 0},
+ { Bad_Opcode },
+ { "sm2", { Skip_MODRM }, 0 },
+ },
+
+ /* PREFIX_0FA6_REG_5 */
+ {
+ { Bad_Opcode },
+ { "sm3", { Skip_MODRM }, 0 },
+ },
+
+ /* PREFIX_0FA7_REG_6 */
+ {
+ { Bad_Opcode },
+ { "sm4", { Skip_MODRM }, 0 },
+ },
+
/* PREFIX_0FAE_REG_0_MOD_3 */
{
{ Bad_Opcode },
@@ -13086,6 +13114,17 @@ OP_0f07 (instr_info *ins, int bytemode, int sizeflag)
return OP_E (ins, bytemode, sizeflag);
}
+/* montmul instruction need display repz and skip modrm */
+
+static bool
+MONTMUL_Fixup (instr_info *ins, int bytemode, int sizeflag)
+{
+ /* The 0xf3 prefix should be displayed as "repz" for montmul. */
+ if (ins->prefixes & PREFIX_REPZ)
+ ins->all_prefixes[ins->last_repz_prefix] = 0xf3;
+ return OP_Skip_MODRM(ins, bytemode, sizeflag);
+}
+
/* NOP is an alias of "xchg %ax,%ax" in 16bit mode, "xchg %eax,%eax" in
32bit mode and "xchg %rax,%rax" in 64bit mode. */
diff --git a/opcodes/i386-gen.c b/opcodes/i386-gen.c
index 565aae722f8..0f7ab4c6a56 100644
--- a/opcodes/i386-gen.c
+++ b/opcodes/i386-gen.c
@@ -334,6 +334,7 @@ static bitfield cpu_flags[] =
BITFIELD (3dnow),
BITFIELD (3dnowA),
BITFIELD (PadLock),
+ BITFIELD (GMI),
BITFIELD (SVME),
BITFIELD (VMX),
BITFIELD (SMX),
diff --git a/opcodes/i386-opc.h b/opcodes/i386-opc.h
index c0d5e44d461..d404fbc6b05 100644
--- a/opcodes/i386-opc.h
+++ b/opcodes/i386-opc.h
@@ -66,6 +66,8 @@ enum i386_cpu
CpuSSE3,
/* VIA PadLock required */
CpuPadLock,
+ /* ZHAOXIN GMI required */
+ CpuGMI,
/* AMD Secure Virtual Machine Ext-s required */
CpuSVME,
/* VMX Instructions required */
@@ -400,6 +402,7 @@ typedef union i386_cpu_flags
unsigned int cpusse2:1;
unsigned int cpusse3:1;
unsigned int cpupadlock:1;
+ unsigned int cpugmi:1;
unsigned int cpusvme:1;
unsigned int cpuvmx:1;
unsigned int cpusmx:1;
diff --git a/opcodes/i386-opc.tbl b/opcodes/i386-opc.tbl
index 9a14a4d1819..7ded4e64133 100644
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -2131,6 +2131,11 @@ xcryptofb, 0xf30fa7e8, PadLock, NoSuf|RepPrefixOk, {}
// Alias for xstore-rng.
xstore, 0xfa7c0, PadLock, NoSuf|RepPrefixOk, {}
+// ZHAOXIN GMI instructions
+sm2, 0xf20fa6c0, GMI, NoSuf, {}
+sm3, 0xf30fa6e8, GMI, NoSuf, {}
+sm4, 0xf30fa7f0, GMI, NoSuf, {}
+
// Multy-precision Add Carry, rdseed instructions.
<adx:pfx, c:66, o:f3>
ad<adx>x, 0x<adx:pfx>66, ADX&APX_F, C|Modrm|CheckOperandSize|No_bSuf|No_wSuf|No_sSuf|DstVVVV|EVexMap4, { Reg32|Reg64|Unspecified|BaseIndex, Reg32|Reg64, Reg32|Reg64 }
--
2.27.0
^ permalink raw reply [flat|nested] 80+ messages in thread
* RE: [PATCH v2] x86: Support ZHAOXIN GMI instructions
2024-10-15 6:51 ` [PATCH v2] " mayshao-oc
2024-10-15 11:18 ` Jan Beulich
@ 2024-10-16 2:08 ` Jiang, Haochen
1 sibling, 0 replies; 80+ messages in thread
From: Jiang, Haochen @ 2024-10-16 2:08 UTC (permalink / raw)
To: mayshao-oc, Beulich, Jan; +Cc: H.J. Lu, timhu, louisqi, cobechen, binutils
> From: mayshao-oc <mayshao-oc@zhaoxin.com>
> Sent: Tuesday, October 15, 2024 2:52 PM
>
> >
> > I still don't know why original montmul will display repz prefix although
> > the testcase does show that. I checked the PadLock doc but got no clue
> > and even more confused. Could you explain why?
> >
> I don't know why, I just do this for the backward compatibility. From my
> own perspective, there is no need to display repz, because there is no
> rep related meaning for the montmul instruction in the padlock doc. But
> I don't want to make the legacy padlock testsuite fail.
Ok I see then.
I suppose disassembler display should not break anything and the current is
somehow buggy and testcase might need a change. But I am ok with keeping
them since the original implementation is 20 years ago and there might be some
reasons doing so. Not changing them is a safe choice.
Thx,
Haochen
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v2] x86: Support ZHAOXIN GMI instructions
2024-10-15 11:44 ` mayshao-oc
@ 2024-10-16 6:47 ` Jan Beulich
2024-10-16 7:48 ` mayshao-oc
0 siblings, 1 reply; 80+ messages in thread
From: Jan Beulich @ 2024-10-16 6:47 UTC (permalink / raw)
To: mayshao-oc; +Cc: H.J. Lu, timhu, louisqi, cobechen, binutils, Jiang, Haochen
On 15.10.2024 13:44, mayshao-oc wrote:
> Thanks for your patience, and I refine the patch to name the
> enumerators properly.
Just one remaining issue: In your switching to the use of OP_Skip_MODRM()
you lost (or forgot to add?) the ins->modrm.rm != 0 check that the mis-
named OP_0f07() has, and that also applies to these new insns (aiui).
Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v2] x86: Support ZHAOXIN GMI instructions
2024-10-16 6:47 ` Jan Beulich
@ 2024-10-16 7:48 ` mayshao-oc
2024-10-16 9:22 ` Jan Beulich
0 siblings, 1 reply; 80+ messages in thread
From: mayshao-oc @ 2024-10-16 7:48 UTC (permalink / raw)
To: Jan Beulich; +Cc: H.J. Lu, timhu, louisqi, cobechen, binutils, Jiang, Haochen
[-- Attachment #1: Type: text/plain, Size: 503 bytes --]
On 10/16/24 14:47, Jan Beulich wrote:
>
>
>
> On 15.10.2024 13:44, mayshao-oc wrote:
>> Thanks for your patience, and I refine the patch to name the
>> enumerators properly.
>
> Just one remaining issue: In your switching to the use of OP_Skip_MODRM()
> you lost (or forgot to add?) the ins->modrm.rm != 0 check that the mis-
> named OP_0f07() has, and that also applies to these new insns (aiui) >
> Jan
>
Hi Jan:
Thanks for your review. I fix the issue, ok for trunk?
BR
Mayshao
[-- Attachment #2: gmi_v3_add_check.patch --]
[-- Type: text/x-patch, Size: 8478 bytes --]
From 2bb9eb4afeb877f5715ea3b943c9631999f49f40 Mon Sep 17 00:00:00 2001
From: MayShao-oc <MayShao-oc@zhaoxin.com>
Date: Wed, 16 Oct 2024 15:22:51 +0800
Subject: [PATCH v3] x86: Support x86 ZHAOXIN GMI instructions
Hi Jan:
I fix the missing check, thanks.
BR
Mayshao
gas/ChangeLog:
* NEWS: Support ZHAOXIN GMI instructions.
* config/tc-i386.c: Add gmi.
* doc/c-i386.texi: Document gmi.
* testsuite/gas/i386/i386.exp: Add gmi test.
* testsuite/gas/i386/gmi.d: Ditto.
* testsuite/gas/i386/gmi.s: Ditto.
opcodes/ChangeLog:
* i386-dis.c: New comment.
* i386-gen.c: Add gmi.
* i386-opc.h (CpuGMI): New.
* i386-opc.tbl: Add Zhaoxin GMI instructions.
* i386-tbl.h: Regenerated.
* i386-mnem.h: Ditto.
* i386-init.h: Ditto.
---
gas/NEWS | 2 ++
gas/config/tc-i386.c | 1 +
gas/doc/c-i386.texi | 6 +++--
gas/testsuite/gas/i386/gmi.d | 12 +++++++++
gas/testsuite/gas/i386/gmi.s | 8 ++++++
gas/testsuite/gas/i386/i386.exp | 1 +
opcodes/i386-dis.c | 43 ++++++++++++++++++++++++++++++++-
opcodes/i386-gen.c | 1 +
opcodes/i386-opc.h | 3 +++
opcodes/i386-opc.tbl | 5 ++++
10 files changed, 79 insertions(+), 3 deletions(-)
create mode 100644 gas/testsuite/gas/i386/gmi.d
create mode 100644 gas/testsuite/gas/i386/gmi.s
diff --git a/gas/NEWS b/gas/NEWS
index d64330143b0..d4c571f3474 100644
--- a/gas/NEWS
+++ b/gas/NEWS
@@ -1,5 +1,7 @@
-*- text -*-
+* Add support for the x86 Zhaoxin GMI instructions.
+
* On x86 emulation support (for secondary targets) was dropped.
* Add support for RISC-V Zcmp (cm.mva01s, cm.mvsa01), Smrnmi and CORE-V
diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c
index cdefde03717..735154ee721 100644
--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -1219,6 +1219,7 @@ static const arch_entry cpu_arch[] =
SUBARCH (user_msr, USER_MSR, USER_MSR, false),
SUBARCH (apx_f, APX_F, APX_F, false),
VECARCH (avx10.2, AVX10_2, ANY_AVX10_2, set),
+ SUBARCH (gmi, GMI, GMI, false),
};
#undef SUBARCH
diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi
index 9667061752d..952ddbc7377 100644
--- a/gas/doc/c-i386.texi
+++ b/gas/doc/c-i386.texi
@@ -274,7 +274,8 @@ accept various extension mnemonics. For example,
@code{snp},
@code{invlpgb},
@code{tlbsync},
-@code{svme} and
+@code{svme},
+@code{gmi} and
@code{padlock}.
Note that these extension mnemonics can be prefixed with @code{no} to revoke
the respective (and any dependent) functionality. Note further that the
@@ -1705,7 +1706,8 @@ supported on the CPU specified. The choices for @var{cpu_type} are:
@item @samp{.lwp} @tab @samp{.fma4} @tab @samp{.xop} @tab @samp{.cx16}
@item @samp{.padlock} @tab @samp{.clzero} @tab @samp{.mwaitx} @tab @samp{.rdpru}
@item @samp{.mcommit} @tab @samp{.sev_es} @tab @samp{.snp} @tab @samp{.invlpgb}
-@item @samp{.tlbsync} @tab @samp{.apx_f}
+@item @samp{.tlbsync} @tab @samp{.apx_f} @tab @samp{.gmi}
+
@end multitable
Apart from the warning, there are only two other effects on
diff --git a/gas/testsuite/gas/i386/gmi.d b/gas/testsuite/gas/i386/gmi.d
new file mode 100644
index 00000000000..063da8e120a
--- /dev/null
+++ b/gas/testsuite/gas/i386/gmi.d
@@ -0,0 +1,12 @@
+#objdump: -dw
+#name: zhaoxin gmi
+
+.*: +file format .*
+
+Disassembly of section .text:
+
+0+000 <foo>:
+ 0:[ ]*f2 0f a6 c0 [ ]*sm2
+ 4:[ ]*f3 0f a6 e8 [ ]*sm3
+ 8:[ ]*f3 0f a7 f0 [ ]*sm4
+#pass
diff --git a/gas/testsuite/gas/i386/gmi.s b/gas/testsuite/gas/i386/gmi.s
new file mode 100644
index 00000000000..c412de55d31
--- /dev/null
+++ b/gas/testsuite/gas/i386/gmi.s
@@ -0,0 +1,8 @@
+# ZHAOXIN GMI instructions
+
+ .text
+foo:
+ sm2
+ sm3
+ sm4
+ .p2align 4,0
diff --git a/gas/testsuite/gas/i386/i386.exp b/gas/testsuite/gas/i386/i386.exp
index 699e2004bef..4aaa2239069 100644
--- a/gas/testsuite/gas/i386/i386.exp
+++ b/gas/testsuite/gas/i386/i386.exp
@@ -114,6 +114,7 @@ if [gas_32_check] then {
run_dump_test "quoted2"
run_dump_test "unary"
run_dump_test "padlock"
+ run_dump_test "gmi"
run_dump_test "crx"
run_list_test "cr-err" ""
run_dump_test "cdr"
diff --git a/opcodes/i386-dis.c b/opcodes/i386-dis.c
index 3a4af4d61a3..5569cc1169d 100644
--- a/opcodes/i386-dis.c
+++ b/opcodes/i386-dis.c
@@ -90,6 +90,7 @@ static bool PCLMUL_Fixup (instr_info *, int, int);
static bool VPCMP_Fixup (instr_info *, int, int);
static bool VPCOM_Fixup (instr_info *, int, int);
static bool NOP_Fixup (instr_info *, int, int);
+static bool MONTMUL_Fixup (instr_info *, int, int);
static bool OP_3DNowSuffix (instr_info *, int, int);
static bool CMP_Fixup (instr_info *, int, int);
static bool REP_Fixup (instr_info *, int, int);
@@ -1050,6 +1051,9 @@ enum
PREFIX_0F7D,
PREFIX_0F7E,
PREFIX_0F7F,
+ PREFIX_0FA6_REG_0,
+ PREFIX_0FA6_REG_5,
+ PREFIX_0FA7_REG_6,
PREFIX_0FAE_REG_0_MOD_3,
PREFIX_0FAE_REG_1_MOD_3,
PREFIX_0FAE_REG_2_MOD_3,
@@ -2850,9 +2854,12 @@ static const struct dis386 reg_table[][8] = {
},
/* REG_0FA6 */
{
- { "montmul", { { OP_0f07, 0 } }, 0 },
+ { PREFIX_TABLE (PREFIX_0FA6_REG_0) },
{ "xsha1", { { OP_0f07, 0 } }, 0 },
{ "xsha256", { { OP_0f07, 0 } }, 0 },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { PREFIX_TABLE (PREFIX_0FA6_REG_5) },
},
/* REG_0FA7 */
{
@@ -2862,6 +2869,7 @@ static const struct dis386 reg_table[][8] = {
{ "xcrypt-ctr", { { OP_0f07, 0 } }, 0 },
{ "xcrypt-cfb", { { OP_0f07, 0 } }, 0 },
{ "xcrypt-ofb", { { OP_0f07, 0 } }, 0 },
+ { PREFIX_TABLE (PREFIX_0FA7_REG_6) },
},
/* REG_0FAE */
{
@@ -3438,6 +3446,26 @@ static const struct dis386 prefix_table[][4] = {
{ "movdqa", { EXxS, XM }, PREFIX_OPCODE },
},
+ /* PREFIX_0FA6_REG_0 */
+ {
+ { Bad_Opcode },
+ { "montmul", { { MONTMUL_Fixup, 0 } }, 0},
+ { Bad_Opcode },
+ { "sm2", { Skip_MODRM }, 0 },
+ },
+
+ /* PREFIX_0FA6_REG_5 */
+ {
+ { Bad_Opcode },
+ { "sm3", { Skip_MODRM }, 0 },
+ },
+
+ /* PREFIX_0FA7_REG_6 */
+ {
+ { Bad_Opcode },
+ { "sm4", { Skip_MODRM }, 0 },
+ },
+
/* PREFIX_0FAE_REG_0_MOD_3 */
{
{ Bad_Opcode },
@@ -13086,6 +13114,19 @@ OP_0f07 (instr_info *ins, int bytemode, int sizeflag)
return OP_E (ins, bytemode, sizeflag);
}
+/* montmul instruction need display repz and skip modrm */
+
+static bool
+MONTMUL_Fixup (instr_info *ins, int bytemode, int sizeflag)
+{
+ /* The 0xf3 prefix should be displayed as "repz" for montmul. */
+ if (ins->prefixes & PREFIX_REPZ)
+ ins->all_prefixes[ins->last_repz_prefix] = 0xf3;
+ if (ins->modrm.rm != 0)
+ return BadOp (ins);
+ return OP_Skip_MODRM(ins, bytemode, sizeflag);
+}
+
/* NOP is an alias of "xchg %ax,%ax" in 16bit mode, "xchg %eax,%eax" in
32bit mode and "xchg %rax,%rax" in 64bit mode. */
diff --git a/opcodes/i386-gen.c b/opcodes/i386-gen.c
index 565aae722f8..0f7ab4c6a56 100644
--- a/opcodes/i386-gen.c
+++ b/opcodes/i386-gen.c
@@ -334,6 +334,7 @@ static bitfield cpu_flags[] =
BITFIELD (3dnow),
BITFIELD (3dnowA),
BITFIELD (PadLock),
+ BITFIELD (GMI),
BITFIELD (SVME),
BITFIELD (VMX),
BITFIELD (SMX),
diff --git a/opcodes/i386-opc.h b/opcodes/i386-opc.h
index c0d5e44d461..d404fbc6b05 100644
--- a/opcodes/i386-opc.h
+++ b/opcodes/i386-opc.h
@@ -66,6 +66,8 @@ enum i386_cpu
CpuSSE3,
/* VIA PadLock required */
CpuPadLock,
+ /* ZHAOXIN GMI required */
+ CpuGMI,
/* AMD Secure Virtual Machine Ext-s required */
CpuSVME,
/* VMX Instructions required */
@@ -400,6 +402,7 @@ typedef union i386_cpu_flags
unsigned int cpusse2:1;
unsigned int cpusse3:1;
unsigned int cpupadlock:1;
+ unsigned int cpugmi:1;
unsigned int cpusvme:1;
unsigned int cpuvmx:1;
unsigned int cpusmx:1;
diff --git a/opcodes/i386-opc.tbl b/opcodes/i386-opc.tbl
index 9a14a4d1819..7ded4e64133 100644
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -2131,6 +2131,11 @@ xcryptofb, 0xf30fa7e8, PadLock, NoSuf|RepPrefixOk, {}
// Alias for xstore-rng.
xstore, 0xfa7c0, PadLock, NoSuf|RepPrefixOk, {}
+// ZHAOXIN GMI instructions
+sm2, 0xf20fa6c0, GMI, NoSuf, {}
+sm3, 0xf30fa6e8, GMI, NoSuf, {}
+sm4, 0xf30fa7f0, GMI, NoSuf, {}
+
// Multy-precision Add Carry, rdseed instructions.
<adx:pfx, c:66, o:f3>
ad<adx>x, 0x<adx:pfx>66, ADX&APX_F, C|Modrm|CheckOperandSize|No_bSuf|No_wSuf|No_sSuf|DstVVVV|EVexMap4, { Reg32|Reg64|Unspecified|BaseIndex, Reg32|Reg64, Reg32|Reg64 }
--
2.27.0
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v2] x86: Support ZHAOXIN GMI instructions
2024-10-16 7:48 ` mayshao-oc
@ 2024-10-16 9:22 ` Jan Beulich
2024-10-17 2:17 ` mayshao-oc
0 siblings, 1 reply; 80+ messages in thread
From: Jan Beulich @ 2024-10-16 9:22 UTC (permalink / raw)
To: mayshao-oc; +Cc: H.J. Lu, timhu, louisqi, cobechen, binutils, Jiang, Haochen
On 16.10.2024 09:48, mayshao-oc wrote:
> On 10/16/24 14:47, Jan Beulich wrote:
>> On 15.10.2024 13:44, mayshao-oc wrote:
>>> Thanks for your patience, and I refine the patch to name the
>>> enumerators properly.
>>
>> Just one remaining issue: In your switching to the use of OP_Skip_MODRM()
>> you lost (or forgot to add?) the ins->modrm.rm != 0 check that the mis-
>> named OP_0f07() has, and that also applies to these new insns (aiui) >
>
> Thanks for your review. I fix the issue, ok for trunk?
Mind me asking to move the new conditional ahead of the one that was
already there in (plain) v3? Okay with that adjustment, but before
committing please give Haochen a day or two for possible further
remarks / requests.
Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v2] x86: Support ZHAOXIN GMI instructions
2024-10-16 9:22 ` Jan Beulich
@ 2024-10-17 2:17 ` mayshao-oc
2024-10-17 5:35 ` Jan Beulich
0 siblings, 1 reply; 80+ messages in thread
From: mayshao-oc @ 2024-10-17 2:17 UTC (permalink / raw)
To: Jan Beulich; +Cc: H.J. Lu, timhu, louisqi, cobechen, binutils, Jiang, Haochen
[-- Attachment #1: Type: text/plain, Size: 931 bytes --]
Hi Jan:
I move the conditional check ahead, and update the patch. Thanks
for your comments.
BR
Mayshao
On 10/16/24 17:22, Jan Beulich wrote:
>
>
>
> On 16.10.2024 09:48, mayshao-oc wrote:
>> On 10/16/24 14:47, Jan Beulich wrote:
>>> On 15.10.2024 13:44, mayshao-oc wrote:
>>>> Thanks for your patience, and I refine the patch to name the
>>>> enumerators properly.
>>>
>>> Just one remaining issue: In your switching to the use of OP_Skip_MODRM()
>>> you lost (or forgot to add?) the ins->modrm.rm != 0 check that the mis-
>>> named OP_0f07() has, and that also applies to these new insns (aiui) >
>>
>> Thanks for your review. I fix the issue, ok for trunk?
>
> Mind me asking to move the new conditional ahead of the one that was
> already there in (plain) v3? Okay with that adjustment, but before
> committing please give Haochen a day or two for possible further
> remarks / requests.
>
> Jan
[-- Attachment #2: gmi_v3_if_ahead.patch --]
[-- Type: text/x-patch, Size: 8571 bytes --]
From 1d1714916db37953b1561b8ab2de228dda04c3b5 Mon Sep 17 00:00:00 2001
From: MayShao-oc <MayShao-oc@zhaoxin.com>
Date: Thu, 17 Oct 2024 09:33:17 +0800
Subject: [PATCH v3] x86: Support x86 ZHAOXIN GMI instructions
Hi Jan:
I move the conditional ahead, thanks.
BR
Mayshao
gas/ChangeLog:
* NEWS: Support ZHAOXIN GMI instructions.
* config/tc-i386.c: Add gmi.
* doc/c-i386.texi: Document gmi.
* testsuite/gas/i386/i386.exp: Add gmi test.
* testsuite/gas/i386/gmi.d: Ditto.
* testsuite/gas/i386/gmi.s: Ditto.
opcodes/ChangeLog:
* i386-dis.c: New comment.
* i386-gen.c: Add gmi.
* i386-opc.h (CpuGMI): New.
* i386-opc.tbl: Add Zhaoxin GMI instructions.
* i386-tbl.h: Regenerated.
* i386-mnem.h: Ditto.
* i386-init.h: Ditto.
---
gas/NEWS | 2 ++
gas/config/tc-i386.c | 1 +
gas/doc/c-i386.texi | 6 +++--
gas/testsuite/gas/i386/gmi.d | 12 +++++++++
gas/testsuite/gas/i386/gmi.s | 8 ++++++
gas/testsuite/gas/i386/i386.exp | 1 +
opcodes/i386-dis.c | 48 ++++++++++++++++++++++++++++++++-
opcodes/i386-gen.c | 1 +
opcodes/i386-opc.h | 3 +++
opcodes/i386-opc.tbl | 5 ++++
10 files changed, 84 insertions(+), 3 deletions(-)
create mode 100644 gas/testsuite/gas/i386/gmi.d
create mode 100644 gas/testsuite/gas/i386/gmi.s
diff --git a/gas/NEWS b/gas/NEWS
index d64330143b0..d4c571f3474 100644
--- a/gas/NEWS
+++ b/gas/NEWS
@@ -1,5 +1,7 @@
-*- text -*-
+* Add support for the x86 Zhaoxin GMI instructions.
+
* On x86 emulation support (for secondary targets) was dropped.
* Add support for RISC-V Zcmp (cm.mva01s, cm.mvsa01), Smrnmi and CORE-V
diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c
index cdefde03717..735154ee721 100644
--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -1219,6 +1219,7 @@ static const arch_entry cpu_arch[] =
SUBARCH (user_msr, USER_MSR, USER_MSR, false),
SUBARCH (apx_f, APX_F, APX_F, false),
VECARCH (avx10.2, AVX10_2, ANY_AVX10_2, set),
+ SUBARCH (gmi, GMI, GMI, false),
};
#undef SUBARCH
diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi
index 9667061752d..952ddbc7377 100644
--- a/gas/doc/c-i386.texi
+++ b/gas/doc/c-i386.texi
@@ -274,7 +274,8 @@ accept various extension mnemonics. For example,
@code{snp},
@code{invlpgb},
@code{tlbsync},
-@code{svme} and
+@code{svme},
+@code{gmi} and
@code{padlock}.
Note that these extension mnemonics can be prefixed with @code{no} to revoke
the respective (and any dependent) functionality. Note further that the
@@ -1705,7 +1706,8 @@ supported on the CPU specified. The choices for @var{cpu_type} are:
@item @samp{.lwp} @tab @samp{.fma4} @tab @samp{.xop} @tab @samp{.cx16}
@item @samp{.padlock} @tab @samp{.clzero} @tab @samp{.mwaitx} @tab @samp{.rdpru}
@item @samp{.mcommit} @tab @samp{.sev_es} @tab @samp{.snp} @tab @samp{.invlpgb}
-@item @samp{.tlbsync} @tab @samp{.apx_f}
+@item @samp{.tlbsync} @tab @samp{.apx_f} @tab @samp{.gmi}
+
@end multitable
Apart from the warning, there are only two other effects on
diff --git a/gas/testsuite/gas/i386/gmi.d b/gas/testsuite/gas/i386/gmi.d
new file mode 100644
index 00000000000..063da8e120a
--- /dev/null
+++ b/gas/testsuite/gas/i386/gmi.d
@@ -0,0 +1,12 @@
+#objdump: -dw
+#name: zhaoxin gmi
+
+.*: +file format .*
+
+Disassembly of section .text:
+
+0+000 <foo>:
+ 0:[ ]*f2 0f a6 c0 [ ]*sm2
+ 4:[ ]*f3 0f a6 e8 [ ]*sm3
+ 8:[ ]*f3 0f a7 f0 [ ]*sm4
+#pass
diff --git a/gas/testsuite/gas/i386/gmi.s b/gas/testsuite/gas/i386/gmi.s
new file mode 100644
index 00000000000..c412de55d31
--- /dev/null
+++ b/gas/testsuite/gas/i386/gmi.s
@@ -0,0 +1,8 @@
+# ZHAOXIN GMI instructions
+
+ .text
+foo:
+ sm2
+ sm3
+ sm4
+ .p2align 4,0
diff --git a/gas/testsuite/gas/i386/i386.exp b/gas/testsuite/gas/i386/i386.exp
index 699e2004bef..4aaa2239069 100644
--- a/gas/testsuite/gas/i386/i386.exp
+++ b/gas/testsuite/gas/i386/i386.exp
@@ -114,6 +114,7 @@ if [gas_32_check] then {
run_dump_test "quoted2"
run_dump_test "unary"
run_dump_test "padlock"
+ run_dump_test "gmi"
run_dump_test "crx"
run_list_test "cr-err" ""
run_dump_test "cdr"
diff --git a/opcodes/i386-dis.c b/opcodes/i386-dis.c
index 3a4af4d61a3..f0b5eaa5a3b 100644
--- a/opcodes/i386-dis.c
+++ b/opcodes/i386-dis.c
@@ -90,6 +90,7 @@ static bool PCLMUL_Fixup (instr_info *, int, int);
static bool VPCMP_Fixup (instr_info *, int, int);
static bool VPCOM_Fixup (instr_info *, int, int);
static bool NOP_Fixup (instr_info *, int, int);
+static bool MONTMUL_Fixup (instr_info *, int, int);
static bool OP_3DNowSuffix (instr_info *, int, int);
static bool CMP_Fixup (instr_info *, int, int);
static bool REP_Fixup (instr_info *, int, int);
@@ -1050,6 +1051,9 @@ enum
PREFIX_0F7D,
PREFIX_0F7E,
PREFIX_0F7F,
+ PREFIX_0FA6_REG_0,
+ PREFIX_0FA6_REG_5,
+ PREFIX_0FA7_REG_6,
PREFIX_0FAE_REG_0_MOD_3,
PREFIX_0FAE_REG_1_MOD_3,
PREFIX_0FAE_REG_2_MOD_3,
@@ -2850,9 +2854,12 @@ static const struct dis386 reg_table[][8] = {
},
/* REG_0FA6 */
{
- { "montmul", { { OP_0f07, 0 } }, 0 },
+ { PREFIX_TABLE (PREFIX_0FA6_REG_0) },
{ "xsha1", { { OP_0f07, 0 } }, 0 },
{ "xsha256", { { OP_0f07, 0 } }, 0 },
+ { Bad_Opcode },
+ { Bad_Opcode },
+ { PREFIX_TABLE (PREFIX_0FA6_REG_5) },
},
/* REG_0FA7 */
{
@@ -2862,6 +2869,7 @@ static const struct dis386 reg_table[][8] = {
{ "xcrypt-ctr", { { OP_0f07, 0 } }, 0 },
{ "xcrypt-cfb", { { OP_0f07, 0 } }, 0 },
{ "xcrypt-ofb", { { OP_0f07, 0 } }, 0 },
+ { PREFIX_TABLE (PREFIX_0FA7_REG_6) },
},
/* REG_0FAE */
{
@@ -3438,6 +3446,26 @@ static const struct dis386 prefix_table[][4] = {
{ "movdqa", { EXxS, XM }, PREFIX_OPCODE },
},
+ /* PREFIX_0FA6_REG_0 */
+ {
+ { Bad_Opcode },
+ { "montmul", { { MONTMUL_Fixup, 0 } }, 0},
+ { Bad_Opcode },
+ { "sm2", { Skip_MODRM }, 0 },
+ },
+
+ /* PREFIX_0FA6_REG_5 */
+ {
+ { Bad_Opcode },
+ { "sm3", { Skip_MODRM }, 0 },
+ },
+
+ /* PREFIX_0FA7_REG_6 */
+ {
+ { Bad_Opcode },
+ { "sm4", { Skip_MODRM }, 0 },
+ },
+
/* PREFIX_0FAE_REG_0_MOD_3 */
{
{ Bad_Opcode },
@@ -13086,6 +13114,24 @@ OP_0f07 (instr_info *ins, int bytemode, int sizeflag)
return OP_E (ins, bytemode, sizeflag);
}
+/* montmul instruction need display repz and skip modrm */
+
+static bool
+MONTMUL_Fixup (instr_info *ins, int bytemode ATTRIBUTE_UNUSED, int sizeflag ATTRIBUTE_UNUSED)
+{
+ if (ins->modrm.mod != 3 || ins->modrm.rm != 0)
+ return BadOp (ins);
+
+ /* The 0xf3 prefix should be displayed as "repz" for montmul. */
+ if (ins->prefixes & PREFIX_REPZ)
+ ins->all_prefixes[ins->last_repz_prefix] = 0xf3;
+
+ /* Skip mod/rm byte. */
+ MODRM_CHECK;
+ ins->codep++;
+ return true;
+}
+
/* NOP is an alias of "xchg %ax,%ax" in 16bit mode, "xchg %eax,%eax" in
32bit mode and "xchg %rax,%rax" in 64bit mode. */
diff --git a/opcodes/i386-gen.c b/opcodes/i386-gen.c
index 565aae722f8..0f7ab4c6a56 100644
--- a/opcodes/i386-gen.c
+++ b/opcodes/i386-gen.c
@@ -334,6 +334,7 @@ static bitfield cpu_flags[] =
BITFIELD (3dnow),
BITFIELD (3dnowA),
BITFIELD (PadLock),
+ BITFIELD (GMI),
BITFIELD (SVME),
BITFIELD (VMX),
BITFIELD (SMX),
diff --git a/opcodes/i386-opc.h b/opcodes/i386-opc.h
index c0d5e44d461..d404fbc6b05 100644
--- a/opcodes/i386-opc.h
+++ b/opcodes/i386-opc.h
@@ -66,6 +66,8 @@ enum i386_cpu
CpuSSE3,
/* VIA PadLock required */
CpuPadLock,
+ /* ZHAOXIN GMI required */
+ CpuGMI,
/* AMD Secure Virtual Machine Ext-s required */
CpuSVME,
/* VMX Instructions required */
@@ -400,6 +402,7 @@ typedef union i386_cpu_flags
unsigned int cpusse2:1;
unsigned int cpusse3:1;
unsigned int cpupadlock:1;
+ unsigned int cpugmi:1;
unsigned int cpusvme:1;
unsigned int cpuvmx:1;
unsigned int cpusmx:1;
diff --git a/opcodes/i386-opc.tbl b/opcodes/i386-opc.tbl
index 9a14a4d1819..7ded4e64133 100644
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -2131,6 +2131,11 @@ xcryptofb, 0xf30fa7e8, PadLock, NoSuf|RepPrefixOk, {}
// Alias for xstore-rng.
xstore, 0xfa7c0, PadLock, NoSuf|RepPrefixOk, {}
+// ZHAOXIN GMI instructions
+sm2, 0xf20fa6c0, GMI, NoSuf, {}
+sm3, 0xf30fa6e8, GMI, NoSuf, {}
+sm4, 0xf30fa7f0, GMI, NoSuf, {}
+
// Multy-precision Add Carry, rdseed instructions.
<adx:pfx, c:66, o:f3>
ad<adx>x, 0x<adx:pfx>66, ADX&APX_F, C|Modrm|CheckOperandSize|No_bSuf|No_wSuf|No_sSuf|DstVVVV|EVexMap4, { Reg32|Reg64|Unspecified|BaseIndex, Reg32|Reg64, Reg32|Reg64 }
--
2.27.0
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v2] x86: Support ZHAOXIN GMI instructions
2024-10-17 2:17 ` mayshao-oc
@ 2024-10-17 5:35 ` Jan Beulich
2024-10-18 0:15 ` mayshao-oc
0 siblings, 1 reply; 80+ messages in thread
From: Jan Beulich @ 2024-10-17 5:35 UTC (permalink / raw)
To: mayshao-oc; +Cc: H.J. Lu, timhu, louisqi, cobechen, binutils, Jiang, Haochen
On 17.10.2024 04:17, mayshao-oc wrote:
> I move the conditional check ahead, and update the patch. Thanks for your comments.
Great, feel free to put in then.
Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v2] x86: Support ZHAOXIN GMI instructions
2024-10-17 5:35 ` Jan Beulich
@ 2024-10-18 0:15 ` mayshao-oc
2024-10-18 7:38 ` Jiang, Haochen
0 siblings, 1 reply; 80+ messages in thread
From: mayshao-oc @ 2024-10-18 0:15 UTC (permalink / raw)
To: Jan Beulich; +Cc: H.J. Lu, timhu, louisqi, cobechen, binutils, Jiang, Haochen
Hi Jan:
I thinks this patch submission process is a great experience for
me, so thanks you again. Could you please commit the patch on my behalf?
BR
Mayshao
On 10/17/24 13:35, Jan Beulich wrote:
>
>
>
> On 17.10.2024 04:17, mayshao-oc wrote:
>> I move the conditional check ahead, and update the patch. Thanks for your comments.
>
> Great, feel free to put in then.
>
> Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* RE: [PATCH v2] x86: Support ZHAOXIN GMI instructions
2024-10-18 0:15 ` mayshao-oc
@ 2024-10-18 7:38 ` Jiang, Haochen
2024-10-18 7:47 ` Jiang, Haochen
2024-10-18 8:08 ` mayshao-oc
0 siblings, 2 replies; 80+ messages in thread
From: Jiang, Haochen @ 2024-10-18 7:38 UTC (permalink / raw)
To: mayshao-oc, Beulich, Jan; +Cc: H.J. Lu, timhu, louisqi, cobechen, binutils
> From: mayshao-oc <mayshao-oc@zhaoxin.com>
> Sent: Friday, October 18, 2024 8:16 AM
>
> Hi Jan:
> I thinks this patch submission process is a great experience for
> me, so thanks you again. Could you please commit the patch on my behalf?
>
I suppose Jan is quite busy today, I can do that for you to make it happen this
week.
BRs,
Haochen
^ permalink raw reply [flat|nested] 80+ messages in thread
* RE: [PATCH v2] x86: Support ZHAOXIN GMI instructions
2024-10-18 7:38 ` Jiang, Haochen
@ 2024-10-18 7:47 ` Jiang, Haochen
2024-10-18 7:59 ` [committed][PATCH] x86: Regenerate missing table files (was RE: [PATCH v2] x86: Support ZHAOXIN GMI instructions) Jiang, Haochen
2024-10-18 11:19 ` [PATCH v2] x86: Support ZHAOXIN GMI instructions Jan Beulich
2024-10-18 8:08 ` mayshao-oc
1 sibling, 2 replies; 80+ messages in thread
From: Jiang, Haochen @ 2024-10-18 7:47 UTC (permalink / raw)
To: mayshao-oc, Beulich, Jan; +Cc: H.J. Lu, timhu, louisqi, cobechen, binutils
> From: Jiang, Haochen
> Sent: Friday, October 18, 2024 3:39 PM
>
> > From: mayshao-oc <mayshao-oc@zhaoxin.com>
> > Sent: Friday, October 18, 2024 8:16 AM
> >
> > Hi Jan:
> > I thinks this patch submission process is a great experience
> > for me, so thanks you again. Could you please commit the patch on my
> behalf?
> >
>
> I suppose Jan is quite busy today, I can do that for you to make it happen this
> week.
Committed as https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=8f0d880434b84b222f87c4ee8f9d6d31d330668d
Thx,
Haochen
>
> BRs,
> Haochen
^ permalink raw reply [flat|nested] 80+ messages in thread
* [committed][PATCH] x86: Regenerate missing table files (was RE: [PATCH v2] x86: Support ZHAOXIN GMI instructions)
2024-10-18 7:47 ` Jiang, Haochen
@ 2024-10-18 7:59 ` Jiang, Haochen
2024-10-18 11:19 ` [PATCH v2] x86: Support ZHAOXIN GMI instructions Jan Beulich
1 sibling, 0 replies; 80+ messages in thread
From: Jiang, Haochen @ 2024-10-18 7:59 UTC (permalink / raw)
To: mayshao-oc, Beulich, Jan; +Cc: H.J. Lu, timhu, louisqi, cobechen, binutils
> Committed as https://sourceware.org/git/?p=binutils-
> gdb.git;a=commit;h=8f0d880434b84b222f87c4ee8f9d6d31d330668d
Oops, I forgot the regen file is not in the patch.
Committed a patch as obvious to regenerate them.
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=b2841da4f20b83b22fb46d82a86fe53ba7448469
Thx,
Haochen
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v2] x86: Support ZHAOXIN GMI instructions
2024-10-18 7:38 ` Jiang, Haochen
2024-10-18 7:47 ` Jiang, Haochen
@ 2024-10-18 8:08 ` mayshao-oc
1 sibling, 0 replies; 80+ messages in thread
From: mayshao-oc @ 2024-10-18 8:08 UTC (permalink / raw)
To: Jiang, Haochen, Beulich, Jan; +Cc: H.J. Lu, timhu, louisqi, cobechen, binutils
Hi Haochen:
Thank you. I think all of you are models of the guideline of
<<gnu binutils code of conduct>>. I also want to apply the guideline
when I communicate to others. I think the community is fun, and hope for
more communication with all of you in the long term.
BR
Mayshao
On 10/18/24 15:38, Jiang, Haochen wrote:
>
>
>
>> From: mayshao-oc <mayshao-oc@zhaoxin.com>
>> Sent: Friday, October 18, 2024 8:16 AM
>>
>> Hi Jan:
>> I thinks this patch submission process is a great experience for
>> me, so thanks you again. Could you please commit the patch on my behalf?
>>
>
> I suppose Jan is quite busy today, I can do that for you to make it happen this
> week.
>
> BRs,
> Haochen
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v2] x86: Support ZHAOXIN GMI instructions
2024-10-18 7:47 ` Jiang, Haochen
2024-10-18 7:59 ` [committed][PATCH] x86: Regenerate missing table files (was RE: [PATCH v2] x86: Support ZHAOXIN GMI instructions) Jiang, Haochen
@ 2024-10-18 11:19 ` Jan Beulich
2024-10-21 5:45 ` Jiang, Haochen
1 sibling, 1 reply; 80+ messages in thread
From: Jan Beulich @ 2024-10-18 11:19 UTC (permalink / raw)
To: Jiang, Haochen; +Cc: H.J. Lu, timhu, louisqi, cobechen, binutils, mayshao-oc
On 18.10.2024 09:47, Jiang, Haochen wrote:
>> From: Jiang, Haochen
>> Sent: Friday, October 18, 2024 3:39 PM
>>
>>> From: mayshao-oc <mayshao-oc@zhaoxin.com>
>>> Sent: Friday, October 18, 2024 8:16 AM
>>>
>>> Hi Jan:
>>> I thinks this patch submission process is a great experience
>>> for me, so thanks you again. Could you please commit the patch on my
>> behalf?
>>>
>>
>> I suppose Jan is quite busy today, I can do that for you to make it happen this
>> week.
>
> Committed as https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=8f0d880434b84b222f87c4ee8f9d6d31d330668d
That wasn't the best idea - I had some small tweaks to make, and I was just
about to get to committing. I was asked to do the commit, and the request
wasn't even a day old. Please be a little more patient in the future.
Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* RE: [PATCH v2] x86: Support ZHAOXIN GMI instructions
2024-10-18 11:19 ` [PATCH v2] x86: Support ZHAOXIN GMI instructions Jan Beulich
@ 2024-10-21 5:45 ` Jiang, Haochen
0 siblings, 0 replies; 80+ messages in thread
From: Jiang, Haochen @ 2024-10-21 5:45 UTC (permalink / raw)
To: Beulich, Jan; +Cc: H.J. Lu, timhu, louisqi, cobechen, binutils, mayshao-oc
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Friday, October 18, 2024 7:20 PM
> On 18.10.2024 09:47, Jiang, Haochen wrote:
>
> That wasn't the best idea - I had some small tweaks to make, and I was just
> about to get to committing. I was asked to do the commit, and the request
> wasn't even a day old. Please be a little more patient in the future.
I am sorry for that. Typically I would wait for that. But last week's scenario is
that it is near the off-hour for Zhaoxin guys. I committed that patch to make
them not worried too much during the weekend and kept getting online to
see if the patch is committed. My apologies.
Thx,
Haochen
>
> Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* [PATCH v1] x86: Support ZHAOXIN padlock instructions
2024-10-14 10:16 ` Jan Beulich
2024-10-15 1:19 ` [PATCH v2] " mayshao-oc
@ 2024-12-13 3:25 ` Mayshao-oc
2024-12-13 8:50 ` Jiang, Haochen
2024-12-19 10:33 ` [PATCH v1] x86: Support ZHAOXIN padlock instructions Jan Beulich
1 sibling, 2 replies; 80+ messages in thread
From: Mayshao-oc @ 2024-12-13 3:25 UTC (permalink / raw)
To: Jan Beulich
Cc: H.J. Lu, Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen, mludvig
[-- Attachment #1: Type: text/plain, Size: 221 bytes --]
Hi all:
This patch adds support for Zhaoxin padlock instructions, and
display all the padlock instructions using rep prefix instead of repz,
because all padlock instructions don't effect zf flag.
BR
Mayshao
[-- Attachment #2: padlock instruction set reference.pdf --]
[-- Type: application/pdf, Size: 289466 bytes --]
[-- Attachment #3: 0001-zhaoxin-padlock-patch.patch --]
[-- Type: application/octet-stream, Size: 9423 bytes --]
From 1264640cf01f29d19fb82d33ce1e1db2f1e40d60 Mon Sep 17 00:00:00 2001
From: MayShao-oc <MayShao-oc@zhaoxin.com>
Date: Fri, 13 Dec 2024 10:02:38 +0800
Subject: [PATCH] x86: Support ZHAOXIN padlock
Hi all:
This patch adds support for Zhaoxin padlock instructions, and
display all the padlock instructions using rep prefix instead of repz,
because all padlock instructions don't effect zf flag.
BR
Mayshao
gas/ChangeLog:
* testsuite/gas/i386/padlock.d: Add xcryptctr, xrng2, xsha384,
xsha512, xmodexp, montmul2 test.
* testsuite/gas/i386/padlock.s: Ditto.
opcodes/ChangeLog:
* i386-dis.c (OP_0f07): Delete.
(MONTMUL_Fixup): Ditto.
(PADLOCK_Fixup): New.
* i386-opc.tbl: Add xrng2, xsha384, xsha512, xmodexp, montmul2
instructions.
---
gas/testsuite/gas/i386/padlock.d | 46 ++++++++++++++++++++------------
gas/testsuite/gas/i386/padlock.s | 15 +++++++++--
opcodes/i386-dis.c | 44 +++++++++++++-----------------
opcodes/i386-opc.h | 2 +-
opcodes/i386-opc.tbl | 7 ++++-
5 files changed, 68 insertions(+), 46 deletions(-)
diff --git a/gas/testsuite/gas/i386/padlock.d b/gas/testsuite/gas/i386/padlock.d
index eae6b24ac3e..e308a38c3a9 100644
--- a/gas/testsuite/gas/i386/padlock.d
+++ b/gas/testsuite/gas/i386/padlock.d
@@ -7,21 +7,33 @@ Disassembly of section .text:
0+000 <foo>:
0:[ ]*0f a7 c0 [ ]*xstore-rng
- 3:[ ]*f3 0f a7 c0 [ ]*repz xstore-rng
- 7:[ ]*f3 0f a7 c8 [ ]*repz xcrypt-ecb
- b:[ ]*f3 0f a7 c8 [ ]*repz xcrypt-ecb
- f:[ ]*f3 0f a7 d0 [ ]*repz xcrypt-cbc
- 13:[ ]*f3 0f a7 d0 [ ]*repz xcrypt-cbc
- 17:[ ]*f3 0f a7 e0 [ ]*repz xcrypt-cfb
- 1b:[ ]*f3 0f a7 e0 [ ]*repz xcrypt-cfb
- 1f:[ ]*f3 0f a7 e8 [ ]*repz xcrypt-ofb
- 23:[ ]*f3 0f a7 e8 [ ]*repz xcrypt-ofb
- 27:[ ]*0f a7 c0 [ ]*xstore-rng
- 2a:[ ]*f3 0f a7 c0 [ ]*repz xstore-rng
- 2e:[ ]*f3 0f a6 c0 [ ]*repz montmul
- 32:[ ]*f3 0f a6 c0 [ ]*repz montmul
- 36:[ ]*f3 0f a6 c8 [ ]*repz xsha1
- 3a:[ ]*f3 0f a6 c8 [ ]*repz xsha1
- 3e:[ ]*f3 0f a6 d0 [ ]*repz xsha256
- 42:[ ]*f3 0f a6 d0 [ ]*repz xsha256
+ 3:[ ]*f3 0f a7 c0 [ ]*rep xstore-rng
+ 7:[ ]*f3 0f a7 c8 [ ]*rep xcrypt-ecb
+ b:[ ]*f3 0f a7 c8 [ ]*rep xcrypt-ecb
+ f:[ ]*f3 0f a7 d0 [ ]*rep xcrypt-cbc
+ 13:[ ]*f3 0f a7 d0 [ ]*rep xcrypt-cbc
+ 17:[ ]*f3 0f a7 d8 [ ]*rep xcrypt-ctr
+ 1b:[ ]*f3 0f a7 d8 [ ]*rep xcrypt-ctr
+ 1f:[ ]*f3 0f a7 e0 [ ]*rep xcrypt-cfb
+ 23:[ ]*f3 0f a7 e0 [ ]*rep xcrypt-cfb
+ 27:[ ]*f3 0f a7 e8 [ ]*rep xcrypt-ofb
+ 2b:[ ]*f3 0f a7 e8 [ ]*rep xcrypt-ofb
+ 2f:[ ]*0f a7 c0 [ ]*xstore-rng
+ 32:[ ]*f3 0f a7 c0 [ ]*rep xstore-rng
+ 36:[ ]*f3 0f a6 c0 [ ]*rep montmul
+ 3a:[ ]*f3 0f a6 c0 [ ]*rep montmul
+ 3e:[ ]*f3 0f a6 c8 [ ]*rep xsha1
+ 42:[ ]*f3 0f a6 c8 [ ]*rep xsha1
+ 46:[ ]*f3 0f a6 d0 [ ]*rep xsha256
+ 4a:[ ]*f3 0f a6 d0 [ ]*rep xsha256
+ 4e:[ ]*f3 0f a7 f8 [ ]*rep xrng2
+ 52:[ ]*f3 0f a7 f8 [ ]*rep xrng2
+ 56:[ ]*f3 0f a6 d8 [ ]*rep xsha384
+ 5a:[ ]*f3 0f a6 d8 [ ]*rep xsha384
+ 5e:[ ]*f3 0f a6 e0 [ ]*rep xsha512
+ 62:[ ]*f3 0f a6 e0 [ ]*rep xsha512
+ 66:[ ]*f3 0f a6 f0 [ ]*rep montmul2
+ 6a:[ ]*f3 0f a6 f0 [ ]*rep montmul2
+ 6e:[ ]*f3 0f a6 f8 [ ]*rep xmodexp
+ 72:[ ]*f3 0f a6 f8 [ ]*rep xmodexp
#pass
diff --git a/gas/testsuite/gas/i386/padlock.s b/gas/testsuite/gas/i386/padlock.s
index b4a19506b27..c41ed5210ad 100644
--- a/gas/testsuite/gas/i386/padlock.s
+++ b/gas/testsuite/gas/i386/padlock.s
@@ -1,4 +1,4 @@
-# VIA Nehemiah PadLock instructions
+# ZHAOXIN PadLock instructions
.text
foo:
@@ -8,6 +8,8 @@ foo:
rep xcryptecb
xcryptcbc
rep xcryptcbc
+ xcryptctr
+ rep xcryptctr
xcryptcfb
rep xcryptcfb
xcryptofb
@@ -20,5 +22,14 @@ foo:
rep xsha1
xsha256
rep xsha256
-
+ xrng2
+ rep xrng2
+ xsha384
+ rep xsha384
+ xsha512
+ rep xsha512
+ montmul2
+ rep montmul2
+ xmodexp
+ rep xmodexp
.p2align 4,0
diff --git a/opcodes/i386-dis.c b/opcodes/i386-dis.c
index 8795e397082..e376b5e83ad 100644
--- a/opcodes/i386-dis.c
+++ b/opcodes/i386-dis.c
@@ -82,7 +82,6 @@ static bool OP_VexW (instr_info *, int, int);
static bool OP_Rounding (instr_info *, int, int);
static bool OP_REG_VexI4 (instr_info *, int, int);
static bool OP_VexI4 (instr_info *, int, int);
-static bool OP_0f07 (instr_info *, int, int);
static bool OP_Monitor (instr_info *, int, int);
static bool OP_Mwait (instr_info *, int, int);
@@ -90,7 +89,7 @@ static bool PCLMUL_Fixup (instr_info *, int, int);
static bool VPCMP_Fixup (instr_info *, int, int);
static bool VPCOM_Fixup (instr_info *, int, int);
static bool NOP_Fixup (instr_info *, int, int);
-static bool MONTMUL_Fixup (instr_info *, int, int);
+static bool PADLOCK_Fixup (instr_info *, int, int);
static bool OP_3DNowSuffix (instr_info *, int, int);
static bool CMP_Fixup (instr_info *, int, int);
static bool REP_Fixup (instr_info *, int, int);
@@ -2897,21 +2896,24 @@ static const struct dis386 reg_table[][8] = {
/* REG_0FA6 */
{
{ PREFIX_TABLE (PREFIX_0FA6_REG_0) },
- { "xsha1", { { OP_0f07, 0 } }, 0 },
- { "xsha256", { { OP_0f07, 0 } }, 0 },
- { Bad_Opcode },
- { Bad_Opcode },
+ { "xsha1", { { PADLOCK_Fixup, 0 } }, 0 },
+ { "xsha256", { { PADLOCK_Fixup, 0 } }, 0 },
+ { "xsha384", { { PADLOCK_Fixup, 0 } }, 0 },
+ { "xsha512", { { PADLOCK_Fixup, 0 } }, 0 },
{ PREFIX_TABLE (PREFIX_0FA6_REG_5) },
+ { "montmul2", { { PADLOCK_Fixup, 0 } }, 0},
+ { "xmodexp", { { PADLOCK_Fixup, 0 } }, 0},
},
/* REG_0FA7 */
{
- { "xstore-rng", { { OP_0f07, 0 } }, 0 },
- { "xcrypt-ecb", { { OP_0f07, 0 } }, 0 },
- { "xcrypt-cbc", { { OP_0f07, 0 } }, 0 },
- { "xcrypt-ctr", { { OP_0f07, 0 } }, 0 },
- { "xcrypt-cfb", { { OP_0f07, 0 } }, 0 },
- { "xcrypt-ofb", { { OP_0f07, 0 } }, 0 },
+ { "xstore-rng", { { PADLOCK_Fixup, 0 } }, 0 },
+ { "xcrypt-ecb", { { PADLOCK_Fixup, 0 } }, 0 },
+ { "xcrypt-cbc", { { PADLOCK_Fixup, 0 } }, 0 },
+ { "xcrypt-ctr", { { PADLOCK_Fixup, 0 } }, 0 },
+ { "xcrypt-cfb", { { PADLOCK_Fixup, 0 } }, 0 },
+ { "xcrypt-ofb", { { PADLOCK_Fixup, 0 } }, 0 },
{ PREFIX_TABLE (PREFIX_0FA7_REG_6) },
+ { "xrng2", { { PADLOCK_Fixup, 0 } }, 0 },
},
/* REG_0FAE */
{
@@ -3495,7 +3497,7 @@ static const struct dis386 prefix_table[][4] = {
/* PREFIX_0FA6_REG_0 */
{
{ Bad_Opcode },
- { "montmul", { { MONTMUL_Fixup, 0 } }, 0},
+ { "montmul", { { PADLOCK_Fixup, 0 } }, 0},
{ Bad_Opcode },
{ "sm2", { Skip_MODRM }, 0 },
},
@@ -13191,25 +13193,17 @@ OP_M (instr_info *ins, int bytemode, int sizeflag)
return OP_E_memory (ins, bytemode, sizeflag);
}
-static bool
-OP_0f07 (instr_info *ins, int bytemode, int sizeflag)
-{
- if (ins->modrm.mod != 3 || ins->modrm.rm != 0)
- return BadOp (ins);
- return OP_E (ins, bytemode, sizeflag);
-}
-
-/* montmul instruction need display repz and skip modrm */
+/* padlock instruction need display rep and skip modrm */
static bool
-MONTMUL_Fixup (instr_info *ins, int bytemode ATTRIBUTE_UNUSED, int sizeflag ATTRIBUTE_UNUSED)
+PADLOCK_Fixup (instr_info *ins, int bytemode ATTRIBUTE_UNUSED, int sizeflag ATTRIBUTE_UNUSED)
{
if (ins->modrm.mod != 3 || ins->modrm.rm != 0)
return BadOp (ins);
- /* The 0xf3 prefix should be displayed as "repz" for montmul. */
+ /* The 0xf3 prefix should be displayed as "rep" for padlock. */
if (ins->prefixes & PREFIX_REPZ)
- ins->all_prefixes[ins->last_repz_prefix] = 0xf3;
+ ins->all_prefixes[ins->last_repz_prefix] = REP_PREFIX;
/* Skip mod/rm byte. */
MODRM_CHECK;
diff --git a/opcodes/i386-opc.h b/opcodes/i386-opc.h
index e50f518ec1a..9d20f0a4359 100644
--- a/opcodes/i386-opc.h
+++ b/opcodes/i386-opc.h
@@ -64,7 +64,7 @@ enum i386_cpu
CpuSSE2,
/* SSE3 support required */
CpuSSE3,
- /* VIA PadLock required */
+ /* ZHAOXIN PadLock required */
CpuPadLock,
/* ZHAOXIN GMI required */
CpuGMI,
diff --git a/opcodes/i386-opc.tbl b/opcodes/i386-opc.tbl
index 502264cb78a..a52d597573e 100644
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -2114,16 +2114,21 @@ lzcnt, 0xf5, LZCNT&APX_F, Modrm|CheckOperandSize|No_bSuf|No_sSuf|EVexMap4|NF, {
popcnt, 0xf30fb8, POPCNT, Modrm|CheckOperandSize|No_bSuf|No_sSuf, { Reg16|Reg32|Reg64|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
popcnt, 0x88, POPCNT&APX_F, Modrm|CheckOperandSize|No_bSuf|No_sSuf|EVexMap4|NF, { Reg16|Reg32|Reg64|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
-// VIA PadLock extensions.
+// ZHAOXIN PadLock extensions.
xstore-rng, 0xfa7c0, PadLock, NoSuf|RepPrefixOk, {}
+xrng2, 0xf30fa7f8, PadLock, NoSuf|RepPrefixOk, {}
xcrypt-ecb, 0xf30fa7c8, PadLock, NoSuf|RepPrefixOk, {}
xcrypt-cbc, 0xf30fa7d0, PadLock, NoSuf|RepPrefixOk, {}
xcrypt-ctr, 0xf30fa7d8, PadLock, NoSuf|RepPrefixOk, {}
xcrypt-cfb, 0xf30fa7e0, PadLock, NoSuf|RepPrefixOk, {}
xcrypt-ofb, 0xf30fa7e8, PadLock, NoSuf|RepPrefixOk, {}
montmul, 0xf30fa6c0, PadLock, NoSuf|RepPrefixOk, {}
+montmul2, 0xf30fa6f0, PadLock, NoSuf|RepPrefixOk, {}
+xmodexp, 0xf30fa6f8, PadLock, NoSuf|RepPrefixOk, {}
xsha1, 0xf30fa6c8, PadLock, NoSuf|RepPrefixOk, {}
xsha256, 0xf30fa6d0, PadLock, NoSuf|RepPrefixOk, {}
+xsha384, 0xf30fa6d8, PadLock, NoSuf|RepPrefixOk, {}
+xsha512, 0xf30fa6e0, PadLock, NoSuf|RepPrefixOk, {}
// Aliases without hyphens.
xstorerng, 0xfa7c0, PadLock, NoSuf|RepPrefixOk, {}
xcryptecb, 0xf30fa7c8, PadLock, NoSuf|RepPrefixOk, {}
--
2.27.0
^ permalink raw reply [flat|nested] 80+ messages in thread
* RE: [PATCH v1] x86: Support ZHAOXIN padlock instructions
2024-12-13 3:25 ` [PATCH v1] x86: Support ZHAOXIN padlock instructions Mayshao-oc
@ 2024-12-13 8:50 ` Jiang, Haochen
2024-12-16 6:48 ` Mayshao-oc
2024-12-16 7:03 ` [PATCH v1] x86: Change padlock instructions prefix as rep Mayshao-oc
2024-12-19 10:33 ` [PATCH v1] x86: Support ZHAOXIN padlock instructions Jan Beulich
1 sibling, 2 replies; 80+ messages in thread
From: Jiang, Haochen @ 2024-12-13 8:50 UTC (permalink / raw)
To: Mayshao-oc, Beulich, Jan
Cc: H.J. Lu, Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, mludvig
> From: Mayshao-oc <Mayshao-oc@zhaoxin.com>
> Sent: Friday, December 13, 2024 11:25 AM
>
> Hi all:
>
> This patch adds support for Zhaoxin padlock instructions, and display all the
> padlock instructions using rep prefix instead of repz, because all padlock
> instructions don't effect zf flag.
>
A quick reminder. From documentation, it seems that Zhaoxin is going to extend
the usage for old bits for new instructions. If you are only using inline asm in the
future (and I suppose so since I did not get PadLock in GCC code base from my quick
search), it should be ok. But there will be a potential issue for illegal instruction on
HW if the assumption is wrong since I don't see a way to reject those insts.
For the patch, could you split it into two patch, one to replace repz and one to add
new insts? It will help to get a clearer picture on refactoring.
Thx,
Haochen
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v1] x86: Support ZHAOXIN padlock instructions
2024-12-13 8:50 ` Jiang, Haochen
@ 2024-12-16 6:48 ` Mayshao-oc
2024-12-16 7:17 ` Jiang, Haochen
2024-12-16 7:03 ` [PATCH v1] x86: Change padlock instructions prefix as rep Mayshao-oc
1 sibling, 1 reply; 80+ messages in thread
From: Mayshao-oc @ 2024-12-16 6:48 UTC (permalink / raw)
To: Jiang, Haochen, Beulich, Jan
Cc: H.J. Lu, Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD), binutils
> > From: Mayshao-oc <Mayshao-oc@zhaoxin.com>
> > Sent: Friday, December 13, 2024 11:25 AM
> >
> > Hi all:
> >
> > This patch adds support for Zhaoxin padlock instructions, and display all the
> > padlock instructions using rep prefix instead of repz, because all padlock
> > instructions don't effect zf flag.
> >
>
> A quick reminder. From documentation, it seems that Zhaoxin is going to extend
> the usage for old bits for new instructions. If you are only using inline asm in the
> future (and I suppose so since I did not get PadLock in GCC code base from my quick
> search), it should be ok. But there will be a potential issue for illegal instruction on
> HW if the assumption is wrong since I don't see a way to reject those insts.
Hi Haochen:
Thanks for your comments,but I am a little confused.Why it is ok to be used as inline assembly,
and there will be an issue if gcc generates it? Could you please give an example to illustrate
your idea?
>
> For the patch, could you split it into two patch, one to replace repz and one to add
> new insts? It will help to get a clearer picture on refactoring.
Ok, I'll do it.
>
> Thx,
> Haochen
BR
Mayshao
^ permalink raw reply [flat|nested] 80+ messages in thread
* [PATCH v1] x86: Change padlock instructions prefix as rep
2024-12-13 8:50 ` Jiang, Haochen
2024-12-16 6:48 ` Mayshao-oc
@ 2024-12-16 7:03 ` Mayshao-oc
2024-12-19 10:26 ` Jan Beulich
1 sibling, 1 reply; 80+ messages in thread
From: Mayshao-oc @ 2024-12-16 7:03 UTC (permalink / raw)
To: Jiang, Haochen, Beulich, Jan
Cc: H.J. Lu, Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, mludvig
[-- Attachment #1: Type: text/plain, Size: 187 bytes --]
Hi all:
This patch change the display of all padlock instructions prefix
from repz to rep, because padlock instructions don't effect zf flag.
Test ok, ok for trunk?
BR
Mayshao
[-- Attachment #2: 0001-display-padlock-insts-prefix-as-rep.patch --]
[-- Type: application/octet-stream, Size: 7416 bytes --]
From b8efd62e7856de987113db1e271cb22838a4dbe0 Mon Sep 17 00:00:00 2001
From: MayShao-oc <MayShao-oc@zhaoxin.com>
Date: Mon, 16 Dec 2024 13:54:13 +0800
Subject: [PATCH] x86: Change padlock instructions prefix as rep
Hi all:
This patch change the display of all padlock instructions prefix
from repz to rep, because padlock instructions don't effect zf flag.
Test ok, ok for trunk?
BR
Mayshao
gas/ChangeLog:
* testsuite/gas/i386/padlock.d: Change padlock instructions prefix.
opcodes/ChangeLog:
* i386-dis.c (OP_0f07): Delete.
(MONTMUL_Fixup): Ditto.
(PADLOCK_Fixup): New.
---
gas/testsuite/gas/i386/padlock.d | 32 +++++++++++++--------------
gas/testsuite/gas/i386/padlock.s | 2 +-
opcodes/i386-dis.c | 37 ++++++++++++--------------------
opcodes/i386-opc.h | 2 +-
opcodes/i386-opc.tbl | 2 +-
5 files changed, 33 insertions(+), 42 deletions(-)
diff --git a/gas/testsuite/gas/i386/padlock.d b/gas/testsuite/gas/i386/padlock.d
index eae6b24ac3e..663b1ab0697 100644
--- a/gas/testsuite/gas/i386/padlock.d
+++ b/gas/testsuite/gas/i386/padlock.d
@@ -7,21 +7,21 @@ Disassembly of section .text:
0+000 <foo>:
0:[ ]*0f a7 c0 [ ]*xstore-rng
- 3:[ ]*f3 0f a7 c0 [ ]*repz xstore-rng
- 7:[ ]*f3 0f a7 c8 [ ]*repz xcrypt-ecb
- b:[ ]*f3 0f a7 c8 [ ]*repz xcrypt-ecb
- f:[ ]*f3 0f a7 d0 [ ]*repz xcrypt-cbc
- 13:[ ]*f3 0f a7 d0 [ ]*repz xcrypt-cbc
- 17:[ ]*f3 0f a7 e0 [ ]*repz xcrypt-cfb
- 1b:[ ]*f3 0f a7 e0 [ ]*repz xcrypt-cfb
- 1f:[ ]*f3 0f a7 e8 [ ]*repz xcrypt-ofb
- 23:[ ]*f3 0f a7 e8 [ ]*repz xcrypt-ofb
+ 3:[ ]*f3 0f a7 c0 [ ]*rep xstore-rng
+ 7:[ ]*f3 0f a7 c8 [ ]*rep xcrypt-ecb
+ b:[ ]*f3 0f a7 c8 [ ]*rep xcrypt-ecb
+ f:[ ]*f3 0f a7 d0 [ ]*rep xcrypt-cbc
+ 13:[ ]*f3 0f a7 d0 [ ]*rep xcrypt-cbc
+ 17:[ ]*f3 0f a7 e0 [ ]*rep xcrypt-cfb
+ 1b:[ ]*f3 0f a7 e0 [ ]*rep xcrypt-cfb
+ 1f:[ ]*f3 0f a7 e8 [ ]*rep xcrypt-ofb
+ 23:[ ]*f3 0f a7 e8 [ ]*rep xcrypt-ofb
27:[ ]*0f a7 c0 [ ]*xstore-rng
- 2a:[ ]*f3 0f a7 c0 [ ]*repz xstore-rng
- 2e:[ ]*f3 0f a6 c0 [ ]*repz montmul
- 32:[ ]*f3 0f a6 c0 [ ]*repz montmul
- 36:[ ]*f3 0f a6 c8 [ ]*repz xsha1
- 3a:[ ]*f3 0f a6 c8 [ ]*repz xsha1
- 3e:[ ]*f3 0f a6 d0 [ ]*repz xsha256
- 42:[ ]*f3 0f a6 d0 [ ]*repz xsha256
+ 2a:[ ]*f3 0f a7 c0 [ ]*rep xstore-rng
+ 2e:[ ]*f3 0f a6 c0 [ ]*rep montmul
+ 32:[ ]*f3 0f a6 c0 [ ]*rep montmul
+ 36:[ ]*f3 0f a6 c8 [ ]*rep xsha1
+ 3a:[ ]*f3 0f a6 c8 [ ]*rep xsha1
+ 3e:[ ]*f3 0f a6 d0 [ ]*rep xsha256
+ 42:[ ]*f3 0f a6 d0 [ ]*rep xsha256
#pass
diff --git a/gas/testsuite/gas/i386/padlock.s b/gas/testsuite/gas/i386/padlock.s
index b4a19506b27..6c22fab90fa 100644
--- a/gas/testsuite/gas/i386/padlock.s
+++ b/gas/testsuite/gas/i386/padlock.s
@@ -1,4 +1,4 @@
-# VIA Nehemiah PadLock instructions
+# ZHAOXIN PadLock instructions
.text
foo:
diff --git a/opcodes/i386-dis.c b/opcodes/i386-dis.c
index 8795e397082..ef926c303e5 100644
--- a/opcodes/i386-dis.c
+++ b/opcodes/i386-dis.c
@@ -82,7 +82,6 @@ static bool OP_VexW (instr_info *, int, int);
static bool OP_Rounding (instr_info *, int, int);
static bool OP_REG_VexI4 (instr_info *, int, int);
static bool OP_VexI4 (instr_info *, int, int);
-static bool OP_0f07 (instr_info *, int, int);
static bool OP_Monitor (instr_info *, int, int);
static bool OP_Mwait (instr_info *, int, int);
@@ -90,7 +89,7 @@ static bool PCLMUL_Fixup (instr_info *, int, int);
static bool VPCMP_Fixup (instr_info *, int, int);
static bool VPCOM_Fixup (instr_info *, int, int);
static bool NOP_Fixup (instr_info *, int, int);
-static bool MONTMUL_Fixup (instr_info *, int, int);
+static bool PADLOCK_Fixup (instr_info *, int, int);
static bool OP_3DNowSuffix (instr_info *, int, int);
static bool CMP_Fixup (instr_info *, int, int);
static bool REP_Fixup (instr_info *, int, int);
@@ -2897,20 +2896,20 @@ static const struct dis386 reg_table[][8] = {
/* REG_0FA6 */
{
{ PREFIX_TABLE (PREFIX_0FA6_REG_0) },
- { "xsha1", { { OP_0f07, 0 } }, 0 },
- { "xsha256", { { OP_0f07, 0 } }, 0 },
+ { "xsha1", { { PADLOCK_Fixup, 0 } }, 0 },
+ { "xsha256", { { PADLOCK_Fixup, 0 } }, 0 },
{ Bad_Opcode },
{ Bad_Opcode },
{ PREFIX_TABLE (PREFIX_0FA6_REG_5) },
},
/* REG_0FA7 */
{
- { "xstore-rng", { { OP_0f07, 0 } }, 0 },
- { "xcrypt-ecb", { { OP_0f07, 0 } }, 0 },
- { "xcrypt-cbc", { { OP_0f07, 0 } }, 0 },
- { "xcrypt-ctr", { { OP_0f07, 0 } }, 0 },
- { "xcrypt-cfb", { { OP_0f07, 0 } }, 0 },
- { "xcrypt-ofb", { { OP_0f07, 0 } }, 0 },
+ { "xstore-rng", { { PADLOCK_Fixup, 0 } }, 0 },
+ { "xcrypt-ecb", { { PADLOCK_Fixup, 0 } }, 0 },
+ { "xcrypt-cbc", { { PADLOCK_Fixup, 0 } }, 0 },
+ { "xcrypt-ctr", { { PADLOCK_Fixup, 0 } }, 0 },
+ { "xcrypt-cfb", { { PADLOCK_Fixup, 0 } }, 0 },
+ { "xcrypt-ofb", { { PADLOCK_Fixup, 0 } }, 0 },
{ PREFIX_TABLE (PREFIX_0FA7_REG_6) },
},
/* REG_0FAE */
@@ -3495,7 +3494,7 @@ static const struct dis386 prefix_table[][4] = {
/* PREFIX_0FA6_REG_0 */
{
{ Bad_Opcode },
- { "montmul", { { MONTMUL_Fixup, 0 } }, 0},
+ { "montmul", { { PADLOCK_Fixup, 0 } }, 0},
{ Bad_Opcode },
{ "sm2", { Skip_MODRM }, 0 },
},
@@ -13191,25 +13190,17 @@ OP_M (instr_info *ins, int bytemode, int sizeflag)
return OP_E_memory (ins, bytemode, sizeflag);
}
-static bool
-OP_0f07 (instr_info *ins, int bytemode, int sizeflag)
-{
- if (ins->modrm.mod != 3 || ins->modrm.rm != 0)
- return BadOp (ins);
- return OP_E (ins, bytemode, sizeflag);
-}
-
-/* montmul instruction need display repz and skip modrm */
+/* padlock instruction need display rep and skip modrm */
static bool
-MONTMUL_Fixup (instr_info *ins, int bytemode ATTRIBUTE_UNUSED, int sizeflag ATTRIBUTE_UNUSED)
+PADLOCK_Fixup (instr_info *ins, int bytemode ATTRIBUTE_UNUSED, int sizeflag ATTRIBUTE_UNUSED)
{
if (ins->modrm.mod != 3 || ins->modrm.rm != 0)
return BadOp (ins);
- /* The 0xf3 prefix should be displayed as "repz" for montmul. */
+ /* The 0xf3 prefix should be displayed as "rep" for padlock. */
if (ins->prefixes & PREFIX_REPZ)
- ins->all_prefixes[ins->last_repz_prefix] = 0xf3;
+ ins->all_prefixes[ins->last_repz_prefix] = REP_PREFIX;
/* Skip mod/rm byte. */
MODRM_CHECK;
diff --git a/opcodes/i386-opc.h b/opcodes/i386-opc.h
index e50f518ec1a..9d20f0a4359 100644
--- a/opcodes/i386-opc.h
+++ b/opcodes/i386-opc.h
@@ -64,7 +64,7 @@ enum i386_cpu
CpuSSE2,
/* SSE3 support required */
CpuSSE3,
- /* VIA PadLock required */
+ /* ZHAOXIN PadLock required */
CpuPadLock,
/* ZHAOXIN GMI required */
CpuGMI,
diff --git a/opcodes/i386-opc.tbl b/opcodes/i386-opc.tbl
index 502264cb78a..2e973a4a9b1 100644
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -2114,7 +2114,7 @@ lzcnt, 0xf5, LZCNT&APX_F, Modrm|CheckOperandSize|No_bSuf|No_sSuf|EVexMap4|NF, {
popcnt, 0xf30fb8, POPCNT, Modrm|CheckOperandSize|No_bSuf|No_sSuf, { Reg16|Reg32|Reg64|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
popcnt, 0x88, POPCNT&APX_F, Modrm|CheckOperandSize|No_bSuf|No_sSuf|EVexMap4|NF, { Reg16|Reg32|Reg64|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
-// VIA PadLock extensions.
+// ZHAOXIN PadLock extensions.
xstore-rng, 0xfa7c0, PadLock, NoSuf|RepPrefixOk, {}
xcrypt-ecb, 0xf30fa7c8, PadLock, NoSuf|RepPrefixOk, {}
xcrypt-cbc, 0xf30fa7d0, PadLock, NoSuf|RepPrefixOk, {}
--
2.27.0
^ permalink raw reply [flat|nested] 80+ messages in thread
* RE: [PATCH v1] x86: Support ZHAOXIN padlock instructions
2024-12-16 6:48 ` Mayshao-oc
@ 2024-12-16 7:17 ` Jiang, Haochen
2024-12-17 2:56 ` Mayshao-oc
0 siblings, 1 reply; 80+ messages in thread
From: Jiang, Haochen @ 2024-12-16 7:17 UTC (permalink / raw)
To: Mayshao-oc, Beulich, Jan
Cc: H.J. Lu, Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD), binutils
> From: Mayshao-oc <Mayshao-oc@zhaoxin.com>
> Sent: Monday, December 16, 2024 2:48 PM
> >
> > A quick reminder. From documentation, it seems that Zhaoxin is going to extend
> > the usage for old bits for new instructions. If you are only using inline asm in the
> > future (and I suppose so since I did not get PadLock in GCC code base from my quick
> > search), it should be ok. But there will be a potential issue for illegal instruction on
> > HW if the assumption is wrong since I don't see a way to reject those insts.
> Hi Haochen:
> Thanks for your comments,but I am a little confused.Why it is ok to be
> used as inline assembly,
> and there will be an issue if gcc generates it? Could you please give an example
> to illustrate
> your idea?
Let's assume that you enabled the new insts with new intrins in GCC. Then for example,
when we are building a source file with GCC and -march=native on an old machine
has PadLock bit set, GCC will also enable the new insts since they are combined. Then if
you used the new intrins, GCC could not reject the code the machine does not support.
HW will throw out illegal inst at the end of the day. This is not an expected behavior for
compiler. Compiler should reject that intrin at the beginning.
On the other hand, inline assembly in a source file won't check CPUID when compiling
with GCC. User should use asm at their own risk and have the knowledge the asm they
wrote is valid or not. They should not expect compiler reject inline assembly.
But as I said, if you are not going to add new intrins, it seems no problem for the CPUID.
Thx,
Haochen
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v1] x86: Support ZHAOXIN padlock instructions
2024-12-16 7:17 ` Jiang, Haochen
@ 2024-12-17 2:56 ` Mayshao-oc
0 siblings, 0 replies; 80+ messages in thread
From: Mayshao-oc @ 2024-12-17 2:56 UTC (permalink / raw)
To: Jiang, Haochen, Beulich, Jan
Cc: H.J. Lu, Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD), binutils
> > From: Mayshao-oc <Mayshao-oc@zhaoxin.com>
> > Sent: Monday, December 16, 2024 2:48 PM
> > >
> > > A quick reminder. From documentation, it seems that Zhaoxin is going to extend
> > > the usage for old bits for new instructions. If you are only using inline asm in the
> > > future (and I suppose so since I did not get PadLock in GCC code base from my quick
> > > search), it should be ok. But there will be a potential issue for illegal instruction on
> > > HW if the assumption is wrong since I don't see a way to reject those insts.
> > Hi Haochen:
> > Thanks for your comments,but I am a little confused.Why it is ok to be
> > used as inline assembly,
> > and there will be an issue if gcc generates it? Could you please give an example
> > to illustrate
> > your idea?
>
> Let's assume that you enabled the new insts with new intrins in GCC. Then for example,
> when we are building a source file with GCC and -march=native on an old machine
> has PadLock bit set, GCC will also enable the new insts since they are combined. Then if
> you used the new intrins, GCC could not reject the code the machine does not support.
> HW will throw out illegal inst at the end of the day. This is not an expected behavior for
> compiler. Compiler should reject that intrin at the beginning.
>
> On the other hand, inline assembly in a source file won't check CPUID when compiling
> with GCC. User should use asm at their own risk and have the knowledge the asm they
> wrote is valid or not. They should not expect compiler reject inline assembly.
>
> But as I said, if you are not going to add new intrins, it seems no problem for the CPUID.
>
> Thx,
> Haochen
Hi Haochen:
Thanks for your patience. I got it.
For the Zhaoxin platforms, we can guarantee the CPUID information is correct. For example, if cpuid return edx bit[3] that xstore, rep xstore, and rep xrng2 instructions are present, then these instructions exist.So no illegal inst GP will generate.
For the VIA platforms, GCC does not detect features for VIA CPUs(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100758), so I think gcc will never generate any padlock instructions on these platforms.
So practically, there is no need for gcc to reject these instructions.
BR
Mayshao
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v1] x86: Change padlock instructions prefix as rep
2024-12-16 7:03 ` [PATCH v1] x86: Change padlock instructions prefix as rep Mayshao-oc
@ 2024-12-19 10:26 ` Jan Beulich
2024-12-24 1:57 ` Mayshao-oc
0 siblings, 1 reply; 80+ messages in thread
From: Jan Beulich @ 2024-12-19 10:26 UTC (permalink / raw)
To: Mayshao-oc
Cc: H.J. Lu, Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, mludvig, Jiang, Haochen
On 16.12.2024 08:03, Mayshao-oc wrote:
> Hi all:
> This patch change the display of all padlock instructions prefix
> from repz to rep, because padlock instructions don't effect zf flag.
"Affect" doesn't matter for REP/REPZ/REPNZ. What may matter is that ZF
isn't checked by these insns. However, can you confirm that on the VIA
CPUs the same opcodes prefixed with REPNZ wouldn't have the same
behavior? I have a sneaking suspicion that while not documented that
way, either REP would have been "fine" (just like is the case for e.g.
LODS, MOVS, and STOS). If that was the case, then sticking to REPZ in
disassembly may be better.
As to the actual changes, two remarks:
Why do you fiddle with the comments in gas/testsuite/gas/i386/padlock.s,
opcodes/i386-opc.h, and opcodes/i386-opc.tbl? (Even if that was
appropriate for some reason, please can you avoid spelling Zhaoxin all
uppercase? That's the cosmetic adjustment which I meant to do to the
earlier patch that Haochen ended up rushing in. Aiui VIA is an
abbreviation while Zhaoxin isn't.)
In the comment immediately ahead of PADLOCK_Fixup() you want to change
from singular to plural, now that the function deals with multiple
insns.
As to the mechanical ChangeLog - you don't really delete MONTMUL_Fixup()
and introduce a brand new PADLOCK_Fixup(). Instead you rename the former
to the latter.
Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v1] x86: Support ZHAOXIN padlock instructions
2024-12-13 3:25 ` [PATCH v1] x86: Support ZHAOXIN padlock instructions Mayshao-oc
2024-12-13 8:50 ` Jiang, Haochen
@ 2024-12-19 10:33 ` Jan Beulich
2024-12-24 1:59 ` Mayshao-oc
1 sibling, 1 reply; 80+ messages in thread
From: Jan Beulich @ 2024-12-19 10:33 UTC (permalink / raw)
To: Mayshao-oc
Cc: H.J. Lu, Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen, mludvig
On 13.12.2024 04:25, Mayshao-oc wrote:
> This patch adds support for Zhaoxin padlock instructions, and
> display all the padlock instructions using rep prefix instead of repz,
> because all padlock instructions don't effect zf flag.
Shouldn't the 2nd hunk changing gas/testsuite/gas/i386/padlock.s also
be part of the split out patch you sent out later (or yet another
separate one)?
For the xrng2 table entry in the disassembler, please make padding
adhere to what adjacent similar entries have.
And no, along the lines what Haochen indicated in his reply: You cannot
tie the new insns to the same old PadLock CPU feature. Iirc you had
that properly separate in the earlier form of the patch.
In those opcode table additions I'm also puzzled about where you insert
new entries: The table section looks to be at least partly sorted. I'd
expect you to respect that partial sorting.
Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v1] x86: Change padlock instructions prefix as rep
2024-12-19 10:26 ` Jan Beulich
@ 2024-12-24 1:57 ` Mayshao-oc
0 siblings, 0 replies; 80+ messages in thread
From: Mayshao-oc @ 2024-12-24 1:57 UTC (permalink / raw)
To: Jan Beulich
Cc: H.J. Lu, Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen
> On 16.12.2024 08:03, Mayshao-oc wrote:
>
> > Hi all:
>
> > This patch change the display of all padlock instructions prefix
>
> > from repz to rep, because padlock instructions don't effect zf flag.
>
>
>
> "Affect" doesn't matter for REP/REPZ/REPNZ. What may matter is that ZF isn't checked by these insns. However, can you confirm that on the VIA CPUs the same opcodes prefixed with REPNZ wouldn't have the same behavior? I have a sneaking suspicion that while not documented that way, either REP would have been "fine" (just like is the case for e.g.
>
> LODS, MOVS, and STOS). If that was the case, then sticking to REPZ in disassembly may be better.
Thanks for your comment. I will stick to REPZ.
>
>
>
> As to the actual changes, two remarks:
>
>
>
> Why do you fiddle with the comments in gas/testsuite/gas/i386/padlock.s, opcodes/i386-opc.h, and opcodes/i386-opc.tbl? (Even if that was appropriate for some reason, please can you avoid spelling Zhaoxin all uppercase? That's the cosmetic adjustment which I meant to do to the earlier patch that Haochen ended up rushing in. Aiui VIA is an abbreviation while Zhaoxin isn't.)
I wanna use comments to convey the message that Zhaoxin support this instructions, so software guys know where to look for the information about these instructions. I will pay attention to the letter case, thanks.
>
>
>
> In the comment immediately ahead of PADLOCK_Fixup() you want to change from singular to plural, now that the function deals with multiple insns.
>
>
>
> As to the mechanical ChangeLog - you don't really delete MONTMUL_Fixup() and introduce a brand new PADLOCK_Fixup(). Instead you rename the former to the latter.
Thanks for your comments, I fix this in the new patch.
>
>
>
> Jan
BR
Mayshao
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v1] x86: Support ZHAOXIN padlock instructions
2024-12-19 10:33 ` [PATCH v1] x86: Support ZHAOXIN padlock instructions Jan Beulich
@ 2024-12-24 1:59 ` Mayshao-oc
2024-12-27 11:31 ` Jan Beulich
0 siblings, 1 reply; 80+ messages in thread
From: Mayshao-oc @ 2024-12-24 1:59 UTC (permalink / raw)
To: Jan Beulich
Cc: H.J. Lu, Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen
[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]
> On 13.12.2024 04:25, Mayshao-oc wrote:
> > This patch adds support for Zhaoxin padlock instructions, and
> > display all the padlock instructions using rep prefix instead of repz,
> > because all padlock instructions don't effect zf flag.
>
> Shouldn't the 2nd hunk changing gas/testsuite/gas/i386/padlock.s also be part of the split out patch you sent out later (or yet another separate one)?
>
> For the xrng2 table entry in the disassembler, please make padding adhere to what adjacent similar entries have.
>
> And no, along the lines what Haochen indicated in his reply: You cannot tie the new insns to the same old PadLock CPU feature. Iirc you had that properly separate in the earlier form of the patch.
>
> In those opcode table additions I'm also puzzled about where you insert new entries: The table section looks to be at least partly sorted. I'd expect you to respect that partial sorting.
>
> Jan
Hi Jan:
Thanks for your review, I change the patch according to your comments.
As to the "You cannot tie the new insns to the same old PadLock CPU feature", I agree with you, new insns need new cpuid bit to indicate their present.
BR
Mayshao
[-- Attachment #2: 0002-padlock.patch --]
[-- Type: application/octet-stream, Size: 8688 bytes --]
From 9fae18a9e83677f5da5df196a4ed1d2691dd06bd Mon Sep 17 00:00:00 2001
From: MayShao-oc <MayShao-oc@zhaoxin.com>
Date: Mon, 23 Dec 2024 13:57:17 +0800
Subject: [PATCH v2] x86: Support Zhaoxin padlock instructions
Hi all:
This patch adds support for Zhaoxin padlock instructions.
BR
Mayshao
gas/ChangeLog:
* testsuite/gas/i386/padlock.d: Add xcryptctr, xrng2, xsha384,
xsha512, xmodexp, montmul2 test.
* testsuite/gas/i386/padlock.s: Ditto.
opcodes/ChangeLog:
* i386-dis.c (OP_0f07): Delete.
(MONTMUL_Fixup): Rename to PADLOCK_Fixups.
* i386-opc.tbl: Add xrng2, xsha384, xsha512, xmodexp, montmul2
instructions.
---
gas/testsuite/gas/i386/padlock.d | 12 +++++++++
gas/testsuite/gas/i386/padlock.s | 14 ++++++++++-
opcodes/i386-dis.c | 42 ++++++++++++++------------------
opcodes/i386-opc.h | 4 +--
opcodes/i386-opc.tbl | 23 ++++++++++-------
5 files changed, 59 insertions(+), 36 deletions(-)
diff --git a/gas/testsuite/gas/i386/padlock.d b/gas/testsuite/gas/i386/padlock.d
index eae6b24ac3e..4a8917ace09 100644
--- a/gas/testsuite/gas/i386/padlock.d
+++ b/gas/testsuite/gas/i386/padlock.d
@@ -24,4 +24,16 @@ Disassembly of section .text:
3a:[ ]*f3 0f a6 c8 [ ]*repz xsha1
3e:[ ]*f3 0f a6 d0 [ ]*repz xsha256
42:[ ]*f3 0f a6 d0 [ ]*repz xsha256
+ 46:[ ]*f3 0f a6 f0 [ ]*repz montmul2
+ 4a:[ ]*f3 0f a6 f0 [ ]*repz montmul2
+ 4e:[ ]*f3 0f a7 d8 [ ]*repz xcrypt-ctr
+ 52:[ ]*f3 0f a7 d8 [ ]*repz xcrypt-ctr
+ 56:[ ]*f3 0f a6 f8 [ ]*repz xmodexp
+ 5a:[ ]*f3 0f a6 f8 [ ]*repz xmodexp
+ 5e:[ ]*f3 0f a7 f8 [ ]*repz xrng2
+ 62:[ ]*f3 0f a7 f8 [ ]*repz xrng2
+ 66:[ ]*f3 0f a6 d8 [ ]*repz xsha384
+ 6a:[ ]*f3 0f a6 d8 [ ]*repz xsha384
+ 6e:[ ]*f3 0f a6 e0 [ ]*repz xsha512
+ 72:[ ]*f3 0f a6 e0 [ ]*repz xsha512
#pass
diff --git a/gas/testsuite/gas/i386/padlock.s b/gas/testsuite/gas/i386/padlock.s
index b4a19506b27..c7eceaa729e 100644
--- a/gas/testsuite/gas/i386/padlock.s
+++ b/gas/testsuite/gas/i386/padlock.s
@@ -1,4 +1,4 @@
-# VIA Nehemiah PadLock instructions
+# Zhaoxin PadLock instructions
.text
foo:
@@ -20,5 +20,17 @@ foo:
rep xsha1
xsha256
rep xsha256
+ montmul2
+ rep montmul2
+ xcryptctr
+ rep xcryptctr
+ xmodexp
+ rep xmodexp
+ xrng2
+ rep xrng2
+ xsha384
+ rep xsha384
+ xsha512
+ rep xsha512
.p2align 4,0
diff --git a/opcodes/i386-dis.c b/opcodes/i386-dis.c
index e8f5d8b293c..245a579b8fa 100644
--- a/opcodes/i386-dis.c
+++ b/opcodes/i386-dis.c
@@ -82,7 +82,6 @@ static bool OP_VexW (instr_info *, int, int);
static bool OP_Rounding (instr_info *, int, int);
static bool OP_REG_VexI4 (instr_info *, int, int);
static bool OP_VexI4 (instr_info *, int, int);
-static bool OP_0f07 (instr_info *, int, int);
static bool OP_Monitor (instr_info *, int, int);
static bool OP_Mwait (instr_info *, int, int);
@@ -90,7 +89,7 @@ static bool PCLMUL_Fixup (instr_info *, int, int);
static bool VPCMP_Fixup (instr_info *, int, int);
static bool VPCOM_Fixup (instr_info *, int, int);
static bool NOP_Fixup (instr_info *, int, int);
-static bool MONTMUL_Fixup (instr_info *, int, int);
+static bool PADLOCK_Fixups (instr_info *, int, int);
static bool OP_3DNowSuffix (instr_info *, int, int);
static bool CMP_Fixup (instr_info *, int, int);
static bool REP_Fixup (instr_info *, int, int);
@@ -2897,21 +2896,24 @@ static const struct dis386 reg_table[][8] = {
/* REG_0FA6 */
{
{ PREFIX_TABLE (PREFIX_0FA6_REG_0) },
- { "xsha1", { { OP_0f07, 0 } }, 0 },
- { "xsha256", { { OP_0f07, 0 } }, 0 },
- { Bad_Opcode },
- { Bad_Opcode },
+ { "xsha1", { { PADLOCK_Fixups, 0 } }, 0 },
+ { "xsha256", { { PADLOCK_Fixups, 0 } }, 0 },
+ { "xsha384", { { PADLOCK_Fixups, 0 } }, 0 },
+ { "xsha512", { { PADLOCK_Fixups, 0 } }, 0 },
{ PREFIX_TABLE (PREFIX_0FA6_REG_5) },
+ { "montmul2", { { PADLOCK_Fixups, 0 } }, 0},
+ { "xmodexp", { { PADLOCK_Fixups, 0 } }, 0},
},
/* REG_0FA7 */
{
- { "xstore-rng", { { OP_0f07, 0 } }, 0 },
- { "xcrypt-ecb", { { OP_0f07, 0 } }, 0 },
- { "xcrypt-cbc", { { OP_0f07, 0 } }, 0 },
- { "xcrypt-ctr", { { OP_0f07, 0 } }, 0 },
- { "xcrypt-cfb", { { OP_0f07, 0 } }, 0 },
- { "xcrypt-ofb", { { OP_0f07, 0 } }, 0 },
+ { "xstore-rng", { { PADLOCK_Fixups, 0 } }, 0 },
+ { "xcrypt-ecb", { { PADLOCK_Fixups, 0 } }, 0 },
+ { "xcrypt-cbc", { { PADLOCK_Fixups, 0 } }, 0 },
+ { "xcrypt-ctr", { { PADLOCK_Fixups, 0 } }, 0 },
+ { "xcrypt-cfb", { { PADLOCK_Fixups, 0 } }, 0 },
+ { "xcrypt-ofb", { { PADLOCK_Fixups, 0 } }, 0 },
{ PREFIX_TABLE (PREFIX_0FA7_REG_6) },
+ { "xrng2", { { PADLOCK_Fixups, 0 } }, 0 },
},
/* REG_0FAE */
{
@@ -3495,7 +3497,7 @@ static const struct dis386 prefix_table[][4] = {
/* PREFIX_0FA6_REG_0 */
{
{ Bad_Opcode },
- { "montmul", { { MONTMUL_Fixup, 0 } }, 0},
+ { "montmul", { { PADLOCK_Fixups, 0 } }, 0},
{ Bad_Opcode },
{ "sm2", { Skip_MODRM }, 0 },
},
@@ -13191,23 +13193,15 @@ OP_M (instr_info *ins, int bytemode, int sizeflag)
return OP_E_memory (ins, bytemode, sizeflag);
}
-static bool
-OP_0f07 (instr_info *ins, int bytemode, int sizeflag)
-{
- if (ins->modrm.mod != 3 || ins->modrm.rm != 0)
- return BadOp (ins);
- return OP_E (ins, bytemode, sizeflag);
-}
-
-/* montmul instruction need display repz and skip modrm */
+/* padlock instruction need display repz and skip modrm */
static bool
-MONTMUL_Fixup (instr_info *ins, int bytemode ATTRIBUTE_UNUSED, int sizeflag ATTRIBUTE_UNUSED)
+PADLOCK_Fixups (instr_info *ins, int bytemode ATTRIBUTE_UNUSED, int sizeflag ATTRIBUTE_UNUSED)
{
if (ins->modrm.mod != 3 || ins->modrm.rm != 0)
return BadOp (ins);
- /* The 0xf3 prefix should be displayed as "repz" for montmul. */
+ /* The 0xf3 prefix should be displayed as "repz" for padlock. */
if (ins->prefixes & PREFIX_REPZ)
ins->all_prefixes[ins->last_repz_prefix] = 0xf3;
diff --git a/opcodes/i386-opc.h b/opcodes/i386-opc.h
index 75d8c4f8b70..3def7a50d7b 100644
--- a/opcodes/i386-opc.h
+++ b/opcodes/i386-opc.h
@@ -64,9 +64,9 @@ enum i386_cpu
CpuSSE2,
/* SSE3 support required */
CpuSSE3,
- /* VIA PadLock required */
+ /* Zhaoxin PadLock required */
CpuPadLock,
- /* ZHAOXIN GMI required */
+ /* Zhaoxin GMI required */
CpuGMI,
/* AMD Secure Virtual Machine Ext-s required */
CpuSVME,
diff --git a/opcodes/i386-opc.tbl b/opcodes/i386-opc.tbl
index 5800e5811f4..c847bd5c68e 100644
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -2114,27 +2114,32 @@ lzcnt, 0xf5, LZCNT&APX_F, Modrm|CheckOperandSize|No_bSuf|No_sSuf|EVexMap4|NF, {
popcnt, 0xf30fb8, POPCNT, Modrm|CheckOperandSize|No_bSuf|No_sSuf, { Reg16|Reg32|Reg64|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
popcnt, 0x88, POPCNT&APX_F, Modrm|CheckOperandSize|No_bSuf|No_sSuf|EVexMap4|NF, { Reg16|Reg32|Reg64|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
-// VIA PadLock extensions.
-xstore-rng, 0xfa7c0, PadLock, NoSuf|RepPrefixOk, {}
-xcrypt-ecb, 0xf30fa7c8, PadLock, NoSuf|RepPrefixOk, {}
+// Zhaoxin PadLock extensions.
+montmul, 0xf30fa6c0, PadLock, NoSuf|RepPrefixOk, {}
+montmul2, 0xf30fa6f0, PadLock, NoSuf|RepPrefixOk, {}
xcrypt-cbc, 0xf30fa7d0, PadLock, NoSuf|RepPrefixOk, {}
-xcrypt-ctr, 0xf30fa7d8, PadLock, NoSuf|RepPrefixOk, {}
xcrypt-cfb, 0xf30fa7e0, PadLock, NoSuf|RepPrefixOk, {}
+xcrypt-ctr, 0xf30fa7d8, PadLock, NoSuf|RepPrefixOk, {}
+xcrypt-ecb, 0xf30fa7c8, PadLock, NoSuf|RepPrefixOk, {}
xcrypt-ofb, 0xf30fa7e8, PadLock, NoSuf|RepPrefixOk, {}
-montmul, 0xf30fa6c0, PadLock, NoSuf|RepPrefixOk, {}
+xmodexp, 0xf30fa6f8, PadLock, NoSuf|RepPrefixOk, {}
+xrng2, 0xf30fa7f8, PadLock, NoSuf|RepPrefixOk, {}
xsha1, 0xf30fa6c8, PadLock, NoSuf|RepPrefixOk, {}
xsha256, 0xf30fa6d0, PadLock, NoSuf|RepPrefixOk, {}
+xsha384, 0xf30fa6d8, PadLock, NoSuf|RepPrefixOk, {}
+xsha512, 0xf30fa6e0, PadLock, NoSuf|RepPrefixOk, {}
+xstore-rng, 0xfa7c0, PadLock, NoSuf|RepPrefixOk, {}
// Aliases without hyphens.
-xstorerng, 0xfa7c0, PadLock, NoSuf|RepPrefixOk, {}
-xcryptecb, 0xf30fa7c8, PadLock, NoSuf|RepPrefixOk, {}
xcryptcbc, 0xf30fa7d0, PadLock, NoSuf|RepPrefixOk, {}
-xcryptctr, 0xf30fa7d8, PadLock, NoSuf|RepPrefixOk, {}
xcryptcfb, 0xf30fa7e0, PadLock, NoSuf|RepPrefixOk, {}
+xcryptctr, 0xf30fa7d8, PadLock, NoSuf|RepPrefixOk, {}
+xcryptecb, 0xf30fa7c8, PadLock, NoSuf|RepPrefixOk, {}
xcryptofb, 0xf30fa7e8, PadLock, NoSuf|RepPrefixOk, {}
+xstorerng, 0xfa7c0, PadLock, NoSuf|RepPrefixOk, {}
// Alias for xstore-rng.
xstore, 0xfa7c0, PadLock, NoSuf|RepPrefixOk, {}
-// ZHAOXIN GMI instructions
+// Zhaoxin GMI instructions
sm2, 0xf20fa6c0, GMI, NoSuf, {}
sm3, 0xf30fa6e8, GMI, NoSuf, {}
sm4, 0xf30fa7f0, GMI, NoSuf, {}
--
2.27.0
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v1] x86: Support ZHAOXIN padlock instructions
2024-12-24 1:59 ` Mayshao-oc
@ 2024-12-27 11:31 ` Jan Beulich
2024-12-30 9:18 ` Mayshao-oc
2024-12-30 9:20 ` [PATCH v1] x86: Support Zhaoxin RNG2 instruction Mayshao-oc
0 siblings, 2 replies; 80+ messages in thread
From: Jan Beulich @ 2024-12-27 11:31 UTC (permalink / raw)
To: Mayshao-oc
Cc: H.J. Lu, Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen
On 24.12.2024 02:59, Mayshao-oc wrote:
> Thanks for your review, I change the patch according to your comments.
> As to the "You cannot tie the new insns to the same old PadLock CPU feature", I agree with you, new insns need new cpuid bit to indicate their present.
Yet you still key all new insns to PadLock?
As said before - please don't replace existing references to VIA by ones
to Zhaoxin. And please don't make unrelated changes to the opcode table.
I'm pretty sure I said before that I don't see why you move around some
of the entries.
Please also stick to singular when renaming MONTMUL_Fixup(). All other
such functions are named xyz_Fixup() as well, iirc.
Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v1] x86: Support ZHAOXIN padlock instructions
2024-12-27 11:31 ` Jan Beulich
@ 2024-12-30 9:18 ` Mayshao-oc
2024-12-30 9:20 ` [PATCH v1] x86: Support Zhaoxin RNG2 instruction Mayshao-oc
1 sibling, 0 replies; 80+ messages in thread
From: Mayshao-oc @ 2024-12-30 9:18 UTC (permalink / raw)
To: Jan Beulich
Cc: H.J. Lu, Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen
> On 24.12.2024 02:59, Mayshao-oc wrote:
> > Thanks for your review, I change the patch according to your comments.
> > As to the "You cannot tie the new insns to the same old PadLock CPU feature", I agree with you, new insns need new cpuid bit to indicate their present.
>
> Yet you still key all new insns to PadLock?
>
> As said before - please don't replace existing references to VIA by ones
> to Zhaoxin. And please don't make unrelated changes to the opcode table.
> I'm pretty sure I said before that I don't see why you move around some
> of the entries.
>
> Please also stick to singular when renaming MONTMUL_Fixup(). All other
> such functions are named xyz_Fixup() as well, iirc.
>
> Jan
Hi Jan:
Thanks for your patience. At first, I think a bitfield in cpu_flags represent a ISA extension like PadLock.
At present, I think the bitfield in cpu_flags represent a cpu feature flag which cpuid returns. I change
the patch according to the new understanding.
I also update the instruction reference documentation. Our hardware not tie new insns to old features, but we
document in a wrong way.
BR
Mayshao
^ permalink raw reply [flat|nested] 80+ messages in thread
* [PATCH v1] x86: Support Zhaoxin RNG2 instruction
2024-12-27 11:31 ` Jan Beulich
2024-12-30 9:18 ` Mayshao-oc
@ 2024-12-30 9:20 ` Mayshao-oc
2025-01-06 8:53 ` Ping for " Mayshao-oc
2025-01-06 15:52 ` Jan Beulich
1 sibling, 2 replies; 80+ messages in thread
From: Mayshao-oc @ 2024-12-30 9:20 UTC (permalink / raw)
To: Jan Beulich
Cc: H.J. Lu, Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen
[-- Attachment #1: Type: text/plain, Size: 115 bytes --]
Hi all:
This patch adds support for Zhaoxin RNG2 instruction.
Test ok, ok for trunk?
BR
MayShao
[-- Attachment #2: padlock instruction reference.pdf --]
[-- Type: application/pdf, Size: 521434 bytes --]
[-- Attachment #3: 0001-x86-Support-x86-Zhaoxin-RNG2-instruction_v1.patch --]
[-- Type: application/octet-stream, Size: 7382 bytes --]
From 87251a0ac60e23f8fdb3ab216562bee5dba089bf Mon Sep 17 00:00:00 2001
From: MayShao-oc <MayShao-oc@zhaoxin.com>
Date: Mon, 30 Dec 2024 15:49:10 +0800
Subject: [PATCH] x86: Support x86 Zhaoxin RNG2 instruction
Hi all:
This patch adds support for Zhaoxin RNG2 instruction.
Test ok, ok for trunk?
BR
Mayshao
gas/ChangeLog:
* NEWS: Support zhaoxin rng2 instruction.
* config/tc-i386.c (add_branch_prefix_frag_p): Don't add prefix to
RNG2 instruction.
(output_insn): Handle RNG2 instruction.
* doc/c-i386.texi: Document RNG2.
* testsuite/gas/i386/i386.exp: Add RNG2 test.
* testsuite/gas/i386/rng2.d: Ditto.
* testsuite/gas/i386/rng2.s: Ditto.
opcodes/ChangeLog:
* i386-dis.c: Add RNG2.
* i386-gen.c: Ditto
* i386-opc.h (CpuRNG2): New.
* i386-opc.tbl: Add zhaoxin rng2 instruction.
* i386-tbl.h: Regenerated.
* i386-mnem.h: Ditto.
* i386-init.h: Ditto.
---
gas/NEWS | 2 ++
gas/config/tc-i386.c | 8 ++++++--
gas/doc/c-i386.texi | 5 +++--
gas/testsuite/gas/i386/i386.exp | 1 +
gas/testsuite/gas/i386/rng2.d | 11 +++++++++++
gas/testsuite/gas/i386/rng2.s | 7 +++++++
opcodes/i386-dis.c | 1 +
opcodes/i386-gen.c | 1 +
opcodes/i386-opc.h | 5 ++++-
opcodes/i386-opc.tbl | 5 ++++-
10 files changed, 40 insertions(+), 6 deletions(-)
create mode 100644 gas/testsuite/gas/i386/rng2.d
create mode 100644 gas/testsuite/gas/i386/rng2.s
diff --git a/gas/NEWS b/gas/NEWS
index 51f2a97291b..6b4f05fa586 100644
--- a/gas/NEWS
+++ b/gas/NEWS
@@ -1,5 +1,7 @@
-*- text -*-
+* Add support for the x86 Zhaoxin RNG2 instruction.
+
* Add support for the x86 Intel AVX10.2 instructions.
* Add support for the x86 Intel SM4 AVX10.2 instructions.
diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c
index f508a13efae..ed85c5ede94 100644
--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -1222,6 +1222,7 @@ static const arch_entry cpu_arch[] =
VECARCH (avx10.2, AVX10_2, ANY_AVX10_2, set),
SUBARCH (gmi, GMI, GMI, false),
SUBARCH (msr_imm, MSR_IMM, MSR_IMM, false),
+ SUBARCH (rng2, RNG2, RNG2, false),
};
#undef SUBARCH
@@ -12012,11 +12013,13 @@ static int
add_branch_prefix_frag_p (const struct last_insn *last_insn)
{
/* NB: Don't work with COND_JUMP86 without i386. Don't add prefix
- to PadLock instructions since they include prefixes in opcode. */
+ to PadLock instructions and RNG2 instruction since they include prefixes
+ in opcode. */
if (!align_branch_power
|| !align_branch_prefix_size
|| now_seg == absolute_section
|| is_cpu (&i.tm, CpuPadLock)
+ || is_cpu (&i.tm, CpuRNG2)
|| !cpu_arch_flags.bitfield.cpui386)
return 0;
@@ -12391,7 +12394,8 @@ output_insn (const struct last_insn *last_insn)
add_prefix (0xf2);
break;
case PREFIX_0XF3:
- if (!is_cpu (&i.tm, CpuPadLock)
+ if (!(is_cpu (&i.tm, CpuPadLock)
+ || is_cpu (&i.tm, CpuRNG2))
|| (i.prefix[REP_PREFIX] != 0xf3))
add_prefix (0xf3);
break;
diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi
index adcc1711665..646e0e7c47d 100644
--- a/gas/doc/c-i386.texi
+++ b/gas/doc/c-i386.texi
@@ -276,7 +276,8 @@ accept various extension mnemonics. For example,
@code{invlpgb},
@code{tlbsync},
@code{svme},
-@code{gmi} and
+@code{gmi},
+@code{rng2} and
@code{padlock}.
Note that these extension mnemonics can be prefixed with @code{no} to revoke
the respective (and any dependent) functionality. Note further that the
@@ -1707,7 +1708,7 @@ supported on the CPU specified. The choices for @var{cpu_type} are:
@item @samp{.lwp} @tab @samp{.fma4} @tab @samp{.xop} @tab @samp{.cx16}
@item @samp{.padlock} @tab @samp{.clzero} @tab @samp{.mwaitx} @tab @samp{.rdpru}
@item @samp{.mcommit} @tab @samp{.sev_es} @tab @samp{.snp} @tab @samp{.invlpgb}
-@item @samp{.tlbsync} @tab @samp{.apx_f} @tab @samp{.gmi}
+@item @samp{.tlbsync} @tab @samp{.apx_f} @tab @samp{.gmi} @tab @samp{.rng2}
@end multitable
diff --git a/gas/testsuite/gas/i386/i386.exp b/gas/testsuite/gas/i386/i386.exp
index 9a310375123..30febecc112 100644
--- a/gas/testsuite/gas/i386/i386.exp
+++ b/gas/testsuite/gas/i386/i386.exp
@@ -115,6 +115,7 @@ if [gas_32_check] then {
run_dump_test "unary"
run_dump_test "padlock"
run_dump_test "gmi"
+ run_dump_test "rng2"
run_dump_test "crx"
run_list_test "cr-err" ""
run_dump_test "cdr"
diff --git a/gas/testsuite/gas/i386/rng2.d b/gas/testsuite/gas/i386/rng2.d
new file mode 100644
index 00000000000..4d22fad2292
--- /dev/null
+++ b/gas/testsuite/gas/i386/rng2.d
@@ -0,0 +1,11 @@
+#objdump: -dw
+#name: zhaoxin rng2
+
+.*: +file format .*
+
+Disassembly of section .text:
+
+0+000 <foo>:
+ 0:[ ]*f3 0f a7 f8 [ ]*repz xrng2
+ 4:[ ]*f3 0f a7 f8 [ ]*repz xrng2
+#pass
diff --git a/gas/testsuite/gas/i386/rng2.s b/gas/testsuite/gas/i386/rng2.s
new file mode 100644
index 00000000000..f2f9f332d83
--- /dev/null
+++ b/gas/testsuite/gas/i386/rng2.s
@@ -0,0 +1,7 @@
+# Zhaoxin RNG2 instruction
+
+ .text
+foo:
+ xrng2
+ rep xrng2
+ .p2align 4,0
diff --git a/opcodes/i386-dis.c b/opcodes/i386-dis.c
index 813295c8aad..d269271ca2d 100644
--- a/opcodes/i386-dis.c
+++ b/opcodes/i386-dis.c
@@ -2925,6 +2925,7 @@ static const struct dis386 reg_table[][8] = {
{ "xcrypt-cfb", { { OP_0f07, 0 } }, 0 },
{ "xcrypt-ofb", { { OP_0f07, 0 } }, 0 },
{ PREFIX_TABLE (PREFIX_0FA7_REG_6) },
+ { "xrng2", { { OP_0f07, 0 } }, 0 },
},
/* REG_0FAE */
{
diff --git a/opcodes/i386-gen.c b/opcodes/i386-gen.c
index bb10ae8b621..9dcaa23470f 100644
--- a/opcodes/i386-gen.c
+++ b/opcodes/i386-gen.c
@@ -339,6 +339,7 @@ static bitfield cpu_flags[] =
BITFIELD (3dnowA),
BITFIELD (PadLock),
BITFIELD (GMI),
+ BITFIELD (RNG2),
BITFIELD (SVME),
BITFIELD (VMX),
BITFIELD (SMX),
diff --git a/opcodes/i386-opc.h b/opcodes/i386-opc.h
index 75d8c4f8b70..07ad7059f6f 100644
--- a/opcodes/i386-opc.h
+++ b/opcodes/i386-opc.h
@@ -66,8 +66,10 @@ enum i386_cpu
CpuSSE3,
/* VIA PadLock required */
CpuPadLock,
- /* ZHAOXIN GMI required */
+ /* Zhaoxin GMI required */
CpuGMI,
+ /* Zhaoxin RNG2 required */
+ CpuRNG2,
/* AMD Secure Virtual Machine Ext-s required */
CpuSVME,
/* VMX Instructions required */
@@ -406,6 +408,7 @@ typedef union i386_cpu_flags
unsigned int cpusse3:1;
unsigned int cpupadlock:1;
unsigned int cpugmi:1;
+ unsigned int cpurng2:1;
unsigned int cpusvme:1;
unsigned int cpuvmx:1;
unsigned int cpusmx:1;
diff --git a/opcodes/i386-opc.tbl b/opcodes/i386-opc.tbl
index 666ad99563a..a760b547ae4 100644
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -2134,11 +2134,14 @@ xcryptofb, 0xf30fa7e8, PadLock, NoSuf|RepPrefixOk, {}
// Alias for xstore-rng.
xstore, 0xfa7c0, PadLock, NoSuf|RepPrefixOk, {}
-// ZHAOXIN GMI instructions
+// Zhaoxin GMI instructions
sm2, 0xf20fa6c0, GMI, NoSuf, {}
sm3, 0xf30fa6e8, GMI, NoSuf, {}
sm4, 0xf30fa7f0, GMI, NoSuf, {}
+// Zhaoxin RNG2 instruction
+xrng2, 0xf30fa7f8, RNG2, NoSuf|RepPrefixOk, {}
+
// Multy-precision Add Carry, rdseed instructions.
<adx:pfx, c:66, o:f3>
ad<adx>x, 0x<adx:pfx>66, ADX&APX_F, C|Modrm|CheckOperandSize|No_bSuf|No_wSuf|No_sSuf|DstVVVV|EVexMap4, { Reg32|Reg64|Unspecified|BaseIndex, Reg32|Reg64, Reg32|Reg64 }
--
2.27.0
^ permalink raw reply [flat|nested] 80+ messages in thread
* Ping for [PATCH v1] x86: Support Zhaoxin RNG2 instruction
2024-12-30 9:20 ` [PATCH v1] x86: Support Zhaoxin RNG2 instruction Mayshao-oc
@ 2025-01-06 8:53 ` Mayshao-oc
2025-01-06 9:11 ` Jan Beulich
2025-01-06 15:52 ` Jan Beulich
1 sibling, 1 reply; 80+ messages in thread
From: Mayshao-oc @ 2025-01-06 8:53 UTC (permalink / raw)
To: Jan Beulich, Jiang, Haochen, binutils
Cc: H.J. Lu, Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD)
[-- Attachment #1: Type: text/plain, Size: 302 bytes --]
Friendly ping.
This patch adds support for Zhaoxin RNG2 instruction, the CPUID EDX bit[23]
indicates its enablement, it includes REP XRNG2 instruction.
BR
Mayshao
> Hi all:
>
> This patch adds support for Zhaoxin RNG2 instruction.
> Test ok, ok for trunk?
>
> BR
> MayShao
[-- Attachment #2: 0001-x86-Support-x86-Zhaoxin-RNG2-instruction_v1.patch --]
[-- Type: application/octet-stream, Size: 7382 bytes --]
From 87251a0ac60e23f8fdb3ab216562bee5dba089bf Mon Sep 17 00:00:00 2001
From: MayShao-oc <MayShao-oc@zhaoxin.com>
Date: Mon, 30 Dec 2024 15:49:10 +0800
Subject: [PATCH] x86: Support x86 Zhaoxin RNG2 instruction
Hi all:
This patch adds support for Zhaoxin RNG2 instruction.
Test ok, ok for trunk?
BR
Mayshao
gas/ChangeLog:
* NEWS: Support zhaoxin rng2 instruction.
* config/tc-i386.c (add_branch_prefix_frag_p): Don't add prefix to
RNG2 instruction.
(output_insn): Handle RNG2 instruction.
* doc/c-i386.texi: Document RNG2.
* testsuite/gas/i386/i386.exp: Add RNG2 test.
* testsuite/gas/i386/rng2.d: Ditto.
* testsuite/gas/i386/rng2.s: Ditto.
opcodes/ChangeLog:
* i386-dis.c: Add RNG2.
* i386-gen.c: Ditto
* i386-opc.h (CpuRNG2): New.
* i386-opc.tbl: Add zhaoxin rng2 instruction.
* i386-tbl.h: Regenerated.
* i386-mnem.h: Ditto.
* i386-init.h: Ditto.
---
gas/NEWS | 2 ++
gas/config/tc-i386.c | 8 ++++++--
gas/doc/c-i386.texi | 5 +++--
gas/testsuite/gas/i386/i386.exp | 1 +
gas/testsuite/gas/i386/rng2.d | 11 +++++++++++
gas/testsuite/gas/i386/rng2.s | 7 +++++++
opcodes/i386-dis.c | 1 +
opcodes/i386-gen.c | 1 +
opcodes/i386-opc.h | 5 ++++-
opcodes/i386-opc.tbl | 5 ++++-
10 files changed, 40 insertions(+), 6 deletions(-)
create mode 100644 gas/testsuite/gas/i386/rng2.d
create mode 100644 gas/testsuite/gas/i386/rng2.s
diff --git a/gas/NEWS b/gas/NEWS
index 51f2a97291b..6b4f05fa586 100644
--- a/gas/NEWS
+++ b/gas/NEWS
@@ -1,5 +1,7 @@
-*- text -*-
+* Add support for the x86 Zhaoxin RNG2 instruction.
+
* Add support for the x86 Intel AVX10.2 instructions.
* Add support for the x86 Intel SM4 AVX10.2 instructions.
diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c
index f508a13efae..ed85c5ede94 100644
--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -1222,6 +1222,7 @@ static const arch_entry cpu_arch[] =
VECARCH (avx10.2, AVX10_2, ANY_AVX10_2, set),
SUBARCH (gmi, GMI, GMI, false),
SUBARCH (msr_imm, MSR_IMM, MSR_IMM, false),
+ SUBARCH (rng2, RNG2, RNG2, false),
};
#undef SUBARCH
@@ -12012,11 +12013,13 @@ static int
add_branch_prefix_frag_p (const struct last_insn *last_insn)
{
/* NB: Don't work with COND_JUMP86 without i386. Don't add prefix
- to PadLock instructions since they include prefixes in opcode. */
+ to PadLock instructions and RNG2 instruction since they include prefixes
+ in opcode. */
if (!align_branch_power
|| !align_branch_prefix_size
|| now_seg == absolute_section
|| is_cpu (&i.tm, CpuPadLock)
+ || is_cpu (&i.tm, CpuRNG2)
|| !cpu_arch_flags.bitfield.cpui386)
return 0;
@@ -12391,7 +12394,8 @@ output_insn (const struct last_insn *last_insn)
add_prefix (0xf2);
break;
case PREFIX_0XF3:
- if (!is_cpu (&i.tm, CpuPadLock)
+ if (!(is_cpu (&i.tm, CpuPadLock)
+ || is_cpu (&i.tm, CpuRNG2))
|| (i.prefix[REP_PREFIX] != 0xf3))
add_prefix (0xf3);
break;
diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi
index adcc1711665..646e0e7c47d 100644
--- a/gas/doc/c-i386.texi
+++ b/gas/doc/c-i386.texi
@@ -276,7 +276,8 @@ accept various extension mnemonics. For example,
@code{invlpgb},
@code{tlbsync},
@code{svme},
-@code{gmi} and
+@code{gmi},
+@code{rng2} and
@code{padlock}.
Note that these extension mnemonics can be prefixed with @code{no} to revoke
the respective (and any dependent) functionality. Note further that the
@@ -1707,7 +1708,7 @@ supported on the CPU specified. The choices for @var{cpu_type} are:
@item @samp{.lwp} @tab @samp{.fma4} @tab @samp{.xop} @tab @samp{.cx16}
@item @samp{.padlock} @tab @samp{.clzero} @tab @samp{.mwaitx} @tab @samp{.rdpru}
@item @samp{.mcommit} @tab @samp{.sev_es} @tab @samp{.snp} @tab @samp{.invlpgb}
-@item @samp{.tlbsync} @tab @samp{.apx_f} @tab @samp{.gmi}
+@item @samp{.tlbsync} @tab @samp{.apx_f} @tab @samp{.gmi} @tab @samp{.rng2}
@end multitable
diff --git a/gas/testsuite/gas/i386/i386.exp b/gas/testsuite/gas/i386/i386.exp
index 9a310375123..30febecc112 100644
--- a/gas/testsuite/gas/i386/i386.exp
+++ b/gas/testsuite/gas/i386/i386.exp
@@ -115,6 +115,7 @@ if [gas_32_check] then {
run_dump_test "unary"
run_dump_test "padlock"
run_dump_test "gmi"
+ run_dump_test "rng2"
run_dump_test "crx"
run_list_test "cr-err" ""
run_dump_test "cdr"
diff --git a/gas/testsuite/gas/i386/rng2.d b/gas/testsuite/gas/i386/rng2.d
new file mode 100644
index 00000000000..4d22fad2292
--- /dev/null
+++ b/gas/testsuite/gas/i386/rng2.d
@@ -0,0 +1,11 @@
+#objdump: -dw
+#name: zhaoxin rng2
+
+.*: +file format .*
+
+Disassembly of section .text:
+
+0+000 <foo>:
+ 0:[ ]*f3 0f a7 f8 [ ]*repz xrng2
+ 4:[ ]*f3 0f a7 f8 [ ]*repz xrng2
+#pass
diff --git a/gas/testsuite/gas/i386/rng2.s b/gas/testsuite/gas/i386/rng2.s
new file mode 100644
index 00000000000..f2f9f332d83
--- /dev/null
+++ b/gas/testsuite/gas/i386/rng2.s
@@ -0,0 +1,7 @@
+# Zhaoxin RNG2 instruction
+
+ .text
+foo:
+ xrng2
+ rep xrng2
+ .p2align 4,0
diff --git a/opcodes/i386-dis.c b/opcodes/i386-dis.c
index 813295c8aad..d269271ca2d 100644
--- a/opcodes/i386-dis.c
+++ b/opcodes/i386-dis.c
@@ -2925,6 +2925,7 @@ static const struct dis386 reg_table[][8] = {
{ "xcrypt-cfb", { { OP_0f07, 0 } }, 0 },
{ "xcrypt-ofb", { { OP_0f07, 0 } }, 0 },
{ PREFIX_TABLE (PREFIX_0FA7_REG_6) },
+ { "xrng2", { { OP_0f07, 0 } }, 0 },
},
/* REG_0FAE */
{
diff --git a/opcodes/i386-gen.c b/opcodes/i386-gen.c
index bb10ae8b621..9dcaa23470f 100644
--- a/opcodes/i386-gen.c
+++ b/opcodes/i386-gen.c
@@ -339,6 +339,7 @@ static bitfield cpu_flags[] =
BITFIELD (3dnowA),
BITFIELD (PadLock),
BITFIELD (GMI),
+ BITFIELD (RNG2),
BITFIELD (SVME),
BITFIELD (VMX),
BITFIELD (SMX),
diff --git a/opcodes/i386-opc.h b/opcodes/i386-opc.h
index 75d8c4f8b70..07ad7059f6f 100644
--- a/opcodes/i386-opc.h
+++ b/opcodes/i386-opc.h
@@ -66,8 +66,10 @@ enum i386_cpu
CpuSSE3,
/* VIA PadLock required */
CpuPadLock,
- /* ZHAOXIN GMI required */
+ /* Zhaoxin GMI required */
CpuGMI,
+ /* Zhaoxin RNG2 required */
+ CpuRNG2,
/* AMD Secure Virtual Machine Ext-s required */
CpuSVME,
/* VMX Instructions required */
@@ -406,6 +408,7 @@ typedef union i386_cpu_flags
unsigned int cpusse3:1;
unsigned int cpupadlock:1;
unsigned int cpugmi:1;
+ unsigned int cpurng2:1;
unsigned int cpusvme:1;
unsigned int cpuvmx:1;
unsigned int cpusmx:1;
diff --git a/opcodes/i386-opc.tbl b/opcodes/i386-opc.tbl
index 666ad99563a..a760b547ae4 100644
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -2134,11 +2134,14 @@ xcryptofb, 0xf30fa7e8, PadLock, NoSuf|RepPrefixOk, {}
// Alias for xstore-rng.
xstore, 0xfa7c0, PadLock, NoSuf|RepPrefixOk, {}
-// ZHAOXIN GMI instructions
+// Zhaoxin GMI instructions
sm2, 0xf20fa6c0, GMI, NoSuf, {}
sm3, 0xf30fa6e8, GMI, NoSuf, {}
sm4, 0xf30fa7f0, GMI, NoSuf, {}
+// Zhaoxin RNG2 instruction
+xrng2, 0xf30fa7f8, RNG2, NoSuf|RepPrefixOk, {}
+
// Multy-precision Add Carry, rdseed instructions.
<adx:pfx, c:66, o:f3>
ad<adx>x, 0x<adx:pfx>66, ADX&APX_F, C|Modrm|CheckOperandSize|No_bSuf|No_wSuf|No_sSuf|DstVVVV|EVexMap4, { Reg32|Reg64|Unspecified|BaseIndex, Reg32|Reg64, Reg32|Reg64 }
--
2.27.0
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: Ping for [PATCH v1] x86: Support Zhaoxin RNG2 instruction
2025-01-06 8:53 ` Ping for " Mayshao-oc
@ 2025-01-06 9:11 ` Jan Beulich
2025-01-06 10:36 ` Mayshao-oc
0 siblings, 1 reply; 80+ messages in thread
From: Jan Beulich @ 2025-01-06 9:11 UTC (permalink / raw)
To: Mayshao-oc
Cc: H.J. Lu, Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
Jiang, Haochen, binutils
On 06.01.2025 09:53, Mayshao-oc wrote:
>
> Friendly ping.
> This patch adds support for Zhaoxin RNG2 instruction, the CPUID EDX bit[23]
> indicates its enablement, it includes REP XRNG2 instruction.
I'm sorry, your posting was at what is largely holiday season in Europe. It's
my first workday only this year, so please be patient for some more time. I
don't think I'm known for "losing" patches ...
Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: Ping for [PATCH v1] x86: Support Zhaoxin RNG2 instruction
2025-01-06 9:11 ` Jan Beulich
@ 2025-01-06 10:36 ` Mayshao-oc
0 siblings, 0 replies; 80+ messages in thread
From: Mayshao-oc @ 2025-01-06 10:36 UTC (permalink / raw)
To: Jan Beulich
Cc: H.J. Lu, Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
Jiang, Haochen, binutils
> >
> > Friendly ping.
> > This patch adds support for Zhaoxin RNG2 instruction, the CPUID EDX bit[23]
> > indicates its enablement, it includes REP XRNG2 instruction.
>
> I'm sorry, your posting was at what is largely holiday season in Europe. It's
> my first workday only this year, so please be patient for some more time. I
> don't think I'm known for "losing" patches ...
>
> Jan
Hi Jan:
Thanks for your reply. I think I am the one need to say sorry.
I hesitate to send this ping, and I wander in the gcc and binutils mailing
list, read some ping email by chance, and send a ping for myself. I think
you are professional and friendly. I don't think you are known for "losing"
patches, as to my experience in wandering in binutils mailing list and the
patch submit experience of myself.
BR
Mayshao
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v1] x86: Support Zhaoxin RNG2 instruction
2024-12-30 9:20 ` [PATCH v1] x86: Support Zhaoxin RNG2 instruction Mayshao-oc
2025-01-06 8:53 ` Ping for " Mayshao-oc
@ 2025-01-06 15:52 ` Jan Beulich
2025-01-07 3:08 ` Mayshao-oc
1 sibling, 1 reply; 80+ messages in thread
From: Jan Beulich @ 2025-01-06 15:52 UTC (permalink / raw)
To: Mayshao-oc, H.J. Lu
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen
On 30.12.2024 10:20, Mayshao-oc wrote:
> This patch adds support for Zhaoxin RNG2 instruction.
> Test ok, ok for trunk?
The change to output_insn() needs at least indenting correctly. The two
||-s don't really belong to the same level of the expression. Even better
would imo be to use (!is_cpu (&i.tm, CpuPadLock) &&
!is_cpu (&i.tm, CpuRNG2)) instead of the 2nd nested ||.
Speaking of RNG2 - we can only hope that no other vendor will come up with
a similarly abbreviated random number generator feature. The name is
pretty generic, after all. H.J. - what do you think?
Is there a connection between PadLock and RNG2? Does RNG2 perhaps even
imply PadLock as a prereq feature (wanting a dependency recorded in
i386-gen.c)? If so, naming it "PadLockRNG2" may be an option to avoid a
potential future clash.
Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v1] x86: Support Zhaoxin RNG2 instruction
2025-01-06 15:52 ` Jan Beulich
@ 2025-01-07 3:08 ` Mayshao-oc
2025-01-07 8:34 ` Jan Beulich
0 siblings, 1 reply; 80+ messages in thread
From: Mayshao-oc @ 2025-01-07 3:08 UTC (permalink / raw)
To: Jan Beulich, H.J. Lu
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen
> On 30.12.2024 10:20, Mayshao-oc wrote:
> > This patch adds support for Zhaoxin RNG2 instruction.
> > Test ok, ok for trunk?
>
> The change to output_insn() needs at least indenting correctly. The two
> ||-s don't really belong to the same level of the expression. Even
> ||better
> would imo be to use (!is_cpu (&i.tm, CpuPadLock) && !is_cpu (&i.tm, CpuRNG2)) instead of the 2nd nested ||.
Thanks for your review. The indenting is definitely wrong, I will correct it.
As to || and &&, I don't understand why (!is_cpu (&i.tm, CpuPadLock) && !is_cpu (&i.tm, CpuRNG2)) is better?
In respect of performance, I think compiler will produce the same assembly code for ||-s form and && form.
Maybe && form helps to readability?
>
> Speaking of RNG2 - we can only hope that no other vendor will come up with a similarly abbreviated random number generator feature. The name is pretty generic, after all. H.J. - what do you think?
>
> Is there a connection between PadLock and RNG2? Does RNG2 perhaps even imply PadLock as a prereq feature (wanting a dependency recorded in i386-gen.c)? If so, naming it "PadLockRNG2" may be an option to avoid a potential future clash.
Yes, there is a connection. I think it's reasonable to naming it "PadLockRNG2", I will rename it.
>
> Jan
BR
MayShao
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v1] x86: Support Zhaoxin RNG2 instruction
2025-01-07 3:08 ` Mayshao-oc
@ 2025-01-07 8:34 ` Jan Beulich
2025-01-07 11:04 ` Mayshao-oc
0 siblings, 1 reply; 80+ messages in thread
From: Jan Beulich @ 2025-01-07 8:34 UTC (permalink / raw)
To: Mayshao-oc
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen, H.J. Lu
On 07.01.2025 04:08, Mayshao-oc wrote:
>> On 30.12.2024 10:20, Mayshao-oc wrote:
>>> This patch adds support for Zhaoxin RNG2 instruction.
>>> Test ok, ok for trunk?
>>
>> The change to output_insn() needs at least indenting correctly. The two
>> ||-s don't really belong to the same level of the expression. Even
>> ||better
>> would imo be to use (!is_cpu (&i.tm, CpuPadLock) && !is_cpu (&i.tm, CpuRNG2)) instead of the 2nd nested ||.
> Thanks for your review. The indenting is definitely wrong, I will correct it.
> As to || and &&, I don't understand why (!is_cpu (&i.tm, CpuPadLock) && !is_cpu (&i.tm, CpuRNG2)) is better?
> In respect of performance, I think compiler will produce the same assembly code for ||-s form and && form.
> Maybe && form helps to readability?
It's entirely about readability, yes. The compiler is free to transform
one form into the other anyway.
>> Speaking of RNG2 - we can only hope that no other vendor will come up with a similarly abbreviated random number generator feature. The name is pretty generic, after all. H.J. - what do you think?
>>
>> Is there a connection between PadLock and RNG2? Does RNG2 perhaps even imply PadLock as a prereq feature (wanting a dependency recorded in i386-gen.c)? If so, naming it "PadLockRNG2" may be an option to avoid a potential future clash.
> Yes, there is a connection. I think it's reasonable to naming it "PadLockRNG2", I will rename it.
Well, if there's a connection, then (as said) the dependency also wants
recording in i386-gen.c.
Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v1] x86: Support Zhaoxin RNG2 instruction
2025-01-07 8:34 ` Jan Beulich
@ 2025-01-07 11:04 ` Mayshao-oc
2025-01-08 3:29 ` Jiang, Haochen
2025-01-08 7:06 ` Jan Beulich
0 siblings, 2 replies; 80+ messages in thread
From: Mayshao-oc @ 2025-01-07 11:04 UTC (permalink / raw)
To: Jan Beulich
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen, H.J. Lu
> On 07.01.2025 04:08, Mayshao-oc wrote:
> >> On 30.12.2024 10:20, Mayshao-oc wrote:
> >>> This patch adds support for Zhaoxin RNG2 instruction.
> >>> Test ok, ok for trunk?
> >>
> >> The change to output_insn() needs at least indenting correctly. The
> >> two
> >> ||-s don't really belong to the same level of the expression. Even
> >> ||better
> >> would imo be to use (!is_cpu (&i.tm, CpuPadLock) && !is_cpu (&i.tm, CpuRNG2)) instead of the 2nd nested ||.
> > Thanks for your review. The indenting is definitely wrong, I will correct it.
> > As to || and &&, I don't understand why (!is_cpu (&i.tm, CpuPadLock) && !is_cpu (&i.tm, CpuRNG2)) is better?
> > In respect of performance, I think compiler will produce the same assembly code for ||-s form and && form.
> > Maybe && form helps to readability?
>
> It's entirely about readability, yes. The compiler is free to transform one form into the other anyway.
Thanks for your comments.
>
> >> Speaking of RNG2 - we can only hope that no other vendor will come up with a similarly abbreviated random number generator feature. The name is pretty generic, after all. H.J. - what do you think?
> >>
> >> Is there a connection between PadLock and RNG2? Does RNG2 perhaps even imply PadLock as a prereq feature (wanting a dependency recorded in i386-gen.c)? If so, naming it "PadLockRNG2" may be an option to avoid a potential future clash.
> > Yes, there is a connection. I think it's reasonable to naming it "PadLockRNG2", I will rename it.
>
> Well, if there's a connection, then (as said) the dependency also wants recording in i386-gen.c.
Ok, you mean add an element in isa_dependencies[],like {"PadLockRNG2", "PadLock"}?
Assambler need this depenency information to do some check? I will take a while to understand this.
>
> Jan
BR
MayShao
^ permalink raw reply [flat|nested] 80+ messages in thread
* RE: [PATCH v1] x86: Support Zhaoxin RNG2 instruction
2025-01-07 11:04 ` Mayshao-oc
@ 2025-01-08 3:29 ` Jiang, Haochen
2025-01-08 9:38 ` Mayshao-oc
2025-01-08 7:06 ` Jan Beulich
1 sibling, 1 reply; 80+ messages in thread
From: Jiang, Haochen @ 2025-01-08 3:29 UTC (permalink / raw)
To: Mayshao-oc, Beulich, Jan
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD), binutils, H.J. Lu
> From: Mayshao-oc <Mayshao-oc@zhaoxin.com>
> Sent: Tuesday, January 7, 2025 7:04 PM
>
> > On 07.01.2025 04:08, Mayshao-oc wrote:
> > >> On 30.12.2024 10:20, Mayshao-oc wrote:
> > >>> This patch adds support for Zhaoxin RNG2 instruction.
> > >>> Test ok, ok for trunk?
> > >>
> > >> The change to output_insn() needs at least indenting correctly. The
> > >> two
> > >> ||-s don't really belong to the same level of the expression. Even
> > >> ||better
> > >> would imo be to use (!is_cpu (&i.tm, CpuPadLock) && !is_cpu (&i.tm,
> CpuRNG2)) instead of the 2nd nested ||.
> > > Thanks for your review. The indenting is definitely wrong, I will correct it.
> > > As to || and &&, I don't understand why (!is_cpu (&i.tm, CpuPadLock)
> && !is_cpu (&i.tm, CpuRNG2)) is better?
> > > In respect of performance, I think compiler will produce the same assembly
> code for ||-s form and && form.
> > > Maybe && form helps to readability?
> >
> > It's entirely about readability, yes. The compiler is free to transform one form
> into the other anyway.
> Thanks for your comments.
> >
> > >> Speaking of RNG2 - we can only hope that no other vendor will come up
> with a similarly abbreviated random number generator feature. The name is
> pretty generic, after all. H.J. - what do you think?
> > >>
> > >> Is there a connection between PadLock and RNG2? Does RNG2 perhaps
> even imply PadLock as a prereq feature (wanting a dependency recorded in
> i386-gen.c)? If so, naming it "PadLockRNG2" may be an option to avoid a
> potential future clash.
> > > Yes, there is a connection. I think it's reasonable to naming it
> "PadLockRNG2", I will rename it.
> >
> > Well, if there's a connection, then (as said) the dependency also wants
> recording in i386-gen.c.
> Ok, you mean add an element in isa_dependencies[],like {"PadLockRNG2",
> "PadLock"}?
> Assambler need this depenency information to do some check? I will take a
> while to understand this.
It will help you enable PadLock when enabling PadLockRNG2 instead of only
enabling PadLockRNG2 insns only. If there is a connection (or imply) between
them from documentation, programmers will have the impression that the base
feature should have been enabled when enabling the extension feature. Thus, they
will use all the asm in both base and extension features. Then if you don't add them
in the table, it might break the code with unsupported inst.
Thx,
Haochen
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v1] x86: Support Zhaoxin RNG2 instruction
2025-01-07 11:04 ` Mayshao-oc
2025-01-08 3:29 ` Jiang, Haochen
@ 2025-01-08 7:06 ` Jan Beulich
2025-01-08 9:40 ` Mayshao-oc
1 sibling, 1 reply; 80+ messages in thread
From: Jan Beulich @ 2025-01-08 7:06 UTC (permalink / raw)
To: Mayshao-oc
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen, H.J. Lu
On 07.01.2025 12:04, Mayshao-oc wrote:
>> On 07.01.2025 04:08, Mayshao-oc wrote:
>>>> On 30.12.2024 10:20, Mayshao-oc wrote:
>>>> Is there a connection between PadLock and RNG2? Does RNG2 perhaps even imply PadLock as a prereq feature (wanting a dependency recorded in i386-gen.c)? If so, naming it "PadLockRNG2" may be an option to avoid a potential future clash.
>>> Yes, there is a connection. I think it's reasonable to naming it "PadLockRNG2", I will rename it.
>>
>> Well, if there's a connection, then (as said) the dependency also wants recording in i386-gen.c.
> Ok, you mean add an element in isa_dependencies[],like {"PadLockRNG2", "PadLock"}?
Yes.
> Assambler need this depenency information to do some check? I will take a while to understand this.
It'll ensure that when PadLock is turned off, PadLockRNG2 would be
turned off automatically as well.
Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v1] x86: Support Zhaoxin RNG2 instruction
2025-01-08 3:29 ` Jiang, Haochen
@ 2025-01-08 9:38 ` Mayshao-oc
2025-01-08 11:30 ` Jan Beulich
0 siblings, 1 reply; 80+ messages in thread
From: Mayshao-oc @ 2025-01-08 9:38 UTC (permalink / raw)
To: Jiang, Haochen, Beulich, Jan
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD), binutils, H.J. Lu
> > From: Mayshao-oc <Mayshao-oc@zhaoxin.com>
> > Sent: Tuesday, January 7, 2025 7:04 PM
> >
> > > On 07.01.2025 04:08, Mayshao-oc wrote:
> > > >> On 30.12.2024 10:20, Mayshao-oc wrote:
> > > >>> This patch adds support for Zhaoxin RNG2 instruction.
> > > >>> Test ok, ok for trunk?
> > > >>
> > > >> The change to output_insn() needs at least indenting correctly.
> > > >> The two
> > > >> ||-s don't really belong to the same level of the expression.
> > > >> ||Even better
> > > >> would imo be to use (!is_cpu (&i.tm, CpuPadLock) && !is_cpu
> > > >> (&i.tm,
> > CpuRNG2)) instead of the 2nd nested ||.
> > > > Thanks for your review. The indenting is definitely wrong, I will correct it.
> > > > As to || and &&, I don't understand why (!is_cpu (&i.tm,
> > > > CpuPadLock)
> > && !is_cpu (&i.tm, CpuRNG3)) is better?
> > > > In respect of performance, I think compiler will produce the same
> > > > assembly
> > code for ||-s form and && form.
> > > > Maybe && form helps to readability?
> > >
> > > It's entirely about readability, yes. The compiler is free to
> > > transform one form
> > into the other anyway.
> > Thanks for your comments.
> > >
> > > >> Speaking of RNG2 - we can only hope that no other vendor will
> > > >> come up
> > with a similarly abbreviated random number generator feature. The name
> > is pretty generic, after all. H.J. - what do you think?
> > > >>
> > > >> Is there a connection between PadLock and RNG2? Does RNG2 perhaps
> > even imply PadLock as a prereq feature (wanting a dependency recorded
> > in i386-gen.c)? If so, naming it "PadLockRNG2" may be an option to
> > avoid a potential future clash.
> > > > Yes, there is a connection. I think it's reasonable to naming it
> > "PadLockRNG2", I will rename it.
> > >
> > > Well, if there's a connection, then (as said) the dependency also
> > > wants
> > recording in i386-gen.c.
> > Ok, you mean add an element in isa_dependencies[],like
> > {"PadLockRNG2", "PadLock"}?
> > Assambler need this depenency information to do some check? I will
> > take a while to understand this.
>
> It will help you enable PadLock when enabling PadLockRNG2 instead of only enabling PadLockRNG2 insns only. If there is a connection (or imply) between them from documentation, programmers will have the impression that the base feature should have been enabled when enabling the extension feature. Thus, they will use all the asm in both base and extension features. Then if you don't add them in the table, it might break the code with unsupported inst.
Thanks for your comments, it helps a lot. I test "as -march=generic64+padlockrng2 padlock.s" and the assembler not complains instruction not support.If I don't add them in the table, assembler will print instruction is not supported.
BTW: Whether gcc -march=xxx will imply a -march=xxx to assembler in gcc driver and do some check? I am curious about this.
>
> Thx,
> Haochen
BR
MayShao
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v1] x86: Support Zhaoxin RNG2 instruction
2025-01-08 7:06 ` Jan Beulich
@ 2025-01-08 9:40 ` Mayshao-oc
2025-01-08 9:46 ` [PATCH v2] x86: Support Zhaoxin PadLock " Mayshao-oc
2025-01-08 11:31 ` [PATCH v1] x86: Support Zhaoxin RNG2 instruction Jan Beulich
0 siblings, 2 replies; 80+ messages in thread
From: Mayshao-oc @ 2025-01-08 9:40 UTC (permalink / raw)
To: Jan Beulich
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen, H.J. Lu
> On 07.01.2025 12:04, Mayshao-oc wrote:
> >> On 07.01.2025 04:08, Mayshao-oc wrote:
> >>>> On 30.12.2024 10:20, Mayshao-oc wrote:
> >>>> Is there a connection between PadLock and RNG2? Does RNG2 perhaps even imply PadLock as a prereq feature (wanting a dependency recorded in i386-gen.c)? If so, naming it "PadLockRNG2" may be an option to avoid a potential future clash.
> >>> Yes, there is a connection. I think it's reasonable to naming it "PadLockRNG2", I will rename it.
> >>
> >> Well, if there's a connection, then (as said) the dependency also wants recording in i386-gen.c.
> > Ok, you mean add an element in isa_dependencies[],like {"PadLockRNG2", "PadLock"}?
>
> Yes.
>
> > Assambler need this depenency information to do some check? I will take a while to understand this.
>
> It'll ensure that when PadLock is turned off, PadLockRNG2 would be turned off automatically as well.
Thanks for your comments. I don't understand the "when PadLock is turned off" means it is turned off in hardware or it is turned off in assembler.
If it means turned off in assembler, how can I test it?
>
> Jan
BR
MayShao
^ permalink raw reply [flat|nested] 80+ messages in thread
* [PATCH v2] x86: Support Zhaoxin PadLock RNG2 instruction
2025-01-08 9:40 ` Mayshao-oc
@ 2025-01-08 9:46 ` Mayshao-oc
2025-01-09 12:15 ` Jan Beulich
2025-01-08 11:31 ` [PATCH v1] x86: Support Zhaoxin RNG2 instruction Jan Beulich
1 sibling, 1 reply; 80+ messages in thread
From: Mayshao-oc @ 2025-01-08 9:46 UTC (permalink / raw)
To: Jan Beulich
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen, H.J. Lu
[-- Attachment #1: Type: text/plain, Size: 384 bytes --]
Hi all:
This patch adds support for Zhaoxin PadLock RNG2 instruction, the
CPUID EDX bit[23] indicates its enablement, it includes REP XRNG2
instruction.
Test ok, ok for trunk?
Changes in V2:
1. Change the indenting correctly and change the boolean expression in output_insn()
2. Rename RNG2 to PadLockRNG2
3. Add PadLockRNG2 to dependency table.
BR
MayShao
[-- Attachment #2: 0001-x86-Support-x86-Zhaoxin-RNG2-instruction_v2.patch --]
[-- Type: application/octet-stream, Size: 8039 bytes --]
From 0c006e2ae64b9217b20d76911d248b4c98ae191e Mon Sep 17 00:00:00 2001
From: MayShao-oc <MayShao-oc@zhaoxin.com>
Date: Wed, 8 Jan 2025 16:16:20 +0800
Subject: [PATCH v2] x86: Support x86 Zhaoxin PadLockRNG2 instruction
Hi all:
This patch adds support for Zhaoxin PadLock RNG2 instruction, the
CPUID EDX bit[23] indicates its enablement, it includes REP XRNG2
instruction.
Test ok, ok for trunk?
BR
MayShao
gas/ChangeLog:
* NEWS: Support Zhaoxin PadLock RNG2 instruction.
* config/tc-i386.c (add_branch_prefix_frag_p): Don't add prefix to
PadLock RNG2 instruction.
(output_insn): Handle PadLock RNG2 instruction.
* doc/c-i386.texi: Document PadLock RNG2.
* testsuite/gas/i386/i386.exp: Add PadLock RNG2 test.
* testsuite/gas/i386/padlock_rng2.d: Ditto.
* testsuite/gas/i386/padlock_rng2.s: Ditto.
opcodes/ChangeLog:
* i386-dis.c: Add PadLockRNG2.
* i386-gen.c: Ditto
* i386-opc.h (CpuPadLockRNG2): New.
* i386-opc.tbl: Add Zhaoxin PadLock RNG2 instruction.
* i386-tbl.h: Regenerated.
* i386-mnem.h: Ditto.
* i386-init.h: Ditto.
---
gas/NEWS | 2 ++
gas/config/tc-i386.c | 7 +++++--
gas/doc/c-i386.texi | 5 +++--
gas/testsuite/gas/i386/i386.exp | 1 +
gas/testsuite/gas/i386/padlockrng2.d | 11 +++++++++++
gas/testsuite/gas/i386/padlockrng2.s | 7 +++++++
opcodes/i386-dis.c | 1 +
opcodes/i386-gen.c | 3 +++
opcodes/i386-opc.h | 5 ++++-
opcodes/i386-opc.tbl | 5 ++++-
10 files changed, 41 insertions(+), 6 deletions(-)
create mode 100644 gas/testsuite/gas/i386/padlockrng2.d
create mode 100644 gas/testsuite/gas/i386/padlockrng2.s
diff --git a/gas/NEWS b/gas/NEWS
index 2b31fdb1515..be4afb65fa3 100644
--- a/gas/NEWS
+++ b/gas/NEWS
@@ -1,5 +1,7 @@
-*- text -*-
+* Add support for the x86 Zhaoxin PadLock RNG2 instruction.
+
* Add support for the x86 Intel AVX10.2 instructions.
* Add support for the x86 Intel SM4 AVX10.2 instructions.
diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c
index e659d6841cb..21ea8588d9b 100644
--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -1224,6 +1224,7 @@ static const arch_entry cpu_arch[] =
VECARCH (avx10.2, AVX10_2, ANY_AVX10_2, set),
SUBARCH (gmi, GMI, GMI, false),
SUBARCH (msr_imm, MSR_IMM, MSR_IMM, false),
+ SUBARCH (padlockrng2, PADLOCKRNG2, PADLOCKRNG2, false),
};
#undef SUBARCH
@@ -12024,11 +12025,13 @@ static int
add_branch_prefix_frag_p (const struct last_insn *last_insn)
{
/* NB: Don't work with COND_JUMP86 without i386. Don't add prefix
- to PadLock instructions since they include prefixes in opcode. */
+ to PadLock instructions and PadLock RNG2 instruction since they include prefixes
+ in opcode. */
if (!align_branch_power
|| !align_branch_prefix_size
|| now_seg == absolute_section
|| is_cpu (&i.tm, CpuPadLock)
+ || is_cpu (&i.tm, CpuPadLockRNG2)
|| !cpu_arch_flags.bitfield.cpui386)
return 0;
@@ -12403,7 +12406,7 @@ output_insn (const struct last_insn *last_insn)
add_prefix (0xf2);
break;
case PREFIX_0XF3:
- if (!is_cpu (&i.tm, CpuPadLock)
+ if ((!is_cpu (&i.tm, CpuPadLock) && !is_cpu (&i.tm, CpuPadLockRNG2))
|| (i.prefix[REP_PREFIX] != 0xf3))
add_prefix (0xf3);
break;
diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi
index 8832af8a631..6a86e7ca09d 100644
--- a/gas/doc/c-i386.texi
+++ b/gas/doc/c-i386.texi
@@ -278,7 +278,8 @@ accept various extension mnemonics. For example,
@code{invlpgb},
@code{tlbsync},
@code{svme},
-@code{gmi} and
+@code{gmi},
+@code{padlockrng2} and
@code{padlock}.
Note that these extension mnemonics can be prefixed with @code{no} to revoke
the respective (and any dependent) functionality. Note further that the
@@ -1710,7 +1711,7 @@ supported on the CPU specified. The choices for @var{cpu_type} are:
@item @samp{.lwp} @tab @samp{.fma4} @tab @samp{.xop} @tab @samp{.cx16}
@item @samp{.padlock} @tab @samp{.clzero} @tab @samp{.mwaitx} @tab @samp{.rdpru}
@item @samp{.mcommit} @tab @samp{.sev_es} @tab @samp{.snp} @tab @samp{.invlpgb}
-@item @samp{.tlbsync} @tab @samp{.apx_f} @tab @samp{.gmi}
+@item @samp{.tlbsync} @tab @samp{.apx_f} @tab @samp{.gmi} @tab @samp{.padlockrng2}
@end multitable
diff --git a/gas/testsuite/gas/i386/i386.exp b/gas/testsuite/gas/i386/i386.exp
index 650729d8b5b..2ba0def9547 100644
--- a/gas/testsuite/gas/i386/i386.exp
+++ b/gas/testsuite/gas/i386/i386.exp
@@ -115,6 +115,7 @@ if [gas_32_check] then {
run_dump_test "unary"
run_dump_test "padlock"
run_dump_test "gmi"
+ run_dump_test "padlockrng2"
run_dump_test "crx"
run_list_test "cr-err" ""
run_dump_test "cdr"
diff --git a/gas/testsuite/gas/i386/padlockrng2.d b/gas/testsuite/gas/i386/padlockrng2.d
new file mode 100644
index 00000000000..14187228a4a
--- /dev/null
+++ b/gas/testsuite/gas/i386/padlockrng2.d
@@ -0,0 +1,11 @@
+#objdump: -dw
+#name: Zhaoxin PadLock RNG2
+
+.*: +file format .*
+
+Disassembly of section .text:
+
+0+000 <foo>:
+ 0:[ ]*f3 0f a7 f8 [ ]*repz xrng2
+ 4:[ ]*f3 0f a7 f8 [ ]*repz xrng2
+#pass
diff --git a/gas/testsuite/gas/i386/padlockrng2.s b/gas/testsuite/gas/i386/padlockrng2.s
new file mode 100644
index 00000000000..019bb3b3bfa
--- /dev/null
+++ b/gas/testsuite/gas/i386/padlockrng2.s
@@ -0,0 +1,7 @@
+# Zhaoxin PadLock RNG2 instruction
+
+ .text
+foo:
+ xrng2
+ rep xrng2
+ .p2align 4,0
diff --git a/opcodes/i386-dis.c b/opcodes/i386-dis.c
index 8e71c1bdda8..6f4c74f67ae 100644
--- a/opcodes/i386-dis.c
+++ b/opcodes/i386-dis.c
@@ -2947,6 +2947,7 @@ static const struct dis386 reg_table[][8] = {
{ "xcrypt-cfb", { { OP_0f07, 0 } }, 0 },
{ "xcrypt-ofb", { { OP_0f07, 0 } }, 0 },
{ PREFIX_TABLE (PREFIX_0FA7_REG_6) },
+ { "xrng2", { { OP_0f07, 0 } }, 0 },
},
/* REG_0FAE */
{
diff --git a/opcodes/i386-gen.c b/opcodes/i386-gen.c
index ed47a0cedd2..472fe1e6fa4 100644
--- a/opcodes/i386-gen.c
+++ b/opcodes/i386-gen.c
@@ -289,6 +289,8 @@ static const dependency isa_dependencies[] =
"64" },
{ "APX_F",
"XSAVE|64" },
+ { "PadLockRNG2",
+ "PadLock" },
};
/* This array is populated as process_i386_initializers() walks cpu_flags[]. */
@@ -343,6 +345,7 @@ static bitfield cpu_flags[] =
BITFIELD (3dnowA),
BITFIELD (PadLock),
BITFIELD (GMI),
+ BITFIELD (PadLockRNG2),
BITFIELD (SVME),
BITFIELD (VMX),
BITFIELD (SMX),
diff --git a/opcodes/i386-opc.h b/opcodes/i386-opc.h
index cf7aa3dcb30..80eef398442 100644
--- a/opcodes/i386-opc.h
+++ b/opcodes/i386-opc.h
@@ -66,8 +66,10 @@ enum i386_cpu
CpuSSE3,
/* VIA PadLock required */
CpuPadLock,
- /* ZHAOXIN GMI required */
+ /* Zhaoxin GMI required */
CpuGMI,
+ /* Zhaoxin PadLock RNG2 required */
+ CpuPadLockRNG2,
/* AMD Secure Virtual Machine Ext-s required */
CpuSVME,
/* VMX Instructions required */
@@ -411,6 +413,7 @@ typedef union i386_cpu_flags
unsigned int cpusse3:1;
unsigned int cpupadlock:1;
unsigned int cpugmi:1;
+ unsigned int cpupadlockrng2:1;
unsigned int cpusvme:1;
unsigned int cpuvmx:1;
unsigned int cpusmx:1;
diff --git a/opcodes/i386-opc.tbl b/opcodes/i386-opc.tbl
index 59eed7bb08d..b299147b5e1 100644
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -2134,11 +2134,14 @@ xcryptofb, 0xf30fa7e8, PadLock, NoSuf|RepPrefixOk, {}
// Alias for xstore-rng.
xstore, 0xfa7c0, PadLock, NoSuf|RepPrefixOk, {}
-// ZHAOXIN GMI instructions
+// Zhaoxin GMI instructions
sm2, 0xf20fa6c0, GMI, NoSuf, {}
sm3, 0xf30fa6e8, GMI, NoSuf, {}
sm4, 0xf30fa7f0, GMI, NoSuf, {}
+// Zhaoxin PadLock RNG2 instruction
+xrng2, 0xf30fa7f8, PadLockRNG2, NoSuf|RepPrefixOk, {}
+
// Multy-precision Add Carry, rdseed instructions.
<adx:pfx, c:66, o:f3>
ad<adx>x, 0x<adx:pfx>66, ADX&APX_F, C|Modrm|CheckOperandSize|No_bSuf|No_wSuf|No_sSuf|DstVVVV|EVexMap4, { Reg32|Reg64|Unspecified|BaseIndex, Reg32|Reg64, Reg32|Reg64 }
--
2.27.0
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v1] x86: Support Zhaoxin RNG2 instruction
2025-01-08 9:38 ` Mayshao-oc
@ 2025-01-08 11:30 ` Jan Beulich
2025-01-09 2:05 ` Jiang, Haochen
0 siblings, 1 reply; 80+ messages in thread
From: Jan Beulich @ 2025-01-08 11:30 UTC (permalink / raw)
To: Mayshao-oc
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, H.J. Lu, Jiang, Haochen
On 08.01.2025 10:38, Mayshao-oc wrote:
> BTW: Whether gcc -march=xxx will imply a -march=xxx to assembler in gcc driver and do some check? I am curious about this.
No, the compiler doesn't convert -march= passed to it to respective
gas command line options (nor directives) for x86.
Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v1] x86: Support Zhaoxin RNG2 instruction
2025-01-08 9:40 ` Mayshao-oc
2025-01-08 9:46 ` [PATCH v2] x86: Support Zhaoxin PadLock " Mayshao-oc
@ 2025-01-08 11:31 ` Jan Beulich
1 sibling, 0 replies; 80+ messages in thread
From: Jan Beulich @ 2025-01-08 11:31 UTC (permalink / raw)
To: Mayshao-oc
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen, H.J. Lu
On 08.01.2025 10:40, Mayshao-oc wrote:
>
>> On 07.01.2025 12:04, Mayshao-oc wrote:
>>>> On 07.01.2025 04:08, Mayshao-oc wrote:
>>>>>> On 30.12.2024 10:20, Mayshao-oc wrote:
>>>>>> Is there a connection between PadLock and RNG2? Does RNG2 perhaps even imply PadLock as a prereq feature (wanting a dependency recorded in i386-gen.c)? If so, naming it "PadLockRNG2" may be an option to avoid a potential future clash.
>>>>> Yes, there is a connection. I think it's reasonable to naming it "PadLockRNG2", I will rename it.
>>>>
>>>> Well, if there's a connection, then (as said) the dependency also wants recording in i386-gen.c.
>>> Ok, you mean add an element in isa_dependencies[],like {"PadLockRNG2", "PadLock"}?
>>
>> Yes.
>>
>>> Assambler need this depenency information to do some check? I will take a while to understand this.
>>
>> It'll ensure that when PadLock is turned off, PadLockRNG2 would be turned off automatically as well.
> Thanks for your comments. I don't understand the "when PadLock is turned off" means it is turned off in hardware or it is turned off in assembler.
The latter of course.
> If it means turned off in assembler, how can I test it?
Via -march= or .arch directives.
Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* RE: [PATCH v1] x86: Support Zhaoxin RNG2 instruction
2025-01-08 11:30 ` Jan Beulich
@ 2025-01-09 2:05 ` Jiang, Haochen
0 siblings, 0 replies; 80+ messages in thread
From: Jiang, Haochen @ 2025-01-09 2:05 UTC (permalink / raw)
To: Beulich, Jan, Mayshao-oc
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD), binutils, H.J. Lu
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Wednesday, January 8, 2025 7:30 PM
>
> On 08.01.2025 10:38, Mayshao-oc wrote:
> > BTW: Whether gcc -march=xxx will imply a -march=xxx to assembler in gcc
> driver and do some check? I am curious about this.
>
> No, the compiler doesn't convert -march= passed to it to respective gas
> command line options (nor directives) for x86.
>
You should take GCC and Binutils separate components here.
You can take it this way, GCC mostly take charge of generating asm while
Binutils mostly take charge of transforming asm to bytecode.
For LLVM, their asm generate and bytecode transform are in the same
codebase, and they might could pass them.
Thx,
Haochen
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v2] x86: Support Zhaoxin PadLock RNG2 instruction
2025-01-08 9:46 ` [PATCH v2] x86: Support Zhaoxin PadLock " Mayshao-oc
@ 2025-01-09 12:15 ` Jan Beulich
2025-01-13 2:17 ` Mayshao-oc
0 siblings, 1 reply; 80+ messages in thread
From: Jan Beulich @ 2025-01-09 12:15 UTC (permalink / raw)
To: Mayshao-oc
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen, H.J. Lu
On 08.01.2025 10:46, Mayshao-oc wrote:
>
> Hi all:
> This patch adds support for Zhaoxin PadLock RNG2 instruction, the
> CPUID EDX bit[23] indicates its enablement, it includes REP XRNG2
> instruction.
> Test ok, ok for trunk?
>
> Changes in V2:
> 1. Change the indenting correctly and change the boolean expression in output_insn()
That adjustment has resulted in too long a line now.
> 2. Rename RNG2 to PadLockRNG2
With this I don't think the comment in add_branch_prefix_frag_p() needs
adjusting anymore.
I can make these adjustments when committing the change on your behalf,
unless you disagree. Beyond these the patch is okay to go in now.
> 3. Add PadLockRNG2 to dependency table.
Orthogonal to this: Should there be a similar dependency of GMI on PadLock?
Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH v2] x86: Support Zhaoxin PadLock RNG2 instruction
2025-01-09 12:15 ` Jan Beulich
@ 2025-01-13 2:17 ` Mayshao-oc
2025-01-14 6:46 ` [PATCH] x86: Add CpuGMISM2 and CpuGMICCS Mayshao-oc
2025-01-15 8:06 ` [PATCH] x86: Support Zhaoxin PadLock PHE2 instructions Mayshao-oc
0 siblings, 2 replies; 80+ messages in thread
From: Mayshao-oc @ 2025-01-13 2:17 UTC (permalink / raw)
To: Jan Beulich
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen, H.J. Lu
> On 08.01.2025 10:46, Mayshao-oc wrote:
> >
> > Hi all:
> > This patch adds support for Zhaoxin PadLock RNG2 instruction, the
> > CPUID EDX bit[23] indicates its enablement, it includes REP XRNG2
> > instruction.
> > Test ok, ok for trunk?
> >
> > Changes in V2:
> > 1. Change the indenting correctly and change the boolean expression in
> > output_insn()
>
> That adjustment has resulted in too long a line now.
>
> > 2. Rename RNG2 to PadLockRNG2
>
> With this I don't think the comment in add_branch_prefix_frag_p() needs adjusting anymore.
>
> I can make these adjustments when committing the change on your behalf, unless you disagree. Beyond these the patch is okay to go in now.
Thank you for your comment. I agree with you, there is no need to adjust the comment of add_branch_prefix_frag_p().
Please commit the patch on my behalf.
>
> > 3. Add PadLockRNG2 to dependency table.
>
> Orthogonal to this: Should there be a similar dependency of GMI on PadLock?
I ask my colleague to answer this question in perspective of hardware. He said GMI and PadLock is independent, and GMI itself includes two cpu features. SM2 and SM3/SM4 is independent in perspective of hardware, they enable both when the platform supports both. I think I need to change CpuGMI to two cpu features. I didn't know that cpuid matters, when I submitted the GMI patch, so I'll change GMI related code.
>
> Jan
BR
MayShao
^ permalink raw reply [flat|nested] 80+ messages in thread
* [PATCH] x86: Add CpuGMISM2 and CpuGMICCS
2025-01-13 2:17 ` Mayshao-oc
@ 2025-01-14 6:46 ` Mayshao-oc
2025-01-15 14:40 ` Jan Beulich
2025-01-15 8:06 ` [PATCH] x86: Support Zhaoxin PadLock PHE2 instructions Mayshao-oc
1 sibling, 1 reply; 80+ messages in thread
From: Mayshao-oc @ 2025-01-14 6:46 UTC (permalink / raw)
To: Jan Beulich
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen, H.J. Lu
[-- Attachment #1: Type: text/plain, Size: 231 bytes --]
Hi all:
There are separate CPUID feature bits for SM2 and CCS instructions.
CCS includes SM3 and SM4 instructions. This patch adds CpuGMISM2 and
CpuGMICCS to replace CpuGMI on corresponding instructions.
BR
MayShao
[-- Attachment #2: 0001-x86-Add-CpuGMISM2-and-CpuGMICCS.patch --]
[-- Type: application/octet-stream, Size: 4563 bytes --]
From 6c61cc80b76b7070780fd5a3ca22808acde1bc4d Mon Sep 17 00:00:00 2001
From: MayShao-oc <MayShao-oc@zhaoxin.com>
Date: Tue, 14 Jan 2025 13:45:36 +0800
Subject: [PATCH] x86: Add CpuGMISM2 and CpuGMICCS
Hi all:
There are separate CPUID feature bits for SM2 and CCS instructions.
CCS includes SM3 and SM4 instructions. This patch adds CpuGMISM2 and
CpuGMICCS to replace CpuGMI on corresponding instructions.
BR
MayShao
gas/ChangeLog:
* config/tc-i386.c: Add gmism2 and gmiccs to replace gmi.
* doc/c-i386.texi: Ditto.
opcodes/ChangeLog:
* i386-gen.c: Add GMISM2 and GMICCS to replace GMI.
* i386-opc.h (enum i386_cpu): Add CpuGMISM2 and CpuGMICCS to
replace CpuGMI.
* i386-opc.tbl: Replace GMI with GMISM2 on sm2 instruction. Replace GMI
with GMICCS on sm3 and sm4 instructions.
* i386-tbl.h: Regenerated.
* i386-mnem.h: Ditto.
* i386-init.h: Ditto.
---
gas/config/tc-i386.c | 3 ++-
gas/doc/c-i386.texi | 6 ++++--
opcodes/i386-gen.c | 3 ++-
opcodes/i386-opc.h | 9 ++++++---
opcodes/i386-opc.tbl | 10 ++++++----
5 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c
index af1b9988dd8..ce2c9449308 100644
--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -1223,7 +1223,8 @@ static const arch_entry cpu_arch[] =
SUBARCH (user_msr, USER_MSR, USER_MSR, false),
SUBARCH (apx_f, APX_F, APX_F, false),
VECARCH (avx10.2, AVX10_2, ANY_AVX10_2, set),
- SUBARCH (gmi, GMI, GMI, false),
+ SUBARCH (gmism2, GMISM2, GMISM2, false),
+ SUBARCH (gmiccs, GMICCS, GMICCS, false),
SUBARCH (msr_imm, MSR_IMM, MSR_IMM, false),
SUBARCH (padlockrng2, PADLOCKRNG2, PADLOCKRNG2, false),
};
diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi
index 20e21405053..230ac253d63 100644
--- a/gas/doc/c-i386.texi
+++ b/gas/doc/c-i386.texi
@@ -279,7 +279,8 @@ accept various extension mnemonics. For example,
@code{invlpgb},
@code{tlbsync},
@code{svme},
-@code{gmi},
+@code{gmism2},
+@code{gmiccs},
@code{padlockrng2} and
@code{padlock}.
Note that these extension mnemonics can be prefixed with @code{no} to revoke
@@ -1712,7 +1713,8 @@ supported on the CPU specified. The choices for @var{cpu_type} are:
@item @samp{.lwp} @tab @samp{.fma4} @tab @samp{.xop} @tab @samp{.cx16}
@item @samp{.padlock} @tab @samp{.clzero} @tab @samp{.mwaitx} @tab @samp{.rdpru}
@item @samp{.mcommit} @tab @samp{.sev_es} @tab @samp{.snp} @tab @samp{.invlpgb}
-@item @samp{.tlbsync} @tab @samp{.apx_f} @tab @samp{.gmi} @tab @samp{.padlockrng2}
+@item @samp{.tlbsync} @tab @samp{.apx_f} @tab @samp{.gmism2} @tab @samp{.gmiccs}
+@item @samp{.padlockrng2}
@end multitable
diff --git a/opcodes/i386-gen.c b/opcodes/i386-gen.c
index 60aa8ddbad7..3e93982b357 100644
--- a/opcodes/i386-gen.c
+++ b/opcodes/i386-gen.c
@@ -346,7 +346,8 @@ static bitfield cpu_flags[] =
BITFIELD (3dnow),
BITFIELD (3dnowA),
BITFIELD (PadLock),
- BITFIELD (GMI),
+ BITFIELD (GMISM2),
+ BITFIELD (GMICCS),
BITFIELD (PadLockRNG2),
BITFIELD (SVME),
BITFIELD (VMX),
diff --git a/opcodes/i386-opc.h b/opcodes/i386-opc.h
index 5d330550205..a4c63038adb 100644
--- a/opcodes/i386-opc.h
+++ b/opcodes/i386-opc.h
@@ -66,8 +66,10 @@ enum i386_cpu
CpuSSE3,
/* VIA PadLock required */
CpuPadLock,
- /* Zhaoxin GMI required */
- CpuGMI,
+ /* Zhaoxin GMI SM2 required */
+ CpuGMISM2,
+ /* Zhaoxin GMI CCS required */
+ CpuGMICCS,
/* Zhaoxin PadLock RNG2 required */
CpuPadLockRNG2,
/* AMD Secure Virtual Machine Ext-s required */
@@ -414,7 +416,8 @@ typedef union i386_cpu_flags
unsigned int cpusse2:1;
unsigned int cpusse3:1;
unsigned int cpupadlock:1;
- unsigned int cpugmi:1;
+ unsigned int cpugmism2:1;
+ unsigned int cpugmiccs:1;
unsigned int cpupadlockrng2:1;
unsigned int cpusvme:1;
unsigned int cpuvmx:1;
diff --git a/opcodes/i386-opc.tbl b/opcodes/i386-opc.tbl
index 32dd883926c..54c516fe554 100644
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -2134,10 +2134,12 @@ xcryptofb, 0xf30fa7e8, PadLock, NoSuf|RepPrefixOk, {}
// Alias for xstore-rng.
xstore, 0xfa7c0, PadLock, NoSuf|RepPrefixOk, {}
-// Zhaoxin GMI instructions
-sm2, 0xf20fa6c0, GMI, NoSuf, {}
-sm3, 0xf30fa6e8, GMI, NoSuf, {}
-sm4, 0xf30fa7f0, GMI, NoSuf, {}
+// Zhaoxin GMI SM2 instruction
+sm2, 0xf20fa6c0, GMISM2, NoSuf, {}
+
+// Zhaoxin GMI CCS instructions
+sm3, 0xf30fa6e8, GMICCS, NoSuf, {}
+sm4, 0xf30fa7f0, GMICCS, NoSuf, {}
// Zhaoxin PadLock RNG2 instruction
xrng2, 0xf30fa7f8, PadLockRNG2, NoSuf|RepPrefixOk, {}
--
2.27.0
^ permalink raw reply [flat|nested] 80+ messages in thread
* [PATCH] x86: Support Zhaoxin PadLock PHE2 instructions
2025-01-13 2:17 ` Mayshao-oc
2025-01-14 6:46 ` [PATCH] x86: Add CpuGMISM2 and CpuGMICCS Mayshao-oc
@ 2025-01-15 8:06 ` Mayshao-oc
2025-01-15 14:45 ` Jan Beulich
1 sibling, 1 reply; 80+ messages in thread
From: Mayshao-oc @ 2025-01-15 8:06 UTC (permalink / raw)
To: Jan Beulich
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen, H.J. Lu
[-- Attachment #1: Type: text/plain, Size: 219 bytes --]
Hi all:
This patch adds support for Zhaoxin PadLockPHE2 instructions.
The CPUID EDX bit[26] indicates its enablement, and it includes REP
XSHA384 and REP XSHA512.
Test ok, ok for trunk?
BR
MayShao
[-- Attachment #2: 0001-x86-Support-x86-Zhaoxin-PadLock-PHE2-instructions_v1.patch --]
[-- Type: application/octet-stream, Size: 7819 bytes --]
From 836bf88a8176b1a1d47c89bffe81615a54acad9f Mon Sep 17 00:00:00 2001
From: MayShao-oc <MayShao-oc@zhaoxin.com>
Date: Wed, 15 Jan 2025 15:22:04 +0800
Subject: [PATCH] x86: Support x86 Zhaoxin PadLock PHE2 instructions
Hi all:
This patch adds support for Zhaoxin PadLockPHE2 instructions.
The CPUID EDX bit[26] indicates its enablement, and it includes REP
XSHA384 and REP XSHA512.
Test ok, ok for trunk?
BR
MayShao
gas/ChangeLog:
* NEWS: Support Zhaoxin PadLock PHE2 instructions.
* config/tc-i386.c (add_branch_prefix_frag_p): Don't add prefix to
PadLockPHE2 instructions.
(output_insn): Handle PadLockPHE2 instructions.
* doc/c-i386.texi: Document PadLockPHE2.
* testsuite/gas/i386/i386.exp: Add PadLockPHE2 test.
* testsuite/gas/i386/padlock_phe2.d: Ditto.
* testsuite/gas/i386/padlock_phe2.s: Ditto.
opcodes/ChangeLog:
* i386-dis.c: Add PadLockPHE2.
* i386-gen.c: Ditto
* i386-opc.h (CpuPadLockPHE2): New.
* i386-opc.tbl: Add Zhaoxin PadLock PHE2 instructions.
* i386-tbl.h: Regenerated.
* i386-mnem.h: Ditto.
* i386-init.h: Ditto.
---
gas/NEWS | 2 ++
gas/config/tc-i386.c | 5 ++++-
gas/doc/c-i386.texi | 4 +++-
gas/testsuite/gas/i386/i386.exp | 1 +
gas/testsuite/gas/i386/padlockphe2.d | 13 +++++++++++++
gas/testsuite/gas/i386/padlockphe2.s | 9 +++++++++
opcodes/i386-dis.c | 4 ++--
opcodes/i386-gen.c | 3 +++
opcodes/i386-opc.h | 3 +++
opcodes/i386-opc.tbl | 4 ++++
10 files changed, 44 insertions(+), 4 deletions(-)
create mode 100644 gas/testsuite/gas/i386/padlockphe2.d
create mode 100644 gas/testsuite/gas/i386/padlockphe2.s
diff --git a/gas/NEWS b/gas/NEWS
index 5c8975dbc44..5251569e8bb 100644
--- a/gas/NEWS
+++ b/gas/NEWS
@@ -1,5 +1,7 @@
-*- text -*-
+* Add support for the x86 Zhaoxin PadLock PHE2 instructions.
+
* Add support for the x86 Zhaoxin PadLock RNG2 instruction.
* Add support for AArch64 SME and SVE non-widening BFloat16 (SVE_B16B16 and
diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c
index af1b9988dd8..0b65690aef2 100644
--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -1226,6 +1226,7 @@ static const arch_entry cpu_arch[] =
SUBARCH (gmi, GMI, GMI, false),
SUBARCH (msr_imm, MSR_IMM, MSR_IMM, false),
SUBARCH (padlockrng2, PADLOCKRNG2, PADLOCKRNG2, false),
+ SUBARCH (padlockphe2, PADLOCKPHE2, PADLOCKPHE2, false),
};
#undef SUBARCH
@@ -12033,6 +12034,7 @@ add_branch_prefix_frag_p (const struct last_insn *last_insn)
|| now_seg == absolute_section
|| is_cpu (&i.tm, CpuPadLock)
|| is_cpu (&i.tm, CpuPadLockRNG2)
+ || is_cpu (&i.tm, CpuPadLockPHE2)
|| !cpu_arch_flags.bitfield.cpui386)
return 0;
@@ -12408,7 +12410,8 @@ output_insn (const struct last_insn *last_insn)
break;
case PREFIX_0XF3:
if ((!is_cpu (&i.tm, CpuPadLock)
- && !is_cpu (&i.tm, CpuPadLockRNG2))
+ && !is_cpu (&i.tm, CpuPadLockRNG2)
+ && !is_cpu (&i.tm, CpuPadLockPHE2))
|| (i.prefix[REP_PREFIX] != 0xf3))
add_prefix (0xf3);
break;
diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi
index 20e21405053..578ae872f0e 100644
--- a/gas/doc/c-i386.texi
+++ b/gas/doc/c-i386.texi
@@ -280,7 +280,8 @@ accept various extension mnemonics. For example,
@code{tlbsync},
@code{svme},
@code{gmi},
-@code{padlockrng2} and
+@code{padlockrng2},
+@code{padlockphe2} and
@code{padlock}.
Note that these extension mnemonics can be prefixed with @code{no} to revoke
the respective (and any dependent) functionality. Note further that the
@@ -1713,6 +1714,7 @@ supported on the CPU specified. The choices for @var{cpu_type} are:
@item @samp{.padlock} @tab @samp{.clzero} @tab @samp{.mwaitx} @tab @samp{.rdpru}
@item @samp{.mcommit} @tab @samp{.sev_es} @tab @samp{.snp} @tab @samp{.invlpgb}
@item @samp{.tlbsync} @tab @samp{.apx_f} @tab @samp{.gmi} @tab @samp{.padlockrng2}
+@item @samp{.padlockphe2}
@end multitable
diff --git a/gas/testsuite/gas/i386/i386.exp b/gas/testsuite/gas/i386/i386.exp
index fed9283d4ed..1c81909f83e 100644
--- a/gas/testsuite/gas/i386/i386.exp
+++ b/gas/testsuite/gas/i386/i386.exp
@@ -116,6 +116,7 @@ if [gas_32_check] then {
run_dump_test "padlock"
run_dump_test "gmi"
run_dump_test "padlockrng2"
+ run_dump_test "padlockphe2"
run_dump_test "crx"
run_list_test "cr-err" ""
run_dump_test "cdr"
diff --git a/gas/testsuite/gas/i386/padlockphe2.d b/gas/testsuite/gas/i386/padlockphe2.d
new file mode 100644
index 00000000000..794e0823a9b
--- /dev/null
+++ b/gas/testsuite/gas/i386/padlockphe2.d
@@ -0,0 +1,13 @@
+#objdump: -dw
+#name: Zhaoxin PadLock PHE2
+
+.*: +file format .*
+
+Disassembly of section .text:
+
+0+000 <foo>:
+ 0:[ ]*f3 0f a6 d8 [ ]*repz xsha384
+ 4:[ ]*f3 0f a6 d8 [ ]*repz xsha384
+ 8:[ ]*f3 0f a6 e0 [ ]*repz xsha512
+ c:[ ]*f3 0f a6 e0 [ ]*repz xsha512
+#pass
diff --git a/gas/testsuite/gas/i386/padlockphe2.s b/gas/testsuite/gas/i386/padlockphe2.s
new file mode 100644
index 00000000000..0068cb79bbb
--- /dev/null
+++ b/gas/testsuite/gas/i386/padlockphe2.s
@@ -0,0 +1,9 @@
+# Zhaoxin PadLock PHE2 instructions
+
+ .text
+foo:
+ xsha384
+ rep xsha384
+ xsha512
+ rep xsha512
+ .p2align 4,0
diff --git a/opcodes/i386-dis.c b/opcodes/i386-dis.c
index f9b6cf30fd0..f00062d8dc3 100644
--- a/opcodes/i386-dis.c
+++ b/opcodes/i386-dis.c
@@ -2939,8 +2939,8 @@ static const struct dis386 reg_table[][8] = {
{ PREFIX_TABLE (PREFIX_0FA6_REG_0) },
{ "xsha1", { { OP_0f07, 0 } }, 0 },
{ "xsha256", { { OP_0f07, 0 } }, 0 },
- { Bad_Opcode },
- { Bad_Opcode },
+ { "xsha384", { { OP_0f07, 0 } }, 0 },
+ { "xsha512", { { OP_0f07, 0 } }, 0 },
{ PREFIX_TABLE (PREFIX_0FA6_REG_5) },
},
/* REG_0FA7 */
diff --git a/opcodes/i386-gen.c b/opcodes/i386-gen.c
index 60aa8ddbad7..e1dacfbdf7e 100644
--- a/opcodes/i386-gen.c
+++ b/opcodes/i386-gen.c
@@ -293,6 +293,8 @@ static const dependency isa_dependencies[] =
"XSAVE|64" },
{ "PadLockRNG2",
"PadLock" },
+ { "PadLockPHE2",
+ "PadLock" },
};
/* This array is populated as process_i386_initializers() walks cpu_flags[]. */
@@ -348,6 +350,7 @@ static bitfield cpu_flags[] =
BITFIELD (PadLock),
BITFIELD (GMI),
BITFIELD (PadLockRNG2),
+ BITFIELD (PadLockPHE2),
BITFIELD (SVME),
BITFIELD (VMX),
BITFIELD (SMX),
diff --git a/opcodes/i386-opc.h b/opcodes/i386-opc.h
index 5d330550205..9e73b3df8b0 100644
--- a/opcodes/i386-opc.h
+++ b/opcodes/i386-opc.h
@@ -70,6 +70,8 @@ enum i386_cpu
CpuGMI,
/* Zhaoxin PadLock RNG2 required */
CpuPadLockRNG2,
+ /* Zhaoxin PadLock PHE2 required */
+ CpuPadLockPHE2,
/* AMD Secure Virtual Machine Ext-s required */
CpuSVME,
/* VMX Instructions required */
@@ -416,6 +418,7 @@ typedef union i386_cpu_flags
unsigned int cpupadlock:1;
unsigned int cpugmi:1;
unsigned int cpupadlockrng2:1;
+ unsigned int cpupadlockphe2:1;
unsigned int cpusvme:1;
unsigned int cpuvmx:1;
unsigned int cpusmx:1;
diff --git a/opcodes/i386-opc.tbl b/opcodes/i386-opc.tbl
index 32dd883926c..db5f5e750e4 100644
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -2142,6 +2142,10 @@ sm4, 0xf30fa7f0, GMI, NoSuf, {}
// Zhaoxin PadLock RNG2 instruction
xrng2, 0xf30fa7f8, PadLockRNG2, NoSuf|RepPrefixOk, {}
+// Zhaoxin PadLock PHE2 instructions
+xsha384, 0xf30fa6d8, PadLockPHE2, NoSuf|RepPrefixOk, {}
+xsha512, 0xf30fa6e0, PadLockPHE2, NoSuf|RepPrefixOk, {}
+
// Multy-precision Add Carry, rdseed instructions.
<adx:pfx, c:66, o:f3>
ad<adx>x, 0x<adx:pfx>66, ADX&APX_F, C|Modrm|CheckOperandSize|No_bSuf|No_wSuf|No_sSuf|DstVVVV|EVexMap4, { Reg32|Reg64|Unspecified|BaseIndex, Reg32|Reg64, Reg32|Reg64 }
--
2.27.0
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] x86: Add CpuGMISM2 and CpuGMICCS
2025-01-14 6:46 ` [PATCH] x86: Add CpuGMISM2 and CpuGMICCS Mayshao-oc
@ 2025-01-15 14:40 ` Jan Beulich
2025-01-16 1:51 ` Jiang, Haochen
` (2 more replies)
0 siblings, 3 replies; 80+ messages in thread
From: Jan Beulich @ 2025-01-15 14:40 UTC (permalink / raw)
To: Mayshao-oc
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen, H.J. Lu
On 14.01.2025 07:46, Mayshao-oc wrote:
> There are separate CPUID feature bits for SM2 and CCS instructions.
> CCS includes SM3 and SM4 instructions. This patch adds CpuGMISM2 and
> CpuGMICCS to replace CpuGMI on corresponding instructions.
Mechanically the patch okay, yet I wonder about the names chosen: Are "GMISM2"
and "GMICCS" how your doc is going to talk about these features?
Irrespective of the answer, I think it would be nice if the description said
what "CCS" actually stands for; it surely isn't "Carbon Capture & Storage".
Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] x86: Support Zhaoxin PadLock PHE2 instructions
2025-01-15 8:06 ` [PATCH] x86: Support Zhaoxin PadLock PHE2 instructions Mayshao-oc
@ 2025-01-15 14:45 ` Jan Beulich
2025-01-16 6:52 ` Mayshao-oc
0 siblings, 1 reply; 80+ messages in thread
From: Jan Beulich @ 2025-01-15 14:45 UTC (permalink / raw)
To: Mayshao-oc
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen, H.J. Lu
On 15.01.2025 09:06, Mayshao-oc wrote:
>
> Hi all:
> This patch adds support for Zhaoxin PadLockPHE2 instructions.
> The CPUID EDX bit[26] indicates its enablement, and it includes REP
> XSHA384 and REP XSHA512.
> Test ok, ok for trunk?
In gas/NEWS, how about amending the PadLock RNG2 line instead of adding
yet another bullet point? Preferably with that adjustment: Okay. Aiui
this once again will need committing on your behalf?
Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* RE: [PATCH] x86: Add CpuGMISM2 and CpuGMICCS
2025-01-15 14:40 ` Jan Beulich
@ 2025-01-16 1:51 ` Jiang, Haochen
2025-01-16 6:54 ` Mayshao-oc
2025-01-17 9:07 ` Mayshao-oc
2025-01-16 6:53 ` Mayshao-oc
2025-01-17 8:58 ` Mayshao-oc
2 siblings, 2 replies; 80+ messages in thread
From: Jiang, Haochen @ 2025-01-16 1:51 UTC (permalink / raw)
To: Beulich, Jan, Mayshao-oc
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD), binutils, H.J. Lu
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Wednesday, January 15, 2025 10:40 PM
>
> On 14.01.2025 07:46, Mayshao-oc wrote:
> > There are separate CPUID feature bits for SM2 and CCS instructions.
> > CCS includes SM3 and SM4 instructions. This patch adds CpuGMISM2 and
> > CpuGMICCS to replace CpuGMI on corresponding instructions.
>
> Mechanically the patch okay, yet I wonder about the names chosen: Are
> "GMISM2"
> and "GMICCS" how your doc is going to talk about these features?
>
> Irrespective of the answer, I think it would be nice if the description said what
> "CCS" actually stands for; it surely isn't "Carbon Capture & Storage".
>
Does CCS stand for Chinese cryptography standards here? I guess so but please
name it explicitly since I get them from multiple sources, both Chinese and English.
Thx,
Haochen
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] x86: Support Zhaoxin PadLock PHE2 instructions
2025-01-15 14:45 ` Jan Beulich
@ 2025-01-16 6:52 ` Mayshao-oc
2025-01-17 9:00 ` [PATCH] x86: Support Zhaoxin PadLock XMODX instructions Mayshao-oc
0 siblings, 1 reply; 80+ messages in thread
From: Mayshao-oc @ 2025-01-16 6:52 UTC (permalink / raw)
To: Jan Beulich
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen, H.J. Lu
> On 15.01.2025 09:06, Mayshao-oc wrote:
> >
> > Hi all:
> > This patch adds support for Zhaoxin PadLockPHE2 instructions.
> > The CPUID EDX bit[26] indicates its enablement, and it includes
> > REP
> > XSHA384 and REP XSHA512.
> > Test ok, ok for trunk?
>
> In gas/NEWS, how about amending the PadLock RNG2 line instead of adding yet another bullet point? Preferably with that adjustment: Okay. Aiui this once again will need committing on your behalf?
Thanks for your review. I think the adjustment is Okay. I appreciate it.
>
> Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] x86: Add CpuGMISM2 and CpuGMICCS
2025-01-15 14:40 ` Jan Beulich
2025-01-16 1:51 ` Jiang, Haochen
@ 2025-01-16 6:53 ` Mayshao-oc
2025-01-17 8:58 ` Mayshao-oc
2 siblings, 0 replies; 80+ messages in thread
From: Mayshao-oc @ 2025-01-16 6:53 UTC (permalink / raw)
To: Jan Beulich
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen, H.J. Lu
> On 14.01.2025 07:46, Mayshao-oc wrote:
> > There are separate CPUID feature bits for SM2 and CCS instructions.
> > CCS includes SM3 and SM4 instructions. This patch adds CpuGMISM2 and
> > CpuGMICCS to replace CpuGMI on corresponding instructions.
>
> Mechanically the patch okay, yet I wonder about the names chosen: Are "GMISM2"
> and "GMICCS" how your doc is going to talk about these features?
Thanks for your review. I will communicate with my colleague to get more information.
>
> Irrespective of the answer, I think it would be nice if the description said what "CCS" actually stands for; it surely isn't "Carbon Capture & Storage".
Thanks for your reminder. I will describe the abbreviation next time.
>
> Jan
BR
MayShao
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] x86: Add CpuGMISM2 and CpuGMICCS
2025-01-16 1:51 ` Jiang, Haochen
@ 2025-01-16 6:54 ` Mayshao-oc
2025-01-17 9:07 ` Mayshao-oc
1 sibling, 0 replies; 80+ messages in thread
From: Mayshao-oc @ 2025-01-16 6:54 UTC (permalink / raw)
To: Jiang, Haochen, Beulich, Jan
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD), binutils, H.J. Lu
> > On 14.01.2025 07:46, Mayshao-oc wrote:
> > > There are separate CPUID feature bits for SM2 and CCS instructions.
> > > CCS includes SM3 and SM4 instructions. This patch adds CpuGMISM2 and
> > > CpuGMICCS to replace CpuGMI on corresponding instructions.
> >
> > Mechanically the patch okay, yet I wonder about the names chosen: Are
> > "GMISM2"
> > and "GMICCS" how your doc is going to talk about these features?
> >
> > Irrespective of the answer, I think it would be nice if the
> > description said what "CCS" actually stands for; it surely isn't "Carbon Capture & Storage".
> >
>
> Does CCS stand for Chinese cryptography standards here? I guess so but please name it explicitly since I get them from multiple sources, both Chinese and English.
Thanks for your comment. I don't know yet, I will discuss with my colleague, and clarify this later.
>
> Thx,
> Haochen
BR
MayShao
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] x86: Add CpuGMISM2 and CpuGMICCS
2025-01-15 14:40 ` Jan Beulich
2025-01-16 1:51 ` Jiang, Haochen
2025-01-16 6:53 ` Mayshao-oc
@ 2025-01-17 8:58 ` Mayshao-oc
2025-01-17 9:36 ` Jan Beulich
2 siblings, 1 reply; 80+ messages in thread
From: Mayshao-oc @ 2025-01-17 8:58 UTC (permalink / raw)
To: Jan Beulich
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen, H.J. Lu
> On 14.01.2025 07:46, Mayshao-oc wrote:
> > There are separate CPUID feature bits for SM2 and CCS instructions.
> > CCS includes SM3 and SM4 instructions. This patch adds CpuGMISM2 and
> > CpuGMICCS to replace CpuGMI on corresponding instructions.
>
> Mechanically the patch okay, yet I wonder about the names chosen: Are "GMISM2"
> and "GMICCS" how your doc is going to talk about these features?
I got the answer from my colleague. CCS is the acronym of chinese cipher system.
We develop SM3, SM4 at first and name the cpu feature bit as CCS, then develop the SM2, and name it as SM2.
If its ok, I appreciate you could commit on my behalf.
>
> Irrespective of the answer, I think it would be nice if the description said what "CCS" actually stands for; it surely isn't "Carbon Capture & Storage".
>
> Jan
BR
MayShao
^ permalink raw reply [flat|nested] 80+ messages in thread
* [PATCH] x86: Support Zhaoxin PadLock XMODX instructions
2025-01-16 6:52 ` Mayshao-oc
@ 2025-01-17 9:00 ` Mayshao-oc
2025-01-20 9:41 ` Jan Beulich
0 siblings, 1 reply; 80+ messages in thread
From: Mayshao-oc @ 2025-01-17 9:00 UTC (permalink / raw)
To: Jan Beulich
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen, H.J. Lu
[-- Attachment #1: Type: text/plain, Size: 359 bytes --]
Hi all:
This patch adds support for Zhaoxin XMODX instructions.
The CPUID EDX bit[28] indicates its enablement, and it includes REP
XMODEXP and REP MONTMUL2. XMODX stands for modular exponentiation, it indicates
the support of modular exponentiation feature, both REP XMODEXP and
REP MONTMUL2 use it.
Test ok, ok for trunk?
BR
MayShao
[-- Attachment #2: 0001-x86-Support-x86-Zhaoxin-PadLock-XMODX-instructions_v1.patch --]
[-- Type: application/octet-stream, Size: 8220 bytes --]
From f228cdbf7de59af1438abbe56d390fcf1dd80278 Mon Sep 17 00:00:00 2001
From: MayShao-oc <MayShao-oc@zhaoxin.com>
Date: Fri, 17 Jan 2025 15:57:26 +0800
Subject: [PATCH] x86: Support x86 Zhaoxin PadLock XMODX instructions
Hi all:
This patch adds support for Zhaoxin XMODX instructions.
The CPUID EDX bit[28] indicates its enablement, and it includes REP
XMODEXP and REP MONTMUL2. XMODX stands for modular exponentiation, it indicates
the support of modular exponentiation feature, both REP XMODEXP and
REP MONTMUL2 use it.
Test ok, ok for trunk?
BR
MayShao
gas/ChangeLog:
* NEWS: Support Zhaoxin PadLock XMODX instructions.
* config/tc-i386.c (add_branch_prefix_frag_p): Don't add prefix to
PadLockXMODX instructions.
(output_insn): Handle PadLockXMODX instructions.
* doc/c-i386.texi: Document PadLockXMODX.
* testsuite/gas/i386/i386.exp: Add PadLockXMODX test.
* testsuite/gas/i386/padlockxmodx.d: Ditto.
* testsuite/gas/i386/padlockxmodx.s: Ditto.
opcodes/ChangeLog:
* i386-dis.c: Add PadLockXMODX.
* i386-gen.c: Ditto
* i386-opc.h (CpuPadLockXMODX): New.
* i386-opc.tbl: Add Zhaoxin PadLock XMODX instructions.
* i386-tbl.h: Regenerated.
* i386-mnem.h: Ditto.
* i386-init.h: Ditto.
---
gas/NEWS | 2 +-
gas/config/tc-i386.c | 5 ++++-
gas/doc/c-i386.texi | 5 +++--
gas/testsuite/gas/i386/i386.exp | 1 +
gas/testsuite/gas/i386/padlockxmodx.d | 13 +++++++++++++
gas/testsuite/gas/i386/padlockxmodx.s | 9 +++++++++
opcodes/i386-dis.c | 2 ++
opcodes/i386-gen.c | 3 +++
opcodes/i386-opc.h | 3 +++
opcodes/i386-opc.tbl | 4 ++++
10 files changed, 43 insertions(+), 4 deletions(-)
create mode 100644 gas/testsuite/gas/i386/padlockxmodx.d
create mode 100644 gas/testsuite/gas/i386/padlockxmodx.s
diff --git a/gas/NEWS b/gas/NEWS
index 6192c208a5e..3870541854d 100644
--- a/gas/NEWS
+++ b/gas/NEWS
@@ -5,7 +5,7 @@
* Add support for the x86 Intel MOVRS instructions.
-* Add support for the x86 Zhaoxin PadLock PHE2 and RNG2 instructions.
+* Add support for the x86 Zhaoxin PadLock XMODX, PHE2 and RNG2 instructions.
* Add support for AArch64 SME and SVE non-widening BFloat16 (SVE_B16B16 and
SME_B16B16) instructions.
diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c
index ea370071282..8ace980233f 100644
--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -1229,6 +1229,7 @@ static const arch_entry cpu_arch[] =
SUBARCH (msr_imm, MSR_IMM, MSR_IMM, false),
SUBARCH (padlockrng2, PADLOCKRNG2, PADLOCKRNG2, false),
SUBARCH (padlockphe2, PADLOCKPHE2, PADLOCKPHE2, false),
+ SUBARCH (padlockxmodx, PADLOCKXMODX, PADLOCKXMODX, false),
SUBARCH (movrs, MOVRS, MOVRS, false),
};
@@ -12049,6 +12050,7 @@ add_branch_prefix_frag_p (const struct last_insn *last_insn)
|| is_cpu (&i.tm, CpuPadLock)
|| is_cpu (&i.tm, CpuPadLockRNG2)
|| is_cpu (&i.tm, CpuPadLockPHE2)
+ || is_cpu (&i.tm, CpuPadLockXMODX)
|| !cpu_arch_flags.bitfield.cpui386)
return 0;
@@ -12425,7 +12427,8 @@ output_insn (const struct last_insn *last_insn)
case PREFIX_0XF3:
if ((!is_cpu (&i.tm, CpuPadLock)
&& !is_cpu (&i.tm, CpuPadLockRNG2)
- && !is_cpu (&i.tm, CpuPadLockPHE2))
+ && !is_cpu (&i.tm, CpuPadLockPHE2)
+ && !is_cpu (&i.tm, CpuPadLockXMODX))
|| (i.prefix[REP_PREFIX] != 0xf3))
add_prefix (0xf3);
break;
diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi
index 06bef9048c5..dcb589a6daa 100644
--- a/gas/doc/c-i386.texi
+++ b/gas/doc/c-i386.texi
@@ -284,7 +284,8 @@ accept various extension mnemonics. For example,
@code{svme},
@code{gmi},
@code{padlockrng2},
-@code{padlockphe2} and
+@code{padlockphe2}
+@code{padlockxmodx} and
@code{padlock}.
Note that these extension mnemonics can be prefixed with @code{no} to revoke
the respective (and any dependent) functionality. Note further that the
@@ -1719,7 +1720,7 @@ supported on the CPU specified. The choices for @var{cpu_type} are:
@item @samp{.padlock} @tab @samp{.clzero} @tab @samp{.mwaitx} @tab @samp{.rdpru}
@item @samp{.mcommit} @tab @samp{.sev_es} @tab @samp{.snp} @tab @samp{.invlpgb}
@item @samp{.tlbsync} @tab @samp{.apx_f} @tab @samp{.gmi} @tab @samp{.padlockrng2}
-@item @samp{.padlockphe2}
+@item @samp{.padlockphe2} @tab @samp{.padlockxmodx}
@end multitable
diff --git a/gas/testsuite/gas/i386/i386.exp b/gas/testsuite/gas/i386/i386.exp
index b4d33cc7500..34d0a2fab8c 100644
--- a/gas/testsuite/gas/i386/i386.exp
+++ b/gas/testsuite/gas/i386/i386.exp
@@ -117,6 +117,7 @@ if [gas_32_check] then {
run_dump_test "gmi"
run_dump_test "padlockrng2"
run_dump_test "padlockphe2"
+ run_dump_test "padlockxmodx"
run_dump_test "crx"
run_list_test "cr-err" ""
run_dump_test "cdr"
diff --git a/gas/testsuite/gas/i386/padlockxmodx.d b/gas/testsuite/gas/i386/padlockxmodx.d
new file mode 100644
index 00000000000..9184d2c7426
--- /dev/null
+++ b/gas/testsuite/gas/i386/padlockxmodx.d
@@ -0,0 +1,13 @@
+#objdump: -dw
+#name: Zhaoxin PadLock XMODX
+
+.*: +file format .*
+
+Disassembly of section .text:
+
+0+000 <foo>:
+ 0:[ ]*f3 0f a6 f0 [ ]*repz montmul2
+ 4:[ ]*f3 0f a6 f0 [ ]*repz montmul2
+ 8:[ ]*f3 0f a6 f8 [ ]*repz xmodexp
+ c:[ ]*f3 0f a6 f8 [ ]*repz xmodexp
+#pass
diff --git a/gas/testsuite/gas/i386/padlockxmodx.s b/gas/testsuite/gas/i386/padlockxmodx.s
new file mode 100644
index 00000000000..4092fa539fd
--- /dev/null
+++ b/gas/testsuite/gas/i386/padlockxmodx.s
@@ -0,0 +1,9 @@
+# Zhaoxin PadLock XMODX instructions
+
+ .text
+foo:
+ montmul2
+ rep montmul2
+ xmodexp
+ rep xmodexp
+ .p2align 4,0
diff --git a/opcodes/i386-dis.c b/opcodes/i386-dis.c
index 06bd1e0f712..5324ae3bddc 100644
--- a/opcodes/i386-dis.c
+++ b/opcodes/i386-dis.c
@@ -2975,6 +2975,8 @@ static const struct dis386 reg_table[][8] = {
{ "xsha384", { { OP_0f07, 0 } }, 0 },
{ "xsha512", { { OP_0f07, 0 } }, 0 },
{ PREFIX_TABLE (PREFIX_0FA6_REG_5) },
+ { "montmul2", { { OP_0f07, 0 } }, 0 },
+ { "xmodexp", { { OP_0f07, 0 } }, 0 },
},
/* REG_0FA7 */
{
diff --git a/opcodes/i386-gen.c b/opcodes/i386-gen.c
index d2d9b5de006..3864de9aa5b 100644
--- a/opcodes/i386-gen.c
+++ b/opcodes/i386-gen.c
@@ -299,6 +299,8 @@ static const dependency isa_dependencies[] =
"PadLock" },
{ "PadLockPHE2",
"PadLock" },
+ { "PadLockXMODX",
+ "PadLock" },
};
/* This array is populated as process_i386_initializers() walks cpu_flags[]. */
@@ -355,6 +357,7 @@ static bitfield cpu_flags[] =
BITFIELD (GMI),
BITFIELD (PadLockRNG2),
BITFIELD (PadLockPHE2),
+ BITFIELD (PadLockXMODX),
BITFIELD (SVME),
BITFIELD (VMX),
BITFIELD (SMX),
diff --git a/opcodes/i386-opc.h b/opcodes/i386-opc.h
index c4751130d29..bbc77b9e3c0 100644
--- a/opcodes/i386-opc.h
+++ b/opcodes/i386-opc.h
@@ -72,6 +72,8 @@ enum i386_cpu
CpuPadLockRNG2,
/* Zhaoxin PadLock PHE2 required */
CpuPadLockPHE2,
+ /* Zhaoxin PadLock XMODX required */
+ CpuPadLockXMODX,
/* AMD Secure Virtual Machine Ext-s required */
CpuSVME,
/* VMX Instructions required */
@@ -425,6 +427,7 @@ typedef union i386_cpu_flags
unsigned int cpugmi:1;
unsigned int cpupadlockrng2:1;
unsigned int cpupadlockphe2:1;
+ unsigned int cpupadlockxmodx:1;
unsigned int cpusvme:1;
unsigned int cpuvmx:1;
unsigned int cpusmx:1;
diff --git a/opcodes/i386-opc.tbl b/opcodes/i386-opc.tbl
index 8b1d155941d..2272479edbe 100644
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -2146,6 +2146,10 @@ xrng2, 0xf30fa7f8, PadLockRNG2, NoSuf|RepPrefixOk, {}
xsha384, 0xf30fa6d8, PadLockPHE2, NoSuf|RepPrefixOk, {}
xsha512, 0xf30fa6e0, PadLockPHE2, NoSuf|RepPrefixOk, {}
+// Zhaoxin PadLock XMODX instructions
+montmul2, 0xf30fa6f0, PadLockXMODX, NoSuf|RepPrefixOk, {}
+xmodexp, 0xf30fa6f8, PadLockXMODX, NoSuf|RepPrefixOk, {}
+
// Multy-precision Add Carry, rdseed instructions.
<adx:pfx, c:66, o:f3>
ad<adx>x, 0x<adx:pfx>66, ADX&APX_F, C|Modrm|CheckOperandSize|No_bSuf|No_wSuf|No_sSuf|DstVVVV|EVexMap4, { Reg32|Reg64|Unspecified|BaseIndex, Reg32|Reg64, Reg32|Reg64 }
--
2.27.0
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] x86: Add CpuGMISM2 and CpuGMICCS
2025-01-16 1:51 ` Jiang, Haochen
2025-01-16 6:54 ` Mayshao-oc
@ 2025-01-17 9:07 ` Mayshao-oc
1 sibling, 0 replies; 80+ messages in thread
From: Mayshao-oc @ 2025-01-17 9:07 UTC (permalink / raw)
To: Jiang, Haochen, Beulich, Jan
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD), binutils, H.J. Lu
> > From: Jan Beulich <jbeulich@suse.com>
> > Sent: Wednesday, January 15, 2025 10:40 PM
> >
> > On 14.01.2025 07:46, Mayshao-oc wrote:
> > > There are separate CPUID feature bits for SM2 and CCS instructions.
> > > CCS includes SM3 and SM4 instructions. This patch adds CpuGMISM2 and
> > > CpuGMICCS to replace CpuGMI on corresponding instructions.
> >
> > Mechanically the patch okay, yet I wonder about the names chosen: Are
> > "GMISM2"
> > and "GMICCS" how your doc is going to talk about these features?
> >
> > Irrespective of the answer, I think it would be nice if the
> > description said what "CCS" actually stands for; it surely isn't "Carbon Capture & Storage".
> >
>
> Does CCS stand for Chinese cryptography standards here? I guess so but please name it explicitly since I get them from multiple sources, both Chinese and English.
I got the answer from my colleague. CCS is the acronym of chinese cipher system. I will pay attention to the use of acronym next time, thanks.
>
> Thx,
> Haochen
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] x86: Add CpuGMISM2 and CpuGMICCS
2025-01-17 8:58 ` Mayshao-oc
@ 2025-01-17 9:36 ` Jan Beulich
2025-01-17 10:03 ` Mayshao-oc
0 siblings, 1 reply; 80+ messages in thread
From: Jan Beulich @ 2025-01-17 9:36 UTC (permalink / raw)
To: Mayshao-oc
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen, H.J. Lu
On 17.01.2025 09:58, Mayshao-oc wrote:
>> On 14.01.2025 07:46, Mayshao-oc wrote:
>>> There are separate CPUID feature bits for SM2 and CCS instructions.
>>> CCS includes SM3 and SM4 instructions. This patch adds CpuGMISM2 and
>>> CpuGMICCS to replace CpuGMI on corresponding instructions.
>>
>> Mechanically the patch okay, yet I wonder about the names chosen: Are "GMISM2"
>> and "GMICCS" how your doc is going to talk about these features?
> I got the answer from my colleague. CCS is the acronym of chinese cipher system.
> We develop SM3, SM4 at first and name the cpu feature bit as CCS, then develop the SM2, and name it as SM2.
> If its ok, I appreciate you could commit on my behalf.
I'll be happy to do so, but you first need to re-base the patch (at
which point you will also want to add the expansion of the CCS
acronym in the description).
Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] x86: Add CpuGMISM2 and CpuGMICCS
2025-01-17 9:36 ` Jan Beulich
@ 2025-01-17 10:03 ` Mayshao-oc
2025-01-17 11:19 ` Mayshao-oc
0 siblings, 1 reply; 80+ messages in thread
From: Mayshao-oc @ 2025-01-17 10:03 UTC (permalink / raw)
To: Jan Beulich
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen, H.J. Lu
[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]
> >> On 14.01.2025 07:46, Mayshao-oc wrote:
> >>> There are separate CPUID feature bits for SM2 and CCS instructions.
> >>> CCS includes SM3 and SM4 instructions. This patch adds CpuGMISM2 and
> >>> CpuGMICCS to replace CpuGMI on corresponding instructions.
> >>
> >> Mechanically the patch okay, yet I wonder about the names chosen: Are "GMISM2"
> >> and "GMICCS" how your doc is going to talk about these features?
> > I got the answer from my colleague. CCS is the acronym of chinese cipher system.
> > We develop SM3, SM4 at first and name the cpu feature bit as CCS, then develop the SM2, and name it as SM2.
> > If its ok, I appreciate you could commit on my behalf.
>
> I'll be happy to do so, but you first need to re-base the patch (at
> which point you will also want to add the expansion of the CCS
> acronym in the description).
Thanks for your comment. I add the description of CCS in the patch, but I am not
quite sure I re-base the patch. Do you think I add the description in mail content
is ok, or I need to add the description elsewhere?
>
> Jan
BR
MayShao
[-- Attachment #2: 0001-x86-Add-CpuGMISM2-and-CpuGMICCS_v2.patch --]
[-- Type: application/octet-stream, Size: 4609 bytes --]
From 6c61cc80b76b7070780fd5a3ca22808acde1bc4d Mon Sep 17 00:00:00 2001
From: MayShao-oc <MayShao-oc@zhaoxin.com>
Date: Tue, 14 Jan 2025 13:45:36 +0800
Subject: [PATCH] x86: Add CpuGMISM2 and CpuGMICCS
Hi all:
There are separate CPUID feature bits for SM2 and CCS instructions.
CCS is the acronym of chinese cipher system, it includes SM3 and SM4
instructions. This patch adds CpuGMISM2 and CpuGMICCS to replace CpuGMI on
corresponding instructions.
BR
MayShao
gas/ChangeLog:
* config/tc-i386.c: Add gmism2 and gmiccs to replace gmi.
* doc/c-i386.texi: Ditto.
opcodes/ChangeLog:
* i386-gen.c: Add GMISM2 and GMICCS to replace GMI.
* i386-opc.h (enum i386_cpu): Add CpuGMISM2 and CpuGMICCS to
replace CpuGMI.
* i386-opc.tbl: Replace GMI with GMISM2 on sm2 instruction. Replace GMI
with GMICCS on sm3 and sm4 instructions.
* i386-tbl.h: Regenerated.
* i386-mnem.h: Ditto.
* i386-init.h: Ditto.
---
gas/config/tc-i386.c | 3 ++-
gas/doc/c-i386.texi | 6 ++++--
opcodes/i386-gen.c | 3 ++-
opcodes/i386-opc.h | 9 ++++++---
opcodes/i386-opc.tbl | 10 ++++++----
5 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c
index af1b9988dd8..ce2c9449308 100644
--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -1223,7 +1223,8 @@ static const arch_entry cpu_arch[] =
SUBARCH (user_msr, USER_MSR, USER_MSR, false),
SUBARCH (apx_f, APX_F, APX_F, false),
VECARCH (avx10.2, AVX10_2, ANY_AVX10_2, set),
- SUBARCH (gmi, GMI, GMI, false),
+ SUBARCH (gmism2, GMISM2, GMISM2, false),
+ SUBARCH (gmiccs, GMICCS, GMICCS, false),
SUBARCH (msr_imm, MSR_IMM, MSR_IMM, false),
SUBARCH (padlockrng2, PADLOCKRNG2, PADLOCKRNG2, false),
};
diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi
index 20e21405053..230ac253d63 100644
--- a/gas/doc/c-i386.texi
+++ b/gas/doc/c-i386.texi
@@ -279,7 +279,8 @@ accept various extension mnemonics. For example,
@code{invlpgb},
@code{tlbsync},
@code{svme},
-@code{gmi},
+@code{gmism2},
+@code{gmiccs},
@code{padlockrng2} and
@code{padlock}.
Note that these extension mnemonics can be prefixed with @code{no} to revoke
@@ -1712,7 +1713,8 @@ supported on the CPU specified. The choices for @var{cpu_type} are:
@item @samp{.lwp} @tab @samp{.fma4} @tab @samp{.xop} @tab @samp{.cx16}
@item @samp{.padlock} @tab @samp{.clzero} @tab @samp{.mwaitx} @tab @samp{.rdpru}
@item @samp{.mcommit} @tab @samp{.sev_es} @tab @samp{.snp} @tab @samp{.invlpgb}
-@item @samp{.tlbsync} @tab @samp{.apx_f} @tab @samp{.gmi} @tab @samp{.padlockrng2}
+@item @samp{.tlbsync} @tab @samp{.apx_f} @tab @samp{.gmism2} @tab @samp{.gmiccs}
+@item @samp{.padlockrng2}
@end multitable
diff --git a/opcodes/i386-gen.c b/opcodes/i386-gen.c
index 60aa8ddbad7..3e93982b357 100644
--- a/opcodes/i386-gen.c
+++ b/opcodes/i386-gen.c
@@ -346,7 +346,8 @@ static bitfield cpu_flags[] =
BITFIELD (3dnow),
BITFIELD (3dnowA),
BITFIELD (PadLock),
- BITFIELD (GMI),
+ BITFIELD (GMISM2),
+ BITFIELD (GMICCS),
BITFIELD (PadLockRNG2),
BITFIELD (SVME),
BITFIELD (VMX),
diff --git a/opcodes/i386-opc.h b/opcodes/i386-opc.h
index 5d330550205..a4c63038adb 100644
--- a/opcodes/i386-opc.h
+++ b/opcodes/i386-opc.h
@@ -66,8 +66,10 @@ enum i386_cpu
CpuSSE3,
/* VIA PadLock required */
CpuPadLock,
- /* Zhaoxin GMI required */
- CpuGMI,
+ /* Zhaoxin GMI SM2 required */
+ CpuGMISM2,
+ /* Zhaoxin GMI CCS required */
+ CpuGMICCS,
/* Zhaoxin PadLock RNG2 required */
CpuPadLockRNG2,
/* AMD Secure Virtual Machine Ext-s required */
@@ -414,7 +416,8 @@ typedef union i386_cpu_flags
unsigned int cpusse2:1;
unsigned int cpusse3:1;
unsigned int cpupadlock:1;
- unsigned int cpugmi:1;
+ unsigned int cpugmism2:1;
+ unsigned int cpugmiccs:1;
unsigned int cpupadlockrng2:1;
unsigned int cpusvme:1;
unsigned int cpuvmx:1;
diff --git a/opcodes/i386-opc.tbl b/opcodes/i386-opc.tbl
index 32dd883926c..54c516fe554 100644
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -2134,10 +2134,12 @@ xcryptofb, 0xf30fa7e8, PadLock, NoSuf|RepPrefixOk, {}
// Alias for xstore-rng.
xstore, 0xfa7c0, PadLock, NoSuf|RepPrefixOk, {}
-// Zhaoxin GMI instructions
-sm2, 0xf20fa6c0, GMI, NoSuf, {}
-sm3, 0xf30fa6e8, GMI, NoSuf, {}
-sm4, 0xf30fa7f0, GMI, NoSuf, {}
+// Zhaoxin GMI SM2 instruction
+sm2, 0xf20fa6c0, GMISM2, NoSuf, {}
+
+// Zhaoxin GMI CCS instructions
+sm3, 0xf30fa6e8, GMICCS, NoSuf, {}
+sm4, 0xf30fa7f0, GMICCS, NoSuf, {}
// Zhaoxin PadLock RNG2 instruction
xrng2, 0xf30fa7f8, PadLockRNG2, NoSuf|RepPrefixOk, {}
--
2.27.0
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] x86: Add CpuGMISM2 and CpuGMICCS
2025-01-17 10:03 ` Mayshao-oc
@ 2025-01-17 11:19 ` Mayshao-oc
0 siblings, 0 replies; 80+ messages in thread
From: Mayshao-oc @ 2025-01-17 11:19 UTC (permalink / raw)
To: Jan Beulich
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen, H.J. Lu
[-- Attachment #1: Type: text/plain, Size: 962 bytes --]
> >> On 14.01.2025 07:46, Mayshao-oc wrote:
> >>> There are separate CPUID feature bits for SM2 and CCS instructions.
> >>> CCS includes SM3 and SM4 instructions. This patch adds CpuGMISM2 and
> >>> CpuGMICCS to replace CpuGMI on corresponding instructions.
> >>
> >> Mechanically the patch okay, yet I wonder about the names chosen: Are "GMISM2"
> >> and "GMICCS" how your doc is going to talk about these features?
> > I got the answer from my colleague. CCS is the acronym of chinese cipher system.
> > We develop SM3, SM4 at first and name the cpu feature bit as CCS, then develop the SM2, and name it as SM2.
> > If its ok, I appreciate you could commit on my behalf.
>
> I'll be happy to do so, but you first need to re-base the patch (at
> which point you will also want to add the expansion of the CCS
> acronym in the description).
Thanks for your comment. I misunderstand re-base. Now I send a new one.
>
> Jan
BR
MayShao
[-- Attachment #2: 0001-x86-Add-CpuGMISM2-and-CpuGMICCS_v3.patch --]
[-- Type: application/octet-stream, Size: 4654 bytes --]
From 374c5706ee00afc3767c67f15da01d8f8cbe1ef1 Mon Sep 17 00:00:00 2001
From: MayShao-oc <MayShao-oc@zhaoxin.com>
Date: Fri, 17 Jan 2025 19:05:15 +0800
Subject: [PATCH] x86: Add CpuGMISM2 and CpuGMICCS
Hi all:
There are separate CPUID feature bits for SM2 and CCS instructions.
CCS is the acronym of chinese cipher system, it includes SM3 and SM4
instructions. This patch adds CpuGMISM2 and CpuGMICCS to replace CpuGMI on
corresponding instructions.
BR
MayShao
gas/ChangeLog:
* config/tc-i386.c: Add gmism2 and gmiccs to replace gmi.
* doc/c-i386.texi: Ditto.
opcodes/ChangeLog:
* i386-gen.c: Add GMISM2 and GMICCS to replace GMI.
* i386-opc.h (enum i386_cpu): Add CpuGMISM2 and CpuGMICCS to
replace CpuGMI.
* i386-opc.tbl: Replace GMI with GMISM2 on sm2 instruction. Replace GMI
with GMICCS on sm3 and sm4 instructions.
* i386-tbl.h: Regenerated.
* i386-mnem.h: Ditto.
* i386-init.h: Ditto.
---
gas/config/tc-i386.c | 3 ++-
gas/doc/c-i386.texi | 7 ++++---
opcodes/i386-gen.c | 3 ++-
opcodes/i386-opc.h | 9 ++++++---
opcodes/i386-opc.tbl | 10 ++++++----
5 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c
index ea370071282..6ca28d7cee1 100644
--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -1225,7 +1225,8 @@ static const arch_entry cpu_arch[] =
SUBARCH (user_msr, USER_MSR, USER_MSR, false),
SUBARCH (apx_f, APX_F, APX_F, false),
VECARCH (avx10.2, AVX10_2, ANY_AVX10_2, set),
- SUBARCH (gmi, GMI, GMI, false),
+ SUBARCH (gmism2, GMISM2, GMISM2, false),
+ SUBARCH (gmiccs, GMICCS, GMICCS, false),
SUBARCH (msr_imm, MSR_IMM, MSR_IMM, false),
SUBARCH (padlockrng2, PADLOCKRNG2, PADLOCKRNG2, false),
SUBARCH (padlockphe2, PADLOCKPHE2, PADLOCKPHE2, false),
diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi
index 06bef9048c5..723dbef1c37 100644
--- a/gas/doc/c-i386.texi
+++ b/gas/doc/c-i386.texi
@@ -282,7 +282,8 @@ accept various extension mnemonics. For example,
@code{invlpgb},
@code{tlbsync},
@code{svme},
-@code{gmi},
+@code{gmism2},
+@code{gmiccs},
@code{padlockrng2},
@code{padlockphe2} and
@code{padlock}.
@@ -1718,8 +1719,8 @@ supported on the CPU specified. The choices for @var{cpu_type} are:
@item @samp{.lwp} @tab @samp{.fma4} @tab @samp{.xop} @tab @samp{.cx16}
@item @samp{.padlock} @tab @samp{.clzero} @tab @samp{.mwaitx} @tab @samp{.rdpru}
@item @samp{.mcommit} @tab @samp{.sev_es} @tab @samp{.snp} @tab @samp{.invlpgb}
-@item @samp{.tlbsync} @tab @samp{.apx_f} @tab @samp{.gmi} @tab @samp{.padlockrng2}
-@item @samp{.padlockphe2}
+@item @samp{.tlbsync} @tab @samp{.apx_f} @tab @samp{.gmism2} @samp{.gmiccs}
+@item @samp{.padlockrng2} @samp{.padlockphe2}
@end multitable
diff --git a/opcodes/i386-gen.c b/opcodes/i386-gen.c
index d2d9b5de006..ae23734156d 100644
--- a/opcodes/i386-gen.c
+++ b/opcodes/i386-gen.c
@@ -352,7 +352,8 @@ static bitfield cpu_flags[] =
BITFIELD (3dnow),
BITFIELD (3dnowA),
BITFIELD (PadLock),
- BITFIELD (GMI),
+ BITFIELD (GMISM2),
+ BITFIELD (GMICCS),
BITFIELD (PadLockRNG2),
BITFIELD (PadLockPHE2),
BITFIELD (SVME),
diff --git a/opcodes/i386-opc.h b/opcodes/i386-opc.h
index c4751130d29..8ce850ee713 100644
--- a/opcodes/i386-opc.h
+++ b/opcodes/i386-opc.h
@@ -66,8 +66,10 @@ enum i386_cpu
CpuSSE3,
/* VIA PadLock required */
CpuPadLock,
- /* Zhaoxin GMI required */
- CpuGMI,
+ /* Zhaoxin GMI SM2 required */
+ CpuGMISM2,
+ /* Zhaoxin GMI CCS required */
+ CpuGMICCS,
/* Zhaoxin PadLock RNG2 required */
CpuPadLockRNG2,
/* Zhaoxin PadLock PHE2 required */
@@ -422,7 +424,8 @@ typedef union i386_cpu_flags
unsigned int cpusse2:1;
unsigned int cpusse3:1;
unsigned int cpupadlock:1;
- unsigned int cpugmi:1;
+ unsigned int cpugmism2:1;
+ unsigned int cpugmiccs:1;
unsigned int cpupadlockrng2:1;
unsigned int cpupadlockphe2:1;
unsigned int cpusvme:1;
diff --git a/opcodes/i386-opc.tbl b/opcodes/i386-opc.tbl
index 8b1d155941d..06b1a9d8bdf 100644
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -2134,10 +2134,12 @@ xcryptofb, 0xf30fa7e8, PadLock, NoSuf|RepPrefixOk, {}
// Alias for xstore-rng.
xstore, 0xfa7c0, PadLock, NoSuf|RepPrefixOk, {}
-// Zhaoxin GMI instructions
-sm2, 0xf20fa6c0, GMI, NoSuf, {}
-sm3, 0xf30fa6e8, GMI, NoSuf, {}
-sm4, 0xf30fa7f0, GMI, NoSuf, {}
+// Zhaoxin GMI SM2 instruction
+sm2, 0xf20fa6c0, GMISM2, NoSuf, {}
+
+// Zhaoxin GMI CCS instructions
+sm3, 0xf30fa6e8, GMICCS, NoSuf, {}
+sm4, 0xf30fa7f0, GMICCS, NoSuf, {}
// Zhaoxin PadLock RNG2 instruction
xrng2, 0xf30fa7f8, PadLockRNG2, NoSuf|RepPrefixOk, {}
--
2.27.0
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] x86: Support Zhaoxin PadLock XMODX instructions
2025-01-17 9:00 ` [PATCH] x86: Support Zhaoxin PadLock XMODX instructions Mayshao-oc
@ 2025-01-20 9:41 ` Jan Beulich
2025-01-22 2:50 ` Mayshao-oc
2025-01-22 2:52 ` [PATCH] x86: Add the @tab to separate columns in c-i386.texi Mayshao-oc
0 siblings, 2 replies; 80+ messages in thread
From: Jan Beulich @ 2025-01-20 9:41 UTC (permalink / raw)
To: Mayshao-oc, Nick Clifton
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen, H.J. Lu
On 17.01.2025 10:00, Mayshao-oc wrote:
> This patch adds support for Zhaoxin XMODX instructions.
> The CPUID EDX bit[28] indicates its enablement, and it includes REP
> XMODEXP and REP MONTMUL2. XMODX stands for modular exponentiation, it indicates
> the support of modular exponentiation feature, both REP XMODEXP and
> REP MONTMUL2 use it.
> Test ok, ok for trunk?
Looks good to me, except there's a possible issue with the gas/NEWS entry:
As you were likely aware up front, the 2.44 branch was created over the
weekend. Generally I wouldn't expect late feature additions to still be
eligible to go on the branch; Nick, do you concur? If so, the existing
entry may not be altered, and a new one (for 2.45) would need creating
instead. (Once this is settled, I'd be okay making the adjustment [if
necessary] while committing the change on your behalf.)
Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] x86: Support Zhaoxin PadLock XMODX instructions
2025-01-20 9:41 ` Jan Beulich
@ 2025-01-22 2:50 ` Mayshao-oc
2025-01-22 7:43 ` Jan Beulich
2025-01-22 2:52 ` [PATCH] x86: Add the @tab to separate columns in c-i386.texi Mayshao-oc
1 sibling, 1 reply; 80+ messages in thread
From: Mayshao-oc @ 2025-01-22 2:50 UTC (permalink / raw)
To: Jan Beulich, Nick Clifton
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen, H.J. Lu
> On 17.01.2025 10:00, Mayshao-oc wrote:
> > This patch adds support for Zhaoxin XMODX instructions.
> > The CPUID EDX bit[28] indicates its enablement, and it includes
> > REP XMODEXP and REP MONTMUL2. XMODX stands for modular exponentiation,
> > it indicates the support of modular exponentiation feature, both REP
> > XMODEXP and REP MONTMUL2 use it.
> > Test ok, ok for trunk?
>
> Looks good to me, except there's a possible issue with the gas/NEWS entry:
> As you were likely aware up front, the 2.44 branch was created over the weekend. Generally I wouldn't expect late feature additions to still be eligible to go on the branch; Nick, do you concur? If so, the existing entry may not be altered, and a new one (for 2.45) would need creating instead. (Once this is settled, I'd be okay making the adjustment [if necessary] while committing the change on your behalf.)
Thanks for your comment. I appreciate you could commit the change on my behalf after the possible issue is settled.
>
> Jan
BR
MayShao
^ permalink raw reply [flat|nested] 80+ messages in thread
* [PATCH] x86: Add the @tab to separate columns in c-i386.texi
2025-01-20 9:41 ` Jan Beulich
2025-01-22 2:50 ` Mayshao-oc
@ 2025-01-22 2:52 ` Mayshao-oc
2025-01-22 7:41 ` Jan Beulich
1 sibling, 1 reply; 80+ messages in thread
From: Mayshao-oc @ 2025-01-22 2:52 UTC (permalink / raw)
To: Jan Beulich, Nick Clifton
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen, H.J. Lu
[-- Attachment #1: Type: text/plain, Size: 99 bytes --]
Hi all:
I have missed @tab for .gmiccs and .padlockphe2, so fix this doc error.
BR
MayShao
[-- Attachment #2: 0001-Add-the-tab.patch --]
[-- Type: application/octet-stream, Size: 1248 bytes --]
From 81487a54f12eee23ab0bedb0474e5c08fe1aab6e Mon Sep 17 00:00:00 2001
From: timhu2011 <hudi2011@163.com>
Date: Wed, 22 Jan 2025 10:15:46 +0800
Subject: [PATCH] x86: Add the @tab to separate columns in c-i386.texi
Hi all:
I have missed @tab for .gmiccs and .padlockphe2, so fix this doc error.
BR
MayShao
gas/ChangeLog:
* doc/c-i386.texi: Add the missing @tab for .gmiccs and
.padlockphe2
---
gas/doc/c-i386.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi
index 723dbef1c37..d8a9e69b39e 100644
--- a/gas/doc/c-i386.texi
+++ b/gas/doc/c-i386.texi
@@ -1719,8 +1719,8 @@ supported on the CPU specified. The choices for @var{cpu_type} are:
@item @samp{.lwp} @tab @samp{.fma4} @tab @samp{.xop} @tab @samp{.cx16}
@item @samp{.padlock} @tab @samp{.clzero} @tab @samp{.mwaitx} @tab @samp{.rdpru}
@item @samp{.mcommit} @tab @samp{.sev_es} @tab @samp{.snp} @tab @samp{.invlpgb}
-@item @samp{.tlbsync} @tab @samp{.apx_f} @tab @samp{.gmism2} @samp{.gmiccs}
-@item @samp{.padlockrng2} @samp{.padlockphe2}
+@item @samp{.tlbsync} @tab @samp{.apx_f} @tab @samp{.gmism2} @tab @samp{.gmiccs}
+@item @samp{.padlockrng2} @tab @samp{.padlockphe2}
@end multitable
--
2.47.1
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] x86: Add the @tab to separate columns in c-i386.texi
2025-01-22 2:52 ` [PATCH] x86: Add the @tab to separate columns in c-i386.texi Mayshao-oc
@ 2025-01-22 7:41 ` Jan Beulich
0 siblings, 0 replies; 80+ messages in thread
From: Jan Beulich @ 2025-01-22 7:41 UTC (permalink / raw)
To: Mayshao-oc, Nick Clifton
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen, H.J. Lu
On 22.01.2025 03:52, Mayshao-oc wrote:
> I have missed @tab for .gmiccs and .padlockphe2, so fix this doc error.
Thanks, applied. However, a more general remark, in particular when you
need your patches be applied by others: Can you please aim at submitting
patches with their descriptions written like patch descriptions, not like
ordinary emails? For example, patch descriptions don't normally start
with "Hi all", and they also don't end in "BR" and your name or anything
alike. You want to make applying your patches as simple as possible, i.e.
preferably save the committer from any editing whatsoever.
Nick, I've taken the liberty to also put this on the branch without your
explicit consent.
Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] x86: Support Zhaoxin PadLock XMODX instructions
2025-01-22 2:50 ` Mayshao-oc
@ 2025-01-22 7:43 ` Jan Beulich
2025-02-06 3:18 ` Mayshao-oc
0 siblings, 1 reply; 80+ messages in thread
From: Jan Beulich @ 2025-01-22 7:43 UTC (permalink / raw)
To: Mayshao-oc
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen, H.J. Lu, Nick Clifton
On 22.01.2025 03:50, Mayshao-oc wrote:
>> On 17.01.2025 10:00, Mayshao-oc wrote:
>>> This patch adds support for Zhaoxin XMODX instructions.
>>> The CPUID EDX bit[28] indicates its enablement, and it includes
>>> REP XMODEXP and REP MONTMUL2. XMODX stands for modular exponentiation,
>>> it indicates the support of modular exponentiation feature, both REP
>>> XMODEXP and REP MONTMUL2 use it.
>>> Test ok, ok for trunk?
>>
>> Looks good to me, except there's a possible issue with the gas/NEWS entry:
>> As you were likely aware up front, the 2.44 branch was created over the weekend. Generally I wouldn't expect late feature additions to still be eligible to go on the branch; Nick, do you concur? If so, the existing entry may not be altered, and a new one (for 2.45) would need creating instead. (Once this is settled, I'd be okay making the adjustment [if necessary] while committing the change on your behalf.)
> Thanks for your comment. I appreciate you could commit the change on my behalf after the possible issue is settled.
Hmm, looking at it I fear the patch won't even apply anymore. Please
re-submit a re-based version (also taking into account my comment
from a minute ago regarding patch descriptions).
Jan
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: [PATCH] x86: Support Zhaoxin PadLock XMODX instructions
2025-01-22 7:43 ` Jan Beulich
@ 2025-02-06 3:18 ` Mayshao-oc
0 siblings, 0 replies; 80+ messages in thread
From: Mayshao-oc @ 2025-02-06 3:18 UTC (permalink / raw)
To: Jan Beulich
Cc: Tim Hu(WH-RD), Louis Qi(BJ-RD), Cobe Chen(BJ-RD),
binutils, Jiang, Haochen, H.J. Lu, Nick Clifton
[-- Attachment #1: Type: text/plain, Size: 1479 bytes --]
> On 22.01.2025 03:50, Mayshao-oc wrote:
> >> On 17.01.2025 10:00, Mayshao-oc wrote:
> >>> This patch adds support for Zhaoxin XMODX instructions.
> >>> The CPUID EDX bit[28] indicates its enablement, and it includes
> >>> REP XMODEXP and REP MONTMUL2. XMODX stands for modular
> >>> exponentiation, it indicates the support of modular exponentiation
> >>> feature, both REP XMODEXP and REP MONTMUL2 use it.
> >>> Test ok, ok for trunk?
> >>
> >> Looks good to me, except there's a possible issue with the gas/NEWS entry:
> >> As you were likely aware up front, the 2.44 branch was created over
> >> the weekend. Generally I wouldn't expect late feature additions to
> >> still be eligible to go on the branch; Nick, do you concur? If so,
> >> the existing entry may not be altered, and a new one (for 2.45) would
> >> need creating instead. (Once this is settled, I'd be okay making the
> >> adjustment [if necessary] while committing the change on your
> >> behalf.)
> > Thanks for your comment. I appreciate you could commit the change on my behalf after the possible issue is settled.
>
> Hmm, looking at it I fear the patch won't even apply anymore. Please re-submit a re-based version (also taking into account my comment from a minute ago regarding patch descriptions).
Thanks for your patience. I will not include unnecessary words in the patch descriptions any more. I resubmit a re-based version.
>
> Jan
BR
MayShao
[-- Attachment #2: 0001-x86-Support-x86-Zhaoxin-PadLock-XMODX-instructions_v2.patch --]
[-- Type: application/octet-stream, Size: 7940 bytes --]
From a0bd2b7c292f84294f763b50a77c9581b73a5e5e Mon Sep 17 00:00:00 2001
From: MayShao-oc <MayShao-oc@zhaoxin.com>
Date: Thu, 6 Feb 2025 10:22:44 +0800
Subject: [PATCH] x86: Support x86 Zhaoxin PadLock XMODX instructions
The CPUID EDX bit[28] indicates its enablement, and it includes REP
XMODEXP and REP MONTMUL2. XMODX stands for modular exponentiation, it indicates
the support of modular exponentiation feature, both REP XMODEXP and
REP MONTMUL2 use it.
gas/ChangeLog:
* NEWS: Support Zhaoxin PadLock XMODX instructions.
* config/tc-i386.c (add_branch_prefix_frag_p): Don't add prefix to
PadLockXMODX instructions.
(output_insn): Handle PadLockXMODX instructions.
* doc/c-i386.texi: Document PadLockXMODX.
* testsuite/gas/i386/i386.exp: Add PadLockXMODX test.
* testsuite/gas/i386/padlockxmodx.d: Ditto.
* testsuite/gas/i386/padlockxmodx.s: Ditto.
opcodes/ChangeLog:
* i386-dis.c: Add PadLockXMODX.
* i386-gen.c: Ditto
* i386-opc.h (CpuPadLockXMODX): New.
* i386-opc.tbl: Add Zhaoxin PadLock XMODX instructions.
* i386-tbl.h: Regenerated.
* i386-mnem.h: Ditto.
* i386-init.h: Ditto.
---
gas/NEWS | 2 ++
gas/config/tc-i386.c | 5 ++++-
gas/doc/c-i386.texi | 4 +++-
gas/testsuite/gas/i386/i386.exp | 1 +
gas/testsuite/gas/i386/padlockxmodx.d | 13 +++++++++++++
gas/testsuite/gas/i386/padlockxmodx.s | 9 +++++++++
opcodes/i386-dis.c | 2 ++
opcodes/i386-gen.c | 3 +++
opcodes/i386-opc.h | 3 +++
opcodes/i386-opc.tbl | 4 ++++
10 files changed, 44 insertions(+), 2 deletions(-)
create mode 100644 gas/testsuite/gas/i386/padlockxmodx.d
create mode 100644 gas/testsuite/gas/i386/padlockxmodx.s
diff --git a/gas/NEWS b/gas/NEWS
index 70f3ad40dba..6c5af12178f 100644
--- a/gas/NEWS
+++ b/gas/NEWS
@@ -1,5 +1,7 @@
-*- text -*-
+* Add support for the x86 Zhaoxin PadLock XMODX instructions.
+
Changes in 2.44:
* Add support for the x86 Intel Diamond Rapids AMX instructions, including
diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c
index 2b5f07519f9..62058f7e993 100644
--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -1230,6 +1230,7 @@ static const arch_entry cpu_arch[] =
SUBARCH (msr_imm, MSR_IMM, MSR_IMM, false),
SUBARCH (padlockrng2, PADLOCKRNG2, PADLOCKRNG2, false),
SUBARCH (padlockphe2, PADLOCKPHE2, PADLOCKPHE2, false),
+ SUBARCH (padlockxmodx, PADLOCKXMODX, PADLOCKXMODX, false),
SUBARCH (movrs, MOVRS, MOVRS, false),
};
@@ -12048,6 +12049,7 @@ add_branch_prefix_frag_p (const struct last_insn *last_insn)
|| is_cpu (&i.tm, CpuPadLock)
|| is_cpu (&i.tm, CpuPadLockRNG2)
|| is_cpu (&i.tm, CpuPadLockPHE2)
+ || is_cpu (&i.tm, CpuPadLockXMODX)
|| !cpu_arch_flags.bitfield.cpui386)
return 0;
@@ -12424,7 +12426,8 @@ output_insn (const struct last_insn *last_insn)
case PREFIX_0XF3:
if ((!is_cpu (&i.tm, CpuPadLock)
&& !is_cpu (&i.tm, CpuPadLockRNG2)
- && !is_cpu (&i.tm, CpuPadLockPHE2))
+ && !is_cpu (&i.tm, CpuPadLockPHE2)
+ && !is_cpu (&i.tm, CpuPadLockXMODX))
|| (i.prefix[REP_PREFIX] != 0xf3))
add_prefix (0xf3);
break;
diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi
index 7b24cbf1ddb..d488703a6e7 100644
--- a/gas/doc/c-i386.texi
+++ b/gas/doc/c-i386.texi
@@ -287,7 +287,8 @@ accept various extension mnemonics. For example,
@code{gmism2},
@code{gmiccs},
@code{padlockrng2},
-@code{padlockphe2} and
+@code{padlockphe2},
+@code{padlockxmodx} and
@code{padlock}.
Note that these extension mnemonics can be prefixed with @code{no} to revoke
the respective (and any dependent) functionality. Note further that the
@@ -1723,6 +1724,7 @@ supported on the CPU specified. The choices for @var{cpu_type} are:
@item @samp{.mcommit} @tab @samp{.sev_es} @tab @samp{.snp} @tab @samp{.invlpgb}
@item @samp{.tlbsync} @tab @samp{.rmpquery} @tab @samp{.rmpread} @tab @samp{.apx_f}
@item @samp{.gmism2} @tab @samp{.gmiccs} @tab @samp{.padlockrng2} @tab @samp{.padlockphe2}
+@item @samp{.padlockxmodx}
@end multitable
diff --git a/gas/testsuite/gas/i386/i386.exp b/gas/testsuite/gas/i386/i386.exp
index b4d33cc7500..34d0a2fab8c 100644
--- a/gas/testsuite/gas/i386/i386.exp
+++ b/gas/testsuite/gas/i386/i386.exp
@@ -117,6 +117,7 @@ if [gas_32_check] then {
run_dump_test "gmi"
run_dump_test "padlockrng2"
run_dump_test "padlockphe2"
+ run_dump_test "padlockxmodx"
run_dump_test "crx"
run_list_test "cr-err" ""
run_dump_test "cdr"
diff --git a/gas/testsuite/gas/i386/padlockxmodx.d b/gas/testsuite/gas/i386/padlockxmodx.d
new file mode 100644
index 00000000000..9184d2c7426
--- /dev/null
+++ b/gas/testsuite/gas/i386/padlockxmodx.d
@@ -0,0 +1,13 @@
+#objdump: -dw
+#name: Zhaoxin PadLock XMODX
+
+.*: +file format .*
+
+Disassembly of section .text:
+
+0+000 <foo>:
+ 0:[ ]*f3 0f a6 f0 [ ]*repz montmul2
+ 4:[ ]*f3 0f a6 f0 [ ]*repz montmul2
+ 8:[ ]*f3 0f a6 f8 [ ]*repz xmodexp
+ c:[ ]*f3 0f a6 f8 [ ]*repz xmodexp
+#pass
diff --git a/gas/testsuite/gas/i386/padlockxmodx.s b/gas/testsuite/gas/i386/padlockxmodx.s
new file mode 100644
index 00000000000..4092fa539fd
--- /dev/null
+++ b/gas/testsuite/gas/i386/padlockxmodx.s
@@ -0,0 +1,9 @@
+# Zhaoxin PadLock XMODX instructions
+
+ .text
+foo:
+ montmul2
+ rep montmul2
+ xmodexp
+ rep xmodexp
+ .p2align 4,0
diff --git a/opcodes/i386-dis.c b/opcodes/i386-dis.c
index cc5448b2784..9cf6de4dbf5 100644
--- a/opcodes/i386-dis.c
+++ b/opcodes/i386-dis.c
@@ -2977,6 +2977,8 @@ static const struct dis386 reg_table[][8] = {
{ "xsha384", { { OP_0f07, 0 } }, 0 },
{ "xsha512", { { OP_0f07, 0 } }, 0 },
{ PREFIX_TABLE (PREFIX_0FA6_REG_5) },
+ { "montmul2", { { OP_0f07, 0 } }, 0 },
+ { "xmodexp", { { OP_0f07, 0 } }, 0 },
},
/* REG_0FA7 */
{
diff --git a/opcodes/i386-gen.c b/opcodes/i386-gen.c
index 3cc0352064c..bd3cd8fd774 100644
--- a/opcodes/i386-gen.c
+++ b/opcodes/i386-gen.c
@@ -301,6 +301,8 @@ static const dependency isa_dependencies[] =
"PadLock" },
{ "PadLockPHE2",
"PadLock" },
+ { "PadLockXMODX",
+ "PadLock" },
};
/* This array is populated as process_i386_initializers() walks cpu_flags[]. */
@@ -358,6 +360,7 @@ static bitfield cpu_flags[] =
BITFIELD (GMICCS),
BITFIELD (PadLockRNG2),
BITFIELD (PadLockPHE2),
+ BITFIELD (PadLockXMODX),
BITFIELD (SVME),
BITFIELD (VMX),
BITFIELD (SMX),
diff --git a/opcodes/i386-opc.h b/opcodes/i386-opc.h
index 5ba84c8ff8d..f861cdc4e50 100644
--- a/opcodes/i386-opc.h
+++ b/opcodes/i386-opc.h
@@ -74,6 +74,8 @@ enum i386_cpu
CpuPadLockRNG2,
/* Zhaoxin PadLock PHE2 required */
CpuPadLockPHE2,
+ /* Zhaoxin PadLock XMODX required */
+ CpuPadLockXMODX,
/* AMD Secure Virtual Machine Ext-s required */
CpuSVME,
/* VMX Instructions required */
@@ -430,6 +432,7 @@ typedef union i386_cpu_flags
unsigned int cpugmiccs:1;
unsigned int cpupadlockrng2:1;
unsigned int cpupadlockphe2:1;
+ unsigned int cpupadlockxmodx:1;
unsigned int cpusvme:1;
unsigned int cpuvmx:1;
unsigned int cpusmx:1;
diff --git a/opcodes/i386-opc.tbl b/opcodes/i386-opc.tbl
index d9e5acd3438..5b26fe8be46 100644
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -2148,6 +2148,10 @@ xrng2, 0xf30fa7f8, PadLockRNG2, NoSuf|RepPrefixOk, {}
xsha384, 0xf30fa6d8, PadLockPHE2, NoSuf|RepPrefixOk, {}
xsha512, 0xf30fa6e0, PadLockPHE2, NoSuf|RepPrefixOk, {}
+// Zhaoxin PadLock XMODX instructions
+montmul2, 0xf30fa6f0, PadLockXMODX, NoSuf|RepPrefixOk, {}
+xmodexp, 0xf30fa6f8, PadLockXMODX, NoSuf|RepPrefixOk, {}
+
// Multy-precision Add Carry, rdseed instructions.
<adx:pfx, c:66, o:f3>
ad<adx>x, 0x<adx:pfx>66, ADX&APX_F, C|Modrm|CheckOperandSize|No_bSuf|No_wSuf|No_sSuf|DstVVVV|EVexMap4, { Reg32|Reg64|Unspecified|BaseIndex, Reg32|Reg64, Reg32|Reg64 }
--
2.27.0
^ permalink raw reply [flat|nested] 80+ messages in thread
end of thread, other threads:[~2025-02-06 6:33 UTC | newest]
Thread overview: 80+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-10-14 2:03 [PATCH v1] x86: Support ZHAOXIN GMI instructions mayshao-oc
2024-10-14 3:09 ` Jiang, Haochen
2024-10-14 3:28 ` mayshao-oc
2024-10-14 3:37 ` Jiang, Haochen
2024-10-14 6:13 ` Jan Beulich
2024-10-14 6:54 ` Jan Beulich
2024-10-14 8:37 ` Jiang, Haochen
2024-10-14 9:05 ` mayshao-oc
2024-10-14 10:16 ` Jan Beulich
2024-10-15 1:19 ` [PATCH v2] " mayshao-oc
2024-10-15 3:02 ` Jiang, Haochen
2024-10-15 5:53 ` Jan Beulich
2024-10-15 7:32 ` [PATCH v3] " mayshao-oc
2024-10-15 6:51 ` [PATCH v2] " mayshao-oc
2024-10-15 11:18 ` Jan Beulich
2024-10-15 11:44 ` mayshao-oc
2024-10-16 6:47 ` Jan Beulich
2024-10-16 7:48 ` mayshao-oc
2024-10-16 9:22 ` Jan Beulich
2024-10-17 2:17 ` mayshao-oc
2024-10-17 5:35 ` Jan Beulich
2024-10-18 0:15 ` mayshao-oc
2024-10-18 7:38 ` Jiang, Haochen
2024-10-18 7:47 ` Jiang, Haochen
2024-10-18 7:59 ` [committed][PATCH] x86: Regenerate missing table files (was RE: [PATCH v2] x86: Support ZHAOXIN GMI instructions) Jiang, Haochen
2024-10-18 11:19 ` [PATCH v2] x86: Support ZHAOXIN GMI instructions Jan Beulich
2024-10-21 5:45 ` Jiang, Haochen
2024-10-18 8:08 ` mayshao-oc
2024-10-16 2:08 ` Jiang, Haochen
2024-12-13 3:25 ` [PATCH v1] x86: Support ZHAOXIN padlock instructions Mayshao-oc
2024-12-13 8:50 ` Jiang, Haochen
2024-12-16 6:48 ` Mayshao-oc
2024-12-16 7:17 ` Jiang, Haochen
2024-12-17 2:56 ` Mayshao-oc
2024-12-16 7:03 ` [PATCH v1] x86: Change padlock instructions prefix as rep Mayshao-oc
2024-12-19 10:26 ` Jan Beulich
2024-12-24 1:57 ` Mayshao-oc
2024-12-19 10:33 ` [PATCH v1] x86: Support ZHAOXIN padlock instructions Jan Beulich
2024-12-24 1:59 ` Mayshao-oc
2024-12-27 11:31 ` Jan Beulich
2024-12-30 9:18 ` Mayshao-oc
2024-12-30 9:20 ` [PATCH v1] x86: Support Zhaoxin RNG2 instruction Mayshao-oc
2025-01-06 8:53 ` Ping for " Mayshao-oc
2025-01-06 9:11 ` Jan Beulich
2025-01-06 10:36 ` Mayshao-oc
2025-01-06 15:52 ` Jan Beulich
2025-01-07 3:08 ` Mayshao-oc
2025-01-07 8:34 ` Jan Beulich
2025-01-07 11:04 ` Mayshao-oc
2025-01-08 3:29 ` Jiang, Haochen
2025-01-08 9:38 ` Mayshao-oc
2025-01-08 11:30 ` Jan Beulich
2025-01-09 2:05 ` Jiang, Haochen
2025-01-08 7:06 ` Jan Beulich
2025-01-08 9:40 ` Mayshao-oc
2025-01-08 9:46 ` [PATCH v2] x86: Support Zhaoxin PadLock " Mayshao-oc
2025-01-09 12:15 ` Jan Beulich
2025-01-13 2:17 ` Mayshao-oc
2025-01-14 6:46 ` [PATCH] x86: Add CpuGMISM2 and CpuGMICCS Mayshao-oc
2025-01-15 14:40 ` Jan Beulich
2025-01-16 1:51 ` Jiang, Haochen
2025-01-16 6:54 ` Mayshao-oc
2025-01-17 9:07 ` Mayshao-oc
2025-01-16 6:53 ` Mayshao-oc
2025-01-17 8:58 ` Mayshao-oc
2025-01-17 9:36 ` Jan Beulich
2025-01-17 10:03 ` Mayshao-oc
2025-01-17 11:19 ` Mayshao-oc
2025-01-15 8:06 ` [PATCH] x86: Support Zhaoxin PadLock PHE2 instructions Mayshao-oc
2025-01-15 14:45 ` Jan Beulich
2025-01-16 6:52 ` Mayshao-oc
2025-01-17 9:00 ` [PATCH] x86: Support Zhaoxin PadLock XMODX instructions Mayshao-oc
2025-01-20 9:41 ` Jan Beulich
2025-01-22 2:50 ` Mayshao-oc
2025-01-22 7:43 ` Jan Beulich
2025-02-06 3:18 ` Mayshao-oc
2025-01-22 2:52 ` [PATCH] x86: Add the @tab to separate columns in c-i386.texi Mayshao-oc
2025-01-22 7:41 ` Jan Beulich
2025-01-08 11:31 ` [PATCH v1] x86: Support Zhaoxin RNG2 instruction Jan Beulich
2024-10-15 1:31 ` [PATCH v1] x86: Support ZHAOXIN GMI instructions mayshao-oc
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).