Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
Re: Should the compiler warn about long doubles?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Should the compiler warn about long doubles?



This is what I understand about what the XLC and MrC 128 "long double" is.

[1] PowerPC does not support more than a 64 bit double in hardware
[with only one small exception, see 2]

[2] The multiply-accumulate instructions does not convert to back to
64 bits until after the instruction completes, so that the 64 bit
value is computed with more precision than IEEE 754 allows for
a 64 bit double. (For this reason most compilers which can generate
the fused multiply accumulate instructions have options for
disabling it so as to be more IEEE compliant).

[3] XLC and MrC support "double double" which is they "long double",
Originally I understand it was implemented for POWER (not POWERPC)
on a CPU which had 2 floating point FPUs which made it easy to run
2 64 bit double instructions at the same time.

[4] double double uses 128 bit to store a 118 bit (aprox) floating point
number, which is stored as two doubles. In effect the only
increase is in the number of bits in the effective fractional part.
I am still unclear if I should consider this to be 106 or 105 bits
because of the issues with the assumed "1" (remember normalized
floating point numbers are 1.fract * 2**exp and the 1 is assumed,
so it does not actually have to be stored in the number, except
zero and denormalized values which are special cases).

[5] While Mac OS was still 68K based, the "C" compiler moved to ANSI,
and people started using "long double" to map to extended precision
which was a 80 or 96 bit number depending. The issue here was in
some case performance.

Since using a type smaller than the internal computation size,
required that the compiler insert extra round (or truncate)
instructions to insure that the values was maintained in the
correct size (so that it would have the same behavior on
all platforms). Code often ran faster in extended precision as
these conversions were not needed.

This behavior relates to the "-ffloat-store" flag in GCC which
in part forces intermediate values to be converted back to the base
type (there are I think other related flags, but I am not going
to look them up since GCC is not my thing anyway).

So using "long double" == "double" is the preferred solution for
those people who were more interested in improving performance
than trying to increase precision.

[6] The extra instructions for rounding/truncation is is not an issue
on PowerPC (except as related to #2), and there are instructions
which do the double to single conversion as part of the instruction
I think that you pay an extra cycle for that, but I think that it
is still less expensive than requiring the extra instruction.

[7] I have been told, but I have not researched it my self that
the double double has issues with precision. What follows is
a message I received from someone who understands the issues
much better than I do: ("by Bob in his mail" refers to an
e-mail I wrote shortly after starting work at Metrowerks,
asking about double double).

I approach it from a different tack. The IBM/Moto
double-double scheme for a 128-bit type is in no way a
"'true' 128-bit double". The type, summarized by Bob in
his mail, suffers from all kinds of anomalies (and you
thought true floating point was bad) because its
precision (not accuracy) varies so much across different
values.

I would lobby against supporting the double-double type,
because it causes more headaches than it cures.

Compare, for example, support of the iA (Intel arch.) 80-bit
extended as long double. Borland did it, but Microsoft still
resists it. The win there is significant, especially with
standard bindings (a la C9x). Too bad Moto support of extended
support has gone the way of the 68K fpus.

My sense from talking to the Apple numerics gang (all of whom
I've worked with on and off over the past 17 years) is that PPC
double-double is a feature offered because it's there, not because
it confers measurable benefit. It's anomalous that making a
predictable, "closed" system like IEEE floating point is a
serious challenge that they've not yet met.

[8] An embedded PowerPC ABI document indicates that a long double is 16
bytes, and has the note:

Note - "extended precision (IEEE)" in Table 3-1 means IEEE 754
double extended precision with a sign bit, a 15-bit exponent with
a bias of -16383, 112 fraction bits (with a leading "implicit" bit).

and an addition note to the note:

Note - Compilers and system may implement the long double data type
in some other way for performance reasons, using a compiler option.
Examples of such formats could be two successive doubles or even
a single double. Such usage does not conform to this ABI, however
and runs the danger of passing a wrongly formatted floating-point
number to another conforming function as an argument. Programs
using other formats should transform long double floating-point
numbers to a conforming format before putting them in permanent
storage.

I am unclear if the document in question became an approved version of
the PPC Embedded ABI document or if it is still a proposal.

===============================

What follows are just my opinions:

1] I don't think that the "double double" implementation of "long double"
should be enabled except by a compiler option. Or if not this there
should be a warning (once per complication unit, i.e. main source
file) and a option which allows disabling this feature.

2] Headers should map the "long double" math functions to the double
functions unless the "128 bit double double" option is on.

3] I would like it if at least for this platform we agree on a MACRO
to indicate the presence of this option.

4] There should be a single word type that people can use to indicate
that they want this type (with out the issues related to "long double"
being different on different machines). Names like __double128__ seem
reasonable and with in the ANSI rules, headers can be then created
to rename that in anyway that is desired by the user/OS. (The compiler
should not define names outside the standard unless they have the
underscores to indicate that they are implementation specific).

5] I really think that programmers should avoid using "long double"
directly since you can't redefine it except by modifications to
the compiler, names like:

float128

can be created with a typedef

typedef long double float128;

providing options for simulating the type (at least in C++) with
compilers which don't support the type directly. To make life easier
it would be good to have these types in a header (along with typedefs
for all the other sizes of integers and floats).

That is my 2 cents.
--
___________________________________________________________________
Bob Campbell email@hidden 408.343.3744 x204
Metrowerks, Inc. Fax: 408.343.3755


References: 
 >Re: Should the compiler warn about long doubles? (From: Gregory Block <email@hidden>)
 >Re: Should the compiler warn about long doubles? (From: Stan Shebs <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.