Re: [PATCH 5/8] Support APX NDD

[Jan Beulich <jbeulich@suse.com>]

On 20.11.2023 02:33, Cui, Lili wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Thursday, November 9, 2023 5:37 PM
>>
>> On 02.11.2023 12:29, Cui, Lili wrote:
>>> @@ -190,6 +193,8 @@ mov, 0xf21, i386|No64,
>>> D|RegMem|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf, { De  mov,
>> 0xf21,
>>> x64, D|RegMem|No_bSuf|No_wSuf|No_lSuf|No_sSuf|NoRex64, { Debug,
>> Reg64
>>> }  mov, 0xf24, i386|No64,
>>> D|RegMem|IgnoreSize|No_bSuf|No_wSuf|No_sSuf|No_qSuf, { Test,
>> Reg32 }
>>>
>>> +// Move after swapping the bytes
>>> +movbe, 0x0f38f0, Movbe,
>> D|Modrm|CheckOperandSize|No_bSuf|No_sSuf, {
>>> +Word|Dword|Qword|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
>>>  // Move after swapping the bytes
>>>  movbe, 0x0f38f0, Movbe, D|Modrm|CheckOperandSize|No_bSuf|No_sSuf,
>> {
>>> Word|Dword|Qword|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
>> movbe,
>>> 0x60, Movbe|APX_F,
>>> D|Modrm|CheckOperandSize|No_bSuf|No_sSuf|EVex128|EVexMap4, {
>>> Reg16|Reg32|Reg64|Unspecified|BaseIndex, Reg16|Reg32|Reg64 } @@
>>> -290,22 +295,36 @@ add, 0x0, 0,
>>> D|W|CheckOperandSize|Modrm|No_sSuf|HLEPrefixLock,
>> { Reg8|Reg16|Reg3
>>> add, 0x83/0, 0, Modrm|No_bSuf|No_sSuf|HLEPrefixLock, { Imm8S,
>>> Reg16|Reg32|Reg64|Word|Dword|Qword|Unspecified|BaseIndex }  add,
>> 0x4,
>>> 0, W|No_sSuf, { Imm8|Imm16|Imm32|Imm32S,
>> Acc|Byte|Word|Dword|Qword }
>>> add, 0x80/0, 0, W|Modrm|No_sSuf|HLEPrefixLock, {
>>> Imm8|Imm16|Imm32|Imm32S,
>>>
>> Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseInde
>> x }
>>> +add, 0x0, APX_F,
>>>
>> +D|W|CheckOperandSize|Modrm|No_sSuf|VexVVVVDest|EVex128|EVexMa
>> p4|NF, {
>>> +Reg8|Reg16|Reg32|Reg64,
>>>
>> +Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseInd
>> ex,
>>> +Reg8|Reg16|Reg32|Reg64 } add, 0x83/0, APX_F,
>>>
>> +Modrm|CheckOperandSize|No_bSuf|No_sSuf|VexVVVVDest|EVex128|EVex
>> Map4|N
>>> +F, { Imm8S,
>> Reg16|Reg32|Reg64|Word|Dword|Qword|Unspecified|BaseIndex,
>>> +Reg16|Reg32|Reg64 } add, 0x80/0, APX_F,
>>>
>> +W|Modrm|CheckOperandSize|No_sSuf|VexVVVVDest|EVex128|EVexMap4
>> |NF, {
>>> +Imm8|Imm16|Imm32|Imm32S,
>>>
>> +Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseInd
>> ex,
>>> +Reg8|Reg16|Reg32|Reg64}
>>
>> Why are there (just as an example) only 3 new forms of ADD, but ...
>>
>>> @@ -338,10 +366,19 @@ adc, 0x10, 0,
>>> D|W|CheckOperandSize|Modrm|No_sSuf|HLEPrefixLock,
>> { Reg8|Reg16|Reg
>>> adc, 0x83/2, 0, Modrm|No_bSuf|No_sSuf|HLEPrefixLock, { Imm8S,
>>> Reg16|Reg32|Reg64|Word|Dword|Qword|Unspecified|BaseIndex }  adc,
>> 0x14,
>>> 0, W|No_sSuf, { Imm8|Imm16|Imm32|Imm32S,
>> Acc|Byte|Word|Dword|Qword }
>>> adc, 0x80/2, 0, W|Modrm|No_sSuf|HLEPrefixLock, {
>>> Imm8|Imm16|Imm32|Imm32S,
>>>
>> Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseInde
>> x }
>>> +adc, 0x10, APX_F,
>>> +D|W|CheckOperandSize|Modrm|EVex128|EVexMap4|No_sSuf, {
>>> +Reg8|Reg16|Reg32|Reg64,
>>>
>> +Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseInd
>> ex }
>>> +adc, 0x83/2, APX_F, Modrm|EVex128|EVexMap4|No_bSuf|No_sSuf,
>> { Imm8S,
>>> +Reg16|Reg32|Reg64|Word|Dword|Qword|Unspecified|BaseIndex } adc,
>>> +0x80/2, APX_F, W|Modrm|EVex128|EVexMap4|No_sSuf, {
>>> +Imm8|Imm16|Imm32|Imm32S,
>>>
>> +Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseInd
>> ex }
>>> +adc, 0x10, APX_F,
>>>
>> +D|W|CheckOperandSize|Modrm|No_sSuf|VexVVVVDest|EVex128|EVexMa
>> p4, {
>>> +Reg8|Reg16|Reg32|Reg64,
>>>
>> +Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseInd
>> ex,
>>> +Reg8|Reg16|Reg32|Reg64 } adc, 0x83/2, APX_F,
>>>
>> +Modrm|CheckOperandSize|No_bSuf|No_sSuf|VexVVVVDest|EVex128|EVex
>> Map4,
>>> +{ Imm8S,
>> Reg16|Reg32|Reg64|Word|Dword|Qword|Unspecified|BaseIndex,
>>> +Reg16|Reg32|Reg64 } adc, 0x80/2, APX_F,
>>>
>> +W|Modrm|CheckOperandSize|No_sSuf|VexVVVVDest|EVex128|EVexMap4,
>> {
>>> +Imm8|Imm16|Imm32|Imm32S,
>>>
>> +Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseInd
>> ex,
>>> +Reg8|Reg16|Reg32|Reg64 }
>>
>> .... 6 new forms of ADC? My guess is that's NF-related, but doesn't that mean
>> that until NF support is added e.g. "{evex} add %eax, %eax" won't assemble
>> as intended? IOW in line with NF as an attribute being added right here, those
>> other templates also will want introducing right here.
>>
>> While looking at patch 7 I'm also wondering whether same-base-opcode
>> forms wouldn't better be kept together. I haven't finished yet looking at
>> what's needed there, but even if it doesn't turn out strictly necessary there it
>> may still be a good idea anyway (unless of course that would get in the way of
>> anything).
>>
> 
> For ADC, there are 3 templates that do not support NDD and NF, I moved them here from patch 3/8 which we discussed before since its decoding is supported together in the NDD patch.

Feels like my question wasn't really answered: Why are there 6 new ADC templates
here, but only 3 ADD ones? Or in other words: Why are the other 3 ADD ones only
added later?

Also I'm curious: Why do ADC and SBB not allow for NF? They always consume
EFLAGS.CF, but subsequent insns may have no need for their EFLAGS output,
just like for e.g. ADD and SUB. Yet NF is only about EFLAGS output aiui, not
about any bit(s) consumed from EFLAGS.

Jan