Does "float" always occupy 32 bits

[chandanlinster]

As far as I know floating point variables, that are declared as float
follow IEEE format representation (which is 32-bit in size). But
chapter1-page no 9 of the book "The C programming language" states that
"THE RANGE OF BOTH int AND float DEPENDS ON THE MACHINE YOU ARE
USING".
Does this mean "float" variables have different sizes on different
machines?

 

[Skarmander]

As far as I know floating point variables, that are declared as float
follow IEEE format representation (which is 32-bit in size). But
chapter1-page no 9 of the book "The C programming language" states that
"THE RANGE OF BOTH int AND float DEPENDS ON THE MACHINE YOU ARE
USING".
Does this mean "float" variables have different sizes on different
machines?

Yes.

Although the IEEE single-precision type is the most common implementation of
float, this is not required. The standard only requires a minimum range and
minimum precision. Implementations can optionally signal that they implement
IEC 60559, a revision of IEEE 754.

In practice, most programs do not depend on the particular size of a float;
the ones that assume are usually those who also assume an int is 32 bits, so
floats and ints can be stored interchangeably. Needless to say, these are
not portable assumptions, and rarely appropriate, let alone necessary.

S.

 

[Philip Potter]

As far as I know floating point variables, that are declared as float
follow IEEE format representation (which is 32-bit in size).

This is not guaranteed.

But
chapter1-page no 9 of the book "The C programming language" states that
"THE RANGE OF BOTH int AND float DEPENDS ON THE MACHINE YOU ARE
USING".
Does this mean "float" variables have different sizes on different
machines?

Yes.

Philip

 

[rramesh1]

Hi Guys.

I have a AMD-64 turion running debian Linux with gcc & here is what I
got..

char:1
short:2
long:8
float:4
double:8
long double:16

Here are my compiler options..

Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,fortran,objc,obj-c++,ada,treelang
--prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre
--enable-mpfr --enable-checking=release x86_64-linux-gnu
Thread model: posix
gcc version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)

Cheers
/R

 

[chandanlinster]

Thanks everybody for providing the solutions.

 

[Keith Thompson]

As far as I know floating point variables, that are declared as float
follow IEEE format representation (which is 32-bit in size). But
chapter1-page no 9 of the book "The C programming language" states that
"THE RANGE OF BOTH int AND float DEPENDS ON THE MACHINE YOU ARE
USING".
Does this mean "float" variables have different sizes on different
machines?

Potentially, yes.

I've never heard of a C implementation where float is not 32 bits
(i.e., where sizeof(float) * CHAR_BIT != 32), but such implementations
could easily exist.

In any case, there's no real reason or need to assume that float is 32
bits. The compiler knows how big a float is so you don't need to
worry about it.

 

[Ben Pfaff]

Potentially, yes.

I've never heard of a C implementation where float is not 32 bits
(i.e., where sizeof(float) * CHAR_BIT != 32), but such implementations
could easily exist.

I don't think that float could be much smaller than 32 bits. By
my calculations, a floating point number represented in the
format that the Standard expects would need approximately 28 bits
to have the required range and precision.

 

[Keith Thompson]

I don't think that float could be much smaller than 32 bits. By
my calculations, a floating point number represented in the
format that the Standard expects would need approximately 28 bits
to have the required range and precision.

Sure, but float could easily be larger than 32 bits.

And, in fact, contrary to what I wrote above, I've worked on machines
where float is 64 bits (and double is 64 bits, and long double is 128
bits). These were Cray vector machines, where the native word size is
64 bits.

 

[Ben Pfaff]

Sure, but float could easily be larger than 32 bits.

Yes, I should have added that. I didn't mean to sound contradictory.

And, in fact, contrary to what I wrote above, I've worked on machines
where float is 64 bits (and double is 64 bits, and long double is 128
bits). These were Cray vector machines, where the native word size is
64 bits.

Right.

 

[Dik T. Winter]

>
> Potentially, yes.
>
> I've never heard of a C implementation where float is not 32 bits
> (i.e., where sizeof(float) * CHAR_BIT != 32), but such implementations
> could easily exist.

I have used them. sizeof(float) == 8.

 

[Neil]

Potentially, yes.

I've never heard of a C implementation where float is not 32 bits
(i.e., where sizeof(float) * CHAR_BIT != 32), but such implementations
could easily exist.

In any case, there's no real reason or need to assume that float is 32
bits. The compiler knows how big a float is so you don't need to
worry about it.

The Hi-Tech compiler for the PIC gives you the option of 24 or 32 bit
floats. I am not sure what ANSI says about that.

 

[Keith Thompson]

The Hi-Tech compiler for the PIC gives you the option of 24 or 32 bit
floats. I am not sure what ANSI says about that.

It doesn't directly say anything, but I don't believe it's possible to
meet the standard's requirements for type float in 24 bits. By my
calculations you need at least 27 bits (1 sign bit, 20 mantissa bits,
6 exponent bits).

 

[Malcolm]

It doesn't directly say anything, but I don't believe it's possible to
meet the standard's requirements for type float in 24 bits. By my
calculations you need at least 27 bits (1 sign bit, 20 mantissa bits,
6 exponent bits).

Easy.Your 24 bits index into an array of double-precision 64 bit values.
Since the user isn't guaranteed more than 64 K of memory, you've done it.

 

[Joe Wright]

It doesn't directly say anything, but I don't believe it's possible to
meet the standard's requirements for type float in 24 bits. By my
calculations you need at least 27 bits (1 sign bit, 20 mantissa bits,
6 exponent bits).

Without regard to the Standard's requirements..

IEEE 754 has an extra bit. Float on my Sun and x86 iron is 32 bits and
includes a sign, 8 exponent bits and a 24-bit mantissa. They squeeze 33
bits into 32 by assuming the high order bit of a normalized mantissa is
always 1. This means we can use the bit position to hold the low order
bit of the exponent.

Same system for double, of course. Sign + 11 exponent bits + 53 mantissa
bits == 65. It fits, of course, in 64 bits.

 

[CBFalconer]

.... snip ...

Easy.Your 24 bits index into an array of double-precision 64 bit
values. Since the user isn't guaranteed more than 64 K of memory,
you've done it.

Harumph. C passes by value. How do you pass those beasts by value?

 

[Keith Thompson]

Harumph. C passes by value. How do you pass those beasts by value?

They're only 24 bits; why would there be any problem passing them by
value?

So the idea is that a value of type "float" is a 24-bit index into a
table of, say, 32-bit floating-point objects. There are up to 2**32
possible values, but only 2**24 of them can exist within a single
execution of a program. Any operation that produces a new (32-bit)
value creates a new entry in the table and a new 24-bit index value.

This is a very silly idea, but it could satisfy *most* of the required
semantics of type float.

One thing that you couldn't do with this is write a value of type
"float" to a binary file, read it from another instance of the same
program, and get the same value. Maybe a conforming freestanding
implementation could get away this this. (Is there an embedded
version of the DS9K?)

 

[David Wade]

Without regard to the Standard's requirements..

IEEE 754 has an extra bit. Float on my Sun and x86 iron is 32 bits and
includes a sign, 8 exponent bits and a 24-bit mantissa. They squeeze 33
bits into 32 by assuming the high order bit of a normalized mantissa is
always 1. This means we can use the bit position to hold the low order
bit of the exponent.

Same system for double, of course. Sign + 11 exponent bits + 53 mantissa
bits == 65. It fits, of course, in 64 bits.

Honeywell L66 has 36 bit floats.....