public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Cui, Lili" <lili.cui@intel.com>
To: "Beulich, Jan" <JBeulich@suse.com>, "Hu, Lin1" <lin1.hu@intel.com>
Cc: "hjl.tools@gmail.com" <hjl.tools@gmail.com>,
	"binutils@sourceware.org" <binutils@sourceware.org>
Subject: RE: [PATCH] Support {evex} pseudo prefix for decode evex promoted insns without egpr32.
Date: Fri, 22 Mar 2024 09:45:46 +0000	[thread overview]
Message-ID: <SJ0PR11MB560050FBD30E3ECB2D5084479E312@SJ0PR11MB5600.namprd11.prod.outlook.com> (raw)
In-Reply-To: <1b29c006-7ea6-40d4-ac7c-1c0b40c6243c@suse.com>

> 
> > --- a/opcodes/i386-dis-evex-mod.h
> > +++ b/opcodes/i386-dis-evex-mod.h
> > @@ -1,10 +1,10 @@
> >    /* MOD_EVEX_MAP4_F8_P1 */
> >    {
> > -    { "enqcmds",	{ Gva, M }, 0 },
> > -    { "uwrmsr",		{ Gq, Eq }, 0 },
> > +    { "%XEenqcmds",		{ Gva, M }, 0 },
> > +    { "%XEuwrmsr",		{ Gq, Eq }, 0 },
> >    },
> >    /* MOD_EVEX_MAP4_F8_P3 */
> >    {
> > -    { "enqcmd",		{ Gva, M }, 0 },
> > -    { "urdmsr",		{ Eq, Gq }, 0 },
> > +    { "%XEenqcmd",		{ Gva, M }, 0 },
> > +    { "%XEurdmsr",		{ Eq, Gq }, 0 },
> >    },
> 
> Hmm. Once new encodings appear in Map4, I can see that we will need such
> distinction. But right now can't we get away without touching all of them
> again, by simply taking it being Map4 as an indication? The only place where it
> may be helpful to indeed add all of these right away is MOVBE, where its
> register form then would not have %XE added.
> 

Good idea, overall judgment can avoid missing instructions( found crc32 missing %XE).

> > --- a/opcodes/i386-dis-evex-reg.h
> > +++ b/opcodes/i386-dis-evex-reg.h
> > @@ -53,8 +53,8 @@
> >    {
> >      { "%NFaddA",	{ VexGb, Eb, Ib }, NO_PREFIX },
> >      { "%NForA",	{ VexGb, Eb, Ib }, NO_PREFIX },
> > -    { "adcA",	{ VexGb, Eb, Ib }, NO_PREFIX },
> > -    { "sbbA",	{ VexGb, Eb, Ib }, NO_PREFIX },
> > +    { "%XEadcA",	{ VexGb, Eb, Ib }, NO_PREFIX },
> > +    { "%XEsbbA",	{ VexGb, Eb, Ib }, NO_PREFIX },
> >      { "%NFandA",	{ VexGb, Eb, Ib }, NO_PREFIX },
> >      { "%NFsubA",	{ VexGb, Eb, Ib }, NO_PREFIX },
> >      { "%NFxorA",	{ VexGb, Eb, Ib }, NO_PREFIX },
> 
> IOW this patch goes on top of the NF one, without that being said anywhere?
> Except not quite, as ...
> 
> > --- a/opcodes/i386-dis.c
> > +++ b/opcodes/i386-dis.c
> > @@ -2625,8 +2625,8 @@ static const struct dis386 reg_table[][8] = {
> >    {
> >      { "%NFrolA",	{ VexGb, Eb, Ib }, NO_PREFIX },
> >      { "%NFrorA",	{ VexGb, Eb, Ib }, NO_PREFIX },
> > -    { "rclA",	{ VexGb, Eb, Ib }, NO_PREFIX },
> > -    { "rcrA",	{ VexGb, Eb, Ib }, NO_PREFIX },
> > +    { "%XErclA",	{ VexGb, Eb, Ib }, NO_PREFIX },
> > +    { "%XErcrA",	{ VexGb, Eb, Ib }, NO_PREFIX },
> 
> ... that patch wrongly added %NF here. So looks like that patch was partly
> fixed already in this regard (the NOT adjustment there will then also need
> reflecting here). But please - anything like this needs making entirely
> transparent to the reader.
>

Ok.
 
> > @@ -10595,7 +10595,9 @@ putop (instr_info *ins, const char
> *in_template, int sizeflag)
> >  		  *ins->obufp++ = '}';
> >  		  *ins->obufp++ = ' ';
> >  		}
> > -	      else if (ins->evex_type == evex_from_legacy && !ins->vex.b)
> > +	      else if ((ins->evex_type == evex_from_legacy && !ins->vex.b)
> > +		       || (ins->evex_type == evex_from_vex
> > +			   && !((ins->rex2 & 7) || !ins->vex.v)))
> 
> This double negation is hard to follow:
> 
> 	      else if ((ins->evex_type == evex_from_legacy && !ins->vex.b)
> 		       || (ins->evex_type == evex_from_vex
> 			   && !(ins->rex2 & 7) && ins->vex.v))
> 
Done. 

Thanks,
Lili.

      parent reply	other threads:[~2024-03-22  9:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-06  9:58 Cui, Lili
2024-03-08 10:37 ` Jan Beulich
2024-03-20 13:12   ` Cui, Lili
2024-03-20 13:21     ` Jan Beulich
2024-03-21 12:33       ` Cui, Lili
2024-03-22  9:45   ` Cui, Lili [this message]

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=SJ0PR11MB560050FBD30E3ECB2D5084479E312@SJ0PR11MB5600.namprd11.prod.outlook.com \
    --to=lili.cui@intel.com \
    --cc=JBeulich@suse.com \
    --cc=binutils@sourceware.org \
    --cc=hjl.tools@gmail.com \
    --cc=lin1.hu@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).