Re: Unifying the x86 FPU register sets

[Mark Kettenis <kettenis at wins dot uva dot nl>]

   From: jtc@redback.com (J.T. Conklin)
   Date: 20 Oct 1999 13:36:30 -0700

   Jim> What happens at present is this:
   Jim> - tm-i386.h provides everything you need to get (lossy) float
   Jim>   handling on any host.
   Jim> - the more specific i386/tm-*.h files might use further knowledge
   Jim>   about the host to get better behavior, by redefining the
   Jim>   REGISTER_VIRTUAL_TYPE, REGISTER_CONVERTIBLE, etc. macros.
   Jim>
   Jim> The tm-linux.h header does this now --- look for LD_I387.

   But the test that sets LD_I387 seems risky to me --- just because the
   host is an X86 and supports the long double type does not mean long
   doubles on that host are 80 bit floats.

Yep it is!  If you take a look at gcc you'll notice that OSF/1 on the
i386 has a 64-bit `long double'.  In other words, a `long double' is
the same thing as a `double'.  You'll also notice that all the other
i386 ports (including Linux) have a 96-bit `long double'.  In other
words `sizeof (long double)' is 12.  So there's something really fishy
about those 80-bit floats.

   Perhaps the best place for these (re-)definitions is in the nm-*.h
   headers, since then it is known that the host == target.  But that
   loses for cross debugging X86 FP code from other hosts with extended
   precision long doubles.

   Or longer term, perhaps the tm-* files could somehow define the target
   FP type(s), while the xm-* files could provide macros how to convert
   FP type X to the type supported on the host.  Somehow the two taken
   together, plus whatever magic would make it work, would be used to
   handle FP conversions.  Hmmm, needs more thought...

In principle it should be enough to add

   #define TARGET_LONG_DOUBLE_FORMAT &floatformat_i387_ext

to all `tm-xxx.h' files for targets that have the 80-bit i387 `long
double' type, and add 

   #define HOST_LONG_DOUBLE_FORMAT &floatformat_i387_ext

to all `xm-xxx.h' files for hosts that have that same type.  The i387
registers would be treated as `long doubles' ig the host has `long
double' (thus HAVE_LONG_DOUBLE is defined) and `sizeof (long double)'
matches TARGET_LONG_DOUBLE_BIT.  GDB already contains enough code to
convert between the various floating point formats and the
TARGET_{EXTRACT|STORE}_FLOATING hackery in `tm-linux.h' would be
unecessary.  However, this doesn't work since `sizeof (long double)'
doesn't match {HOST|TARGET}_LONG_DOUBLE_BIT.

I think this mess can be solved by viewing the i387 extended floating
point type as a 96-bit floating point type.  If one looks at
`libiberty/floatformat.c', one sees that this isn't really special
since the m68881, i960, m88110 and arm extended floating point types
are also 80-bit-defined-as-96-bit formats[1].
This means that defining TARGET_LONG_DOUBLE_BIT to 96, has the
additional advantage that examining long double values on those host
with the i386 as a target could become possible.
The only problem is that the FP data registers are only 10 bytes wide,
but this can be taken care of by using REGISTER_CONVERT_TO_* macros.

I have already been experimenting with this setup, and should be able
to provide the necessary patches without too much delay.

Mark

[1] AFAICT the i960 extended floating point type is identical to the
i387 type altough the definitions of `floatformat_i960_ext' differs
from `floatformat_i387_ext'.