- Correct the building on the disassembler decision tree.
- Handle SSE instructions with F2 prefix (\332) correctly.
- Mark instructions which are now used as prefixes with ND.
(In a future version when we have better CPU version handling,
we should probably build the decision tree at runtime based on
the selected CPU feature sets.)
- Sanitize the handling of \144-147 and \154-157 in both the assembler
and disassembler. They take an opcode byte as argument; don't
pretend they don't.
Address data is always int64_t even if the size itself is smaller;
this was broken on bigendian hosts (still need testing!)
Create simple "write sized object" macros.
Un-special-case "xchg rax,rax"; allow it to be encoded as 48 90 for
orthogonality's sake. It's a no-op, to be sure, but so are many other
instructions.
"xchg eax,eax" is still special-cased in 64-bit mode since it is not a
no-op; unadorned opcode 90 is now simply "nop" and nothing else.
Make the disassembler detect unused REX.W and display them as an "o64"
prefix.
More correct -- but not fully correct -- handing of 64-bit addressing
in ndisasm. In particular, we need to generate "a32" versus "dword"
where applicable.
Revamp the address- and prefix-handling code to make more sense in
64-bit mode. We are now a lot closer to where we want to be, but
we're not quite there yet.
ndisasm may very well have problems, or give counterintuitive output.
However, checking it in so we can make forward progress.
Both C and C++ have "bool", "true" and "false" in lower case; C
requires <stdbool.h> for this, in C++ it is an inherent type built
into the compiler. Use those instead of the old macros; emulate with
a simple typedef enum if unavailable.
Concentrate compiler dependencies to compiler.h; make sure compiler.h
is included first in every .c file (since some prototypes may depend
on the presence of feature request macros.)
Actually use the conditional inclusion of various functions (totally
broken in previous releases.)
Auto-generate 0x67 prefixes without the need for \30x codes; the
prefix is automatically added when there is a memory operand with
address size differing from the current address size (and impossible
combinations checked for.)
Modify the disassembler so that we can have separate instruction
tables for prefixed instructions. As it was, all instructions which
started with 0F were linearly searched, and that is by now more than
half the instruction set.
Add the SSSE3, SSE4.1 and SSE4.2 instruction sets. Change \332 to be
a literal 0xF2 prefix, by analog with \333 for 0xF3 prefix (the
previous \332 flag changed to \335). This is necessary to get the REX
prefix in the right place for instructions that use it.
We are going to have to go in and change existing instruction patterns
which use these, as well.
Support r/m operands for non-integer operands types, i.e. mmx or xmm
operands. This allows mmx and xmm operands to be written more
compactly, speeding up the assembler.
- Implement \366 codes in ndisasm
- Prefer instruction patterns without loose prefixes if possible
- Fix improper initialization of operands in ndisasm
Implement "REL" and "ABS" modifiers for offsets in 64-bit mode. This
replaces "rip+XXX" type addressing. The infrastructure to set the default
mode is there, but there is nothing to throw the switch just yet.
\313 indicates a fixed 64-bit address size. It was incorrectly
documented and incorrectly implemented in the assembler, and was
unimplemented in the disassembler.
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.
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.
a) Automatically generate dependencies for all Makefiles;
b) Move register definitions to a separate .dat file;
c) Add support for "unimplemented but there in theory" registers.
