[PATCH v1 1/2] Support AVX10_V2_AUX instructions

[Jan Beulich]

On 29.06.2026 05:41, Jiang, Haochen wrote:
>> From: Ganesh Gopalasubramanian <Ganesh.Gopalasubramanian@amd.com>
>> Sent: Saturday, June 27, 2026 5:56 PM
>> +  /* PREFIX_EVEX_MAP5_3C */
>> +  {
>> +    { Bad_Opcode },
>> +    { "vcvthf82hf6s",	{ XM, EXx }, 0 },
>> +  },
> 
> There are several mod table pass missing throughout
> the implementation. You need restrict MOD.R/M as
> 11 here.
> 
> Also, for non-broadcast operands, please use
> EXEvexXNoBcst instead of EXx.

Except that in cases where memory operands aren't allowed in the first place,
that won't be necessary (nor wanted, for adding clutter).

>> --- a/opcodes/i386-dis-evex-w.h
>> +++ b/opcodes/i386-dis-evex-w.h
>> +  /* EVEX_W_MAP5_3E_P_1 */
>> +  {
>> +    { Bad_Opcode },
>> +    { "vcvtbf82bf6s",	{ XM, EXx }, 0 },
>> +  },
> 
> Please pass W table before prefix table to reduce
> potential tree size.

Judging from the name of the identifier in the comment that's the case already?
With major opcodes 0x3c and 0x3e having only a single code point for now, there
may also be no difference in table size.

>> --- a/opcodes/i386-dis-evex.h
>> +++ b/opcodes/i386-dis-evex.h
>> @@ -652,7 +652,7 @@ static const struct dis386 evex_table[][256] = {
>>      { EVEX_LEN_TABLE (EVEX_LEN_0F3A3A) },
>>      { EVEX_LEN_TABLE (EVEX_LEN_0F3A3B) },
>>      { Bad_Opcode },
>> -    { Bad_Opcode },
>> +    { "vunpackb",	{ XM, EXx, Ib }, 0 },
> 
> Missing W and prefix table pass here.

Going through prefix_table[] shouldn't be needed: NO_PREFIX could be used to
"replace" that.

>> --- a/opcodes/i386-opc.tbl
>> +++ b/opcodes/i386-opc.tbl
>> @@ -3620,6 +3620,95 @@ vucomxs<sdh>, 0x<sdh:spfx>2e, AVX10_2,
>> Modrm|EVexLIG|<sdh:spc1>|<sdh:vexw>|Disp8
>>
>>  // AVX10.2 instructions end.
>>
>> +// AVX10_V2_AUX instructions.

AVX10.2-aux

>> +// VCVTPS2BF8, VCVTPS2BF8S, VCVTPS2HF8, VCVTPS2HF8S - narrowing 2-
>> op (F3.MAP5)
>> +// VCVTROPS2HF8, VCVTROPS2HF8S - narrowing 2-op (66.MAP5)

Please limit such commentary to what you find elsewhere. That is, nothing at
all here. Unexpected aspects, anomalies, etc of course want commenting.

>> +<cvtps8:opc:pfx, +
>> +    bf8:39:f3, +
>> +    bf8s:3b:f3, +
>> +    hf8:38:f3, +
>> +    hf8s:3a:f3>
> 
> Why do you need to put pfx in iterator? They are all f3.
> 
> And we could simply separate them as <fp8> and <sat> here, not <cvtps8>,
> <cvtrops8>, <cvtbiasps8>, where <fp8> has the base opcode 38 and 39,
> <sat> add 2 for them when there is saturation.

Splitting likely won't be a benefit here, and we didn't do so for AVX10.1 (see
<cvt8:...> there.

Jan