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.)
- Allow underscores as group separators in numbers, for example:
0x1234_5678 is now a legal number. The underscore is just ignored,
it adds no meaning.
- Recognize dotless floating-point numbers, such as "1e30". This
entails distinguishing hexadecimal numbers in the scanner, since
e.g. 0x1e30 is a perfectly legitimate hex constant.
Actually generate the appropriate floating-point warnings, and only
one per assembly, pretty please.
Correct the round-to-overflow condition; as written all numbers with a
positive exponent were considered overflows!
Refactor the floating-point formatting code so that the 80-bit format
can be supported with common code. This fixes 80-bit denorms as a
side effect; the shift value in 80-bit denorms was completely wrong.
Substitute in nasm64developer's "acfloat4" routine. This
floating-point conversion routine is not perfect (it gets a fair
number of LSB errors), but the old NASM code was just plain broken.
nasm64developer's code at least gets within ±1 LSB.
