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

[Malcolm McLean]

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

"Malcolm McLean" <re*******@btin ternet.comwrite s:
C has had multiple sizes of integers since before K&R1. If you want a
type that's at least 32 bits, you can easily find one. If you want a
type that's at least 64 bits, you can *probably* find one, typically
called "long long" (standard in C99, a common extension in pre-C99
implementations ).

Your opinion that type int should be 64 bits is, I suppose, perfectly
valid, but the vast majority of C programmers (everyone except you, as
far as I can tell) don't share that opinion. C's type system isn't
perfect, but it is reasonably consistent, and it works.
I'm not saying you're wrong, merely that the language isn't going to
be changed in the way you want it to be changed. You can accept that,
or you can find or invent another language. In the meantime, of
course, you're free to advocate the changes you want, but you need to
be aware that it would be a major change, and that it would *not* be
in keeping with the language as it currently exists, and has existed
for at least 20 years.

I want a type called "int" and signed that is the size of the address bus.
To be fernickety about it it really needs an extra bit, but in practise if
you need over half the address space for a single array then you can code
access to it specially.
That has been the convention until now. The proposal is to change it, to
make int no longer the natural integer size for the machine.

The problem with size_t was that the implications weren't thought through. I
am sure the committee thought that they were adding a minor patch to
malloc() and documenting variables that hold sizes of memory. They didn't
realise the implications. The problem is that if int is 32 bits and memory
is 64 bits, then every array index to an arbitrary array needs to be a
size_t. Virtually every integer, pace Flash Gordon, is used as an array
index or in intermediate calculations to derive indices. But since size_t is
unsigned, awkward to read, and most numbers are much less than 2 billion,
people won't use it consistently. A type is a standard for passing data
between functions. So we'll have the two plugs problem. It will seriously
impact the reusability of C code.
If int is 64 bits on 64-bit machines size_t will gradually fade away.
I'm not proposing removing the symbol from C code just yet, merely
suggesting that it isn't used except as a fix to library functions, or in
special cases. Eventually we will return sizeof() to generating an int, and
remove it from the string functions, so it will survive merely as a fossil
in malloc().
C does not have fixed size basic types. Rightly or wrongly. By making
int a fixed size of 32 bits compiler vendors are the ones making the change,
not me. As 64 bit machines hit the mass market, we have a brief chance to
save our language from ANSI doing to C what they did to C++.

[Malcolm McLean]

"Flash Gordon" <sp**@flash-gordon.me.ukwro te in message
news:tn******** ***@news.flash-gordon.me.uk...

Malcolm McLean wrote, On 12/04/07 22:03:

>>
"Flash Gordon" <sp**@flash-gordon.me.ukwro te in message
news:en******* *****@news.flas h-gordon.me.uk...

>>Malcolm McLean wrote, On 12/04/07 08:07:

<snip>

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

You've claimed that before and failed to support it. In over 20 years of
professiona l programming most of my use of integers has not had anything
to do with array indexes. On the stuff I currently work on we use
integers for money, for example, and I've never needed to use cost as an
index in to an array!

I posted a study for you. You do need a little bit of insight to intepret
data, unless you have the resources to study everything by brute force.

I explained why the study did not prove the point. Amongst other things,
it explicitly excluded major classes of code, such as server applications.

This is an important point.
Finding an objection to evidence doesn't make that evidence disappear, or
turn the opposite case into a "mere assertion" position.
You seldom have exactly the evidence you would like. For instance the
example I gave was Java, not C, it was from a selection of about ten
applications, and the study wasn't designed to show what I asserted, the
conclusion had to be derived by looking at the evidence with some
assumptions.

However whilst your objections were legitimate, in fact the idea that Java
code is very different from C code in its use of arrays, that server
applications use arrays in a very different way from most general
applications, that array access instructions don't bear a very tight
relationship to index calculations, and so on, aren't all that plausible.
You would need to do a proper study to establish the matter beyond all
possible doubt. However do you think I could get a research grant for people
to sit tagging up C code to establish how much indexing is done? It would be
expensive and wouldn't tell us very much that we don't know already. Most
scientific studies have tight cost limits and aren't as rigorous as we would
like. That doesn't mean that they are useless.

You'll often come across this fallacy in a much more gross way than you have
made it. I can find an objection to the evidence, therefore it disappears.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Ian Collins]

Malcolm McLean wrote:

>>

I want a type called "int" and signed that is the size of the address
bus. To be fernickety about it it really needs an extra bit, but in
practise if you need over half the address space for a single array then
you can code access to it specially.
That has been the convention until now. The proposal is to change it, to
make int no longer the natural integer size for the machine.

