xref: /src/regress/lib/libc/ieeefp/testfloat/notes

$NetBSD: README.NetBSD,v 1.3 2003/07/26 19:38:47 salo Exp $


Changes at initial import...ross (a] 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 arm/fpa-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.