Intel VEX 前缀,L 位值不符合文档
Intel VEX prefix, L bit value does not behave according to docs
Intel指令集参考给我们addsd指令:
VEX.NDS.LIG.F2.0F.WIG 58 /r
VADDSD xmm1, xmm2, xmm3/m64
正如我们所见,L 位被忽略(可以是 0 或 1)。
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
让我们测试一下:
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));
}
很好,visual studio 反汇编程序也能识别指令。
然而,当我将 L 位更改为 1(0x7B 被 0x7F 替换)时,反汇编器无法识别该指令并生成无效指令异常。这是否意味着尽管有 Intel 手册,L 位必须始终为 0?
看起来LIG并不真的意味着L位被忽略了; 手册的那部分是错误的。实际上,它实际上是 .LZ
或 .128
的同义词,表示 L 必须为 0。
英特尔的 insn ref 手册(第 3.1.1.2 节(指令摘要中的操作码列 Table(带 VEX 前缀的指令) 第 2 卷是对的x86 手册)与观察到的行为相矛盾:
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.
但是,它也与同一手册中的其他文档相矛盾。英特尔的手册偶尔会有错误。 :( 我认为您可以在英特尔论坛上报告错误。
大概英特尔改变了忽略该位的想法,并决定保留标量操作码的 L=1 编码,但忘记更新文档中 VEX.LIG 在 insn-encoding 部分的含义。
他们在 insn 集参考手册正式发布之前发布了未来扩展更新,可能在硬件设计的每个细节最终确定之前。 (当前的 future-extensions 补充 pdf 描述了 AVX512 指令(在 KNL 中找到),以及一些官方手册中没有的其他扩展,或者在任何商用硅 AFAIK 中可用。)(链接到英特尔的文档页面,和大量其他内容,在 x86 标签 wiki 中)。
来自 Intel 的 insn ref 手册,图 2-9 VEX 位字段:
L: Vector Length
- scalar or 128-bit vector
- 256-bit vector
第 2.3.6.2 节解释了同样的事情。
请注意,一些 BMI1/2 指令使用 VEX 编码,并且 L=0。看起来他们用 .Lz
表示: VEX.NDS.LZ.0F38.W0 F2 /r
是
ANDN r32a, r32b, r/m32
.
Intel指令集参考给我们addsd指令:
VEX.NDS.LIG.F2.0F.WIG 58 /r
VADDSD xmm1, xmm2, xmm3/m64
正如我们所见,L 位被忽略(可以是 0 或 1)。
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
让我们测试一下:
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));
}
很好,visual studio 反汇编程序也能识别指令。
然而,当我将 L 位更改为 1(0x7B 被 0x7F 替换)时,反汇编器无法识别该指令并生成无效指令异常。这是否意味着尽管有 Intel 手册,L 位必须始终为 0?
看起来LIG并不真的意味着L位被忽略了; 手册的那部分是错误的。实际上,它实际上是 .LZ
或 .128
的同义词,表示 L 必须为 0。
英特尔的 insn ref 手册(第 3.1.1.2 节(指令摘要中的操作码列 Table(带 VEX 前缀的指令) 第 2 卷是对的x86 手册)与观察到的行为相矛盾:
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.
但是,它也与同一手册中的其他文档相矛盾。英特尔的手册偶尔会有错误。 :( 我认为您可以在英特尔论坛上报告错误。
大概英特尔改变了忽略该位的想法,并决定保留标量操作码的 L=1 编码,但忘记更新文档中 VEX.LIG 在 insn-encoding 部分的含义。
他们在 insn 集参考手册正式发布之前发布了未来扩展更新,可能在硬件设计的每个细节最终确定之前。 (当前的 future-extensions 补充 pdf 描述了 AVX512 指令(在 KNL 中找到),以及一些官方手册中没有的其他扩展,或者在任何商用硅 AFAIK 中可用。)(链接到英特尔的文档页面,和大量其他内容,在 x86 标签 wiki 中)。
来自 Intel 的 insn ref 手册,图 2-9 VEX 位字段:
L: Vector Length
- scalar or 128-bit vector
- 256-bit vector
第 2.3.6.2 节解释了同样的事情。
请注意,一些 BMI1/2 指令使用 VEX 编码,并且 L=0。看起来他们用 .Lz
表示: VEX.NDS.LZ.0F38.W0 F2 /r
是
ANDN r32a, r32b, r/m32
.