What proposal?

The problem with size_t was that the implications weren't thought
through. I am sure the committee thought that they were adding a minor
patch to malloc() and documenting variables that hold sizes of memory.
They didn't realise the implications. The problem is that if int is 32
bits and memory is 64 bits, then every array index to an arbitrary array
needs to be a size_t. Virtually every integer, pace Flash Gordon, is
used as an array index or in intermediate calculations to derive
indices.

How many of those index more than 2^31 bytes?

But since size_t is unsigned, awkward to read, and most
numbers are much less than 2 billion, people won't use it consistently.

It has to be unsigned to address the full range.

C does not have fixed size basic types. Rightly or wrongly. By
making int a fixed size of 32 bits compiler vendors are the ones making
the change, not me. As 64 bit machines hit the mass market, we have a
brief chance to save our language from ANSI doing to C what they did to
C++.

As of C99 there are fixed size types. I for one am a huge fan of
standardised fixed size types, just like common utility code that
belongs in the standard library, they save everyone from reinventing
them. With the move to 64 bit, the use of these types is pretty much a
requirement for system library functions.

The size of the basic types are not specified by the C standard, or
compiler authors alone, but by the operating system vendors. The two
dominant desktop/server factions already have these locked down and they
aren't going to change. 64 bit has been in the data centre for over a
decade and the choice of 64 bit programming model was made long before
that. Your moment is long gone.

--
Ian Collins.

[Richard Heathfield]

Malcolm McLean said:

<snip>

<snip>

Virtually every integer, pace Flash
Gordon, is used as an array index or in intermediate calculations to
derive indices.

Maybe for you, but not for everyone.

But since size_t is unsigned,

That's an advantage.

awkward to read,

That's a matter of opinion.

and most numbers are much less than 2 billion,

And that's false. There are as many numbers greater than 2 billion as
there are less than 2 billion. (We know this because they can be put
into one-to-one correspondence with each other.) I think you mean most
of the numbers most programmers actually want to *use* are less than 2
billion, and I'll accept that.

people won't use it consistently.

Well, some people won't. Others, however, will. People are inconsistent
like that.

A type is a standard for passing data between functions.

Among other things, yes. This doesn't really affect anything, though.

<snip>

C does not have fixed size basic types. Rightly or wrongly.

Rightly. The silly thing about fixed size types is that, every few
years, you need to introduce a new type. C did this properly right from
the start.

By making
int a fixed size of 32 bits compiler vendors are the ones making the
change, not me. As 64 bit machines hit the mass market, we have a
brief chance to save our language from ANSI doing to C what they did
to C++.

I agree that int should be the natural size for the machine, and there
is certainly an argument that long int should be longer and short
shorter (where possible). I see no particular value in fixing exact
type sizes, though - in fact, quite the opposite.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Malcolm McLean]

"Richard Heathfield" <rj*@see.sig.in validwrote in message
news:we******** *************@b t.com...

Malcolm McLean said:
I agree that int should be the natural size for the machine, and there
is certainly an argument that long int should be longer and short
shorter (where possible). I see no particular value in fixing exact
type sizes, though - in fact, quite the opposite.

The camapign for 64 bit ints is actually a campaign for ints the size of the
address bus. For instance if someone brought out a machine that had 48 bits
of addressable memory space then the natural size for an int would be 48
bits. The idea is that an int should be the type to use for an array index -
except in rare circumstances when memory is at a premium or intermediate
calculations overflow its range. The effectively every integer is an int and
everything works together.
The only time I ever really need a fixed size type is for defining pixel
values. Sometimes it is nice to be able to access a pixel as a single
variable, and 32 bits gives you rgba. However nowadays buffer calculations
aren't the bottleneck they were - high end rasterisation is done in hardware
and low-end is fast enough anyway - so my recent code uses mainly arrays of
unsigned chars.

[Ian Collins]

Malcolm McLean wrote:

>
"Richard Heathfield" <rj*@see.sig.in validwrote in message
news:we******** *************@b t.com...

>Malcolm McLean said:
I agree that int should be the natural size for the machine, and there
is certainly an argument that long int should be longer and short
shorter (where possible). I see no particular value in fixing exact
type sizes, though - in fact, quite the opposite.

The camapign for 64 bit ints is actually a campaign for ints the size of
the address bus. For instance if someone brought out a machine that had
48 bits of addressable memory space then the natural size for an int
would be 48 bits. The idea is that an int should be the type to use for
an array index - except in rare circumstances when memory is at a
premium or intermediate calculations overflow its range.

