RE: [PATCH 5/8] Support APX NDD

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

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Monday, November 20, 2023 4:19 PM
> To: Cui, Lili <lili.cui@intel.com>
> Cc: Lu, Hongjiu <hongjiu.lu@intel.com>; ccoutant@gmail.com;
> binutils@sourceware.org; Kong, Lingling <lingling.kong@intel.com>
> Subject: Re: [PATCH 5/8] Support APX NDD
> 
> 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?
> 

The three extra items of ADC are special, they support neither ND nor NF. ADD does not have this situation. The ND part of add is here, and the remaining part of NF place in NF patch.

> 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.
> 

I will get back to you when I know the answer。

Thanks,
Lili.