Number of bits in C99 float types?

[Dom Fulton]

Has anyone got a mechanism for finding the number of bits in floats,
doubles, and long doubles? I need this to communicate with some
hardware.

I guess I could try to deduce this from float.h, but that looks
difficult.

I don't mind something which is system-specific; the older gccs had
various defines in cpu_limits.h and related files, but I can't find
anything in later gccs.

Thanks -

Dom

[Harald van =?UTF-8?b?RMSzaw==?=]

On Mon, 17 Mar 2008 20:13:21 +0000, Dom Fulton wrote:

Has anyone got a mechanism for finding the number of bits in floats,
doubles, and long doubles? I need this to communicate with some
hardware.

I guess I could try to deduce this from float.h, but that looks
difficult.

I don't mind something which is system-specific; the older gccs had
various defines in cpu_limits.h and related files, but I can't find
anything in later gccs.

If you're already looking for something system-specific, why can't you
simply put the number of bits as a constant in your code? What do you
want to do with the number of bits, that it's useful at all to be able to
deal with different numbers?

That said, every object consists of sizeof(object) * CHAR_BIT bits. Some
of those bits may not be useful in determining the value, depending on
the system and compiler. Most likely, on your system, this will work just
fine for floating point types.

[Dom Fulton]

I've got to support several different systems - Windows, SunOS, and
various Linuxes. I guess I could just find out what the answer is for
the various platforms, and hard-code it in, but that gives me a bad
feeling...

sizeof doesn't work; it's rounded up for alignment reasons. On most
systems, float/double/long double will be 32/64/80 bits, but sizeof
generally returns 96 or 128 for 80-bit floats.

Thanks -

Dom

[jacob navia]

Dom Fulton wrote:

I've got to support several different systems - Windows, SunOS, and
various Linuxes. I guess I could just find out what the answer is for
the various platforms, and hard-code it in, but that gives me a bad
feeling...

sizeof doesn't work; it's rounded up for alignment reasons. On most
systems, float/double/long double will be 32/64/80 bits, but sizeof
generally returns 96 or 128 for 80-bit floats.

Thanks -

Dom

You will find all you need here.
http://docs.sun.com/app/docs/doc/801...uc?l=ru&a=view
The processor is important, not the OS/ There you will find all docs
for x86 and SPARC. The power pc is IEEE too, without any support for
long double.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Harald van =?UTF-8?b?RMSzaw==?=]

On Mon, 17 Mar 2008 21:56:45 +0100, jacob navia wrote:

Dom Fulton wrote:

>I've got to support several different systems - Windows, SunOS, and
various Linuxes. I guess I could just find out what the answer is for
the various platforms, and hard-code it in, but that gives me a bad
feeling...

sizeof doesn't work; it's rounded up for alignment reasons. On most
systems, float/double/long double will be 32/64/80 bits, but sizeof
generally returns 96 or 128 for 80-bit floats.

[...]
The
processor is important, not the OS/

The processor and the OS are both important. The processor determines
which floating point representations are available, and the OS (along
with the compiler, I suppose) decides how those map them to C's types.

[Eric Sosman]

Dom Fulton wrote:

I've got to support several different systems - Windows, SunOS, and
various Linuxes. I guess I could just find out what the answer is for
the various platforms, and hard-code it in, but that gives me a bad
feeling...

sizeof doesn't work; it's rounded up for alignment reasons. On most
systems, float/double/long double will be 32/64/80 bits, but sizeof
generally returns 96 or 128 for 80-bit floats.

If sizeof(long double) * CHAR_BIT == 96 on some system,
then 96 *is* the number of bits in a long double, not some
kind of "rounded up" result. If you are attaching some other
meaning to "number of bits," you need to explain what you mean.
It might be

- The number of significand bits (variation: count or
omit a "hidden" bit),

- The number of bits that participate in the value
(sign, exponent, and significand),

- Something else altogether.

It might also help if you described what you intend to
do with the answer once you have it. So far, you've said
only that you need to "communicate with some hardware," a
description that's pretty low on the specificity scale.

--
Er*********@sun.com

[jacob navia]

Eric Sosman wrote:

Dom Fulton wrote:

>I've got to support several different systems - Windows, SunOS, and
various Linuxes. I guess I could just find out what the answer is for
the various platforms, and hard-code it in, but that gives me a bad
feeling...

