为什么 ia32/x64 操作码映射文档 0x66 和 0xF2 作为操作码 0x0F38F1 (CRC32) 的双重强制前缀？答案

【问题标题】：Why does the ia32/x64 opcode map document 0x66 and 0xF2 as a double mandatory prefix for opcode 0x0F38F1 (CRC32)?为什么 ia32/x64 操作码映射文档 0x66 和 0xF2 作为操作码 0x0F38F1 (CRC32) 的双重强制前缀？
【发布时间】：2013-05-23 13:11:20
【问题描述】：

在英特尔 64 和 IA-32 架构软件开发人员手册中，第 F 行表 A-4 附录 A.3 第 2C 卷（订单号 326018-045US 2013 年 1 月）的独特之处在于它有一个前缀子行两个前缀的组合：0x66 和 0xF2。

与此相关的唯一操作码是 0x0F38F1 (CRC32)。对于单独的前缀 0xF2，源操作数是 Ey（内存或通用寄存器；32 位或 64 位），而对于前缀 0x66 和 0xF2 一起，源操作数是 Ew（内存或通用寄存器；始终为 16 位）

但是，如果 0x66 只是可选的操作数大小覆盖前缀而不是两个强制前缀组合中的第一个，则这些源操作数是相同的。事实上，0x66 作为可选前缀是第 3.2 卷第 2A 章中记录 CRC32 指令的方式（隐含：16 位和 32 位源操作数的相同字节序列）。该表似乎可以省略 0x66 和 0xF2 行，并将源操作数记录为 0xF2 行中的 Ev（内存或通用寄存器；16 位或 32 位或 64 位）。

操作码映射以这种独特的方式记录操作码 0x0F38F1 的源操作数是否有原因？

编辑：添加的手册版本

【问题讨论】：

标签： assembly x86 x86-64 opcode machine-code

【解决方案1】：

此操作码与 Atom 的 MOVBE 指令共享。我认为这是所有组合的外观：

0F 38 F1        movbe My, Gy
66 0F 38 F1     movbe Mw, Gw
66 F2 0F 38 F1  crc32 Gd, Ew
F2 0F 38 F1     crc32 Gd, Ey
F2 66 0F 38 F1  crc32 Gd, Ew

EDIT：对于 0F38 和 0F3A 组中的大多数操作码，66 前缀是定义实际指令的强制前缀，而不是通常的操作数大小前缀：

长度为 4 字节的三字节操作码以强制开头前缀（66H、F2H 或 F3H）和两个转义字节（0F38H 或 0F3AH）。这第四个字节的高低四位用于索引a 表 A-4 或表 A-5 中的特定行和列。

这就是为什么必须单独列出在其传统的操作数大小覆盖角色中使用的附加可选 66 前缀的情况。

【讨论】：

是的，我的表格版本还列出了 MOVBE 作为操作码 0F 38 F1 的指令，没有 F2 前缀。我只是好奇为什么 66 F2 0F 38 F1 crc32 Gd, Ew 和 F2 0F 38 F1 crc32 Fd, Ey 的表条目没有组合成一个条目： F2 0F 38 F1 crc32 Gd, Ev