3

英特尔指令集参考为我们提供了添加指令：

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

我们可以看到 L 位被忽略（可以是 0 或 1）。

addd 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

让我们测试一下：

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));
}

很好，视觉工作室反汇编程序也可以识别指令。

但是，当我将L 位更改为 1（0x7B 替换为 0x7F）时，反汇编程序无法识别指令并生成无效指令异常。这是否意味着尽管英特尔手册 L 位必须始终为 0？

4

1 回答 1

2

看起来 LIG 并不意味着 L 位被忽略；手册的那部分是错误的。在实践中，它实际上是.LZor的同义词.128，意味着 L 必须为 0。

您是对的，英特尔的 insn 参考手册（x86 手册第 2 卷的第 3.1.1.2 节（指令摘要表中的操作码列（带有 VEX 前缀的指令））与观察到的行为相矛盾：

如果操作码列中存在 VEX.LIG：忽略 VEX.L 值。这通常适用于 VEX 编码的标量 SIMD 浮点指令。

但是，它也与同一手册中的其他文档相矛盾。英特尔的手册确实偶尔会出现错误。:( 我认为您可以在英特尔论坛上报告错误。

据推测，英特尔改变了忽略该位的想法，并决定保留标量操作码的 L=1 编码，但忘记更新文档以了解 VEX.LIG 在 insn-encoding 部分中的含义。

他们在正式发布之前，可能会在硬件设计的每个细节最终确定之前，发布对 insn 集参考手册的未来扩展更新。（当前的 future-extensions 补充 pdf 描述了 AVX512 指令（在 KNL 中找到），以及官方手册中尚未包含的一些其他扩展，或者在任何商用硅 AFAIK 中都没有。）（指向英特尔文档页面的链接，以及标签 wiki 中的大量其他内容）。

来自英特尔的 insn 参考手册，图 2-9 VEX 位字段：

L：向量长度

  1. 标量或 128 位向量
  2. 256 位向量

第 2.3.6.2 节解释了同样的事情。

请注意，一些 BMI1/2 指令使用 VEX 编码，L=0。看起来他们用.Lz: VEX.NDS.LZ.0F38.W0 F2 /ris 表示它ANDN r32a, r32b, r/m32。

于 2016-09-05T14:23:00.627 回答