[PATCH V2 3/8] Support APX GPR32 with extend evex prefix

[Cui, Lili]

> >> To avoid the need to fiddle with this file, did you consider changing
> >> the test's command line options instead? In any event ...
> >>
> >
> > Do you mean disabling apx_f with the command line "#as..."?
> 
> Yes.
> 
> >  I tried "#as -march=+noapx_f" , but not worked.
> 
> Listing tests have their command line options passed directly from the .exp
> file.
> 

It worked, thanks.

+run_list_test "x86-64-inval-movbe" "-I${srcdir}/$subdir -march=+noapx_f -al"

> >>> --- a/opcodes/i386-dis-evex-len.h
> >>> +++ b/opcodes/i386-dis-evex-len.h
> >>> @@ -62,6 +62,16 @@ static const struct dis386 evex_len_table[][3] = {
> >>>      { REG_TABLE (REG_EVEX_0F38C7_L_2) },
> >>>    },
> >>>
> >>> +  /* EVEX_LEN_0F38F2 */
> >>> +  {
> >>> +    { "andnS",		{ Gdq, VexGdq, Edq }, 0 },
> >>> +  },
> >>
> >> There's no sign of a prefix decode step here.
> >>
> >
> > The prefix decoding step is in the NF patch and its dependent patches (Part
> II 2/6). Both are suspended currently.
> 
> But prefix decoding is orthogonal to NF handling. Why would that step be
> added only there?
>

In V1 NF patch, we treated {nf} as prefix, {evex} and {nf} need to be selected or empty.

"XN" => print "{nf} " pseudo prefix when EVEX.NF = 1. When EVEX.NF = 0 and under certain conditions, need to print {evex}

  For XN:
              if (ins->vex.nf == true)
                {
                  *ins->obufp++ = '{';
                  *ins->obufp++ = 'n';
                  *ins->obufp++ = 'f';
                  *ins->obufp++ = '}';
                  *ins->obufp++ = ' ';
                }
              else if (ins->evex_type == evex_from_legacy && !ins->vex.b)
                {
                  *ins->obufp++ = '{';
                  *ins->obufp++ = 'e';
                  *ins->obufp++ = 'v';
                  *ins->obufp++ = 'e';
                  *ins->obufp++ = 'x';
                  *ins->obufp++ = '}';
                  *ins->obufp++ = ' ';
                }

Now there is a high probability that nf will be treated as suffix, the specific expression is still uncertain. Maybe we should add %XE to them in this patch. make sure its output is correct.

> >>> --- a/opcodes/i386-dis-evex-mod.h
> >>> +++ b/opcodes/i386-dis-evex-mod.h
> >>> @@ -1 +1,43 @@
> >>>  /* Nothing at present.  */
> >>
> >> This comment needs to go away when new stuff is added here. However,
> >> I'm sure I requested before that no new entries be put here which
> >> have only one of their two slots populated. The reg-only and mem-only
> >> aspects can be expressed via proper choice of operand specifiers, at least
> in almost all cases.
> >> Note how you already use ...
> >>
> >>> +  /* MOD_EVEX_MAP4_DA_PREFIX_1 */
> >>> +  {
> >>> +    { Bad_Opcode },
> >>> +    { "encodekey128", { Gd, Ed }, 0 },  },
> >>> +  /* MOD_EVEX_MAP4_DB_PREFIX_1 */
> >>> +  {
> >>> +    { Bad_Opcode },
> >>> +    { "encodekey256", { Gd, Ed }, 0 },  },
> >>> +  /* MOD_EVEX_MAP4_DC_PREFIX_1 */
> >>> +  {
> >>> +    { "aesenc128kl",    { XM, M }, 0 },
> >>> +  },
> >>> +  /* MOD_EVEX_MAP4_DD_PREFIX_1 */
> >>> +  {
> >>> +    { "aesdec128kl",    { XM, M }, 0 },
> >>> +  },
> >>> +  /* MOD_EVEX_MAP4_DE_PREFIX_1 */
> >>> +  {
> >>> +    { "aesenc256kl",    { XM, M }, 0 },
> >>> +  },
> >>> +  /* MOD_EVEX_MAP4_DF_PREFIX_1 */
> >>> +  {
> >>> +    { "aesdec256kl",    { XM, M }, 0 },
> >>> +  },
> >>> +  /* MOD_EVEX_MAP4_F8_PREFIX_1 */
> >>> +  {
> >>> +    { "enqcmds",	{ Gva, M },  0 },
> >>> +  },
> >>> +  /* MOD_EVEX_MAP4_F8_PREFIX_2 */
> >>> +  {
> >>> +    { "movdir64b",	{ Gva, M }, 0 },
> >>> +  },
> >>> +  /* MOD_EVEX_MAP4_F8_PREFIX_3 */
> >>> +  {
> >>> +    { "enqcmd",		{ Gva, M }, 0 },
> >>> +  },
> >>
> >> ... M in many entries anyway. These can move one level up without
> >> needing further adjustment.
> >>
> >> For all of the above, however, an EVEX.W decode step looks to be missing.
> >> Interestingly the doc consistently omits the (presumably) .W0 suffix
> >> for these, having merely a trailing dot there. The issue (doc and/or
> >> code) is present elsewhere as well.
> >>
> >
> > Do you mean that all EVEX promoted instructions need to be explicitly
> > .W0 in the doc?
> 
> Not exactly, no. The doc should explicitly state what the behavior wrt EVEX.W
> is. I'm merely guessing that for the insns where it's missing
> W0 might be meant (on the assumption that a common goal ought to be to
> waste as little encoding space as possible). If it's WIG (in the present doc
> typically spelled IGNORED) instead, ...
> 
> > in the case of, I'll handle it uniformly in get_valid_dis386.
> 
> ... no W decoding step would be needed of course.
> 
Ok

Thanks,
Lili.