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

[Preben Traerup]

jacob navia wrote:

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

"jacob navia" <ja***@jacob.re mcomp.frwrote in message
news:46******** *************** @news.orange.fr ...

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.

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

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

[broeisi]

On 10 apr, 23:15, Martin Ambuhl <mamb...@earthl ink.netwrote:

broeisi wrote:

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.

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]

In article <11************ **********@w1g2 000hsg.googlegr oups.com>,
broeisi <br*******@gmai l.comwrote:

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

--
Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us. -- Ecclesiastes

[Martin Ambuhl]

broeisi wrote:

On 10 apr, 23:15, Martin Ambuhl <mamb...@earthl ink.netwrote:

>broeisi wrote:

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

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("proctyp e = %zu\n", proctype);
/* otherwise you need */
printf("proctyp e = %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]

On Apr 11, 7:03 pm, "broeisi" <broeis...@gmai l.comwrote:

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]

"Keith Thompson" <ks***@mib.orgw rote in message
news:ln******** ****@nuthaus.mi b.org...

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

>"Eric Sosman" <Er*********@su n.comwrote in message
news:117623761 3.873475@news1n wk...

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

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.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Malcolm McLean]

"CBFalconer " <cb********@yah oo.comwrote in message
news:46******** *******@yahoo.c om...

Malcolm McLean wrote:

>>

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

Exactly.

[Malcolm McLean]

"Ian Collins" <ia******@hotma il.comwrote in message
news:58******** ******@mid.indi vidual.net...

Malcolm McLean wrote:

>>
"jacob navia" <ja***@jacob.re mcomp.frwrote in message
news:46******* *************** @news.orange.fr ...

>>Ian Collins a écrit :

Malcolm McLean wrote:

"Martin Ambuhl" <ma*****@earthl ink.netwrote in message
news:58**** *********@mid.i ndividual.net.. .
>>
>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().
>
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.

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?

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.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Ian Collins]

Malcolm McLean wrote:

>
"Ian Collins" <ia******@hotma il.comwrote in message
news:58******** ******@mid.indi vidual.net...

>Malcolm McLean wrote:

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

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

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

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.

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

I'd rather not!

--
Ian Collins.