BR 1974170: VCVTPD2PS, VCVTPD2DQ, VCVTTPD2DQ with a memory operand are
ambiguous without a specific operand size, so force one to be added.
Split the instruction pattern due to our current clunky handling of
MMX/XMM/YMM registers together with sizes. Fix in the future, please!
Support is4 bytes without meaningful information in the bottom bits.
This is equivalent to /is4=0 for the assembler, but makes the bottom
bits don't care for the disassembler.
Initial NDISASM support for AVX instructions and VEX prefixes. It
doesn't mean it's correct, but it seems to match my current
understanding. It can disassemble *some*, but not *all*, of the AVX
test cases (which are known to be at least partially incorrect...)
First cut at AVX machinery support. The only instruction implemented
is VPERMIL2PS, and it's probably buggy. I'm checking this in with the
hope that other people can start helping out with (a) testing this,
and (b) adding instructions.
NDISASM support is not there yet.
This checkin creates the following date and time macros:
__DATE__, __TIME__, __UTC_DATE__, __UTC_TIME__: strings
__DATE_NUM__, __TIME_NUM__, __UTC_DATE_NUM__, __UTC_TIME_NUM__:
civil dates in digit-string formats
__POSIX_TIME__: time in POSIX time_t format
Support the zero-operand form of floating-point instructions. Note
that in most cases, the form generated is actually the "popping" form,
e.g. "FADD" becomes "FADDP st0,st1". This is in accordance with the
Intel documentation. "FADDP" is also supported.
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.
Correct the implementation of %arg and %local.
It's questionable how much they make sense for 64-bit mode; even in
32-bit mode one normally make references off the stack pointer instead
of the base pointer (frame pointer), but that requires keeping track
of the stack pointer offset.
Permit opcode names to be used as labels if and only if they are
succeeded by a colon. Opcode names occurring when parsing expressions
are all treated as labels; a leading colon occurred when parsing an
instruction forces a parser restart with the instruction forcibly
treated as an identifier.
Use a 32-bit limb size ("like a digit, but bigger") for floating-point
conversion. This cuts the number of multiplications per constant by a
factor of four.
This means supporting fractional-limb-sized numbers, so while we're at
it, add support for 8-bit floating point numbers (apparently used in
graphics and in audio compression applications.)
Correct the handling of floating-point tokens in the preprocessor.
The preprocessor scanner and the main scanner really are painfully
divergent for no good reason.
For consistency, support binary and octal floating-point, and accept
a "0d" or "0t" prefix for decimal floating-point. However, we do not
accept a binary exponent (p) for a decimal mantissa, or vice versa.
Allow any radix letter from the set [bydtoqhx] to be used either
"Intel-style" (0...x) or "C-style" (0x...). In Intel style, the
leading 0 remains optional as long as the first digit is in the range
0-9.
As a consequence, allow the prefix "0h" for hexadecimal floating
point.
Since we allow the prefix $ instead of 0x for integer constants, do
the same for floating point. No suffix support at this time; we may
want to consider if that would be appropriate.
1e30 is a floating-point constant, but 1e30h is not. The scanner
won't know that until it sees the "h", so make sure we keep enough
state to be able to distinguish "1e30" (a possible hex constant) from
"1.e30", "1e+30" or "1.0" (unabiguously floating-point.)
