Re: [rfc] Add some more floatformat types ....

[Andrew Cagney <ac131313@cygnus.com>]

> The i386/i387 ISA always stores values in memory as an 80-bit
> quantity.  All floating point instructions are defined to operate on
> 80-bit memory operands.  As far as the ISA concerned there are no
> 96-bit or 128-bit floating point types.  That's why I think we
> shouldn't introduce the floatformat_i387_ext96 type you're proposing,
> and just keep the floatformat_i387_ext we already have.  I think
> pretending that there are several different ways to store an extended
> floating point number, would be wrong.
> 
> The confusion is caused by the dominant C ABI where `sizeof (long
> double)' is 12.  That's why we define TARGET_LONG_DOUBLE_BITS to 96.
> That's what the coding fragment you see above is all about.  It is
> perfectly possible to create a compiler on the i386 where `sizeof
> (long double)' would be 10.  In fact there is a PASCAL compiler that
> does exactly that.  But this doesn't change the fact that the
> underlying floating point layout is the same 80-bit format defined by
> the ISA.

Ah, ok, now I understand.  So this means the original i386 did a 4:4:2 
memory transfer when storing an extended float (long sigh)? The extra 2 
bytes and the end of the `long double' always remaining undefined (long 
double sigh)?  I've been hacking sane hardware for too long.

I think I'll clarify the `struct type . length' to:

``Length of storage for a value of this type. This is length of the type 
and not the length of the value that resides within the type.  An 
i386-ext floating-point value, for instance, only occupies 80 bits of 
what is typically a 96 bit `long double'.''

I'll drop the i387_ext from the list of things to add to floatformat.h.

> I would simply introduce the builtin_type_i387_ext for the 80-bit
> floating point type and keep builtin_type_long_double for the 96-bit
> floating point type, both based on floatformat_i387_ext.
> register_virtual_type would then indeed return builtin_type_i387_ext
> for the floating-point registers.

Ok.  The key thing here being that GDB gets two instead of one i387_ext 
`struct type' (because the existing builtin_type_long_double can't 
correctly describe an i387 register) which is really all I'm trying to 
achieve.

--

 > The IA-64, for instance, has an 82 bit floating-point register.  That
 >    register is always represented in memory as 128 bits. 
Consequently, my
 >    proposal includes ia64_ext128 and not ia64_ext82.
 >
 > So we only need a single floatformat_ia64_ext.  Why not keep the
 > floatformat_ia64_ext that we already have in ia64-tdep.c and move it
 > to ../libiberty/floatformat.c?

Dam!  You spotted my cunning plan :-)  That is one of the next steps. 
In the light of the exchange above, a double check on this one is in order.

Kevin, am I correct in saying that the ia64 reads/writes 16 bytes when 
loading/storing an ia64_ext?

Mark, this meaning that the ia64_ext should have a size of 128 and not 
82 as it currently does in ia64-tdep.c?

enjoy,
	Andrew