From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Mark Kettenis , Kevin Buettner Cc: gdb-patches@sources.redhat.com Subject: Re: [rfc] Add some more floatformat types .... Date: Fri, 17 Aug 2001 09:13:00 -0000 Message-id: <3B7D4280.8010005@cygnus.com> References: <3B76164B.9060908@cygnus.com> <3B7C1287.9080906@cygnus.com> <3B7C8AFA.1080504@cygnus.com> <200108171308.f7HD8Q325622@delius.kettenis.local> X-SW-Source: 2001-08/msg00203.html > 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