[PATCH] Support APX CCMP and CTEST

[Cui, Lili]

> On 23.05.2024 08:12, Cui, Lili wrote:
> > --- a/opcodes/i386-opc.h
> > +++ b/opcodes/i386-opc.h
> > @@ -757,6 +757,9 @@ enum
> >    /* Support zero upper */
> >    ZU,
> >
> > +  /* Support zero upper */
> > +  SCC,
> > +
> >    /* The last bitfield in i386_opcode_modifier.  */
> >    Opcode_Modifier_Num
> >  };
> 
> As for ZU the question again arises whether this (rarely used) property needs
> to have its own attribute bit. I don't think it does, ...
> 
> > --- a/opcodes/i386-opc.tbl
> > +++ b/opcodes/i386-opc.tbl
> > @@ -341,9 +341,19 @@ cmp, 0x83/7, 0, Modrm|No_bSuf|No_sSuf,
> { Imm8S,
> > Reg16|Reg32|Reg64|Unspecified|Ba  cmp, 0x3c, 0, W|No_sSuf, {
> > Imm8|Imm16|Imm32|Imm32S, Acc|Byte|Word|Dword|Qword }  cmp,
> 0x80/7, 0,
> > W|Modrm|No_sSuf, { Imm8|Imm16|Imm32|Imm32S,
> > Reg8|Reg16|Reg32|Reg64|Unspecified|BaseIndex }
> >
> > +<cc:opc, o:0, no:1, b:2, c:2, nae:2, nb:3, nc:3, ae:3, e:4, z:4, ne:5, nz:5,
> be:6, na:6, nbe:7, a:7, +
> > +         s:8, ns:9, t:a, p:a, pe:a, f:b, np:b, po:b, l:c, nge:c,
> > +nl:d, ge:d, le:e, ng:e, nle:f, g:f>
> > +
> > +ccmp<cc>, 0x380<cc:opc>, APX_F,
> > +D|W|CheckOperandSize|Modrm|EVexMap4|SCC|No_sSuf, {
> > +Reg8|Reg16|Reg32|Reg64,
> Reg8|Reg16|Reg32|Reg64|Unspecified|BaseIndex
> > +} ccmp<cc>, 0x830<cc:opc>/7, APX_F,
> > +Modrm|EVexMap4|SCC|No_bSuf|No_sSuf, { Imm8S,
> > +Reg16|Reg32|Reg64|Unspecified|BaseIndex } ccmp<cc>,
> 0x800<cc:opc>/7,
> > +APX_F, W|Modrm|EVexMap4|SCC|No_sSuf,
> { Imm8|Imm16|Imm32|Imm32S,
> > +Reg8|Reg16|Reg32|Reg64|Unspecified|BaseIndex }
> > +
> >  test, 0x84, 0, D|W|C|CheckOperandSize|Modrm|No_sSuf, {
> > Reg8|Reg16|Reg32|Reg64,
> Reg8|Reg16|Reg32|Reg64|Unspecified|BaseIndex }
> > test, 0xa8, 0, W|No_sSuf|Optimize, { Imm8|Imm16|Imm32|Imm32S,
> > Acc|Byte|Word|Dword|Qword }  test, 0xf6/0, 0,
> > W|Modrm|No_sSuf|Optimize, { Imm8|Imm16|Imm32|Imm32S,
> > Reg8|Reg16|Reg32|Reg64|Unspecified|BaseIndex }
> > +ctest<cc>, 0x840<cc:opc>, APX_F,
> > +D|W|C|CheckOperandSize|Modrm|EVexMap4|SCC|No_sSuf, {
> > +Reg8|Reg16|Reg32|Reg64,
> Reg8|Reg16|Reg32|Reg64|Unspecified|BaseIndex
> > +} ctest<cc>, 0xf60<cc:opc>/0, APX_F, W|Modrm|EVexMap4|SCC|No_sSuf, {
> > +Imm8|Imm16|Imm32|Imm32S,
> Reg8|Reg16|Reg32|Reg64|Unspecified|BaseIndex
> > +} ctest<cc>, 0xf60<cc:opc>/1, APX_F, W|Modrm|EVexMap4|SCC|No_sSuf, {
> > +Imm8|Imm16|Imm32|Imm32S,
> Reg8|Reg16|Reg32|Reg64|Unspecified|BaseIndex
> > +}
> 
> ... as I see no other use of anything covered by OperandConstraint. And if there
> were concerns with using OperandConstraint here, another option may be to
> introduce EVEXSCC as another value for EVex.
> 
> And btw, I have a patch in the works undoing ZU needing a separate attribute
> bit. That turned out pretty straightforward.
> 
> Jan

I prefer to put it in OperandConstraint.

Lili.