public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: "Cui, Lili" <lili.cui@intel.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: Mon, 20 Nov 2023 17:33:28 +0100	[thread overview]
Message-ID: <ff44c134-6e1a-4bd2-86aa-1aec280efb21@suse.com> (raw)
In-Reply-To: <SJ0PR11MB56003F6CC9CCB65CCC325B4A9EB4A@SJ0PR11MB5600.namprd11.prod.outlook.com>

On 20.11.2023 13:36, Cui, Lili wrote:
>> On 02.11.2023 12:29, Cui, Lili wrote:
>>> --- 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.

>>> --- 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).

>>> @@ -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).

Jan

  reply	other threads:[~2023-11-20 16:33 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 [this message]
2023-11-22  7:46         ` Cui, Lili
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=ff44c134-6e1a-4bd2-86aa-1aec280efb21@suse.com \
    --to=jbeulich@suse.com \
    --cc=binutils@sourceware.org \
    --cc=ccoutant@gmail.com \
    --cc=hongjiu.lu@intel.com \
    --cc=lili.cui@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).