Unifying the x86 FPU register sets
Mark Kettenis
kettenis@wins.uva.nl
Thu Oct 21 09:13:00 GMT 1999
[ Sorry Eli, but I guess you know why you receive this message another
time ;-)]
Date: Thu, 21 Oct 1999 11:04:53 -0400
From: Eli Zaretskii <eliz@gnu.org>
< 5mwvsjoyu0.fsf@jtc.redbacknetworks.com > < 199910211332.PAA00729@delius.kettenis.local >
Subject: Re: Unifying the x86 FPU register sets
--text follows this line--
> Note that in `tm-go32.h' there is a
>
> #undef TARGET_LONG_DOUBLE_BIT
> #define TARGET_LONG_DOUBLE_BIT 96
>
> So DJGPP is already treating the 80-bit extended types as a 96-bit
> type.
Why, of course! ;-) That's because somebody noticed, a long time ago,
that this is required in order to get 80-bit registers supported.
Apparently the Linux people didn't notice it ;-).
> Then it will be very easy to support the i387 data registers as `long
> doubles' on hosts that have an equivalent type, without the LD_387
> kludge that's now used by DJGPP and Linux/i386.
I'm not sure. There's a related issue of whether the library supports
long double in scanf and printf families of functions. (There's also
the issue of the compiler support for long double, but it's a
non-issue for DJGPP and Linux ;-)
Would your suggestion handle all of these considerations?
Yes!
The nice thing is that GDB already has all the code that is necessary
to handle this. If the compiler doesn't support a 80/96-bit `long
double' type, the registers are converted to ordinary doubles right
away. Printing those should be no problem. If the compiler does
support a 80/96-bit `long double' type, the registers are padded to
96-bits. Before printing, these are converted to the representation
the host uses, taking in account endianness and other representation
details. If the library on the host supports printing long double
(PRINTF_HAS_LONG_DOUBLE) it is printed with full precision. If not,
then the result is converted to double before printing. See
valprint.c:print_floating() for details.
Mark
More information about the Gdb
mailing list