指令解码器如何在32位模式下区分EVEX前缀和BOUND操作码？

Question

在32位模式下,英特尔通过反转寄存器扩展的高位来解决VEX前缀与LDS/LES冲突,因为ModRM字节的mod字段不能为11b

VEX前缀的初始字节值C4h和C5h与LDS和LES指令的操作码相同.64位模式不支持这些指令.为了在32位模式下解决模糊性,VEX的规范利用了合法的LDS或LES的ModRM字节不能是11xxxxxx(它将指定寄存器操作数)的事实.VEX前缀的第二个字节中的各个位字段被反转,以确保该字节在32位模式下始终为此形式.

https://en.wikipedia.org/wiki/VEX_prefix#Technical_description

但是在EVEX中,R和X位不反转,导致mod = 00b,这也表示BOUND指令中的内存操作数

来自REX前缀的四位R,X,B和W. W将操作数大小扩展为64位或作为附加操作码,R扩展reg,B扩展r/m或reg,X和B扩展索引和SIB字节中的基址.与VEX前缀相比,RXB以非反转形式提供,就像在REX前缀中一样.

https://en.wikipedia.org/wiki/EVEX_prefix

那么他们如何能够干净地解码该指令？

---

我查看了英特尔手册,他们似乎只提到了VEX中的位反转,而不是EVEX.

OTOH表中的沙堆说,在这些EVEX RxB位也应该被反转.

哪一项是正确的？

Answer 1

反转位的技巧之所以有效，是因为有两个事实：

\n\n

\n
1. 在 32 位模式下，32 个 ZMM 寄存器中只有 8 个可用，因此 EVEX.R 位永远不会翻转，因此永远不会使用允许的 BOUND 编码进行别名。
\n
2. 在 64 位模式下，无法识别 BOUND 指令，因此 EVEX 位可以采用任何值。
\n

\n\n

AVX专利的摘录澄清了这一点：

\n\n

\n

[0111]\n REX\xe2\x80\xb2 字段\xe2\x80\x94这是 REX\xe2\x80\xb2 字段的第一部分，并且是 EVEX.R\xe2\x80\xb2 位字段（EVEX 字节1，位[4]\xe2\x80\x94R\xe2\x80\xb2)，用于对扩展32寄存器组的高16位或低16位进行编码。在本发明的一个实施例中，该位以及如下所示的其他位以位反转格式存储，以与BOUND指令区分开（在众所周知的x86 32位模式中），BOUND指令的实际操作码字节是62，但是MOD R/M 字段（如下所述）不接受 MOD 字段中的值 11；本发明的替代实施例不以反转格式存储该比特和下面其他指示的比特。值 1 用于对低 16 个寄存器进行编码。换句话说，R\xe2\x80\xb2Rrrr 是由 EVEX.R\xe2\x80\xb2、EVEX.R 和其他字段中的其他 RRR 组合而成。

\n

\n\n

然而，Intel SDM对此并不清楚。\n我浏览了SDM，确实，在EVEX部分中没有提及EVEX编码的补码含义的痕迹。人们必须以某种方式从 EVEX 是 VEX 的扩展这一事实中推断出它，并且对于后者，有一个反向含义的陈述（第 2A 卷，第 2.3.5 节，第一个项目符号）：

\n\n

\n

该字段使用1\xe2\x80\x99s补码形式（反转形式）进行编码，即XMM0/YMM0/R0编码为1111B，XMM15/YMM15/R15编码为0000B。

\n

\n