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

[Keith Thompson]

Ian Collins <ia******@hotma il.comwrites:

Keith Thompson wrote:

>Eric Sosman <Er*********@su n.comwrites:
[snip]

>> 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.

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>

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[robertwessel2]

On Apr 10, 9:56 pm, Keith Thompson <[e-mail] ote:

"robertwess...@ yahoo.com" <robertwess...@ yahoo.comwrites :

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.

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]

"Eric Sosman" <Er*********@su n.comwrote in message
news:1176237613 .873475@news1nw k...

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

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
--
Posted via a free Usenet account from http://www.teranews.com

[Jean-Marc Bourguet]

"Stephen Sprunk" <st*****@sprunk .orgwrites:

"Eric Sosman" <Er*********@su n.comwrote in message
news:1176237613 .873475@news1nw k...

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?

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,

--
Jean-Marc

[Chris Dollin]

broeisi wrote:

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]

"Stephen Sprunk" <st*****@sprunk .orgwrites:

"Eric Sosman" <Er*********@su n.comwrote in message
news:1176237613 .873475@news1nw k...

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

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 (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Ian Collins <ia******@hotma il.comwrites:

Keith Thompson wrote:

>"ro*********** @yahoo.com" <ro***********@ yahoo.comwrites :

[...]

>>>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.

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.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Eric Sosman]

broeisi wrote:

On 10 apr, 21:30, Flash Gordon <[e-mail] te:

>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.
--
Flash Gordon

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
es*****@acm-dot-org.invalid

[Eric Sosman]

jacob navia wrote:

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.

64-bit SPARC running a 32-bit program.

--
Eric Sosman
es*****@acm-dot-org.invalid

[jacob navia]

Eric Sosman a écrit :

jacob navia wrote:

>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.

64-bit SPARC running a 32-bit program.

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