32 or 64 bit processor info in C

[jacob navia]

Ian Collins a écrit :

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?

Neither SPARC 64 bits, nor Linux 64 bit nor WIndows 64 have an int
of 64 bits.

It would have been better to use "long", but that fails in
windows 64/Vista 64 since long is 32 bits in those systems.

 

[Malcolm McLean]

Ian Collins a écrit :
Neither SPARC 64 bits, nor Linux 64 bit nor WIndows 64 have an int
of 64 bits.

It would have been better to use "long", but that fails in
windows 64/Vista 64 since long is 32 bits in those systems.

I know. Most systems are not conforming. Lack of 64 bit ints also has the
potential to wreck our beloved C language. Soon it will be necessary to use
a gibberish type every time you need an integer, and cast to another
gibberish type to pass to a library function.

 

[jacob navia]

broeisi a écrit :

Hello,

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

Cheers,

Broeisi

Tbe processor in the machine that I use to write this message
can transform itself from

o 16 bit processor (at startup)
o 32 bit processor (If I boot into Windows XP or linux 32)
o 64 bit processor (If I boot into Vista 64 or linux 64)

All those systems use EXACTLY THE SAME HARDWARE!

If the processor runs under a 32 bit system there is NO
WAY (unless you use assembly) to know that processor can be
64 bits.

For x86 systems the only way to know the kind of processor
you are running on is to issue the CPUID assembly instruction.

lcc-win32 has an "intrinsic" function (called cpuid() )
that will return you a structure with several bit fields that
specify the type of processor, etc. But this must be done
in a machine specific way. Other processors may support different
instructions and return values for similar instructions.

But this can't be done at all from C. Actually C is designed
to ABSTRACT from those details and make your programs run the
same in different machines by emulating missing features. That is why
you can use 64 bit integers (or even 128 ones) in a 32 bit system.

C will emulate the missing functionality for you, masking the
differences in hardware. This makes programs written in C portable
from a machine to the next.

 

[Ian Collins]

Ian Collins a écrit :

Neither SPARC 64 bits, nor Linux 64 bit nor WIndows 64 have an int
of 64 bits.

It would have been better to use "long", but that fails in
windows 64/Vista 64 since long is 32 bits in those systems.

Better still void*. But still not a 100% solution.

 

[Flash Gordon]

Malcolm McLean wrote, On 10/04/07 23:45:

We no longer have a standard.

Yes we do. At least, it seems to work fine for a lot of us.

> When a standard fails it takes down the
system with it. Virtually no C programs are compiled under strictly
conforming ANSI compilers any longer.

Most never have been.

Then we don't want to go the size_t route.

Too late. size_t exists and it is the the type you get from sizeof. If
you don't like it, use another language.

> For various reasons it is not
a humanly useable construct,

A number of people manage to use it. Perhaps none of us are human?

> and one of two things will happen. Either
it will quietly be dropped and go away,

The first C standard came out in 1989 and since then size_t has not been
dropped, so that shows no sign of happening.

> or it will run through C code
wrecking every array index or,

It hasn't wrecked any of mine.

> in this case, call to printf,

Which as has been shown is easy to handle. The chances of sizeof being
applied to anything with a size too large for unsigned long are pretty slim.

> which in
turn will provoke other changes, and turn the language into something
unrecognisable.

It's not Martin's fault if you have been unable to recognise C since it
was first standardised in 1989. I suspect size_t pre-dates the standard,
but I'm too lazy to check.

 

[Ian Collins]

I know. Most systems are not conforming. Lack of 64 bit ints also has
the potential to wreck our beloved C language. Soon it will be necessary
to use a gibberish type every time you need an integer, and cast to
another gibberish type to pass to a library function.

Non-conforming to what?

At least with most sensible 64 bit models we now have sizeof(sort) <
sizeof(int) < sizeof(long).

I've no idea where the notion of "gibberish type" comes into this.

 

[jacob navia]

Ian Collins a écrit :

Better still void*. But still not a 100% solution.

WOW, after all those pointless discussions you bring about a true
solution!!!

Why would be that wrong?

I can't imagine a 64 bit system where pointers are 32 bits.

It would fail only in 16 bit systems with 32 bit pointers...
like MSDOS, for instance.

In system mode, some 32 bit processors (x86) use 48 bit pointers
(with 16+32 segmented model pointers). But none of those constructs
are visible in user mode, as far as I know.

 

[Ian Collins]

Ian Collins a écrit :


WOW, after all those pointless discussions you bring about a true
solution!!!

Why would be that wrong?

It's undoubtedly wrong on a DS9000 and probably wrong on a number of
Harvard architecture machines. This being clc, one has to minimise the
opportunities for the smart arses!

 

