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]

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

Richard Heathfield wrote:

>Ian Collins said:

>>>When ever C hits the real world, developers have added fixed size
types.
Now they are standardised. Good.

Whenever language designers specify fixed size types, they have to come
back later and specify some more. Bad.

If don't specify the type, everyone else who wants it has to add their
own, so we ended up with typedefs like U8, INT16 and just about every
other possible naming of fixed types. At least the standard now sets a
naming convention.

People should be taught that it is almost never necessary to write code like
this.

Data is almost always either real numbers, strings, booleans, enumerated
symbols, or indices into arrays (technically a subset of keys). So double or
float, char *, and int should be basically all you need.
Almost always isn't alway always, and just occasionally you need an integer
of a different type. But it is very occasionally.

A cynic like me might argue that once you admit the size_t and ptrdif_t
gibberish into you code it is unreadable anyway and more gibberish won't
make any difference.

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

>Richard Heathfield wrote:

>>Ian Collins said:

When ever C hits the real world, developers have added fixed size
types.
Now they are standardised. Good.
Whenever language designers specify fixed size types, they have to come
back later and specify some more. Bad.

If don't specify the type, everyone else who wants it has to add their
own, so we ended up with typedefs like U8, INT16 and just about every
other possible naming of fixed types. At least the standard now sets a
naming convention.

People should be taught that it is almost never necessary to write code
like this.

Data is almost always either real numbers, strings, booleans, enumerated
symbols, or indices into arrays (technically a subset of keys). So
double or float, char *, and int should be basically all you need.

Never written any device drivers or protocol stacks then?

--
Ian Collins.

[Walter Roberson]

In article <1r************ *********@bt.co m>,
Malcolm McLean <re*******@btin ternet.comwrote :

>Data is almost always either real numbers, strings, booleans, enumerated
symbols, or indices into arrays (technically a subset of keys). So double or
float, char *, and int should be basically all you need.
Almost always isn't alway always, and just occasionally you need an integer
of a different type. But it is very occasionally.

I don't know what kind of programming you do, but the majority of
my programming over the years has been for integer data. Accounting
information for computer usage (time, disk, I/O). Network usage
analysis. Network trouble-shooting (e.g., number of late collisions).
Security log analysis (yes, that involves strings, but there are also
fundamental statistical summarization phases.) Compression programs
(string input, yes, but the output is integer arithmetic). And so on.

I have also worked on a number of scientic programs which used
real numbers extensively, so I am certainly not attempting to imply
that real numbers are unimportant, but the -majority- of my programs
have involved manipulating integral values.
--
Prototypes are supertypes of their clones. -- maplesoft

[CBFalconer]

Ian Collins wrote:

Malcolm McLean wrote:

.... snip ...

>>
Data is almost always either real numbers, strings, booleans,
enumerated symbols, or indices into arrays (technically a subset
of keys). So double or float, char *, and int should be basically

all you need.

Never written any device drivers or protocol stacks then?

(val & 0xff) is fairly well guaranteed to carry exactly 8 bits.

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

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

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

[Flash Gordon]

Walter Roberson wrote, On 21/04/07 13:02:

In article <1r************ *********@bt.co m>,
Malcolm McLean <re*******@btin ternet.comwrote :

>Data is almost always either real numbers, strings, booleans, enumerated
symbols, or indices into arrays (technically a subset of keys). So double or
float, char *, and int should be basically all you need.
Almost always isn't alway always, and just occasionally you need an integer
of a different type. But it is very occasionally.

I don't know what kind of programming you do, but the majority of
my programming over the years has been for integer data.

For me there has been a lot of fixed point stuff. I really do mean fixed
point, floating point would have been inappropriate for several reasons.

Accounting
information for computer usage (time, disk, I/O).

I can add accounting information in the sense accountants are interested
in as well. Also various other quantities, such as weights and measures,
for accounting, billing, invoicing reasons you want in fixed point with
a defined scaling rather than floating point.

Network usage
analysis. Network trouble-shooting (e.g., number of late collisions).
Security log analysis (yes, that involves strings, but there are also
fundamental statistical summarization phases.) Compression programs
(string input, yes, but the output is integer arithmetic). And so on.

A lot of embedded work in my experience you want fixed point for
efficiency. Also fixed point or integer is appropriate for certain types
of image processing, and for stability reasons (accurate control of
rounding and precision) you well prefer fixed point for all sorts of
control loops.

I have also worked on a number of scientic programs which used
real numbers extensively, so I am certainly not attempting to imply
that real numbers are unimportant, but the -majority- of my programs
have involved manipulating integral values.

Same here.
--
Flash Gordon

[Walter Roberson]

In article <46************ ***@yahoo.com>,
CBFalconer <cb********@mai neline.netwrote :

