version into different directories. Which version a given port uses is
controlled by the SOFTFLOAT_BITS make variable. This is set to 64 (which
uses the same code we had before) by default. 32-bit platforms that don't
need extended precision support might get better performance by using 32.
Set the ARM port to use the 32-bit version of SoftFloat, since this is more
than a factor of two faster than the 64-bit version. This should get the
floating-point performance back to what it was in 1.5.
variable, float_exception_mask (#defined to _softfloat_float_exception_mask)
contains the current exception mask.
Also make the argument to float_raise into an fp_except.
Also synchronise file header comments between files.
- Add alignment-safe double and float unions.
- Use the above for the __infinity and __nan constants on all
architectures that use the standard ieee754 representation of
those constants.
- Add a single copy of various ieee754 math functions (frexp, isinf,
isnan, ldexp and modf) that had numerous duplicates among the
arch-specific directories.
- Use the above functions on all architectures where the generic C
versions where used. Architectures that had local assembly
routines are untouched (for those functions only).
struct ieee_double, rather than a pointer cast. This seems to enable
GCC 2.95.3 to get the instruction dependencies right (the old one fell
foul of ANSI aliasing rules), and it also generates more sensible code in
general.
If this is the correct solution, it should be applied to the other ports.
If it's not, someone should come up with one that _is_ correct.
The code is (almost) a direct copy of the current arm26 sources.
It's identical to the current arm32 sources, with the following exceptions:
- _C_LABEL is used on references to C labels from assembler.
- Function returns in assembler have APCS-26 versions in #ifdef __APCS_26__.
- It uses SoftFloat 2a rather than SoftFloat 1a.
The first two of these should be inconsequential. I believe that SoftFloat 2a
should work on arm32 and be backward-compatible with existing code, but this
is not obviously true. For now, arm32 remains using its own bits of libc.
wiz