sizeof doesn't work; it's rounded up for alignment reasons. On most
systems, float/double/long double will be 32/64/80 bits, but sizeof
generally returns 96 or 128 for 80-bit floats.

If sizeof(long double) * CHAR_BIT == 96 on some system,
then 96 *is* the number of bits in a long double, not some
kind of "rounded up" result.

No. In the x86 the long double is 10 bytes, but it
is rounded up into 12 (lcc-win) or even 16, just for
alignment reasons.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[santosh]

jacob navia wrote:

Eric Sosman wrote:

>Dom Fulton wrote:

>>I've got to support several different systems - Windows, SunOS, and
various Linuxes. I guess I could just find out what the answer is
for the various platforms, and hard-code it in, but that gives me a
bad feeling...

sizeof doesn't work; it's rounded up for alignment reasons. On most
systems, float/double/long double will be 32/64/80 bits, but sizeof
generally returns 96 or 128 for 80-bit floats.

If sizeof(long double) * CHAR_BIT == 96 on some system,
then 96 *is* the number of bits in a long double, not some
kind of "rounded up" result.

No. In the x86 the long double is 10 bytes,

ITYM the FPU registers.

but it is rounded up into 12 (lcc-win) or even 16, just for
alignment reasons.

[ymuntyan]

On Mar 17, 4:29 pm, jacob navia <[e-mail]:

Eric Sosman wrote:

Dom Fulton wrote:

I've got to support several different systems - Windows, SunOS, and
various Linuxes. I guess I could just find out what the answer is for
the various platforms, and hard-code it in, but that gives me a bad
feeling...

sizeof doesn't work; it's rounded up for alignment reasons. On most
systems, float/double/long double will be 32/64/80 bits, but sizeof
generally returns 96 or 128 for 80-bit floats.

If sizeof(long double) * CHAR_BIT == 96 on some system,
then 96 *is* the number of bits in a long double, not some
kind of "rounded up" result.

No. In the x86 the long double is 10 bytes, but it
is rounded up into 12 (lcc-win) or even 16, just for
alignment reasons.

Except when you use an MS compiler on windows.

Yevgen

[user923005]

On Mar 17, 6:16*pm, [e-mail] wrote:

On Mar 17, 4:29 pm, jacob navia <[e-mail]:

Eric Sosman wrote:

Dom Fulton wrote:
>I've got to support several different systems - Windows, SunOS, and
>various Linuxes. I guess I could just find out what the answer is for
>the various platforms, and hard-code it in, but that gives me a bad
>feeling...

>sizeof doesn't work; it's rounded up for alignment reasons. On most
>systems, float/double/long double will be 32/64/80 bits, but sizeof
>generally returns 96 or 128 for 80-bit floats.

* * If sizeof(long double) * CHAR_BIT == 96 on some system,
then 96 *is* the number of bits in a long double, not some
kind of "rounded up" result.

No. In the x86 the long double is 10 bytes, but it
is rounded up into 12 (lcc-win) or even 16, just for
alignment reasons.

Except when you use an MS compiler on windows.

The compiler in question does not change the size of the hardware long
double (but one could effectively argue that the C compiler
implementation formally defines what the size of a type for the
compiler is).

With the MS compilers, you can use 80 bits internally:
http://msdn2.microsoft.com/en-us/lib...24(VS.60).aspx says:
"The Microsoft run-time library sets the default internal precision of
the math coprocessor (or emulator) to 64 bits. This default applies
only to the internal precision at which all intermediate calculations
are performed; it does not apply to the size of arguments, return
values, or variables. You can override this default and set the chip
(or emulator) back to 80-bit precision by linking your program with
LIB/FP10.OBJ. On the linker command line, FP10.OBJ must appear before
LIBC.LIB, LIBCMT.LIB, or MSVCRT.LIB."

However, you do not get the full width when printing out the answers,
since the values get truncated to 8 byte doubles.

At any rate, giving me only 64 bits of my 80 bit floating point
registers stinks.

[ymuntyan]

On Mar 17, 8:41 pm, user923005 <[e-mail]:

On Mar 17, 6:16 pm, [e-mail] wrote:

On Mar 17, 4:29 pm, jacob navia <[e-mail]:

