From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: [rfc] Add some more floatformat types .... Date: Thu, 16 Aug 2001 20:10:00 -0000 Message-id: <3B7C8AFA.1080504@cygnus.com> References: <3B76164B.9060908@cygnus.com> <3B7C1287.9080906@cygnus.com> X-SW-Source: 2001-08/msg00200.html [I dropped binutils] > Andrew Cagney writes: > > >> > The attached adds the floatformats: >> > >> > floatformat_i387_ext80; >> > floatformat_i387_ext96; >> > >> > Explicitly sized x86 float formats. >> > >> > Depending on where/how it is stored, >> > an i386 extended could use 80 (10 bytes) >> > or 96 (12 bytes). > > > Andrew, I thought I (implicitly) raised some objections to this > change. See > > http://sources.redhat.com/ml/gdb/2001-07/msg00401.html I am thinking of this as a separate but related patch. Here I'm only trying to define all known ways that a floating point value can be stored in memory. > To clarify things a bit: The ISA (that stands for Istruction Set > Architecture doesn't it) defines a single 80-bit extended floating > point format. On top of that floating point format most ABI's build a > a 96-bit extended floating point type (e.g. GCC's `long double'). I'd > like GDB to somehow maintain this concept, by *not* introducing the > floatformat_i387_ext80 and floatformat_i387_ext96 types you propose. > Instead we should make the distinction at the builtin_type_* level. > By making the 80-bit and 96-bit builtin_type_* variants share the same > underlying floatformat_* variable, we can easiliy check whether two > floating point formats on the ABI level share the same encoding on the > ISA level. I think floatformat is something that exactly describes how an ISA stores a floating-point value in memory. Remember, GDB stores register values in memory. 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. Similarly, the ARM has an 80 bit floating point register. That value is stored in memory as using 96 bits ordered as either big or littlebyte-bigword endian. The extra 16 bits are squeezed into the middle of that memory value. Hence, arm_ext_big and arm_ext_littlebyte_bigword. (I should probably make those ext96_...?) Looking at the i387, I'd tend to suspect that it has been assuming a few too many things. How often, for instance does the code sequence: /* clear the entire 96 bit buffer. */ memset (size of type); /* now store the float in the first 80 bits. */ doublest_to_floatformat (i387_ext); appear? I think this code just happening to work because i387 is a little endian architecture. All other targets (especially big endian ones) have instead used a float-format that exactly described the full 96 bits of memory (big endian ones have little choice in this matter :-). Looking in more detail at the i387/i386. I think, eventually, the following changes can be made: register_virtual_type(fp) return a type that specifies i387_ext80. This exactly describes the contents of the floating-point register buffer. register_convert_to/from_virtual() use the floatformat conversions to convert robustly convert between the registers i387_ext80 and the requested float-format (typically i387_ext96) floatformat for long-double on an i387 be set to i387_ext96. For the short term, the floatformat code could also be tweeked to recognize things like ext80 and ext96 as equivalent (provided things are padded correctly). Someone might even get carried away and tweek it to recognize ieee_double_big as byte swapped ieee_double_little .... Andrew