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

[CBFalconer]

Richard Heathfield wrote:

CBFalconer said:

>Malcolm McLean wrote:

>>>

... snip ...

>>>
Now consider this

foo(char *str1, char *str2)
{
hackme = strlen(str1) - count_spaces(st r2);
if(hackme < 0)
bar(str1, str2);
else
baz(str12, str2);
}

Again nothing too exceptional about this code. Typical rather
horrid flow control logic. What type would you say hackme should
be?

You can simplify, because strlen can never return a value less than
0. It returns a size_t, which is an unsigned quantity. Thus you
can reliably replace the whole routine with:

bar(str1, str2);

and save a minimum of 9 lines of useless source code.

But your "replacemen t" does not actually have the same functionality
as Malcolm's code. You might want to read it again, more carefully.

So it doesn't. Another good idea hits the dust.

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

[Malcolm McLean]

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

Malcolm McLean wrote:

>>
"Keith Thompson" <ks***@mib.orgw rote in message
news:ln******* *****@nuthaus.m ib.org...

>>On the other hand, sometimes it's ok to use int to index into an
array, if, for example, you happen to know that the array cannot have
more than 32768 elements. The indexing operation takes one pointer
operand (often a converted array name) and one integer operand; the
integer operand can be of any integer type, including int, size_t, and
even _Bool if your compiler supports it.

This is the problem.

int count_spaces(ch ar *str)
{
int i;
int answer = 0;

for(i=0;str[i];i++)
if(str[i] == ' ')
answer++;

return answer;
}

Perfectly unexceptional code. In fact it is unlikely that anyone is
going to want that routine on anything other than a line limited
elsewhere to be a thousand or so characters.
But someone might, just might, pass in a really long string. So those
ints have got to be size_ts to be strictly correct. So size_t is
propagating up out type.

So? Consider a 16 bit machine with a 20 bit address space, should int
on that machine be 21 bits?

Ideally yes. In practise it is better to have the extra efficiency and put
burdens on those people who want an array spanning over half the address
space. Once an architecture get weird there is no answer - in practise such
machines had near and far pointers and constrained single arrays to be less
that 64K, allowing 16 bit indexing. It worked, but it was far from ideal,
and threw a hammer in portability.

>
Why would a function that counts something return a signed type?

Because intermediate calculations using it might go below zero.

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

>>This is the problem.

int count_spaces(ch ar *str)
{
int i;
int answer = 0;

for(i=0;str[i];i++)
if(str[i] == ' ')
answer++;

return answer;
}

So? Consider a 16 bit machine with a 20 bit address space, should int
on that machine be 21 bits?

Ideally yes. In practise it is better to have the extra efficiency and
put burdens on those people who want an array spanning over half the
address space.

So there you have it - 32 bit int on a typical contemporary 64 bit
machine *does* provide extra efficiency of over a 64 bit int.

>>
Why would a function that counts something return a signed type?

Because intermediate calculations using it might go below zero.

Bud does it make any sense?

--
Ian Collins.

[Ian Collins]

Ian Collins wrote:

>
Bud does it make any sense?

My word, my typos are in overdrive this evening!

--
Ian Collins.

[Malcolm McLean]

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

Malcolm McLean wrote:

>>
Ideally yes. In practise it is better to have the extra efficiency and
put burdens on those people who want an array spanning over half the
address space.

So there you have it - 32 bit int on a typical contemporary 64 bit
machine *does* provide extra efficiency of over a 64 bit int.

Engineering is like that. A bad design decision usually has something going
for it, and there are good arguments we can use in its favour.
I'd like to see some benchmarks on real applications to see whether hitting
the cache capacity has a big effect or a small effect.

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

[Malcolm McLean]

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

Malcolm McLean wrote On 04/17/07 16:25,:

>>
Again nothing too exceptional about this code. Typical rather horrid flow
control logic. What type would you say hackme should be?

"No type at all."

foo(char *str1, char *str2) {
if (strlen(str1) < count_spaces(st r2))
bar(str1, str2);
else
baz(str12 /* sic */, str2);
}

That's acceptable code, but you are reversing my decision to improve
readbility by splitting the computation into two statements.
Whilst in this case you might be right, readability is highly important, and
layout should not be dictated by the weaknesses of the type sytem. Anyway,
we could easily modify the example so that hackme is required twice.

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

[Eric Sosman]

Malcolm McLean wrote On 04/18/07 15:06,:

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

>>Malcolm McLean wrote On 04/17/07 16:25,:

>>>Again nothing too exceptional about this code. Typical rather horrid flow
control logic. What type would you say hackme should be?

"No type at all."

foo(char *str1, char *str2) {
if (strlen(str1) < count_spaces(st r2))
bar(str1, str2);
else
baz(str12 /* sic */, str2);
}

