- 3DNow! instructions have a trailing immediate byte which indicates the
opcode. Decoding this with the existing table structure requires more
effort (in particular, a new lookup table after decoding ModRM would
be required). Given that AMD even removed 3DNow! over 10 years ago, it
appears unlikely that this will ever be fully supported. Adding the
RMI-encoded pseudo-instruction "3DNOW" just to support that opcode.
- FEMMS is a legacy 3DNow! instruction.
- EXTRQ/INSERTQ are instructions with an "unusual" encoding and
operation mode. This is another instance of 16-bit immediates.
- SVM (AMD's variant of VMX) and SNP instructions are AMD-only.
These instruction ignore the VEX operand if the source operand is a
memory location.
API compatibility: separate handling for different operand types in the
second and third operand (REG+REG vs. MEM+NONE) is needed.
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.
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 formatter now includes the following information:
- Segment overrides
- Address-size overrides
- REP/REPNZ prefixes
- LOCK prefix
- High-byte registers (determined using presence of REX prefix)
