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.
It is possible to configure the build process such that decoding of 32
bit and 64 bit instructions can be chosen at runtime using an additional
parameter of the decode function. The header file is now entirely
architecture-independent and no longer required any previous defines.
Decoding x86-64 still requires a 64-bit pointer size.
This is mainly needed to handle the new control flow enforcement
extensions, making 3E a "notrack" prefix for indirect calls and jumps.
This is not (yet) modeled, and requires additional information on the
order of the prefixes, as 3E_66 (16-bit in ds segment) has a different
meaning than 66_3E (16-bit notrack). Before implementing this, an
analysis of the performance impact when decoding more prefix information
is probably required to avoid degrading overall performance for very few
and (as of now) seldomly used corner cases.
