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.
assemble.c was full of code containing ins->oprs[c - 0xxx] where 0xxx
was the base of the particular code block. Verbose and error prone
when code is moved around. Now we precompute opx = &ins->oprs[c & 3]
before dispatching, resulting in less code.
Don't warn for overflow in segmented references; those are linker
references and it is up to the backend or the linker to warn if they
overflow their permitted size.
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.)
Fix warning in rdfload.c about cast to pointer of different size when
compiling on 64 bits. Of course, rdfload is probably useless on 64
bits, but it's pretty useless in the first place.
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.
Some platforms apparently feel -std=c99, which defines
__STRICT_ANSI__, should also hide a bunch of function prototypes.
This rather sucks. At least try to deal with it.
MinGW and DJGPP both have this problem, in particular.
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.
(pradix && pradix > sradix) etc. is unnecessary since pradix and
sradix cannot be negative, so zero is always the smallest value.
Put in a comment explaining why making the default radix == 10 doesn't
need any additional error checking.
A floating point number starting with 0. 0e or 0E is still decimal.
Make it easier by falling back to the standard decimal conversion
routine for anything not recognized as a radix prefix.
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.
Actually enforce the exponent capping, as opposed to only enforcing it
to within a factor of 10. Furthermore, continue to scan the string in
order to check for invalid characters.
Finally, 16384 is too tight of a bound for a binary exponent: it's a
tight bound, but the shift added due to the digit string can move the
cap into the active region (±16383). Thus, change it to 20000 to be
on the safe side.
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.)