Even at the cost of enlarging the dataset slowing down a large number of
applications that do not require int larger than 32 bits?

--
Ian Collins.

[Richard Heathfield]

Ian Collins said:

Malcolm McLean wrote:

<snip>

>The camapign for 64 bit ints is actually a campaign for ints the size
of the address bus. For instance if someone brought out a machine
that had 48 bits of addressable memory space then the natural size
for an int would be 48 bits. The idea is that an int should be the
type to use for an array index - except in rare circumstances when
memory is at a premium or intermediate calculations overflow its
range.

Even at the cost of enlarging the dataset slowing down a large number
of applications that do not require int larger than 32 bits?

On such systems, you could always use short int. There's nothing magical
about 32, you know. Not that int is the right type for an array index,
of course - it's just another possible source of bugs.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Army1987]

"Malcolm McLean" <re*******@btin ternet.comha scritto nel messaggio
news:iN******** *************** *******@bt.com. ..

The problem with size_t was that the implications weren't thought through.
I am sure the committee thought that they were adding a minor patch to
malloc() and documenting variables that hold sizes of memory. They didn't
realise the implications. The problem is that if int is 32 bits and memory
is 64 bits, then every array index to an arbitrary array needs to be a
size_t.

Why? Unless you have an array larger than 2 GB, a 32-bit signed int will do
that, regardless of any architecture details.

Virtually every integer, pace Flash Gordon, is used as an array index or
in intermediate calculations to derive indices. But since size_t is
unsigned, awkward to read, and most numbers are much less than 2 billion,
people won't use it consistently.

If the problem is that size_t is unsigned, use ptrdiff_t. But, first, ask
yourself wheter you *really* need it.

[Flash Gordon]

Malcolm McLean wrote, On 14/04/07 10:08:

>
"Richard Heathfield" <rj*@see.sig.in validwrote in message
news:we******** *************@b t.com...

>Malcolm McLean said:
I agree that int should be the natural size for the machine, and there
is certainly an argument that long int should be longer and short
shorter (where possible). I see no particular value in fixing exact
type sizes, though - in fact, quite the opposite.

The camapign for 64 bit ints is actually a campaign for ints the size of
the address bus. For instance if someone brought out a machine that had
48 bits of addressable memory space then the natural size for an int
would be 48 bits. The idea is that an int should be the type to use for
an array index - except in rare circumstances when memory is at a
premium or intermediate calculations overflow its range. The effectively
every integer is an int and everything works together.

Apart from all those processors with 24 bit address busses but only 16
bit data busses and registers. Those then have to jump through major
hoops and int suddenly becomes a very inefficient type. If you think it
does not happen, look at the processors by that little company called
Intel, specifically the rarely used x86 series of processors.

The only time I ever really need a fixed size type is for defining pixel
values. Sometimes it is nice to be able to access a pixel as a single
variable, and 32 bits gives you rgba. However nowadays buffer
calculations aren't the bottleneck they were - high end rasterisation is
done in hardware and low-end is fast enough anyway - so my recent code
uses mainly arrays of unsigned chars.

Some stuff is done in hardware some in software some in a mix. It all
depends. For example, I doubt that Paintshop Pro on the PC is using
custom hardware for a lot of its image processing, and the same for a
lot of other software. I also have other uses for known fixed size
integer types and accepting that some SW will need changing if ported to
a system not supporting those types.
--
Flash Gordon

[Flash Gordon]

Richard Heathfield wrote, On 14/04/07 11:40:

Ian Collins said:

>Malcolm McLean wrote:

<snip>

>>The camapign for 64 bit ints is actually a campaign for ints the size
of the address bus. For instance if someone brought out a machine
that had 48 bits of addressable memory space then the natural size
for an int would be 48 bits. The idea is that an int should be the
type to use for an array index - except in rare circumstances when
memory is at a premium or intermediate calculations overflow its
range.

Even at the cost of enlarging the dataset slowing down a large number
of applications that do not require int larger than 32 bits?

On such systems, you could always use short int.

Not if you need an integer type larger than 16 bits. :-)

There's nothing magical
about 32, you know.

Yes there is, add 10 to it and you get the answer! ;-)

Not that int is the right type for an array index,
of course - it's just another possible source of bugs.

Indeed. My opinion is that in the Unix and Windows worlds the decision
to make int 32 bits on 64 bit HW was a valid choice made for good
reasons. On other systems it might be 64 bits for equally good reasons.
This is not a problem.
--
Flash Gordon