在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前缀中一样。
那么他们如何能够干净地解码该指令呢？
我查看了英特尔手册，他们似乎只提到了VEX中的位反转，而不是EVEX。
OTOH sandpile中的表说EVEX中的那些RXB位也应该被反转。
哪一个是正确的？
答案 0 :(得分：2)
反转位的技巧起因于两个事实：
来自AVX patent的摘录澄清了这一点：
[0111] REX'字段 - 这是REX'字段的第一部分，是EVEX.R'位字段（EVEX字节1，位[4] -R'），用于编码16的上部或下部16。扩展32个寄存器组。在本发明的一个实施例中，该位以及如下所示的其它位以位反转格式存储，以区分（在众所周知的x86 32位模式中）与BOUND指令，其实际操作码字节为62，但是在MOD R / M字段（下面描述）中不接受MOD字段中的值11;本发明的备选实施例不以倒置格式存储下面的这个和其他指示的位。值1用于编码低16位寄存器。换句话说，R'Rrrr是通过组合EVEX.R'，EVEX.R和其他领域的其他RRR形成的。
然而，Intel SDM对此事实并不清楚。 我已经浏览了SDM，事实上，在EVEX部分，没有提到EVEX编码的补充含义的痕迹。必须以某种方式从EVEX是VEX的扩展这一事实推断它，而后者则有一个反转意义的陈述（第2A卷，第2.3.5节，第一个子弹）：
该字段使用1的补码形式（反转形式）编码，即XMM0 / YMM0 / R0编码为1111B，XMM15 / YMM15 / R15编码为0000B。