32 or 64 bit processor info in C

[broeisi]

Hello,

Is there a way in C to get information at runtime if a processor is 32
or 64 bit?

Cheers,

Broeisi

 

[Walter Roberson]

Is there a way in C to get information at runtime if a processor is 32
or 64 bit?

No, not in standard C.

First you'd have to define exactly what it means for a processor
to be 32 or 64 bit, which is something that has at least 4 different
correct (but contradictory) answers.

 

[broeisi]

No, not in standard C.

First you'd have to define exactly what it means for a processor
to be 32 or 64 bit, which is something that has at least 4 different
correct (but contradictory) answers.

Thank you very much for you answer Christopher.
But how does an OS like linux or windows know that it's installed on a
computer with a 32 or 64 bit processor?

 

[Flash Gordon]

broeisi wrote, On 10/04/07 19:46:

Hello,

Is there a way in C to get information at runtime if a processor is 32
or 64 bit?

Is that really what you want to know? Depending on what your real
problem is a combination of the information in limits.h and the result
of the sizeof operator should help.

 

[Walter Roberson]

But how does an OS like linux or windows know that it's installed on a
computer with a 32 or 64 bit processor?

The OS is implementation, and so is allowed to do things that
C leaves undefined or unspecified.

When an OS is compiled, it already has certain hardware assumptions
built into it -- assumptions such as what the machine language of
the processor looks like. OSes may have access to processor status
registers that C does not define; the status registers may even
require special instructions to access. Since the OS knows what
kind of processor (generally) it is running on, it knows how to
interpret the status registers to determine processor capabilities
(such as whether there is hardware audio support instructions.)

Some people define "32 or 64 bit processor" according to the
instructions that are supported. That's not the best of definitions,
though, because you also need to know things like how many data
bits may be transfered at a time on the databus: a particular
processor model might support several different databus widths
and hide all the details from the users. A processor might
have an instruction to multiply two 32 bit numbers and produce
a 64 bit number, but it might transfer those 64 bits to memory
16 bits at a time. Do you define "32 or 64 bit" by the instruction
set, or do you define it by what the hardware actually does?
Note: generally, the processor reads some cpu pins hardwired on the
motherboard in order to figure out bus widths.

The C language itself provides no mechanisms to access hardware
directly, and provides almost no restrictions on how the
hardware operates. The C langauge standard provide user facilities
to write -portable- code, and leaves the details of the portable
facilties to the implementation. If you have something that
depends on whether the processor is 32 or 64 bit (whatever that
might mean), then you have something that is almost certainly
not portable C.

 

[Doug]

But how does an OS like linux or windows know that it's installed on a
computer with a 32 or 64 bit processor?

Normally you tell this sort of information when you compile it. So
you'll compile different binaries for 32 bit and 64 bit.

This is an operating system, though. *Usually*, a well-written app
doesn't really need to know whether it's running on 32 or 64 bit.

Hope that helps,
Doug

 

[Malcolm McLean]

Hello,

Is there a way in C to get information at runtime if a processor is 32
or 64 bit?

Cheers,

int is the natural integer size for the machine. CHAR_BIT gives the number
of bits in a byte.
So printf("%d-bit processor\n", sizeof(int) * CHAR_BIT);
should tell you whether you are dealing with a processor that handles 64-bit
values nicely or an inferior machine.

 

[Army1987]

Hello,

Is there a way in C to get information at runtime if a processor is 32
or 64 bit?

Nothing guarantees it to always work, but the standard says "A ''plain'' int
object has the natural size suggested by the architecture of the execution
environment", so CHAR_BIT*sizeof (int) is likely to do that (and when it
isn't, it is very likely to be more useful than the actual processor bits in
a C program).

 

[broeisi]

No, not in standard C.

First you'd have to define exactly what it means for a processor
to be 32 or 64 bit, which is something that has at least 4 different
correct (but contradictory) answers.

Thank you very much for you answer Christopher.
But how does an OS like linux or windows know that it's installed on a
computer with a 32 or 64 bit processor?

 

[Walter Roberson]

"broeisi" <[email protected]> ha scritto nel messaggio

Nothing guarantees it to always work, but the standard says "A ''plain'' int
object has the natural size suggested by the architecture of the execution
environment", so CHAR_BIT*sizeof (int) is likely to do that (and when it
isn't, it is very likely to be more useful than the actual processor bits in
a C program).

I can't think at the moment of any 64 bit systems on which that
would be true. Not saying there aren't any, but they aren't common.
On "64 bit systems", int is commonly 32 bits, and it is usually
long or long long that is 64 bits. (Okay, maybe excepting Crays.)

The fact that a particular processor can -do- 64 bit operations
doesn't mean that those are the "most natural" operations on that
system.

 

[broeisi]

broeisi wrote, On 10/04/07 19:46:



Is that really what you want to know? Depending on what your real
problem is a combination of the information in limits.h and the result
of the sizeof operator should help.

Flash Gordon,

Yes, that's really what I want to know.
Just trying to learn C by writing lots of silly little programs that
make sense to me..

I think that the answer given by Malcolm is a good one.

Thanks you all for your answers....

Cheers,

Broeisi

 

[Martin Ambuhl]

int is the natural integer size for the machine. CHAR_BIT gives the
number of bits in a byte.
So printf("%d-bit processor\n", sizeof(int) * CHAR_BIT);
should tell you whether you are dealing with a processor that handles
64-bit values nicely or an inferior machine.