[Gordon Burditt]

Is there a way in C to get information at runtime if a processor is 32

or 64 bit?

I doubt very much whether you can get a consistent answer for this
even if you use two armies of lawyers, a billion dollars, and 10
years of lawsuits. There are many different, and conflicting
definitions for what bittedness a processor is.

 

[Ian Collins]

I doubt very much whether you can get a consistent answer for this
even if you use two armies of lawyers, a billion dollars, and 10
years of lawsuits. There are many different, and conflicting
definitions for what bittedness a processor is.

Who asked the question?

 

[Old Wolf]

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.

There's no such thing as a 'strictly conforming' compiler. Compilers
conform. Programs either conform, or conform strictly. (Or neither).

And yes, many people do in fact write conforming code and compile it
with conforming compilers.

Then we don't want to go the size_t route. For various reasons it is not a
humanly useable construct,

Except by the millions of humans who use it, one presumes.

 

[CBFalconer]

.... snip ...

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.

alias cc=*gcc -W -Wall -ansi -pedantic -Wwrite-strings
-Wfloat-equal -gstabs+ -ftrapv -O1 %1&

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[robertwessel2]

Ian Collins a écrit :




WOW, after all those pointless discussions you bring about a true
solution!!!

Why would be that wrong?

I can't imagine a 64 bit system where pointers are 32 bits.

Actually several compilers support 32 bit pointers (at least as an
option), on 64 bit systems. For programs that don't need the extra
address space, and can be loaded in the first 2GB of memory, this can
lead to a significant reduction in memory and cache usage. For
example, the HP Alpha Tru64/Linux C/C++ compiler has the -xtaso_short
option.

 

[Tim Prince]

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?

The most usual distinction is whether a pointer fits in 32 bits. A
32-bit OS installed on a 64-bit processor doesn't care whether the
processor supports 64 bits. A 64-bit OS doesn't have to care either; it
wouldn't be running without its expected form of more-than-32-bit
support. And, a 32-bit C compiler running under the popular 64-bit
systems doesn't care about what is outside the subset of the platform
capabiity that it sees. It is responsible for generating code that
(normally) doesn't care whether it runs under a 32- or 64-bit OS, nor
does it have a way to know the difference without exceeding the bound of
Standard C and this forum.

 

[Keith Thompson]

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,

Context: The code in question prints the size, in bits, of type int.

has
*anybody* *ever* used a machine where the output would
be "64-bit processor\n"?
Yup.

(An old Cray model, perhaps?)

Yup.

 

[Ian Collins]

Context: The code in question prints the size, in bits, of type int.


Yup.

Given your location, are any of those beasts still in use?

 

[Keith Thompson]

Actually several compilers support 32 bit pointers (at least as an
option), on 64 bit systems. For programs that don't need the extra
address space, and can be loaded in the first 2GB of memory, this can
lead to a significant reduction in memory and cache usage. For
example, the HP Alpha Tru64/Linux C/C++ compiler has the -xtaso_short
option.

One might argue that such a program is running on an emulated 32-bit
system under a 64-bit system.

I agree that CHAR_BIT * sizeof(void*) will capture the "bit-ness" (as
in, 16-bit system vs. 32-bit system vs. 64-bit system) for most, if
not all, systems I've ever seen.

That doesn't, of course, make it meaningful for *all* systems. And
the C standard has no concept of a "32-bit system" or a "64-bit
system".

 

[Keith Thompson]

Undefined by one particular standard.

It's undefined by *several* particular standards: C89/C90, C95, C99,
<OT>and however many C++ standards there have been</OT>.

In any case, ignoring everything after K&R1 is magnificently foolish.

sizeof() return an int in K and
R C.

Chapter and verse, please. K&R1, page 188, says:

This expression is semantically an integer constant and may be
used anywhere a constant is required.

I see no indication that this "integer constant" is necessarily of
type int.

You are more likely to break by passing %z to printf().

So convert to unsigned long and use "%lu". Or convert to int and use
"%d". As long as the size does not exceed 32767, the resulting code
is correct under *all* relevant standards, going all the way back to
K&R1 and probably farther.

 

[Ian Collins]

One might argue that such a program is running on an emulated 32-bit
system under a 64-bit system.

Not in the general case. I don't know about other operating systems,
but Solaris for one runs 32 bit binaries "native" on a 64 bit platform.

 

[Walter Roberson]

One might argue that such a program is running on an emulated 32-bit
system under a 64-bit system.

One might, but then another one might argue that that would be wrong
for SGI IRIX64. There is a control bit in the process status word
that determines whether the processor is running with 32 bit or 64
bit pointers. It isn't an emulation in any traditional sense:
there are different microcode paths, both of which run at full speed.