Addresses relative to the actual address of the instruction are decoded
as new offset operand, where the RIP has to be added to obtain the real
value. For backwards compatibility, the new behavior is only exposed if
the address of the instruction is specified as zero.
It is a longer standing issue that some instructions like ADD, IMUL, and
SHL have multiple mnemonics for different encoding forms. This is a
relict from a time where such information was not stored in the
instruction decoding. This, however, is no longer the case and therefore
the extra mnemonics just increase the number of cases to be handled by
users.
Some instruction opcodes have an entirely different encoding when a VEX
prefix is present. For example, 0f41 is CMOVNO without mandatory
prefixes while VEX.NP.W0.L1.0f41 is KANDW with a mandatory prefix. To
avoid collisions, the VEX prefix is better handled as a completely
separate decode tree, at the cost of a slight increase in table size.
This was previously needed to distinguish VZEROALL and VZEROUPPER. As
mandatory VEX.L is now handled properly, there is no need to export this
encoding detail any longer.
It turns out that in x86-64 mode, address and operand size overrides are
ignored by the processor. (Tested that on a real machine.)
Even libopcodes gets this wrong...
The Intel documentation is, well, inconsistent about this: at one point,
they say that the VEX.W prefix is ignored entirely in 32-bit mode, but
the instruction description indicates that a VEX.W can be required in
32-bit/compatibility mode as well.
Some instructions, e.g. VZEROUPPER, have a prefix table but no
associated byte for that. Fix this by removing the prefix handling from
the table walking loop.
