[PATCH 7/8] Support APX NF

Cui, Lili lili.cui@intel.com
Thu Nov 2 10:46:45 GMT 2023


> Subject: Re: [PATCH 7/8] Support APX NF
> 
> On 02.11.2023 11:15, Cui, Lili wrote:
> >> On 19.09.2023 17:25, Cui, Lili wrote:
> >>> @@ -7652,6 +7680,13 @@ match_template (char mnem_suffix)
> >>>  	  continue;
> >>>  	}
> >>>
> >>> +      /* Check if nf prefix are valid.  */
> >>> +      if (check_NfPrefix (t))
> >>> +	{
> >>> +	  specific_error = progress (i.error);
> >>> +	  continue;
> >>> +	}
> >>
> >> Is it helpful (e.g. diagnostic-wise) to have this check so late? If
> >> so, is it useful to "continue" when this is the only thing that doesn't match?
> >> No other template is going to match in such an event, afaict.
> >>
> >
> > Yes, it is useful to continue.
> > For example" {nf}  add  $123, %bl "
> > In order, we first find legacy add, then the judgment finds they don’t match,
> then continue to find the second template which has NF.
> >
> > add, 0x83/0, 0, Modrm|No_bSuf|No_sSuf|HLEPrefixLock, { Imm8S,
> > Reg16|Reg32|Reg64|Word|Dword|Qword|Unspecified|BaseIndex } add,
> > 0x83/0, APX_F, Modrm|No_bSuf|No_sSuf|EVex128|EVexMap4|NF, { Imm8S,
> > Reg16|Reg32|Reg64|Word|Dword|Qword|Unspecified|BaseIndex }
> 
> Hmm, I wonder whether NF-needed-but-no-permitted-by-template shouldn't
> be a relatively early check: It's pretty cheap and avoids doing a number of
> more involved checks then.
> 
Agreed, it's better to put it in the front.

      /* Check AT&T/Intel syntax.  */
      specific_error = progress (unsupported_syntax);
      if ((intel_syntax && t->opcode_modifier.attsyntax)
          || (!intel_syntax && t->opcode_modifier.intelsyntax))
        continue;

+      /* Check NF support.  */
+      specific_error = progress (unsupported_nf);
+      if (i.has_nf && !t->opcode_modifier.nf)
+       continue;
+
       /* Check Intel64/AMD64 ISA.   */

Thanks,
Lili


More information about the Binutils mailing list