On Thu, Oct 01, 2015 at 12:42:05AM +0200, Mark Kettenis wrote: > > Date: Wed, 30 Sep 2015 19:33:44 +0200 (CEST) > > From: "Ulrich Weigand" <uweig...@de.ibm.com> > > > > Hello, > > > > I've been looking into supporting __float128 in the debugger, since we're > > now introducing this type on PowerPC. Initially, I simply wanted to do > > whatever GDB does on Intel, but it turns out debugging __float128 doesn't > > work on Intel either ... > > > > The most obvious question is, how should the type be represented in > > DWARF debug info in the first place? Currently, GCC generates on i386: > > > > .uleb128 0x3 # (DIE (0x2d) DW_TAG_base_type) > > .byte 0xc # DW_AT_byte_size > > .byte 0x4 # DW_AT_encoding > > .long .LASF0 # DW_AT_name: "long double" > > > > and > > > > .uleb128 0x3 # (DIE (0x4c) DW_TAG_base_type) > > .byte 0x10 # DW_AT_byte_size > > .byte 0x4 # DW_AT_encoding > > .long .LASF1 # DW_AT_name: "__float128" > > > > On x86_64, __float128 is encoded the same way, but long double is: > > > > .uleb128 0x3 # (DIE (0x31) DW_TAG_base_type) > > .byte 0x10 # DW_AT_byte_size > > .byte 0x4 # DW_AT_encoding > > .long .LASF0 # DW_AT_name: "long double" > > > > Now, GDB doesn't recognize __float128 on either platform, but on i386 > > it could at least in theory distinguish the two via DW_AT_byte_size. > > > > But on x86_64 (and also on powerpc), long double and __float128 have > > the identical DWARF encoding, except for the name. > > > > Looking at the current DWARF standard, it's not really clear how to > > make a distinction, either. The standard has no way to specifiy any > > particular floating-point format; the only attributes for a base type > > of DW_ATE_float encoding are related to the size. > > > > (For the Intel case, one option might be to represent the fact that > > for long double, there only 80 data bits and the rest is padding, via > > some combination of the DW_AT_bit_size and DW_AT_bit_offset or > > DW_AT_data_bit_offset attributes. But that wouldn't help for PowerPC > > since both long double and __float128 really use 128 data bits, > > just different encodings.) > > > > Some options might be: > > > > - Extend the official DWARF standard in some way > > > > - Use a private extension (e.g. from the platform-reserved > > DW_AT_encoding value range) > > > > - Have the debugger just hard-code a special case based > > on the __float128 name > > > > Am I missing something here? Any suggestions welcome ... > > > > B.t.w. is there interest in fixing this problem for Intel? I notice > > there is a GDB bug open on the issue, but nothing seems to have happened > > so far: https://sourceware.org/bugzilla/show_bug.cgi?id=14857 > > Perhaps you should start with explaining what __float128 actually is > on your specific platform? And what long double actually is. > > I'm guessing long double is a what we sometimes call an IBM long > double, which is essentially two IEEE double-precision floating point > numbers packed together and that __float128 is an attempt to fix > history and have a proper IEEE quad-precision floating point type ;). > And that __float128 isn't actually implemented in hardware.
An IBM mainframe might want to discuss this point with you :-). See pages 24-25 of http://arith22.gforge.inria.fr/slides/s1-schwarz.pdf Latencies are decent, not extremely low, but we are speaking of a processor clocked at 5GHz, so the latencies are 2.2ns for add/subtract, 4.6ns for multiplications, and ~10ns for division. To put things in perspective, how many cycles is a memory access which misses in both L1 and L2 caches these days? > The reason people haven't bothered to fix this, is probably because > nobody actually implements quad-precision floating point in hardware. > And software implementations are so slow that people don't really use > them unless they need to. Like I did to nomerically calculate some > asymptotic expansions for my Thesis work... Which would probably run much faster if ported to a z13. Gabriel
