Re: [PATCH V2 2/4] x86/insn: Add AVX-512 support to the instruction decoder

Borislav Petkov
2025-12-01T19:02:03Z

On Mon, Dec 01, 2025 at 08:15:19PM +0200, Adrian Hunter wrote:
> EXTRQ Vo,Uo (66) has a mandatory 66 prefix like vcvtps2uqq/pd2uqq Vx,Wx (66),(ev) so they end up on the same attribute table, but (ev) results in INAT_EVEXONLY which is unwanted.
>
> Changing that from (ev) to (evo) is probably all that is needed e.g.
>
> +79: VMWRITE Gy,Ey | EXTRQ Vo,Uo (66) | vcvtps2udq/pd2udq Vx,Wpd (evo) | vcvtsd2usi Gv,Wx (F2),(ev) | vcvtss2usi Gv,Wx (F3),(ev) | vcvtps2uqq/pd2uqq Vx,Wx (66),(evo)
>

That still sounds to me like a hack: looking at the SDM, that thing:

VCVTPS2UQQ—Convert Packed Single Precision Floating-Point Values to Packed
Unsigned Quadword Integer Values

*is* EVEX-only insn:

EVEX.128.66.0F.W0

the "66" meaning in this case EVEX.pp which are the VEX.pp two bits with value
1b meaning there's an implied 66 legacy prefix.

To make it more concrete, let's take an example from the binutils testsuite:

62 f1 7d 4f 79 f5[ ]*vcvtps2uqq zmm6\{k7\},ymm5

and that's basically:

Extended VEctor prefiX: 0x62
P1: [R:1|X:1|B:1|R':1|rsv:0|mm:1] 0xf1
P2: [W:0|vvvv:0xf |rsv:1|pp:1] 0x7d
P3: [z:0|L':1|L:0|b:0|V':1|aaa:7] 0x4f

with the opcode 0x79 and EVEX.pp=1b, as expected.

So there's no real 66 prefix there.

But our opcode map says:

"# Last Prefix Superscripts
# - (66): the last prefix is 0x66"

So we're using the marking (66) to mean both an explicit 66 legacy prefix and
an implied *VEX.pp=1 66 prefix equivalence.

So now the question is, why do the *VEX opcodes need that (66) marking at all?
For operand sizing?

Looking at our example insn VCVTPS2UQQ, I don't see any other encoding where
66 is not present. And there's nothing in the pseudo code either. So VEX.pp=1
is part of the encoding of that insn.

So, that (66) there is not really the prefix ...

Hmm?

--
Regards/Gruss,
Boris.