Re: Unifying the x86 FPU register sets

[Andrew Cagney <ac131313 at cygnus dot com>]

Jim Blandy wrote:

> (This last conversion is controversial, since it loses information;
> ideally, GDB would perform the operations in the target's format,
> using some software implementation of IEEE floating point arithmetic.)

(accessed using alu methods added to struct value or struct type :-)

> So, here's my understanding of folks' suggestions about tm-i386.h:
> 
> - REGISTER_VIRTUAL_TYPE should be some type from tm-i387.c, dedicated
>   to describing FPU registers.  That way, it's not dependent on today's
>   compiler's interpretation of `long double'.

Check config/mips/tm-mips.h.  It is doing similar for the integer
registers.  They are defined in terms of builtin_type_uint32 et.al. 
(uint32 comes straight from C9X).

Extending gdb's type system to include explicitly sized FP types makes
good sense.

> - REGISTER_VIRTUAL_TYPE should be 12 bytes long, and
>   REGISTER_CONVERT_TO_{VIRTUAL,RAW} should simply account for the
>   position of the 10-byte value within the 12-byte space.
> 
>   It makes me a little uncomfortable to have REGISTER_VIRTUAL_TYPE
>   specify a 12-byte size, while floatformat_i387_ext is a ten-byte
>   format, but I think it should work fine.
> 
> - {TARGET,HOST}_LONG_DOUBLE_{FORMAT,BITS} should be defined as
>   appropriate in the right tm-*.h and xm-*.h files, not in tm-i386.h.
>   The latter doesn't know what compiler you're using, and so can't say
>   how long its types are.
> 
> The implications carry on to Linux as follows:
> 
> - Once those definitions are corrected in tm-linux.h, the
>   TARGET_{EXTRACT,STORE}_FLOATING macros will never be used, because
>   the earlier clauses in extract_floating and store_floating will
>   apply, so we can delete the TARGET_{EXTRACT,STORE}_FLOATING
>   definitions from tm-linux.h.
> 
> - But tm-linux.h is the only target in GDB that defines them, so we
>   can remove all references to them from GDB completely.

Ya!!!

	Andrew