Eric Sosman wrote:
Dom Fulton wrote:
I've got to support several different systems - Windows, SunOS, and
various Linuxes. I guess I could just find out what the answer is for
the various platforms, and hard-code it in, but that gives me a bad
feeling...

sizeof doesn't work; it's rounded up for alignment reasons. On most
systems, float/double/long double will be 32/64/80 bits, but sizeof
generally returns 96 or 128 for 80-bit floats.

If sizeof(long double) * CHAR_BIT == 96 on some system,
then 96 *is* the number of bits in a long double, not some
kind of "rounded up" result.

No. In the x86 the long double is 10 bytes, but it
is rounded up into 12 (lcc-win) or even 16, just for
alignment reasons.

Except when you use an MS compiler on windows.

The compiler in question does not change the size of the hardware long
double (but one could effectively argue that the C compiler
implementation formally defines what the size of a type for the
compiler is).

I didn't say anything about hardware, I referred to

"If sizeof(long double) * CHAR_BIT == 96 on some system"
....
"No. In the x86 the long double is 10 bytes, but it
is rounded up into 12 (lcc-win) or even 16,"

I take that meant that on x86 sizeof(long double) will
always be at least 10 (or even 12?), and usually 12 or
even 16. Not true if you are using an MS compiler, that's it.

With the MS compilers, you can use 80 bits internally:
http://msdn2.microsoft.com/en-us/lib...24(VS.60).aspx says:

[snip]

However, you do not get the full width when printing out the answers,
since the values get truncated to 8 byte doubles.

All values, so it's not just printing answers, it's
the answers themselves in the first place. You don't
care much if there were some bits if you can't touch
those bits :)

Yevgen

[Dom Fulton]

Thanks for the input, everyone. It's not quite what I was looking for,
so perhaps I can restate the problem.

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 exactly the same problem if I needed
to do bit manipulation of the FP data.

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 __STC_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 size from these constants.

Any ideas? The gcc system includes did historically have a define
which gave the size of a long double, but this seems to be gone now.

Thanks

-Dom

[Ben Bacarisse]

Dom Fulton <we****@yahoo.comwrites:

Thanks for the input, everyone. It's not quite what I was looking for,
so perhaps I can restate the problem.

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;

You are still a bit too close to your problem to explain all the
corners of it. There is no obvious need to know this details you ask
for to export data -- it is done all time simply by converting to
decimal and back.

Your problem may require either more speed or more accuracy (or both)
than this method is capable of. If accuracy is the only problem
(i.e. you want to loose no more bits than you have to due any
difference in formats been A and B) then I think you can find a way
using frexp and scalbn (repeatedly) to construct a representation that
is portable but loses no information.

If speed is the primary problem I suspect you will probably need
another route -- and it won't be portable!.

--
Ben.

[santosh]

Dom Fulton wrote:

Thanks for the input, everyone. It's not quite what I was looking for,
so perhaps I can restate the problem.

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 exactly the same problem if I needed
to do bit manipulation of the FP data.

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.

No, but float.h gives you compile time access to a lot of constants. You
can test these constants and appropriately declare typedefs for your
own floating types. All conforming implementations are guaranteed to
support the range 1e-37 -1e37 for float, double and long double.

I don't think your problem (moving floating values from one system to
another) requires you to know the number of bits in the floating point
types. I think conditional compiling with the values in float.h should
be enough to declare types appropriately to move the data, as long as
the destination system has at least one floating type that can hold the
largest value possible in the source system.

<snip>

[Harald van =?UTF-8?b?RMSzaw==?=]

On Tue, 18 Mar 2008 09:40:17 -0700, Keith Thompson wrote:

Harald van Dijk <tr*****@gmail.comwrites:

>On Mon, 17 Mar 2008 21:56:45 +0100, jacob navia wrote:

>>Dom Fulton wrote:
I've got to support several different systems - Windows, SunOS, and
various Linuxes. I guess I could just find out what the answer is for
the various platforms, and hard-code it in, but that gives me a bad
feeling...

sizeof doesn't work; it's rounded up for alignment reasons. On most
systems, float/double/long double will be 32/64/80 bits, but sizeof
generally returns 96 or 128 for 80-bit floats.
[...]
The
processor is important, not the OS/

