x86-64非法两字节操作码说明

Question

最近写了一个 C 程序来查找 x86-64 的两字节非法操作码，并将 output 粘贴到https://pastebin.com/5xjjFea6

例如，这里有一些非法的两字节操作码

0x0f,0x04  0x0f,0x0a  0x0f,0x0b  0x0f,0x0c  0x0f,0x0e  0x0f,0x0f  0x0f,0x24  0x0f,0x25 0x0f,0x26  0x0f,0x27  0x0f,0x36  0x0f,0x37 0x0f,0xaa

从谷歌上，我只找到了一些描述

0x0f,0x0b - ud2 - Generates an invalid opcode. 
 
0x0f,0x37 - getsec - Exit authenticated code execution mode.
 
0x0f,0xaa - rsm - Resume operation of interrupted program.

问题

• 是否有解释大多数非法操作码的文档？
• 为什么存在非法操作码？
• 为什么不将它们视为 x86-64 上的 NOP 或分配给有用的东西？

Answer 1

#UD非法指令错误的存在是为了让您知道您试图运行该 CPU 不支持的指令。

对于大多数新指令，最好让旧 CPU #UD在它们上出错，而不是默默地做错事（或什么都不做）。 例如， getsec和rsm不是您可以在它们可能作为 NOP 运行而不是按照您的意愿运行的情况下使用的指令。 （有趣的事实：8086 没有 #UD 错误；任何字节序列都将作为something执行。）

仅对于prefetchw之类的推测性提示，或回退有效的其他情况，您是否希望旧 CPU 将其作为 NOP 运行，以便代码可以在不检查的情况下使用它。 您通常可以在现有指令前使用 REP 获得它（例如pause是rep nop ）。

有足够的 NOP 等效操作码供将来使用； 最好让未使用的编码空间的 rest 实际出错。

从 CPU 供应商的角度来看，有一些字节序列 #UD 错误意味着他们可以确定现有代码不会（无意或有意）依赖它们作为长 NOP 而不是使用推荐的编码来工作。

---

是否有解释大多数非法操作码的文档？

不，除了英特尔表示执行当前手册未明确定义的任何内容的结果是不可预测的。 我没有检查英特尔或 AMD 手册的措辞，但我假设他们说这是其中一种可能性。

请记住，他们不是在记录特定的 CPU，而是在记录 x86-64 ISA，以鼓励人们创建向前兼容的程序，这些程序仍将在未来的 CPU 上正常工作，这些字节序列可能是新指令的一部分目前甚至还没有被提议。

#UD 错误是许多字节序列在实践中的常见行为。 但是其他序列，比如一条指令上的rep前缀，它没有任何意义，通常只是忽略rep前缀。 这让 CPU 供应商引入了一个新的扩展，其中rep xyz意味着其他东西（比如rep bsf变成tzcnt ，它对非零输入产生相同的结果），那时他们可以记录以前运行它的 CPU 的行为只是简单的bsf 。 （或者pause运行rep nop为nop ）。

还有多个其他示例，但要点是该行为一直存在，并且当rep xyz编码被记录为在设置了某些 CPUID 功能位时执行其他操作时，只会对旧 CPU 进行追溯记录。

有关的：

• 当 rep-prefix 附加到非字符串指令时会发生什么？
• 英特尔 TSX 前缀是否作为 NOP 在 AMD 上（安全地）执行？ （ xacquire / xrelease与 F2/F3 REP/REPNE 前缀的字节相同）
• 当您使用 memory 覆盖前缀但所有操作数都是寄存器时会发生什么？ （文档说“保留”，在当前硬件上它被忽略。 lock前缀在不适用时将为#UD ，这与其他前缀不同。）
• "rep; nop;" 是什么意思 x86 汇编中的意思？ 和“暂停”指令一样吗？
• 组装 x86 REP、REPZ、REPNZ、XACQUIRE 和 XRELEASE 指令
• Pentium III CPU 如何处理来自同一组的多个指令前缀？
• `rep ret` 是什么意思？ - 在没有记录的情况下，忽略rep行为被广泛依赖的罕见案例。 如此广泛使用（多年来默认为 GCC）以至于 CPU 供应商无法在不停止其 CPU 运行 GCC 编译的二进制文件的情况下合理地更改它，这对于通用 CPU 来说不是商业上可行的选择。
• 可以使用哪些方法有效地扩展现代 x86 上的指令长度？

---

为什么他们不分配到有用的东西？

在 32 位模式下基本上没有剩余的编码空间，也没有空闲的单字节操作码。 迄今为止的所有扩展都对 32 位和 64 位使用了相同的编码； 如果您关心 32 位模式，那么这是有道理的，您希望解码器只需要寻找相同的模式。 这就是为什么 VEX (AVX) 和 EVEX (AVX-512) 前缀使用一些反转位，因此它们在 32 位模式下与无效编码重叠，也是为什么它们在 32 位模式下仍然限于 8 个向量寄存器。

不幸的是，还没有任何扩展引入新的仅 64 位指令来使用一些释放的 1 字节操作码（BCD 指令，如aaa或段寄存器的压入/弹出）。 他们可以添加多个，例如mov r/m32, sign_extended_imm8以提高 64 位模式下的代码密度，将mov ecx, -2或1之类的指令变为 3 个字节而不是 5 个字节，并将mov rcx, -2指令变为 4 个字节而不是 7 个字节mov rcx, -2 。

但是对于 Microsoft model 软件分发版，一个随处运行的二进制文件，并检测 CPU 功能以用于一些特殊功能，这样的功能无法获得足够的收益。 这种东西对整个二进制文件只有一点帮助，所以只有像gcc -march=native这样的情况。 BMI1/2 就是这样，主要是用 1 条指令完成可以在 2 条指令中完成的操作，因此在程序中的所有功能中使用时大多有帮助。 但可以想象，一些 bithack 函数可以获得足够的加速，这是值得的。

Intel 和 AMD 没有兴趣引入不会立即有用的扩展，因此在十年左右的时间里它们无处不在时会变得最有用的扩展大多被忽略了（广泛到某些程序可以将其视为一部分他们的“基线”）。 尽管他们在 BMI1/2 中试水，但英特尔多年来继续销售没有这些扩展的 CPU，包括 Skylake Pentium/Celeron，我认为是 Silvermont 系列 CPU、上网本和低功耗服务器。）

一些 BMI1/2 指令使用 VEX 编码，我认为禁用 VEX 解码是英特尔如何在 Ice Lake 之前的低端 CPU 中禁用 AVX，而 BMI1/2 是一个牺牲品。 （在 Gracemont（Alder Lake E-core）之前，Silvermont 系列完全不支持 AVX，他们也根本不需要能够解码 VEX 前缀。）

AMD 对 AMD64 的原始设计非常保守，除了删除一些操作码以释放它们以供将来可能的扩展之外，尽可能少地改变机器代码的含义。 很明显，他们不想因为需要更多的解码器晶体管而陷入困境，以防 AMD64 没有在商业上流行起来。 为了提高编译器和汇编器的采用率，他们保留了 32 位模式的大部分缺点，包括setcc r/m8而不是setcc r32/m8 ，因此 x86 在从比较条件有效地实现 integer 0/1 方面仍然很糟糕。