32 or 64 bit processor info in C

[Keith Thompson]

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

<OT>Not here at SDSC, no. (I miss the old Cray T90 with its
"waterfall" of Flourinert coolant behind a transparent panel.)</OT>

 

[robertwessel2]

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

No, this is different than running a 32 bit binary on a 64 bit system
(which many systems can do, of course). This is basically a native 64
bit executable that happens to store only the low halves of pointers
(with appropriate tweaks to ensure it's never loaded or allocated
memory above 4GB). The executable still calls the normal 64 bit OS
API (and other) functions, widening pointers as needed.

 

[Stephen Sprunk]

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?)

Didn't Alphas have a 64-bit int?

S

 

[Jean-Marc Bourguet]

Didn't Alphas have a 64-bit int?

I've access to an Alpha machine running NetBSD and it has 32 bits int and
64 bits long. Obviously other OS can do something other -- and compilation
flags may also play a roll. I seem to remember that Unix recommands the
LP64 model.

Yours,

 

[Chris Dollin]

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

Not portably. Why do you want to know (ie what is it you're trying to do)?

--
The second Jena user conference! http://hpl.hp.com/conferences/juc2007/
"- born in the lab under strict supervision -", - Magenta, /Genetesis/

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

 

[Keith Thompson]

Didn't Alphas have a 64-bit int?

It depends on the C implementation. On Alpha systems I've used
running DEC OSF (well, HP OSF, I guess), int is 32 bits and long is 64
bits. On a Cray T3E, which also used Alpha CPUs, int and long are
both 64 bits. (char is 8 bits, and short is 32 bits; the lack of any
16-bit integer type causes problems porting some software.)

 

[Keith Thompson]

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.

I didn't say one would *win* the argument. Obviously that "one" guy
doesn't know what he's talking about. I'm glad *I* didn't make such a
silly claim.

 

[Eric Sosman]

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.

It follows that you haven't learned much.

Yes, that's a smart-ass remark. But it's also an
entirely serious remark: Malcolm has given an "answer"
that is faulty in both conception and execution. If you
consider his answer "good," you have much yet to learn.

A suggestion: If you are interested in learning C,
you will do better to concentrate on *C* and ignore the
ill-defined side-issues. As Malcolm's sad case shows us,
pursuing such matters can lead one so far afield that one
loses the ability to tell C from "C-ish" and winds up making
a fool of oneself in public.

Take this thread's question, for example: What will your
program do differently if it discovers that it is running on
a "64-bit processor" or a "32-bit processor," or for that
matter on an "8-bit processor" or an "18-bit processor?" That
is, what use would your program make of the answer to the
question?

Perhaps you ask whether you have a "64-bit processor" in
order to decide whether you can use a 64-bit `long' or allocate
a forty-gigabyte region with malloc(). If that's the goal, you
are asking the wrong question! If you want to know the range
of `long', use the LONG_MIN and LONG_MAX macros. If you want
to allocate forty gigabytes, first check SIZE_MAX or `(size_t)-1'
and then attempt the allocation. In short, ask the question whose
answer you will actually use, not some other question from which
you imagine you might deduce the answer.

Be direct, don't be circuitous, and DON'T be tricky.

 

[Eric Sosman]

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.

64-bit SPARC running a 32-bit program.

 

[jacob navia]

Eric Sosman a écrit :

64-bit SPARC running a 32-bit program.

Obvious, but as far as that program is concerned the processor *is* 32 bits!

 

[Preben Traerup]

broeisi a écrit :

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 AMD and some Intel CPU's:

I have never tried to boot a 32 bit linux OS on 64 bit CPU, thus
this may be wrong:
On a linux platform booted with a 32 bit OS version,
one could open file /proc/cpuinfo (plain text file) and check if the
CPU supports the flag lm (long mode = 64 bit).

If booted with 64 bit linux OS, flag lm is always present if CPU is AMD
x86_64 bit type.


So yes by using standard C one can figure out if certain CPU's
supports 64 bit by parsing a plain text file - the latter being very
little portable and very much non standard.

 

[Stephen Sprunk]

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.

x64 has various code models, and at least one of them allows for 32-bit
pointers. This allows access to the additional registers and RIP-relative
addressing without paying the penalties of larger pointers when you don't
need them.

The Linux kernel also uses 32-bit pointers for its internal structures, even
when running in 64-bit mode. AMD specifically noted pointers to be signed
in x64 so that the kernel could live in the same space (-2GB to 0) on both
32-bit and 64-bit systems without fragmenting user address space. Full
64-bit pointers are only required if you want more than 4GB of memory, and
most programs don't; the kernel only does when accessing 64-bit userland.

IIRC, WinNT on Alpha also used 32-bit pointers, but then again it had 32-bit
ints and (IIRC) longs as well. All of that was a lame attempt at making it
easier to port bad code between all Win32 OSes.

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

MSDOS had pretty broken pointers anyways, i.e. the near vs far thing.

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.

They're visible at the asm level, but not generally useful. There's little
reason to bother making them visible at the C level.

I've seen various GCC branches that used 48-bit and 96-bit pointers on x86,
BTW. Does that make x86 a 96-bit CPU?

S

 

[broeisi]

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

Ahhh... I'm just starting out.. didn't know that the answer wasn't
correct.

So it's just not possible to know whether you're dealing with a 32 or
64 bit processor from C.
hmmm.. thought that C could handle any programming problem?

Broeisi

 

[Walter Roberson]

So it's just not possible to know whether you're dealing with a 32 or
64 bit processor from C.

Add the word "standard" before "C".

hmmm.. thought that C could handle any programming problem?

No, standard C does not promise any access to hardware, nor
any access to specific memory locations, nor any access to
multiprocessing or multithreading, nor any access to
networking, nor any access to arbitrary operating system
interfaces. It also does not promise any particular parameter
calling sequence.

Standard C defines only features that can be done portably on
nearly any computer; anything hardware or operating system
specific, it leaves unspecified or says is implementation defined,
or does not define, or says specifically is "undefined behavior"
(known as "UB" around here.)

It so happens that the C programming model is a useful one
to start from and add in the sort of non-portable extensions
that are useful to control hardware or to interface with operating
system facilities. But those extensions might or might not work
on the next system over, so if your goal is to write portable C
then you should avoid those extensions. And in cases where
portable C can't handle the job, isolate the non-portable sections
so as to make it easier to enhance when the program is moved on to
a new system.

So it's just not possible to know whether you're dealing with a 32 or
64 bit processor from C.
hmmm.. thought that C could handle any programming problem?

Knowing whether you are dealing with a 32 or 64 bit processor
is not a programming problem: it is a problem of language.
There is no technical standard about what it -means- to
say that you are dealing with a 32 or 64 bit processor.
Or perhaps closer would be to say that there are half a dozen
different *conflicting* technical standards about what it means.

 

[Martin Ambuhl]

Ahhh... I'm just starting out.. didn't know that the answer wasn't
correct.

So it's just not possible to know whether you're dealing with a 32 or
64 bit processor from C.
hmmm.. thought that C could handle any programming problem?

If you consider any particular kind of object (or pointer) to correspond
to something you think makes something a "32 or 64 bit processor", then
you can take its size in chars with sizeof and multiply by CHAR_BIT.
Suppose you think that a pointer-to-void satisfies this requirement,
remembering that whatever you mean by "32 or 64 bit processor" is by no
means the only definition of those terms, you could have

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

int main(void)
{
size_t proctype = sizeof(void *) * CHAR_BIT;

/* If you have a C99 library, or a version of printf
that understands it, you can print it with */
printf("proctype = %zu\n", proctype);
/* otherwise you need */
printf("proctype = %lu\n", (unsigned long)proctype);

return 0;
}

I have covered all this before.

The one programming problem that C certainly cannot handle is cleaning
up the semantics of "32 or 64 bit processor", which has a number of
meanings.

Also consider, for example, possibly having a C compiler on a PDP-8 with
12-bit words, a PDP=15 with 18 bit words, an IBM 7094 or PDP-10 with
36-bit words. It is unlikely that, on any meaning, any of these can be
described as a 32-bit or 64-bit processor. The number of machines with
word sizes such that they are not describable as 32-bit or 64-bit
machines is very large. That you haven't encountered them doesn't matter.

 

[christian.bau]

So it's just not possible to know whether you're dealing with a 32 or
64 bit processor from C.
hmmm.. thought that C could handle any programming problem?

It is not a programming problem. The problem is that it is not a well-
defined problem. The question that has nobody asked yet: What is it
that you actually want to achieve?

Some people want to know "Is int 64 bit? Is long 64 bit? Are pointers
64 bit? Exactly 64 bit or more than 64 bit?" That is easy to answer
using portable C (but CHAR_BIT * sizeof (int) is _not_ the answer.
Some guys here should really know that).

A more interesting question is: "Are operations with 64 bit numbers as
efficient as operations with 32 bit numbers? ". There is no portable
answer to this. However, you could check whether long is 64 bit or
more - in that case it is highly likely that 64 bit operations are as
efficient as 32 bit operations, and your code should run either way.

Next, you might want to know what processor you are running on. That
requires methods that depend on the implementation. And it can be a
very non-trivial problem. Just for fun, try writing a MacOS X program
using PowerPC code, that will identify the processor correctly that it
is running on. Make sure it gets it right when running on a 32 bit
PowerPC, a 64 bit PowerPC, a 32 bit Intel processor, a 64 bit Intel
processor, a VM emulating a 32 bit processor running on a 64 bit
processor. Have fun.

 

[Malcolm McLean]

It depends on the C implementation. On Alpha systems I've used
running DEC OSF (well, HP OSF, I guess), int is 32 bits and long is 64
bits. On a Cray T3E, which also used Alpha CPUs, int and long are
both 64 bits. (char is 8 bits, and short is 32 bits; the lack of any
16-bit integer type causes problems porting some software.)

You've made this post several times over the past few months. I don't know
what size most of the types are on the machines I work on.

 

[Malcolm McLean]

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

Exactly.

 

[Malcolm McLean]

Non-conforming to what?

The convention that int is not a fixed-size type but represents the natural
integer size for the machine. It is also a clause in one of the standards.

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

That is creeping in. It is part of where the size_t nonsense leads you.
People should be educated to realise that it doesn't matter how many bits an
integer has as long as it is big enough to hold the biggest number you need.
Since most integers are used in array indexes, i.e. count things in the
computer's memory, that tells you what the natural integer size is on any
particualr machine.

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

A gibberish type is one that is adapted to the needs of compilers and or
standards bodies rather than the human programmers using the system. Read
any Wondows code to see where going down this path leads.

 

[Ian Collins]

The convention that int is not a fixed-size type but represents the
natural integer size for the machine. It is also a clause in one of the
standards.

For many 64 bit systems, a 32 bit int is still an optimum, or natural
size in situations where the extra range of a 64 bit variable is not
required. Smaller memory and cache requirements can make a significant
difference. Most 64 bit processors are designed to run 32 bit code
without any performance degradation. Those that don't haven't been very
successful (Itanic anyone?).

That is creeping in. It is part of where the size_t nonsense leads you.

I see no relationship between the LP64 model and size_t. Consider a 32
bit machine that can address >4GB, unless you have a transparent size
type, how can you represent the difference in two pointers?

People should be educated to realise that it doesn't matter how many
bits an integer has as long as it is big enough to hold the biggest
number you need. Since most integers are used in array indexes, i.e.
count things in the computer's memory, that tells you what the natural
integer size is on any particualr machine.

Fair point, but at least in this day and age, the times when a counter
has to go beyond 32 bits are rare.

A gibberish type is one that is adapted to the needs of compilers and or
standards bodies rather than the human programmers using the system.
Read any Wondows code to see where going down this path leads.

I'd rather not!