RE: [PATCH 2/8] Support APX GPR32 with extend evex prefix

["Cui, Lili" <lili.cui@intel.com>]

> +Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseInde
> x }
> >
> >  neg, 0xf6/3, 0, W|Modrm|No_sSuf|HLEPrefixLock, {
> >
> Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseIndex
> }
> > +
> >  not, 0xf6/2, 0, W|Modrm|No_sSuf|HLEPrefixLock, {
> >
> Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseIndex
> }
> > +not, 0xf6/2, APX_F|x64, W|Modrm|No_sSuf|EVex128|EVexMap4, {
> >
> +Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseInde
> x }
> 
> I can't seem to be able to find the disassembly part for these. The reason I've
> noticed is because I was meaning to figure how you deal with EVEX.nf needing
> to be zero for those (and others). For that bit specifically I expect we want a
> new %NF macro, which would be used as !%NF when (bad) (or some such)
> wants printing instead of {nf}.
> 
Their disassembly part are putted in NDD patch, I'll move them here. 
For EVEX.nf, I added a new macro %XN to print bad for Non-NF instructions. As you can see in [PATCH 7/8] Support APX NF.

> Similary I don't think I can spot anywhere that you would check the other bits
> which need to be zero in extended EVEX. Nor Improper use of EVEX.x4 in
> certain pre-existing encodings (S/G insns at least; perhaps all others are okay).

Sorry, I can't get you here, what are S/G insns, could you provide more details here, thanks.

Lili.