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

[Ian Collins]

Malcolm McLean wrote:

>
Though mainframes are an important part of the computing world, they
tend to be staffed by teams of professional programmers, and run
software specially written for them. The programs installed and the data
run through them can be strictly controlled.

I built my first 64 bit desktop system over 10 years ago and I still use
it. You are still deliberately avoiding the fact that 64 bit, LL64 and
more the more common LP64 systems have been in widespread use for a long
time, it's too late to start whinging now.

--
Ian Collins.

[Malcolm McLean]

"Ian Collins" <ia******@hotma il.comwrote in message
news:59******** *****@mid.indiv idual.net...

Malcolm McLean wrote:

>>
Though mainframes are an important part of the computing world, they
tend to be staffed by teams of professional programmers, and run
software specially written for them. The programs installed and the data
run through them can be strictly controlled.

I built my first 64 bit desktop system over 10 years ago and I still use
it. You are still deliberately avoiding the fact that 64 bit, LL64 and
more the more common LP64 systems have been in widespread use for a
long time, it's too late to start whinging now.

Exactly. You built it. Hobbyists or people with special requirements do
that. Most people don't have the interest or the ability.
It is not too late. At the moment 2GB is enough for anyone, but that is
going to change when people start using PCs to watch telly, and we'll see 64
bit machines with 64GB+ coming on to the market. Now is the time to get 64
bit ints so we can write games for them.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Ian Collins]

Malcolm McLean wrote:

"Ian Collins" <ia******@hotma il.comwrote:

>>
I built my first 64 bit desktop system over 10 years ago and I still use
it. You are still deliberately avoiding the fact that 64 bit, LL64 and
more the more common LP64 systems have been in widespread use for a
long time, it's too late to start whinging now.

Exactly. You built it. Hobbyists or people with special requirements do
that. Most people don't have the interest or the ability.

You just don't get it do you? I built it because I always build my own
systems. The parts were off the shelf. I could just as well have got a
system off the shelf, or borrowed one of the several hundred we had in
our building at work.

It is not too late. At the moment 2GB is enough for anyone, but that is
going to change when people start using PCs to watch telly,

Start? I do it all the time...

and we'll
see 64 bit machines with 64GB+ coming on to the market.

They've been there for many years.

Now is the time
to get 64 bit ints so we can write games for them.

No, its not. It's too late. The key decisions were made nigh on 20
years ago. This has nothing to do with C and everything to do with
operating system suppliers.

--
Ian Collins.

[CBFalconer]

Malcolm McLean wrote:

>

.... snip ...

>
In a consumer environment things are very different. Small
companies are trying to write software with very limited resources
which will be run on hardware they can't exactly specify, and will
have to exchange data with programs they know nothing about. If
there is a bug you don't have a list of installations and an
agreed patch schedule. If Microsoft decide that your compiler will
no longer run of Windows Vista, you have no choice but to run the
code through a different compiler.

Nonsense. You just go out and replace Vista. See below.

--
<http://www.cs.auckland .ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfoc us.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline.net

--
Posted via a free Usenet account from http://www.teranews.com

[Flash Gordon]

Malcolm McLean wrote, On 22/04/07 09:31:

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

>Malcolm McLean wrote, On 21/04/07 17:45:

>>Most architectures don't distinguish between address and data integer
registers,

Most that you have come across possibly, but I doubt that you have
come across most architectures.

There is an interesting social factor here. Virtually everyone has
access to a PC,

Apart from being wrong in assuming virtually everyone has access to s PC
(large number of people do not) all the PCs you can buy off the shelf
have several processors and you are only thinking about one of them.

quite a high proportion of them have a C compiler
installed.

Since Windows does not come with a C compiler and most computer users
are not interested in programming I think it highly likely that by far
the majority do not have a C compiler installed.

Quite a lot of programmer never need to touch another
platform.

A significant number yes, but I'm not convinced it is the majority.

So those who program other devices consider themselves to be
superior beings.

No. At least, none I've met, and the first 15 years of my career was
mainly working with such people and being one.

Few people if any program every architecture.

I doubt that anyone programs for all architectures since there are far
too many.

However as it happens I am
one of the superior beings.

You have shown no sing of superior knowledge or ability.

so it makes sense to use the same registers to hold pointers
and ints.

It is not simply the width of the address register that is important,
it is also the memory bandwidth. Since memory is slow using 64 bit
integers when you do not need them can slow things significantly.

That is a good argument. You could of course always say that it is up to
the programmer to use a shorter type if he wants performance,

That would be a very stupid attitude since smaller types are often slower.

or you
could take the ANSI route and make everything take and return a size_t,

You seem to being deliberately stupid. There are lots of things which
are nothing to do with indexing or array sizes.

so that sizeof int is irrelevant.

