Conversion notes.

This commit is contained in:
ross 2001-03-13 08:02:17 +00:00
parent 4d8829d5a8
commit d4a390a3c3

View File

@ -0,0 +1,53 @@
$NetBSD: README.NetBSD,v 1.1 2001/03/13 08:02:17 ross Exp $
Changes at initial import...ross@netbsd.org
o WARNS=2 fixes
o source reorganized with arch/
o <sys/endian.h> conversion
o <inttypes.h> conversion
o <ieeefp.h> conversion
o <asm.h> conversion
o the previously target-specific softfloat.h and milieu.h made mostly
generic. Still some work to do with default NaN bitpatterns, endian,
and arm26-DEMANGLE issues.
o arch/i386/systfloat.S extended to handle:
int32_t syst_floatx80_to_int32_round_to_zero(floatx80)
int64_t syst_floatx80_to_int64_round_to_zero(floatx80)
o LONG_DOUBLE_IS_FLOATX80 was used to enable both the C module system
access ops and the FLOATX80 tests, all of which also required FLOATX80.
Besides being rundundant, this made it impossible to use the asm module
for i386 which the package actually comes with and also made it
impossible to test FLOATX80 ops without compiler support even if the
machine actually does them. While this is arguably OK for a regression
test, the two cases are obviously different. Now, the tests (which
don't actually require any compiler-understood extended type) are
always run just by defining FLOATX80. If LONG_DOUBLE_IS_FLOATX80 is
also defined, then the C system ops are also enabled. To switch back
and forth, you modify only the arch/${MACHINE_ARCH}/Makefile.inc to
do the cpp def and add or remove systfloat.S. For regression testing,
it's better in C, but for testing the test itself or verifying a
regression, the .S module is a better reference case.
A similar change should probably be made for LONG_DOUBLE_IS_FLOAT128,
but we can't test that yet.
The basic rules:
LONG_DOUBLE_IS_FLOAT{X80,128}
define if you do not have a .S file and do have compiler
support, or have both and want to use the compiled version
(but then it may be necessary to remove the .S file or add
an ifndef to it)
FLOAT{X80,128}
define if you have either HW or SW support and want it tested
And to confuse things further: the .S files for i386 appear to have been
originally created by compiling C code with -S, at least as a start.
You can see some of the price of ANSI+IEEE in these files: a simple
conversion from floatxx to intxx requires storing, modifying, loading,
and restoring the modes on each conversion in order to get a specific
round, thanks to the four IEEE-mandated options. A pipeline/peephole
pass can no doubt fix this up within one function, but not if other
arithmetic is done in between.