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

[Jan Beulich]

On 17.10.2023 17:52, Cui, Lili wrote:
>> +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.

S/G is scatter/gather (i.e. AVX2 and AVX512).

Jan