Apparently, some platforms (*cough* MSVC *cough*) haven't figured out what
year it is and are behind the curve. Provide <inttypes.h> for common
memory models. We can add more if there are odd platforms which don't
have "long long" for 64 bits, too.
\313 indicates a fixed 64-bit address size. It was incorrectly
documented and incorrectly implemented in the assembler, and was
unimplemented in the disassembler.
Use a script to find \321's that should be \324's. This is not in any
way guaranteed to be an exhaustive list, however, I have manually verified
that all the items that *were* changed *should* be changed.
The recent switch from register numbers (with -1 meaning "none") to
register flags (with 0 meaning "none") broke the generation of 67
prefixes, especially in 64-bit mode.
Remove tests that are bogus (they trigger for legitimate instructions.)
The failure cases are okay anyway since they will be trapped by the
REX generation logic.
Remove a bogus check for 64-bit operands. If appropriate, we will
detect this during REX generation and will bail then. However, there
are other instructions (floating point, MMX, ...) which are legitimately
64 bits in non-64-bit mode.
Get rid of magic open-coded register numbers. We now keep track of
a total of three different kinds of register numbers: the register
enumeration (regs.h), the x86 register value, and the register flags.
That has all the information we need.
Additionally, do massive revamping of the EA generation code and the
REX generation logic.
- MOV gpr,CRx or MOV CRx,gpr can access high control registers with a LOCK
prefix; handle that in both the assembler and disassembler.
- Get a saner error message when trying to access high resources in
non-64-bit mode.
The assembler doesn't seem to care, but for the disassembler, it's
vitally important that we get our operand-size hints correctly. We
probably need to audit insns.dat for this kinds of errors.
64-bit support for ndisasm. This is very much an initial attempt, and
there are guaranteed to be bugs in the code. However, some *very*
preliminary testing seems to indicate it's not completely off-base.
64-bit support required some major changes to regs.dat; clean some of
it up (re-introduce patterns, where appropriate) and allow a single
register to belong to multiple disassembly classes; also keep track
of the x86 register number again.
