Decoder/formatter failures

{er} is ignored, see the SDM

62F17E187AC1 vcvtudq2pd zmm0, ymm1
ERROR: GENERAL_ERROR Could not decode at offset: 0x0 PC: 0x0: [62F17E187AC1000000000000000000]
62F17E18E6C1 vcvtdq2pd zmm0, ymm1
ERROR: GENERAL_ERROR Could not decode at offset: 0x0 PC: 0x0: [62F17E18E6C1000000000000000000]

Offset is unsigned and should not be sign-extended (32-bit code)

669AADE44E6D call far 0xffffe4ad, 0x6d4e
66EAADE44E6D jmp far 0xffffe4ad, 0x6d4e

Can't disassemble pvalidate in 16/32-bit mode (AMD: "While this instruction is intended for use in SNP-active guest system software, it is recognized in any operating mode at CPL0.")

F20F01FF pvalidate

R8D/R9D can't be used in 32-bit mode. RX bits should probably be ignored (I haven't tested real HW)

8F2A7810C100000000 bextr r8d, ecx, 0x0
8F287085044820 vpmacssww xmm0, xmm1, xmmword ptr [eax+r9d*2], xmm2

Fails to decode this in 32-bit mode. According to the SDM, V' is ignored in 16/32-bit mode, see SDM vol 2, Table 2-39 (page 77), bottom two rows.

62F17C0010C1 vmovups xmm0, xmm1 ; XED fails
ERROR: BAD_EVEX_V_PRIME Could not decode at offset: 0x0 PC: 0x0: [62F17C0010C1000000000000000000]
62F17C0810C1 vmovups xmm0, xmm1 ; works

imm shouldn't show the reg op (upper 4 bits)

C4E37148C230 vpermil2ps xmm0, xmm1, xmm2, xmm3, 0x30
C4E37149C230 vpermil2pd xmm0, xmm1, xmm2, xmm3, 0x30

[markcharney]

I started to work on this one. I have fixed the 1st and 4th issues in my work area. Thanks.

I believe the SDM may be wrong for the 5th issue (EVEX.V' appears to be guarded in 32b mode). That instruction pattern generates an illegal instruction fault on real hardware. I'm checking with someone who owns the RTL to confirm before submitting a fix request to t he SDM.

I believe the SDM may be wrong for the 5th issue (EVEX.V' appears to be guarded in 32b mode). That instruction pattern generates an illegal instruction fault on real hardware.

Wouldn't be the first time the SDM is wrong, unfortunately.

[markcharney]

I try not to bash the SDM. The current owner is a friend of mine and was handed a document with a lot of technical debt. We are constantly working to improve things...

[markcharney]

Fixed the 2nd one too. That was probably 16y old bug.

[markcharney]

I fixed all but the last one now. Thinking about whether it is worth bothering. Those are the only 2 instr with "~4b" imm when there is a register in the upper bits. Is AMD even supporting those instructions going forwards? I assumed they were removed from Zen when XOP instr was removed but don't know for sure.

The CPUID feature bit is XOP so they shouldn't be supported by current and future AMD CPUs.

[markcharney]

FWIW, I got a response back from the decoder team. As I suggested above, Table 2-39 is wrong for EVEX.V'. For EVEX.V' (P[19]), the table should say "if 0" in both rows for the non-64b #UD, indicating that bit is guarded. Table 2-39 will be fixed in the next release of the SDM (which happens roughly quarterly). Thank you for bringing that issue to my attention.