Some instructions honor an address-size override or a segment override,
even in the absence of a directly encoded memory operand.
These annotations are not yet used, but may be used in future to
optimize the size of encoded instructions.
This changes the instruction description format:
- Use Intel/AMD terminology for describing operands (where applicable)
- Group instructions by ISA extension
- Indicate read/written status flags
These instructions have plenty of corner cases and some instructions
have a different usage of the memory operand. Given that MPX is already
deprecated by Intel, it seems that the better option is to decode these
(rarely occuring) instructions as NOPs.
The new trie implementation is more flexible and allows omitting
prefixes even with a ModRM specifier in the opcode. Use this flexibility
to simplify instruction descriptions.
- 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.
- SHL (SAL) encoding with /6: this is not documented by Intel and
documented by AMD as present, but unsupported by tools.
- TEST encoding with /1: undocumented by Intel, documented by AMD.
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.
Now that we support different /r and /m encodings on the same opcode, we
can easily identify MOVLHPS/MOVHLPS as different instructions.
API compatibility: existing code can point the new MOVLHPS/MOVHLPS
mnemonics to the existing handler for MOVHPS/MOVLPS.
