Re: Unifying the x86 FPU register sets

[jtc at redback dot com (J.T. Conklin)]

>>>>> "Jim" == Jim Blandy <jimb@cygnus.com> writes:
>> ! #define REGISTER_VIRTUAL_TYPE(N)				\
>> !   (((N) == PC_REGNUM || (N) == FP_REGNUM || (N) == SP_REGNUM)	\
>> !    ? lookup_pointer_type (builtin_type_void)			\
>> !    : IS_FP_REGNUM(N) ? builtin_type_double			\
>> !    : IS_SSE_REGNUM(N) ? builtin_type_v4sf			\
>> !    : builtin_type_int)
>> 
>> Why are FP registers treated as type `double'?  x87 uses long double,
>> not double, and tm-go32.h says this:
>> 
>> #define REGISTER_VIRTUAL_TYPE(N) \
>> ((N < FP0_REGNUM) ? builtin_type_int : \
>> (N < FPC_REGNUM) ? builtin_type_long_double : builtin_type_int)
>> 
>> i386-tdep.c clearly uses 10 bytes when it initializes
>> i386_register_byte[], so I gather that other x86 targets also support
>> the full 80-bit width of FP registers, right?  Don't we want all the
>> 80 bits in "info float"?

Jim> The 80-bit floating point format goes all the way back to the
Jim> 8087, I'm pretty sure.  So every target with an FPU uses the
Jim> 80-bit floating-point format.

Jim> When you're cross-debugging an x86 target, the host may not have long
Jim> double, or may not use the same long double format.  In this case,
Jim> GDB stores the full 80 bits in the register file (that's the "raw"
Jim> format), but converts it to a host double when it needs to produce a
Jim> `struct value' object.  libiberty/floatformat.c has routines for
Jim> ripping apart floats and reassembling them, which GDB uses.

I've had fleeting thoughts about linking GDB with a software FP
library like John Houser's SoftFloat that can handle the extended
precision FP formats found on the X86 and m68k on the theory that
if you're using long double, you're doing it for a reason, and 
that 80->64 bit conversion may lose the very information you need
to debug your program.

Jim> The generic `info float' implementation should do the best it can,
Jim> without requiring that host == target.

Agreed.

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.

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...

        --jtc

-- 
J.T. Conklin
RedBack Networks