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.)
Remove bogus "treat labels different from immediates" code, which
would result in generating of a relative mod/rm but without adjusting
the address accordingly.
Update addressing mode test.
Add special operators to allow the use of floating-point constants in
contexts other than DW/DD/DQ/DT/DO.
As part of this checkin, make MAX_KEYWORD generated by tokhash.pl,
since it knows what all the keywords are so it can tell which one is
the longest.
INVLPGA is defined as taking rax,ecx but "the portion of rax used to
form the address is determined by the effective address size", so it
is really ax/eax/rax.
Unify all the standard IEEE formats into one function, add support for
IEEE standard 128-bit floating point numbers.
The 80-bit format is still special since it explicitly represents the
integer portion.
This checkin completes what is required to actually generate SSE5
instructions. No support in the disassembler yet.
This checkin covers:
- Support for actually generating DREX prefixes.
- Support for matching operand "operand X must match Y"
Simple scripts to generate performance benchmarks for label,
macro and token lookups. The label and macro lookups are simple
numerical sequences; it may be desirable to add some more
sophisticated algorithms for producing tokens in case we want to
compare different hash functions against each other.
