[PATCH] Support APX CFCMOV

[Cui, Lili]

> On 17.06.2024 08:18, Cui, Lili wrote:
> > --- a/opcodes/i386-opc.tbl
> > +++ b/opcodes/i386-opc.tbl
> > @@ -989,6 +989,10 @@ ud0, 0xfff, i186,
> > Modrm|CheckOperandSize|No_bSuf|No_sSuf, { Reg16|Reg32|Reg64|Un
> > cmov<cc>, 0x4<cc:opc>, CMOV&APX_F,
> > Modrm|CheckOperandSize|No_bSuf|No_sSuf|DstVVVV|EVexMap4, {
> > Reg16|Reg32|Reg64|Unspecified|BaseIndex, Reg16|Reg32|Reg64,
> > Reg16|Reg32|Reg64 }  cmov<cc>, 0xf4<cc:opc>, CMOV,
> > Modrm|CheckOperandSize|No_bSuf|No_sSuf, {
> > Reg16|Reg32|Reg64|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
> >
> > +cfcmov<cc>, 0x4<cc:opc>, CMOV&APX_F,
> > +Modrm|CheckOperandSize|No_bSuf|No_sSuf|DstVVVV|EVexMap4|NF, {
> > +Reg16|Reg32|Reg64|Unspecified|BaseIndex, Reg16|Reg32|Reg64,
> > +Reg16|Reg32|Reg64 } cfcmov<cc>, 0x4<cc:opc>, CMOV&APX_F,
> > +Load|Modrm|CheckOperandSize|No_bSuf|No_sSuf|EVexMap4, {
> > +Reg16|Reg32|Reg64|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
> > +cfcmov<cc>, 0x4<cc:opc>, CMOV&APX_F,
> > +Modrm|CheckOperandSize|No_bSuf|No_sSuf|EVexMap4|NF, {
> > +Reg16|Reg32|Reg64, Reg16|Reg32|Reg64|Unspecified|BaseIndex }
> 
> Just on this one for starters (I'll get to the other parts later): NF here permits
> use of {nf}, which is specifically not wanted. EVEX.NF has a different purpose
> here, and hence the pseudo prefix, if used, needs to be rejected.
> 

Added.

> The doc also doesn't mention any dependency on the CMOV CPUID bit (also
> not for CMOVcc, btw, which thus wants fixing, unless of course the doc is
> wrong).
> 

Agree. I will feedback this issue.

> Finally a remark on the spec itself, similarly affecting the 3-operand form of
> CMOVcc: The spec uses Intel syntax. In Intel syntax present NDD operand
> ordering is "ndd, reg, r/m". I consider this severely misleading, and hence I'd
> like to ask that it be considered for operand order to change (in gas we could
> retain present order for AT&T syntax, as _there_ it makes sense). The "reg"
> operand, after all, supplies only the fallback value (i.e. when <cc> resolves to
> false). Naming the fallback before the "main" source operand is, well, at best
> confusing.
> 

We need internal discussion.

Thanks,
Lili.