public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Cui, Lili" <lili.cui@intel.com>
To: "Beulich, Jan" <JBeulich@suse.com>
Cc: "Lu, Hongjiu" <hongjiu.lu@intel.com>,
	"ccoutant@gmail.com" <ccoutant@gmail.com>,
	"binutils@sourceware.org" <binutils@sourceware.org>,
	"Kong, Lingling" <lingling.kong@intel.com>
Subject: RE: [PATCH 5/8] Support APX NDD
Date: Wed, 22 Nov 2023 07:46:42 +0000	[thread overview]
Message-ID: <SJ0PR11MB5600C493097322A426D5E76A9EBAA@SJ0PR11MB5600.namprd11.prod.outlook.com> (raw)
In-Reply-To: <ff44c134-6e1a-4bd2-86aa-1aec280efb21@suse.com>

> >>> --- a/opcodes/i386-dis-evex.h
> >>> +++ b/opcodes/i386-dis-evex.h
> >>> [...]
> >>> @@ -947,23 +947,23 @@ static const struct dis386 evex_table[][256] = {
> >>>      { Bad_Opcode },
> >>>      { Bad_Opcode },
> >>>      /* 40 */
> >>> -    { Bad_Opcode },
> >>> -    { Bad_Opcode },
> >>> -    { Bad_Opcode },
> >>> -    { Bad_Opcode },
> >>> -    { Bad_Opcode },
> >>> -    { Bad_Opcode },
> >>> -    { Bad_Opcode },
> >>> -    { Bad_Opcode },
> >>> +    { "cmovoS",		{ VexGv, Gv, Ev }, 0 },
> >>> +    { "cmovnoS",	{ VexGv, Gv, Ev }, 0 },
> >>> +    { "cmovbS",		{ VexGv, Gv, Ev }, 0 },
> >>> +    { "cmovaeS",	{ VexGv, Gv, Ev }, 0 },
> >>> +    { "cmoveS",		{ VexGv, Gv, Ev }, 0 },
> >>> +    { "cmovneS",	{ VexGv, Gv, Ev }, 0 },
> >>> +    { "cmovbeS",	{ VexGv, Gv, Ev }, 0 },
> >>> +    { "cmovaS",		{ VexGv, Gv, Ev }, 0 },
> >>>      /* 48 */
> >>> -    { Bad_Opcode },
> >>> -    { Bad_Opcode },
> >>> -    { Bad_Opcode },
> >>> -    { Bad_Opcode },
> >>> -    { Bad_Opcode },
> >>> -    { Bad_Opcode },
> >>> -    { Bad_Opcode },
> >>> -    { Bad_Opcode },
> >>> +    { "cmovsS",		{ VexGv, Gv, Ev }, 0 },
> >>> +    { "cmovnsS",	{ VexGv, Gv, Ev }, 0 },
> >>> +    { "cmovpS",		{ VexGv, Gv, Ev }, 0 },
> >>> +    { "cmovnpS",	{ VexGv, Gv, Ev }, 0 },
> >>> +    { "cmovlS",		{ VexGv, Gv, Ev }, 0 },
> >>> +    { "cmovgeS",	{ VexGv, Gv, Ev }, 0 },
> >>> +    { "cmovleS",	{ VexGv, Gv, Ev }, 0 },
> >>> +    { "cmovgS",		{ VexGv, Gv, Ev }, 0 },
> >>
> >> Considering CFCMOVcc which sits at the same opcode, doing things like
> >> this sets us up for needing to touch all of these again. Maybe that's
> >> the best that can be done, but I still wonder whether this couldn't
> >> be taken care of right away when introducing these entries.
> >
> > How about adding a special letter %CF in front of them?
> 
> Why not.
>

Done.
 
> >>> --- a/opcodes/i386-dis.c
> >>> +++ b/opcodes/i386-dis.c
> >>> [...]
> >>> @@ -2660,47 +2668,47 @@ static const struct dis386 reg_table[][8] = {
> >>>    },
> >>>    /* REG_D0 */
> >>>    {
> >>> -    { "rolA",	{ Eb, I1 }, 0 },
> >>> -    { "rorA",	{ Eb, I1 }, 0 },
> >>> -    { "rclA",	{ Eb, I1 }, 0 },
> >>> -    { "rcrA",	{ Eb, I1 }, 0 },
> >>> -    { "shlA",	{ Eb, I1 }, 0 },
> >>> -    { "shrA",	{ Eb, I1 }, 0 },
> >>> -    { "shlA",	{ Eb, I1 }, 0 },
> >>> -    { "sarA",	{ Eb, I1 }, 0 },
> >>> +    { "rolA",	{ VexGb, Eb, I1 }, 0 },
> >>> +    { "rorA",	{ VexGb, Eb, I1 }, 0 },
> >>> +    { "rclA",	{ VexGb, Eb, I1 }, 0 },
> >>> +    { "rcrA",	{ VexGb, Eb, I1 }, 0 },
> >>> +    { "shlA",	{ VexGb, Eb, I1 }, 0 },
> >>> +    { "shrA",	{ VexGb, Eb, I1 }, 0 },
> >>> +    { "shlA",	{ VexGb, Eb, I1 }, 0 },
> >>> +    { "sarA",	{ VexGb, Eb, I1 }, 0 },
> >>>    },
> >>>    /* REG_D1 */
> >>>    {
> >>> -    { "rolQ",	{ Ev, I1 }, 0 },
> >>> -    { "rorQ",	{ Ev, I1 }, 0 },
> >>> -    { "rclQ",	{ Ev, I1 }, 0 },
> >>> -    { "rcrQ",	{ Ev, I1 }, 0 },
> >>> -    { "shlQ",	{ Ev, I1 }, 0 },
> >>> -    { "shrQ",	{ Ev, I1 }, 0 },
> >>> -    { "shlQ",	{ Ev, I1 }, 0 },
> >>> -    { "sarQ",	{ Ev, I1 }, 0 },
> >>> +    { "rolQ",	{ VexGv, Ev, I1 }, 0 },
> >>> +    { "rorQ",	{ VexGv, Ev, I1 }, 0 },
> >>> +    { "rclQ",	{ VexGv, Ev, I1 }, 0 },
> >>> +    { "rcrQ",	{ VexGv, Ev, I1 }, 0 },
> >>> +    { "shlQ",	{ VexGv, Ev, I1 }, 0 },
> >>> +    { "shrQ",	{ VexGv, Ev, I1 }, 0 },
> >>> +    { "shlQ",	{ VexGv, Ev, I1 }, 0 },
> >>> +    { "sarQ",	{ VexGv, Ev, I1 }, 0 },
> >>>    },
> >>
> >> As mentioned on the assembler side already, I think we would be
> >> better off making const_1_mode print $1 in AT&T syntax at least for
> >> these new insn forms, to eliminate the ambiguity.
> >>
> >
> > It is related to correctness and should be revised. Since they share the same
> entries, I will created a new patch to modify the legacy instruction and then
> extend them to NDD. Do you agree?
> 
> I certainly appreciate any reusing, where it is possible (and it ought to be
> possible here, yes).
> 

Done.

> >>> @@ -9087,7 +9104,7 @@ get_valid_dis386 (const struct dis386 *dp,
> >> instr_info *ins)
> >>>  	return &err_opcode;
> >>>
> >>>        /* Set vector length.  */
> >>> -      if (ins->modrm.mod == 3 && ins->vex.b)
> >>> +      if (ins->modrm.mod == 3 && ins->vex.b && ins->evex_type ==
> >>> + evex_default)
> >>>  	ins->vex.length = 512;
> >>>        else
> >>>  	{
> >>
> >> Is this change really needed for anything?
> >
> > If it's NDD and ins->vex.b ==1, we need to avoid giving NDD a wrong value.
> 
> But this is recording ->vex.length, not anything NDD related (afaics).

There are some instructions that use OP_VEX, which will use ->vex.length.

For example:
"addB",             { VexGb, Eb, Gb }

 

  reply	other threads:[~2023-11-22  7:46 UTC|newest]

Thread overview: 113+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-02 11:29 [PATCH v2 0/8] Support Intel APX EGPR Cui, Lili
2023-11-02 11:29 ` [PATCH 1/8] Support APX GPR32 with rex2 prefix Cui, Lili
2023-11-02 17:05   ` Jan Beulich
2023-11-03  6:20     ` Cui, Lili
2023-11-03 13:05     ` Jan Beulich
2023-11-03 14:19   ` Jan Beulich
2023-11-06 15:20     ` Cui, Lili
2023-11-06 16:08       ` Jan Beulich
2023-11-07  8:16         ` Cui, Lili
2023-11-07 10:43           ` Jan Beulich
2023-11-07 15:31             ` Cui, Lili
2023-11-07 15:43               ` Jan Beulich
2023-11-07 15:53                 ` Cui, Lili
2023-11-06 15:02   ` Jan Beulich
2023-11-07  8:06     ` Cui, Lili
2023-11-07 10:20       ` Jan Beulich
2023-11-07 14:32         ` Cui, Lili
2023-11-07 15:08           ` Jan Beulich
2023-11-06 15:39   ` Jan Beulich
2023-11-09  8:02     ` Cui, Lili
2023-11-09 10:52       ` Jan Beulich
2023-11-09 13:27         ` Cui, Lili
2023-11-09 15:22           ` Jan Beulich
2023-11-10  7:11             ` Cui, Lili
2023-11-10  9:14               ` Jan Beulich
2023-11-10  9:21                 ` Jan Beulich
2023-11-10 12:38                   ` Cui, Lili
2023-12-14 10:13                   ` Cui, Lili
2023-12-18 15:24                     ` Jan Beulich
2023-12-18 16:23                       ` H.J. Lu
2023-11-10  9:47                 ` Cui, Lili
2023-11-10  9:57                   ` Jan Beulich
2023-11-10 12:05                     ` Cui, Lili
2023-11-10 12:35                       ` Jan Beulich
2023-11-13  0:18                         ` Cui, Lili
2023-11-02 11:29 ` [PATCH 2/8] Created an empty EVEX_MAP4_ sub-table for EVEX instructions Cui, Lili
2023-11-02 11:29 ` [PATCH 3/8] Support APX GPR32 with extend evex prefix Cui, Lili
2023-11-02 11:29 ` [PATCH 4/8] Add tests for " Cui, Lili
2023-11-08  9:11   ` Jan Beulich
2023-11-15 14:56     ` Cui, Lili
2023-11-16  9:17       ` Jan Beulich
2023-11-16 15:34     ` Cui, Lili
2023-11-16 16:50       ` Jan Beulich
2023-11-17 12:42         ` Cui, Lili
2023-11-17 14:38           ` Jan Beulich
2023-11-22 13:40             ` Cui, Lili
2023-11-02 11:29 ` [PATCH 5/8] Support APX NDD Cui, Lili
2023-11-08 10:39   ` Jan Beulich
2023-11-20  1:19     ` Cui, Lili
2023-11-08 11:13   ` Jan Beulich
2023-11-20 12:36     ` Cui, Lili
2023-11-20 16:33       ` Jan Beulich
2023-11-22  7:46         ` Cui, Lili [this message]
2023-11-22  8:47           ` Jan Beulich
2023-11-22 10:45             ` Cui, Lili
2023-11-23 10:57               ` Jan Beulich
2023-11-23 12:14                 ` Cui, Lili
2023-11-24  6:56                 ` [PATCH v3 0/9] Support Intel APX EGPR Cui, Lili
2023-12-07  8:17                   ` Cui, Lili
2023-12-07  8:33                     ` Cui, Lili
2023-11-09  9:37   ` [PATCH 5/8] Support APX NDD Jan Beulich
2023-11-20  1:33     ` Cui, Lili
2023-11-20  8:19       ` Jan Beulich
2023-11-20 12:54         ` Cui, Lili
2023-11-20 16:43           ` Jan Beulich
2023-11-02 11:29 ` [PATCH 6/8] Support APX Push2/Pop2 Cui, Lili
2023-11-08 11:44   ` Jan Beulich
2023-11-08 12:52     ` Jan Beulich
2023-11-22  5:48     ` Cui, Lili
2023-11-22  8:53       ` Jan Beulich
2023-11-22 12:26         ` Cui, Lili
2023-11-09  9:57   ` Jan Beulich
2023-11-02 11:29 ` [PATCH 7/8] Support APX NDD optimized encoding Cui, Lili
2023-11-09 10:36   ` Jan Beulich
2023-11-10  5:43     ` Hu, Lin1
2023-11-10  9:54       ` Jan Beulich
2023-11-14  2:28         ` Hu, Lin1
2023-11-14 10:50           ` Jan Beulich
2023-11-15  2:52             ` Hu, Lin1
2023-11-15  8:57               ` Jan Beulich
2023-11-15  2:59             ` [PATCH][v3] " Hu, Lin1
2023-11-15  9:34               ` Jan Beulich
2023-11-17  7:24                 ` Hu, Lin1
2023-11-17  9:47                   ` Jan Beulich
2023-11-20  3:28                     ` Hu, Lin1
2023-11-20  8:34                       ` Jan Beulich
2023-11-14  2:58         ` [PATCH 1/2] Reorder APX insns in i386.tbl Hu, Lin1
2023-11-14 11:20           ` Jan Beulich
2023-11-15  1:49             ` Hu, Lin1
2023-11-15  8:52               ` Jan Beulich
2023-11-17  3:27                 ` Hu, Lin1
2023-11-02 11:29 ` [PATCH 8/8] Support APX JMPABS Cui, Lili
2023-11-09 12:59   ` Jan Beulich
2023-11-14  3:26     ` Hu, Lin1
2023-11-14 11:15       ` Jan Beulich
2023-11-24  5:40         ` Hu, Lin1
2023-11-24  7:21           ` Jan Beulich
2023-11-27  2:16             ` Hu, Lin1
2023-11-27  8:03               ` Jan Beulich
2023-11-27  8:46                 ` Hu, Lin1
2023-11-27  8:54                   ` Jan Beulich
2023-11-27  9:03                     ` Hu, Lin1
2023-11-27 10:32                       ` Jan Beulich
2023-12-04  7:33                         ` Hu, Lin1
2023-11-02 13:22 ` [PATCH v2 0/8] Support Intel APX EGPR Jan Beulich
2023-11-03 16:42   ` Cui, Lili
2023-11-06  7:30     ` Jan Beulich
2023-11-06 14:20       ` Cui, Lili
2023-11-06 14:44         ` Jan Beulich
2023-11-06 16:03           ` Cui, Lili
2023-11-06 16:10             ` Jan Beulich
2023-11-07  1:53               ` Cui, Lili
2023-11-07 10:11                 ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SJ0PR11MB5600C493097322A426D5E76A9EBAA@SJ0PR11MB5600.namprd11.prod.outlook.com \
    --to=lili.cui@intel.com \
    --cc=JBeulich@suse.com \
    --cc=binutils@sourceware.org \
    --cc=ccoutant@gmail.com \
    --cc=hongjiu.lu@intel.com \
    --cc=lingling.kong@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).