If you stick within the limits of what the C standard guarantees it is
irrelevant, if you make non-portable assumptions about it then it is not.

But the reality is that most people
will use a kludge of ints and other types.

You are the only person here who seems to think it is a kludge.

So is speed more important
than code falling over for large arrays and easy interfacing?

I've never had code fall over for large arrays and the beauty of using
specific types for different things is that it makes interfacing easy,
you just use the correct type for what you are doing.

How much
speed are we talking about?

Well, in a paper someone else posted a link to in this thread that
explained why 32 bit ints were being selected it said that it was a
large impact.

As I said, engineering is like that.
Normally there are some good arguments for the opposite decision.

Have you ever considered that the reason everyone in this thread seems
to disagree with you about this is that you might be wrong about what
you think is best?
--
Flash Gordon

[Walter Roberson]

In article <a4************ *************** ***@bt.com>,
Malcolm McLean <re*******@btin ternet.comwrote :

>It is not too late. At the moment 2GB is enough for anyone,

I know some people with home machines with over 2GB. Photo work is
key for some of those.

>but that is
going to change when people start using PCs to watch telly,

My wife watched telly on my 512 MB PC for a while; eventually I was
driven to drop more memory into it, but that's because I had several
competing background computations running, and several anti-spyware
or anti-virus running, and everything together was driving the machine
to swap. The telly program itself was less than 10 MB for the
executable and DLLs, and not particularily memory hungry in operation.

>and we'll see 64
bit machines with 64GB+ coming on to the market.

>Now is the time to get 64
bit ints so we can write games for them.

There was an interesting interview in Toms Hardware (actually,
TwitchGuru) not long ago, with one of the successful game developers.
He doesn't consider PCs to be a viable part of the games market, and
believes standardization in the console market is the desirable future
-- and consoles are, of course, special purpose embedded markets with
dedicated teams of programmers, etc., all the things you use an excuse
to justify the success of the LLP64 (int 32) products in the last
decade. Why not PCs? It isn't because of int size issues: it's because
of the lack of "agreed-upon standard for processing power, pixel
throughput, storage devices and Internet connections.". Too much work,
in other words, to generalize the games for the existing PC *hardware*
anarchy.
http://www.twitchguru.com/2007/04/17...off/page2.html
--
Programming is what happens while you're busy making other plans.

[Ben Pfaff]

"Malcolm McLean" <re*******@btin ternet.comwrite s:

>At the moment 2GB is enough for anyone,

I do research on virtual machines. 2 GB is enough to get
started, when you have a few virtual machines running, but memory
requirements go up very quickly.
--
"Some programming practices beg for errors;
this one is like calling an 800 number
and having errors delivered to your door."
--Steve McConnell

[Francine.Neary]

On Apr 21, 8:54 pm, Eric Sosman <[e-mail] e:

How many ways can you say "out of memory?" More than one,
I'm sure. A few possibilities:

- "Out of memory" (the basic bleat)

- "Memory quota exceeded" (maybe if the user petitions the
sysadmin for an increased quota all will be well)

- "No more swap space" (maybe if more swap can be allocated
all will be well)

- "Resource temporarily unavailable" (yes, I've seen this one)

- "No error" (I've seen this one, too)

... and probably others, too. The point is that a library function
may have several reasons for failing, and different reasons may
suggest different responses or corrections. IMHO it's better to
pass along whatever diagnostic information the implementation is
willing to provide than to throw a blanket over it and force the
user to guess about the reasons. Sometimes the diagnostic data is
misleading ("malloc: connection reset by peer"), but when it isn't
it can be most helpful.

OK... so maybe the solution would be to explicitly clear errno before
each call to malloc? Sounds tedious to do consistently :(

--
Eric Sosman
[e-mail]

[Keith Thompson]

Fr************@ googlemail.com writes:

On Apr 21, 8:54 pm, Eric Sosman <[e-mail] e:

> How many ways can you say "out of memory?" More than one,
I'm sure. A few possibilities:

- "Out of memory" (the basic bleat)

- "Memory quota exceeded" (maybe if the user petitions the
sysadmin for an increased quota all will be well)

- "No more swap space" (maybe if more swap can be allocated
all will be well)

- "Resource temporarily unavailable" (yes, I've seen this one)

- "No error" (I've seen this one, too)

... and probably others, too. The point is that a library function
may have several reasons for failing, and different reasons may
suggest different responses or corrections. IMHO it's better to
pass along whatever diagnostic information the implementation is
willing to provide than to throw a blanket over it and force the
user to guess about the reasons. Sometimes the diagnostic data is
misleading ("malloc: connection reset by peer"), but when it isn't
it can be most helpful.

OK... so maybe the solution would be to explicitly clear errno before
each call to malloc? Sounds tedious to do consistently :(

If you're going to use the value of errno, you should *always* set it
to 0 before calling the function of interest.

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