assemblyx86avxmachine-codeillegal-instruction

Intel VEX prefix, L bit value does not behave according to docs


Intel instruction set reference gives us addsd instruction:

VEX.NDS.LIG.F2.0F.WIG 58 /r
VADDSD xmm1, xmm2, xmm3/m64

As we can see L bit is ignored (can be either 0 or 1).

Machine code of addsd xmm0, xmm0, xmm0: 0xC4, 0xE1, 0x7B, 0x58, 0xC0

C4 - indicates 3-byte VEX prefix
E1 - R = 1; X = 1; B = 1; m-mmmm = 1 (implied 0F escape)
7B - W = 0; vvvv = 1111 (xmm0); L = 0; pp = 11 (implied F2 prefix)
58 - opcode byte
C0 - mod-rm byte

Let's test:

void exec(Byte* code, int size)
{
    Byte* buf = (Byte*)VirtualAlloc(NULL, 4096, MEM_COMMIT, PAGE_EXECUTE_READWRITE);

    memcpy(buf, code, size);

    buf[size] = 0xC3;

    ((void (*)())buf)();

    VirtualFree(buf, 4096, MEM_DECOMMIT);
}

void f()
{
    Byte code[] = { 0xC4, 0xE1, 0x7B, 0x58, 0xC0 };

    exec(code, sizeof(code));
}

Fine, also visual studio disassembler recognizes the instruction.

However when I change L bit to 1 (0x7B is replaced by 0x7F) disassembler does not recognize the instruction and Invalid Instruction exception is generated. Does it mean that L bit must always be 0 despite Intel manual?


Solution

  • It looks like LIG doesn't really mean the L bit is ignored; that part of the manual is wrong. In practice it's actually a synonym for .LZ or .128 and means L must be 0.

    You're right that Intel's insn ref manual (Section 3.1.1.2 (Opcode Column in the Instruction Summary Table (Instructions with VEX prefix) of volume 2 of the x86 manuals) contradicts observed behaviour:

    If VEX.LIG is present in the opcode column: The VEX.L value is ignored. This generally applies to VEX-encoded scalar SIMD floating-point instructions.

    However, it also contradicts other documentation in the same manual. Intel's manuals do have occasional mistakes. :( I think you can report bugs on Intel's forum.


    Presumably Intel changed their mind about ignoring the bit, and decided to keep the L=1 encoding of scalar opcodes reserved, but forgot to update the docs for what VEX.LIG means in the insn-encoding section.

    They publish future-extensions updates to the insn set reference manual before they become official, probably before every detail of hardware design is finalized. (The current future-extensions supplemental pdf describes AVX512 instructions (found in KNL), and a few other extensions that aren't in the official manual yet, or available in any commercially-available silicon AFAIK.) (Links to Intel's docs page, and tons of other stuff, in the tag wiki).


    From Intel's insn ref manual, Fig2-9 VEX bit fields:

    L: Vector Length

    1. scalar or 128-bit vector
    2. 256-bit vector

    Section 2.3.6.2 explains the same thing.


    Note that some BMI1/2 instructions use VEX encodings, also with L=0. It looks like they indicate it with .Lz: VEX.NDS.LZ.0F38.W0 F2 /r is ANDN r32a, r32b, r/m32.