Whether sizeof(int) * CHAR_BIT gives the right answer (among several
possible right answers) aside, the above is just wrong. We have just
covered printing size_t values in the last day:

#include <stdio.h>
#include <limits.h>

int main(void)
{
printf("This printf call has undefined behavior,\n"
"since %%d is for signed ints and sizeof(int) * CHAR_BIT\n"
"is of type size_t, which is unsigned and probably\n"
"larger than an int. If it works without problems, it\n"
"is an accident.\n"
"%d-bit processor\n\n", sizeof(int) * CHAR_BIT);
printf("This printf call is OK, since it uses \"%%zu\" with\n"
"the size_t argument.\n"
"%zu-bit processor\n\n", sizeof(int) * CHAR_BIT);
printf("And this will work where sizeof(int) * CHAR_BIT\n"
"is not larger than ULONG_MAX.\n"
"%lu-bit processor\n\n",
(unsigned long) (sizeof(int) * CHAR_BIT));
return 0;
}

 

[Eric Sosman]

Malcolm McLean wrote On 04/10/07 16:00,:

int is the natural integer size for the machine. CHAR_BIT gives the number
of bits in a byte.
So printf("%d-bit processor\n", sizeof(int) * CHAR_BIT);
should tell you whether you are dealing with a processor that handles 64-bit
values nicely or an inferior machine.

Martin Ambuhl has already pointed out that there is
no reason to expect any particular output.

But I have a question for the group at large: Once
the code is fixed, either via "%zd" or by casting, has
*anybody* *ever* used a machine where the output would
be "64-bit processor\n"? (An old Cray model, perhaps?)

If not, we must conclude that all extant machines are
inferior, and then the further question arises: inferior
to what?

 

[Malcolm McLean]

Whether sizeof(int) * CHAR_BIT gives the right answer (among several
possible right answers) aside, the above is just wrong. We have just
covered printing size_t values in the last day:

#include <stdio.h>
#include <limits.h>

int main(void)
{
printf("This printf call has undefined behavior,\n"
"since %%d is for signed ints and sizeof(int) * CHAR_BIT\n"
"is of type size_t, which is unsigned and probably\n"
"larger than an int. If it works without problems, it\n"
"is an accident.\n"
"%d-bit processor\n\n", sizeof(int) * CHAR_BIT);
printf("This printf call is OK, since it uses \"%%zu\" with\n"
"the size_t argument.\n"
"%zu-bit processor\n\n", sizeof(int) * CHAR_BIT);
printf("And this will work where sizeof(int) * CHAR_BIT\n"
"is not larger than ULONG_MAX.\n"
"%lu-bit processor\n\n",
(unsigned long) (sizeof(int) * CHAR_BIT));
return 0;
}

See the sort of mess you get into when you allow size_t into your standard?
Actually the %z specifier is less portable and will break on several real
platforms.

 

[Martin Ambuhl]

I think that the answer given by Malcolm is a good one.

The answer given by Malcom is wrong, broken, and involves undefined
behavior. You don't need to thank people for lying to you.

 

[Malcolm McLean]

The answer given by Malcom is wrong, broken, and involves undefined
behavior. You don't need to thank people for lying to you.

Undefined by one particular standard. sizeof() return an int in K and R C.
You are more likely to break by passing %z to printf().

 

[Martin Ambuhl]

Undefined by one particular standard. sizeof() return an int in K and R
C. You are more likely to break by passing %z to printf().

He never gives up, does he. Malcolm, you are wrong. If he has a C90
compiler, he can always use "%lu" and cast to (unsigned long). That was
included in my answer. And "%x" is not a complete specifier. Did you
not bother with reading my answer before twice defending telling an
unsuspecting new programmer to use a broken construct. If you are using
a pre-C89 K&R compiler, that's your problem. Some day you might start
using a defined version of C.

 

[Ian Collins]

Undefined by one particular standard. sizeof() return an int in K and R
C. You are more likely to break by passing %z to printf().

Leaving that detail aside, the answer is still wrong. Can you name a
widely used "64 bit" system where sizeof(int) * CHAR_BIT equals 64?

 

[Eric Sosman]

Malcolm McLean wrote On 04/10/07 17:32,:

Undefined by one particular standard. sizeof() return an int in K and R C.
You are more likely to break by passing %z to printf().

Out of curiosity, what would that "one particular
standard" be? Does it claim to define anything, and
if so, what? Has it achieved any noticeable level of
support from ISO, ANSI, or other standards bodies?

Most important: Is that "one particular standard,"
by any stretch of imagination, on-topic for c.l.c.?

 

[Malcolm McLean]

He never gives up, does he. Malcolm, you are wrong. If he has a C90
compiler, he can always use "%lu" and cast to (unsigned long). That was
included in my answer. And "%x" is not a complete specifier. Did you not
bother with reading my answer before twice defending telling an
unsuspecting new programmer to use a broken construct. If you are using a
pre-C89 K&R compiler, that's your problem. Some day you might start using
a defined version of C.

We no longer have a standard. When a standard fails it takes down the system
with it. Virtually no C programs are compiled under strictly conforming ANSI
compilers any longer.
Then we don't want to go the size_t route. For various reasons it is not a
humanly useable construct, and one of two things will happen. Either it will
quietly be dropped and go away, or it will run through C code wrecking every
array index or, in this case, call to printf, which in turn will provoke
other changes, and turn the language into something unrecognisable.