Add copyright headers to the *.c/*.h files in the main directory. For
files where I'm sure enough that we have all the approvals, I have
given them the 2-BSD license, the others have been given the "LGPL for
now" license header. Most of them can probably be changed after
auditing.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
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.
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.)
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.
- 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.
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.)
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.