That's acceptable code, but you are reversing my decision to improve
readbility by splitting the computation into two statements.

You "improve" readability by using many statements
where one suffices? Does your family tree blossom with
lawyers, politicians, marketeers, and spin doctors?

Whilst in this case you might be right, readability is highly important, and
layout should not be dictated by the weaknesses of the type sytem. Anyway,
we could easily modify the example so that hackme is required twice.

int hackme = strlen(str1) < count_spaces(st r2);

(Optional: Use _Bool instead of int for C99.)

--
Er*********@sun .com

[Richard Heathfield]

Eric Sosman said:

Malcolm McLean wrote On 04/18/07 15:06,:

>>
That's acceptable code, but you are reversing my decision to improve
readbility by splitting the computation into two statements.

You "improve" readability by using many statements
where one suffices?

This is sometimes the case, yes, although it may depend on what you mean
by "suffices".

Consider, for example, the following (genuine) code:

new->pixel[y] = clc_malloc(widt h * sizeof *new->pixel[y]);
if(new->pixel[y] == NULL)
Now, you /could rewrite this as:

if((new->pixel[y] = clc_malloc(widt h * sizeof *new->pixel[y])) == NULL)

....which certainly suffices, but I am not convinced that readability is
improved by the contraction.

Does your family tree blossom with
lawyers, politicians, marketeers, and spin doctors?

I think that's a touch unfair. I'm actually on your side in this
discussion, but I think you overstate the case here.

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

[William Ahern]

Richard Heathfield <rj*@see.sig.in validwrote:
<snip>

Now, you /could rewrite this as:

if((new->pixel[y] = clc_malloc(widt h * sizeof *new->pixel[y])) == NULL)

...which certainly suffices, but I am not convinced that readability is
improved by the contraction.

I would agree with you. Which is why I generally swap the operands:

if (0 != (new->pixel[y] = clc_malloc(widt h * sizeof *new->pixel[y])))
...

Operands are used in order of most importance to thine eyes and head.
Personally, this reads much more easily than multiple statements.

[Eric Sosman]

Richard Heathfield wrote On 04/18/07 15:43,:

Eric Sosman said:

>>Malcolm McLean wrote On 04/18/07 15:06,:

>>>That's acceptable code, but you are reversing my decision to improve
readbility by splitting the computation into two statements.

You "improve" readability by using many statements
where one suffices?

This is sometimes the case, yes, although it may depend on what you mean
by "suffices".

Consider, for example, the following (genuine) code:

new->pixel[y] = clc_malloc(widt h * sizeof *new->pixel[y]);
if(new->pixel[y] == NULL)
Now, you /could rewrite this as:

if((new->pixel[y] = clc_malloc(widt h * sizeof *new->pixel[y])) == NULL)

...which certainly suffices, but I am not convinced that readability is
improved by the contraction.

Yah. "Bless you, it all depends." It is useful to
decompose lengthy statements into smaller, more easily-
comprehended pieces (not just for the reader's sake, but
for the writer's as well!), but decomposition for its own
sake is, well, compost.

McClean's example showed a perfectly simple, obvious
and easily-comprehended test, which he chose to decompose
into two statements. In the process he introduced a brand-
new variable (the point of his example was to try to expose
a difficulty concerning that unnecessary variable), plus two
additional operators. That sort of rearrangement is not
only obfuscatory (hiding a comparison behind a subtraction,
a la FORTRAN's three-way IF), but bug-inducing.

As for the malloc example, I myself usually write an
assignment statement and a separate test. This is not so
much out of a concern that the whole thing would be too
long, but to direct the focus: "I will now allocate some
memory. (By the way, I'll also check for failure.)" But
sometimes I'll gang the whole thing together, particularly
during an initialization where I'm just going to exit the
program on a failure:

if ( (buff1 = malloc(N1 * sizeof *buff1) == NULL
|| (buff2 = malloc(N2 * sizeof *buff2) == NULL
|| (buff3 = malloc(N3 * sizeof *buff3) == NULL ) {
perror ("malloc");
fputs ("No memory; bye-bye!\n", stderr);
exit (EXIT_FAILURE);
}

I think this is easier to read than three assignments, three
tests, and three error-exits, or than shuffling the test-and-
exit off to a wrapper function -- although I do *that* too,
sometimes. (Note that three assignments followed by one
three-way test and one error-exit is not quite the same: if
malloc() sets errno, the successful allocation of buff3 could
obscure why buff2's allocation failed. malloc() need not set
errno and some do not, but I take the optimistic view and try
to give the poor user all the available diagnoses, even if
they're suspect.)

>>Does your family tree blossom with
lawyers, politicians, marketeers, and spin doctors?

I think that's a touch unfair. I'm actually on your side in this
discussion, but I think you overstate the case here.

Tastes vary. Or, "There's no point arguing with Gus."

--
Er*********@sun .com