Shopping Podder - the Best of Computer Postings! :: View topic - How do I find out what C's long double is?

Dom Fulton · Guest

I've had a go at asking this on comp.lang.c, but I've had no luck so
far. In short, I need some way to determine what exactly a C "long
double" type actually is or, at the very least, how many bits it
contains. Any ideas?

The long version is:

I need to export floating-point data from system A to system B. To do
this, I need to know the characteristics of the data format on system
A; in particular, I need to know if it conforms to IEC60559, and which
IEC60559 type it is. I would have the same problem if I needed
to do bit manipulation of the FP data (which is what system B does).

The problem is that C (or, to be more precise, the compiler in
combination with libc) exposes 3 FP types, which may be a subset, or a
superset, or even unrelated to the FP support from the underlying
hardware. 'sizeof' gives me no useful information about the 3 exposed
types.

My best guess so far is:

1) if __STDC_IEC_559__ is not defined, then I can find out nothing
useful about the types;

2) if __STDC_IEC_559__ *is* defined then (from pp442/445 of the C99
spec):

3) 'float' must be a 32-bit IEC60559 single

4) 'double' must be a 64-bit IEC60559 double

5) 'long double' may be anything. It can be a non-IEC extended format,
an IEC double, an IEC 80-bit, or an IEC 128-bit. C appears to have no
way to tell me what this type is. I can deduce its behaviour from the
constants in float.h, but I have no guarantee that I can correctly
determine the actual long double bitsize from these constants.

Any ideas? I only have to support SunOS, Windows, and various Linuxes,
so I can hard-wire in the knowledge if necessary, but I'd rather not.
I can't find anything useful in the gcc include files. There was a
defined long double size in an older gcc version, but this seems to be
gone now.

Thanks

-Dom

Nick Maclaren · Guest

In article <dl7vt3l4bf1qsk1cbn28k0rtf3u4fmb3lv@4ax.com>,
Dom Fulton <wes104@yahoo.com> writes:
|>
|> I've had a go at asking this on comp.lang.c, but I've had no luck so
|> far. In short, I need some way to determine what exactly a C "long
|> double" type actually is or, at the very least, how many bits it
|> contains. Any ideas?

I could refer you to lots of 1970s work ... but:

Number of bits in storage unit: sizeof(double)*CHAR_BIT
Number of bits in value (assuming FLT_RADIX == 2):
1+(int)ceil(log2(DBL_MAX_EXP-DBL_MIN_EXP))+DBL_MANT_DIG

|> The long version is:
|>
|> I need to export floating-point data from system A to system B. To do
|> this, I need to know the characteristics of the data format on system
|> A; in particular, I need to know if it conforms to IEC60559, and which
|> IEC60559 type it is. I would have the same problem if I needed
|> to do bit manipulation of the FP data (which is what system B does).

You need to run a test program to check (B) the size (see above),
(B) whether it supports denormalised numbers and (C) whether it
supports infinities and NaNs. Don't trust it to do the latter.

|> The problem is that C (or, to be more precise, the compiler in
|> combination with libc) exposes 3 FP types, which may be a subset, or a
|> superset, or even unrelated to the FP support from the underlying
|> hardware. 'sizeof' gives me no useful information about the 3 exposed
|> types.

True. Join the experts' club :-)

|> My best guess so far is:
|>
|> 1) if __STDC_IEC_559__ is not defined, then I can find out nothing
|> useful about the types;

See above.

|> 2) if __STDC_IEC_559__ *is* defined then (from pp442/445 of the C99
|> spec):
|>
|> 3) 'float' must be a 32-bit IEC60559 single
|>
|> 4) 'double' must be a 64-bit IEC60559 double

Vaguely, yes, but I wouldn't trust it all that far.

|> 5) 'long double' may be anything. It can be a non-IEC extended format,
|> an IEC double, an IEC 80-bit, or an IEC 128-bit. C appears to have no
|> way to tell me what this type is. I can deduce its behaviour from the
|> constants in float.h, but I have no guarantee that I can correctly
|> determine the actual long double bitsize from these constants.

If you suspect that the constants in <float.h> are incorrect, then
you can write code to determine that - but it needs more work, of the
sort that was fairly routine in the 1970s.

Regards,
Nick Maclaren.

Dom Fulton · Guest

On 18 Mar 2008 12:03:05 GMT, nmm1@cus.cam.ac.uk (Nick Maclaren) wrote:

Terje Mathisen · Guest

Dom Fulton wrote:

Nick Maclaren · Guest