The processor and the OS are both important. The processor determines
which floating point representations are available, and the OS (along
with the compiler, I suppose) decides how those map them to C's types.

No, floating point representations are determined by the C
implementation, particularly by the compiler. (Typically the CPU and/or
OS imposes requirements that the compiler needs to follow, or can
violate only with some ugly contortions.)

I do not think this contradicts what I posted. Yes, it's the
implementation that decides the floating point representations, but the
processor and OS are a significant part of the implementation.

What I meant was that the OS may already provide, for example, a strtod
function. Regardless of all else, if the implementation is going to use
that strtod function, it must make sure that the representation of double
matches what strtod returns.

[santosh]

Harald van D?k wrote:

On Tue, 18 Mar 2008 09:40:17 -0700, Keith Thompson wrote:

>Harald van D?k <tr*****@gmail.comwrites:

>>On Mon, 17 Mar 2008 21:56:45 +0100, jacob navia wrote:
Dom Fulton wrote:
I've got to support several different systems - Windows, SunOS,
and various Linuxes. I guess I could just find out what the answer
is for the various platforms, and hard-code it in, but that gives
me a bad feeling...
>
sizeof doesn't work; it's rounded up for alignment reasons. On
most systems, float/double/long double will be 32/64/80 bits, but
sizeof generally returns 96 or 128 for 80-bit floats.
[...]
The
processor is important, not the OS/

The processor and the OS are both important. The processor
determines which floating point representations are available, and
the OS (along with the compiler, I suppose) decides how those map
them to C's types.

No, floating point representations are determined by the C
implementation, particularly by the compiler. (Typically the CPU
and/or OS imposes requirements that the compiler needs to follow, or
can violate only with some ugly contortions.)

I do not think this contradicts what I posted. Yes, it's the
implementation that decides the floating point representations, but
the processor and OS are a significant part of the implementation.

What I meant was that the OS may already provide, for example, a
strtod function. Regardless of all else, if the implementation is
going to use that strtod function, it must make sure that the
representation of double matches what strtod returns.

I think the processor and the purpose of the language determine the
format of floating-point types much more than the OS. A compatibility
layer implemented by the compiler can always make sure that the OS is
given what it expects. Operating systems usually don't deal heavily
with floating-point types.

[Keith Thompson]

Harald van Dijk <tr*****@gmail.comwrites:

On Tue, 18 Mar 2008 09:40:17 -0700, Keith Thompson wrote:

>Harald van Dijk <tr*****@gmail.comwrites:

>>On Mon, 17 Mar 2008 21:56:45 +0100, jacob navia wrote:
Dom Fulton wrote:
I've got to support several different systems - Windows, SunOS, and
various Linuxes. I guess I could just find out what the answer is for
the various platforms, and hard-code it in, but that gives me a bad
feeling...
>
sizeof doesn't work; it's rounded up for alignment reasons. On most
systems, float/double/long double will be 32/64/80 bits, but sizeof
generally returns 96 or 128 for 80-bit floats.
[...]
The
processor is important, not the OS/

The processor and the OS are both important. The processor determines
which floating point representations are available, and the OS (along
with the compiler, I suppose) decides how those map them to C's types.

No, floating point representations are determined by the C
implementation, particularly by the compiler. (Typically the CPU and/or
OS imposes requirements that the compiler needs to follow, or can
violate only with some ugly contortions.)

I do not think this contradicts what I posted. Yes, it's the
implementation that decides the floating point representations, but the
processor and OS are a significant part of the implementation.

What I meant was that the OS may already provide, for example, a strtod
function. Regardless of all else, if the implementation is going to use
that strtod function, it must make sure that the representation of double
matches what strtod returns.

The strtod function is part of the C implementation, specifically of
the C runtime library. It may be provided by, or even be a part of,
the OS.

The C compiler and the C library must work together properly (for a
non-buggy implementation). If the library is provided by the OS, then
yes, a lot of the C compiler's decisions are mandated by what the OS
does.

In many cases, the CPU and the OS very strongly suggest a certain set
of floating-point types. The C implementation doesn't *have* to
follow that strong suggestion; it can do whatever it likes within the
requirements imposed by the standard. But very often there's no good
reason not to follow the OS's conventions (and a lot of extra work to
avoid them).

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"