>Ian Collins wrote:

>Malcolm McLean wrote:

>>Data is almost always either real numbers, strings, booleans,
enumerated symbols, or indices into arrays (technically a subset
of keys). So double or float, char *, and int should be basically

all you need.

>Never written any device drivers or protocol stacks then?

>(val & 0xff) is fairly well guaranteed to carry exactly 8 bits.

But (val & 0xff) is not a "key" nor an "enumerated symbol", so
according to Malcolm it does not fall into the class of
"data is almost always". And there are a lot of IPv4 addresses
(and netmasks) still around; those are certain to fit into a C unsigned
long, but not certain to fit into a C "int"; to me it seems unnatural to
deliberately write the code in terms of arrays of unsigned char
or unsigned int just to fit into someone's notion that int
"should be basically all you need".
--
Programming is what happens while you're busy making other plans.

[Flash Gordon]

Ian Collins wrote, On 21/04/07 01:10:

Malcolm McLean wrote:

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

>>Malcolm McLean wrote On 04/20/07 17:58,:

change is not having int as the natural integer type for the platform.
You keep asserting this, but it was never so. int was
always a "useful" size that "made sense" for the platform.
I've used eight-bit machines with C implementations , but
never have I seen an 8-bit int.

Your machine had an eight bit address bus?
There is a bit of wooliness in the "natural integer type". However
generally it is the size needed to index the largest possible array,
which generally boils down to the size of the address bus, but not on
old x86s because of the weirdness of the architecture.

No, it can't do that, int is a signed type, so it can never index the
largest possible array.

Malcolm is also forgetting the Motorola 68000 series of processors. They
had address busses larger than 16 bits but smaller than 32 bits, they
were also flat address spaces. C compilers for those used 16 bit ints.

Some of the DSPs with 24 or 48 bit integer registers and ALUs will have
had 16/32 bit address busses. However, I suppose Malcolm might be happy
with an int larger than the address bus by a few bits.

>On a machine with 64 bits of flat address space and a 64 bit data
register file the natural integer size is quite clearly 64 bits. At the
moment there might be a performace case for using 32-bit integers to
conserve cache space. I've not said that all the good arguments are on
my side. However I suspect that this issue will prove to be quite
short-lived.

Considering 64 bit systems have been in widespread use for over a
decade, short is a relative term.

Indeed.
--
Flash Gordon

[Malcolm McLean]

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

>
Some of the DSPs with 24 or 48 bit integer registers and ALUs will have
had 16/32 bit address busses. However, I suppose Malcolm might be happy
with an int larger than the address bus by a few bits.

Ideally you'd have one extra bit so that signed arithmetic couldn't fail to
have enough resolution. However at least in C the convention is that indices
are scaled by the data type. So the problem only arises for char arrays
taking up over half the address space. That happens rarely enough for it to
be reasonable to say "many functions may not work on your dataset, you will
have to code specially with unsigned types".
Most architectures don't distinguish between address and data integer
registers, so it makes sense to use the same registers to hold pointers and
ints.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Walter Roberson]

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

>Most architectures don't distinguish between address and data integer
registers, so it makes sense to use the same registers to hold pointers and
ints.

"Most" maybe, but some well known and widely implemented architectures
do, such as the Motorola 680x0 and the MIPS R2000/ 3000/ 4000/ 5000/
6000/ 8000/ 10000/ 12000 lines (MIPS is used in a lot of embedded
situations, I hear.)

Are we talking about C for general purpose computing, or are we talking
about imposing non-trivial architecture restrictions on the machines
that will use this modified C?
--
All is vanity. -- Ecclesiastes

[Malcolm McLean]

"Walter Roberson" <ro******@ibd.n rc-cnrc.gc.cawrote in message
news:f0******** **@canopus.cc.u manitoba.ca...

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

>>Most architectures don't distinguish between address and data integer
registers, so it makes sense to use the same registers to hold pointers
and
ints.

"Most" maybe, but some well known and widely implemented architectures
do, such as the Motorola 680x0 and the MIPS R2000/ 3000/ 4000/ 5000/
6000/ 8000/ 10000/ 12000 lines (MIPS is used in a lot of embedded
situations, I hear.)

Are we talking about C for general purpose computing, or are we talking
about imposing non-trivial architecture restrictions on the machines
that will use this modified C?

We're talking about what int should be on a typical 64-bit machine. I'm
arguing 64 bits, the emerging convention is 32 bits, which I oppose. We're
not taling about removing latitude from the language so that DSP chips and
the like can't use funny integer sizes if it is appropriate for them, nor
are we talking about modifying the standard.
Except that I've indicated that as a long-term goal I'd like size_t removed
from the language, or at least generate a mandatory ugliness warning.
However that's for the future. At the moment the fight is for 64 bits.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm