To avoid GCC warnings when building with `-Os`:
warning: inlining failed in call to 'table_walk': call is
unlikely and code size would grow [-Winline]
I don't know if this causes a performance regression when optimizing for
speed instead of size, but perhaps there's a different way we can help
the compiler make this decision in such cases.
Where size_t is only 32 bits wide, and we end up losing the upper bits.
GCC catches this and emits a warning such as:
warning: left shift count >= width of type [-Wshift-count-overflow]
The AMD64 instructions VPERMIL2PS and VPERMIL2PD (currently not
supported) encode a fifth immediate operand in the lower bits of the
re-purposed immediate. Expose this value in any case so that no
information gets lost during decoding.
- 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.
* The encoding of operand types in the decode table now only requires 9
bits instead of the previous 16 bits.
* Operand types are decoded before the operands itself are stored. This
allows to ignore REX.RB prefixed for specific register types.
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.