In article <nlpvt3l60caq99u0j05ugkgotndel6jbjb@4ax.com>,
Dom Fulton <wes104@yahoo.com> writes:
|>
|> >Number of bits in storage unit: sizeof(double)*CHAR_BIT
|> >Number of bits in value (assuming FLT_RADIX == 2):
|> > 1+(int)ceil(log2(DBL_MAX_EXP-DBL_MIN_EXP))+DBL_MANT_DIG
|>
|> Very nice; thanks (and obvious now that you've pointed it out).
|>
|> There's a fly in the ointment, though, which is that it's not quite
|> correct. ...

Yes, I should have said that I hadn't tested it - but you can't expect
testing for free :-)

|> After some digging about, it seems that x_MANT_DIG is the logical
|> number of mantissa digits, including the missing MS significand bit,
|> so it should be (x_MANT_DIG - 1). But '80' is correct on my box, the
|> reason being that the x86 double extended format apparently has an
|> explicit MS significand bit (although I suspect that the silicon may
|> actually only be 79 bits?)

A good point. I wasn't thinking about it very hard, and forgot that.
There are other such gotchas on architectures that are very different
from IEEE 754, but I omitted them for simplicity.

|> After a (very cursory) look at the C99 spec there doesn't seem to be a
|> way to find out whether the MS significand bit is implicit or
|> explicit, so I guess I'll have to live with this.

That's right. You can do it, but it's painful.

Regards,
Nick Maclaren.

Nick Maclaren · Guest

In article <COKdnV_597ibaULanZ2dnUVZ_j6dnZ2d@giganews.com>,
Terje Mathisen <terje.mathisen@hda.hydro.com> writes:
|>
|> I'm guessing the only way to determine if the leading bit exist or not
|> is by checking out what happens when you start underflowing:
|>
|> What happens when the exponent gets close to zero? Do you drop one extra
|> bit of resolution or not?

No, that won't work. Underflow handling doesn't necessarily give any
hints about whether there is a leading bit or not. That is enough to
distinguish IEEE 754 (sensu stricto) from Intel, but not generally.
It won't even distinguish IEEE 754 with no denorms (as commonly used)
from Intel.

There is no substitute for reverse engineering the format properly.
It can be done if you assume a fairly conventional power-of-two
radix representation, but gets to be a gibbering nightmare beyond
that.

Regards,
Nick Maclaren.

glen herrmannsfeldt · Guest

Dom Fulton wrote:

glen herrmannsfeldt · Guest

Dom Fulton wrote:

Nick Maclaren · Guest

In article <556dncn2nJentH3anZ2dnUVZ_siknZ2d@comcast.com>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
|>
|> As long as you only need IEEE types I suppose it might work.
|>
|> Look at VAX floating point (F, D, G, and H-float) for cases where
|> your tests would fail. Also, hex-float and now decimal-float
|> on IBM mainframes. Are you considering different endianness?

Not to say lots of older formats (now all obsolete, except in some
embedded devices?), TWO different formats of decimal floating-point
specified in IEEE 754R (one the same as on IBM mainframes, and one
supposed to be forthcoming on Intel chips) , and whatever lunacies
occur between now and the end of life of the program ....

Regards,
Nick Maclaren.

Michel Hack · Guest

On Mar 18, 7:05 am, Dom Fulton <wes...@yahoo.com> wrote:

Nick Maclaren · Guest

In article <9a46019b-25dc-4b7f-b732-340f51b57ae0@n58g2000hsf.googlegroups.com>,
Michel Hack <hack@watson.ibm.com> writes:
|>
|> Guy Steele once wrote a floating-point conversion program in plain C
|> that ran on nearly any hardware, and must have performed some of the
|> kind of tests I mentioned above.

There were older ones in Fortran that did the same, plus code that
actually analysed the arithmetic, and ran on an even wider range of
hardware. They were NOT pretty! The two killers are the following
(in any language):

You can only analyse and/or handle aberrant behaviours that you
expect. The CDC 6600 and 7600 caught out a lot of otherwise highly
portable programs, for example. Even Intel is tricky if compilers
sometimes use SSE and sometimes don't.

You can't detect the exception boundaries, because you are into
undefined behaviour as soon as you hit them (i.e. unpredictable
nonsense, crashes etc.) I have some C code that attempts to, but
it failed on the Alpha, most vector systems, and so on.

Regards,
Nick Maclaren.


www.ShoppingPodder.com Leading Computer Shopping, News and information	Part of the Identityscape.com network... getxfactor.com jmoodmusic.com smartbusinesschoices.com mintdepot.com lowfaresalways.com evangelicalview.com shoppingpodder.com soproudlywehail.com webnews.ws currenthumor.com

Shopping Podder - the Best of Computer Postings! Forum Index -> Computer Architecture - Arithmetic
Page 1 of 1