This is realized by two changes: first, GP and vector operand size are
completely separated using one extra bit. If the operand size of an
instruction is derived from VEX.L (or EVEX.L'L), then the "opsize" bits
indicate how to derive a smaller vector size (half/quarter/eighth).
Now, an instruction cannot refer to the GP operand size and the vector
operand size at the same time. This isn't necessary, all necessary
distinguishing could also be achieved manually using W0/W1/66 selectors.
There is no instruction that uses an implicit register and an
VEX-encoded register at the same time. Thus, we can merge vexreg and
zeroreg in the instruction descriptor; the zeroreg value will be added
to the vex-operand (which is zero unless set by a VEX prefix).
This also frees 4 descriptor bits for use with AVX-512 (which will
probably need 1-2 additional unused bits, probably from the type).
This is an *experimental* (read: unstable) API which exposes encoding
functionality as one function per instruction. This makes the encoding
process itself significantly faster, at the cost of a much larger binary
size (~1 MiB of code, no data) and much higher compilation time.
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
As the formatter no longer demands a null-terminated string, mnemonics
can arbitarily overlap and therefore save space.
This is the shortest superstring problem, which is NP-hard. This is
currently approximated with a greedy heuristic.
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.
Thanks to William Woodruff for pointing out that -Wcast-align=strict is
a GCC-only option, which causes build errors (instead of just
complaining about an unsupported warning option).