32 or 64 bit processor info in C

[Flash Gordon]

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

I want a type called "int" and signed that is the size of the address
bus.

C has NEVER had that as the definition of what an int should be.

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

No it has not. It has already been pointed out that Intel have done
processors with 24 bit address busses where the compilers provided
either 16 or 32 bit ints. Check up on the x86 series of processors, they
are fairly common.

> The proposal is to change it, to
make int no longer the natural integer size for the machine.

There is no such processors. All the processors around for which
compilers are providing a 32 bit int can natively and naturally handle
32 bit ints.

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.

I'm not the only person doing financial SW. There are lots of other
people doing image processing and avionics SW.

> But since size_t is unsigned,

When have you needed a negative amount of memory or needed to index
before the start of an array?

> awkward to read,

That is a matter of opinion.

> and most
numbers are much less than 2 billion,

Most number used may be, but there is significant demand for larger
numbers, such as in calculating the tax of a company that turns over
more than 20,000,000 of the local currency (assuming something like the
UKP or USD when you have 100 cents/pennies to the dollar/pound). In some
currencies it is even easier to need numbers above 2 billion! Note I
only say significant demand, not that this is the majority usage.

> people won't use it consistently.

That's true of almost everything in all languages.

A type is a standard for passing data between functions.

It is also useful for doing the actual work! In fact, if it is

> So we'll have
the two plugs problem. It will seriously impact the reusability of C code.

No, code that uses it properly is easily reusable. Code that does not
use it, or uses it incorrectly, is harder to reuse, but that is the same
for everything.

If int is 64 bits on 64-bit machines size_t will gradually fade
away.

Not in properly written code, because it is for a different purpose.

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

Then don't use it, no one is forcing you to.

> Eventually we will return sizeof() to generating an
int,

Since it has not changed yet, despite this "problem" having occured
before in the move from "16 bit" to "32 bit" processors, I doubt it will
change in the future. Unless you find a way of creating objects with a
negative size, that is.

> and remove it from the string functions, so it will survive merely
as a fossil in malloc().

I doubt that will happen either, see above.

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.

No, since it is the Unix standard and the OS developers that generally
specify the ABI. In any case, as stated else-thread, the 64 bit
processors in general (the Cray is an exception) can handle 32 bit
integers as naturally as 64 bit ones and using 32 bit integers can give
a significant performance boost by halving the amount of traffic between
the fast processor and the slow memory.

> As 64 bit machines hit the mass market,

Too late, they have already hit it some time back, and the decisions
were made a LONG time before that.

> we have a
brief chance to save our language from ANSI doing to C what they did to
C++.

The language is fine as it is, there is nothing to save it from. Of
course, if you do not like the language defined a few decades ago feel
free to use a different language.

 

[Flash Gordon]

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

Ian Collins said:

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]

Army1987 wrote, On 14/04/07 12:20:

"Malcolm McLean" <[email protected]> ha scritto nel messaggio



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

That reminds me, you also have intptr_t and uintptr_t which, if present,
are guaranteed to be large enough to hold and pointer, so by inference
are going to be as large as the address bus (unless pointers are
narrower than the address bus).

 

[Eric Sosman]

I want a type called "int" and signed that is the size of the address
bus.

That's nice. I want a strawberry shortcake.

More to the point, what extensions do you propose to C to
make "the size of the address bus" measurable? How can C even
detect the existence of an "address bus," much less measure its
size, or its temperature and mass for that matter?

Well, maybe we don't need to have C measure this elusive
quantity; we can follow the tradition of some other hard-to-
measure values and simply supply them as implementation-provided
macros, the same way we do with things like FLT_RADIX. Fine, but
where does that leave your precious 64-bit int? What size int do
you want on a machine with 64-bit virtual addresses but, say, a
48-bit physical address?

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.

Width of int == width of address bus has *never* been the
convention. On some machines -- but by no means all -- the
relation did happen to hold, but that was just coincidence. I
challenge you to find one, even one reference to "width of
address bus" in K&R, either original or revamped.

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.

And why, precisely, is that a problem?

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

Proof by repetition. If you say it even louder next time,
it will be even truer, right?

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

Ah, *that's* why size_t is a problem: Because "programmers"
who won't learn the language write bad code! So you're arguing
that the language design should be driven by the needs of the
ignorant and lazy, to the detriment of the diligent and able?
Recommended reading: "With Folded Hands" by Jack Williamson.

 

[Malcolm McLean]

Malcolm McLean wrote, On 14/04/07 09:09:

If the objections are valid then it means the evidence is not relevant.


If you have no evidence for which there are not valid objections then your
position is merely your opinion.

No. You are comitting the fallacy.
Prosecutor: Bloggs saw Muggins kill the victim.
Defence: But Bloggs is a drugs dealer who has a grudge against Muggins.

True.
Therefore there is a "no evidence" position against Muggins? No. Whilst it
is plausible that Bloggs is making the allegation up, we have a dead body
and a claim that Muggins did it.

That is why people conduct studdies. Some times those studdies can be done
by taking the raw data from a number of other studdies, but you have to
design your study first then go and collect the data from the other
studies.

No. Ideally this would happen, but you can't snap your fingers and summon
data into existence.

>

Assumptions which have to be justified, especially if challenged. You have
not given any justification for your assumptions (which you did not state)
or explanation of why my challenges are wrong.

The challenges are not wrong. To use our prosecutor analogy, it is perfectly
valid for the defence the point out that Bloggs is a drugs dealer. The
fallacy is in supposing that therefore Blogg's evidence disappears.
"Therefore," says the defence, "isn't it suprising that Muggins fired a shot
and no-one heard it?" Totally invalid, because he has manufactured an
absence of Blogg's evidence.

In your case it was quite right to point out the weaknesses in my approach,
which were real, but they do not make the evidence disappear.

I gave specific reasons why certain classes of applications do a lot of
integer work that is not to do with indexing. Here is another, a number of
the SQL data types are either integer types (which will be impleneted as
integer types) or scaled integer types (which will be implemented as
integer types with the scaling stored as part of the column definition.
The manipulation of those integer types will be on the basis of SQL
queries, summing costs etc. On financial applications, such as Sun
Financials, they make use of such types a lot, and hardly any use of
arrays. I suspect that there is a LOT of financial SW out there where they
do not want to use floating point for numbers because the law does not
permit them to have rounding errors (or specifies specific rounding which
you won't be able to guarantee with floating point numbers).

Probable most "indexing" done by a database is indexing in to a file, not
memory, so by that argument we need int to be large enough to store the
size of the largest table that might be required, and that is independent
of the processor!

It is possible that you are right and the example suite of program used in
the study was not representative. When you say that evidence has weakness,
ultimately you may be right. Certainly by using a database with a query
interface we have eliminated a lot of array accesses. Then there is a
question of whether you count internal indexing by the database system -
what exactly are we interested in?

You would need to do rather more than look at one very biased sample to
have any significant evidence.

A sample of one tells you what the probable answer is.

So far the only person to jump in on either side is Richard Heathfield,
and he seems to take the opposing view. So another biased sampling shows
that most C developers either have no opinion on the subject or disagree
with you.

True. I think what happens is that most people think of the results as _the_
calcualtion, and the indexing as intermediates. So if you up twenty salaries
by 10% you are doing twenty multiplications. In fact you are probably doing
five of six array calculations as well.

True, but they have vastly more rigour than looking at a sample that says
it was biased and then using the data for something the collection was not
designed for.

Some do, some don't. In ecology for instance it is often very expensive to
collect data and resources are minimal. In medical trials on the other hand
you can do double blind tests to answer a very narrow question. In our case
I can't be bothered to tag up a representative sample of programs to answer
a fairly minor question, so I'm doing it on the cheap.

If a sample can be shown to be biased for the use it is being put to then
you cannot use it on its own as evidence for your point. If you collect
data from enough other studdies with different biases and can show they
cancel out, or you can come up with a way to counteract the bias (with
evidence supporting your method) then you can use it.

Note that I do not claim to know whether overall integer types are used
more for indexing and related operations or for other purposes. I only
claim that my experience contradicts it and that you have no significant
evidence to support your personal opinion.

You've softened your position by saying "no significant evidence" rather
than "no evidence". That doesn't mean you are off the hook for the fallacy,
though does mean that there is at least some awareness.
First you said that the study wasn't representative, but didn't give
a very plausible reason why this would be so - that amounts of money are
often held as integers. All that does is shift a few flaoting point
operations to integers. Now you've come back with a second reason, that the
main data structures might not be held in arrays because they are in
databases. That's more plausible, and you mgiht just be right, particuarly
if we exclude internal indexing done by the query system, which is arguably
legitimate. However the Java sample showed such a large number of array
index operations that it isn't at all obvious that even this would shift it.
But maybe, just maybe, you are right for one class of applications.

 

[Malcolm McLean]

Army1987 wrote, On 14/04/07 12:20:

That reminds me, you also have intptr_t and uintptr_t which, if present,
are guaranteed to be large enough to hold and pointer, so by inference are
going to be as large as the address bus (unless pointers are narrower than
the address bus).

You see where this is leading? Anyone still disbelieve in the existence of
gibberish types?

 

[Walter Roberson]

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.

It has not "been the convention until now". It was not, for
example, true in the SGI IRIX 64 bit machines introduced late
in 1994; they used LP64 (int 32 bits, long and pointer 64 bits.)
That was before Windows 95, to give you an idea of how many software
generations have been gone through since then.

 

[Flash Gordon]

Malcolm McLean wrote, On 14/04/07 15:48:

No. You are comitting the fallacy.
Prosecutor: Bloggs saw Muggins kill the victim.
Defence: But Bloggs is a drugs dealer who has a grudge against Muggins.

True.
Therefore there is a "no evidence" position against Muggins? No. Whilst
it is plausible that Bloggs is making the allegation up, we have a dead
body and a claim that Muggins did it.

Your analogy is completely bogus because in this case Blogs said
something mode like "Muggins has more guns than his wife, Fred has more
guns than his wife, therefore most men have more weapons than their
wives". Your study claimed nothing about what you are trying to prove,
you are trying to use the data collected from a study for purposes other
than that the data collection strategy was designed for. One of the
major reasons for studies giving inaccurate results is poor data
collection, and that is something you are suffering from.

No. Ideally this would happen, but you can't snap your fingers and
summon data into existence.

So? Your inability to generate good evidence does not mean people should
collect poor evidence.

The challenges are not wrong.

Since you accept that, either provide evidence that does not have those
weaknesses or accept that you are just giving your opinion.

> To use our prosecutor analogy, it is
perfectly valid for the defence the point out that Bloggs is a drugs
dealer. The fallacy is in supposing that therefore Blogg's evidence
disappears. "Therefore," says the defence, "isn't it suprising that
Muggins fired a shot and no-one heard it?" Totally invalid, because he
has manufactured an absence of Blogg's evidence.

Incorrect analogy as stated above.

In your case it was quite right to point out the weaknesses in my
approach, which were real, but they do not make the evidence disappear.

Since I have equally "good" evidence that contradicts what you are
claiming, and I have presented it, there balance is that there is no
objective reason for believing what you claim as fact.

It is possible that you are right and the example suite of program used
in the study was not representative. When you say that evidence has
weakness, ultimately you may be right.

So either present decent evidence or accept you are stating oppinion not
fact.

> Certainly by using a database
with a query interface we have eliminated a lot of array accesses.

Most of my other work has not required array access in the first place.

> Then
there is a question of whether you count internal indexing by the
database system - what exactly are we interested in?

You claiming that integer arithmetic is mainly used for array access and
therefore int should be the same width as the address bus. As the
database would be looking up in a file, not in memory, the width of the
address bus is irrelevant in such an instance as I explained either in
this or another recent post.

A sample of one tells you what the probable answer is.

You would not pass any statistics course if you honestly believe that.

True. I think what happens is that most people think of the results as
_the_ calcualtion, and the indexing as intermediates.

What evidence do you have that this is the reason for Richard's opinion?

> So if you up
twenty salaries by 10% you are doing twenty multiplications. In fact you
are probably doing five of six array calculations as well.

Actually, it is more likely to be adding up the salaries of several
thousand people and involve exactly ZERO array or other memory indexing
operations because the data is help in a database not in memory. Even if
it was a simple array, the code
for (i=0; i<no_employees; i++)
tax += (salary * scaled_tax) / 100;

Involves for indexing one increment and one indexing, so that is two
operations to do with indexing. However, it has an addition, a
multiplication and a division which are to do with money, not indexing.

In reality, you would be doing a database lookup which might involve an
array lookup or three, then doing far more complex integer operations on
the data fetched. So the balance is even further against your position.

Some do, some don't. In ecology for instance it is often very expensive
to collect data and resources are minimal.

So they either collect data targetted at what they are trying to prove
or use the raw data from several studies, not just one.

> In medical trials on the
other hand you can do double blind tests to answer a very narrow
question. In our case I can't be bothered to tag up a representative
sample of programs to answer a fairly minor question, so I'm doing it on
the cheap.

By doing it on the cheap you are failing to prove the point. In any
case, I originally asked you if you had any evidence for what you
were claiming, and the answer to that question was obviously no or you
would have had no need to go looking for evidence! So you started by
claiming your personal opinion as fact and have since tried to use a
study designed to demonstrate something else which you have admitted has
at least serious weaknesses for your purposes. So you are STILL not in a
position to claim it as fact.

You've softened your position by saying "no significant evidence" rather
than "no evidence". That doesn't mean you are off the hook for the
fallacy, though does mean that there is at least some awareness.

One person saying "X is true" is evidence, but it does not prove it or
even on something like this give any real reason to believe it.

First you said that the study wasn't representative, but didn't
give a very plausible reason why this would be so

Yes I did. I pointed out one major class of SW that was EXPLICITLY
excluded from the study, and other classes of SW that it did not seem to
cover. A bit like saying "most people are taller than 165cm based on
this study that explicitly excluded asians from the data it was collecting."

> - that amounts of
money are often held as integers. All that does is shift a few flaoting
point operations to integers.

That was only ONE instance, I gave others as well. Also, on financial
software MOST of the operations are on money, so it shift a VAST NUMBER
of operations from floating point to integer.

Now you've come back with a second reason,

No, I had already given more than two reasons. You obviously did not
read all of it which would explain you not addressing all of the points.

that the main data structures might not be held in arrays because they
are in databases. That's more plausible, and you mgiht just be right,
particuarly if we exclude internal indexing done by the query system,
which is arguably legitimate.

Since indexes in to files are not related to the size of the address bus
I would say it was a very strong argument. In any case, the lookups are
done using hashes and binary trees, and a binary tree does not do
indexing calculations it just reads and follows the pointer!

> However the Java sample showed such a
large number of array index operations that it isn't at all obvious that
even this would shift it. But maybe, just maybe, you are right for one
class of applications.

Mayby I am right for the other classes of applications I mentioned as
well. Unless you think that image processing and avionics systems are
the same class of applications as financial applications. I can add
stabilised motor control of various forms to the list of things I've
done with integer arithmetic without use of arrays.

Also you pointed out that indexing operations are used for accessing
local variables, and I pointed out that there can be a lot of that
without the use of arrays, so without a more detailed analysis of what
the instructions were being used for (which the data you quoted does not
allow) you still don't know that even on that study it was mainly array
operations.

Remember that these are things I've spent years working on so I know how
they are done. Also there are all the other classes of applications
neither of us know anything about. In addition to the point you failed
to address that Java tends to be used for different types of application
designed in a different way to that which C is used for.

 

[Flash Gordon]

Malcolm McLean wrote, On 14/04/07 15:53:

You see where this is leading? Anyone still disbelieve in the existence
of gibberish types?

So any type other than int that would serve your purpose is a gibberish
type then? That certainly seems to be your point, and if so it looks
more like you are spouting gibberish.

int it there for integer arithmetic, nothing more and nothing less. If
you have more specific requirements then it is obvious that you need a
more specific type.

 

[CBFalconer]

Malcolm McLean wrote:
.... snip ...


Ah, *that's* why size_t is a problem: Because "programmers"
who won't learn the language write bad code! So you're arguing
that the language design should be driven by the needs of the
ignorant and lazy, to the detriment of the diligent and able?
Recommended reading: "With Folded Hands" by Jack Williamson.

That may be a problem for him I think the war was on when it
was published. That's WWII.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.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

 

[Keith Thompson]

You see where this is leading? Anyone still disbelieve in the
existence of gibberish types?

They are not gibberish. There are simply different names for types
intended for different purposes. Most of us don't have a problem with
that; I'm not sure why you do.

 

[Keith Thompson]

The camapign for 64 bit ints is actually a campaign for ints the size
of the address bus.

[...]

I hate to tell you this, but there's no "campaign". As far as I can
tell, it's just you.

That's not to say that you're wrong. It's not inconceivable that
you're right and everyone else just doesn't get it. But that's not
the way to bet. You might consider trying to look at it from another
point of view. Think about the possibility that having distict types
for distinct purposes isn't such a bad thing.

 

[Ian Collins]

Ian Collins said:



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.

The bulk of code currently running on desktop/server 64 bit platforms is
code written on 32 bit systems that has been recompiled for 64 bit. It
just isn't practical to go through and change all the uses of int.

 

[Eric Sosman]

That may be a problem for him I think the war was on when it
was published. That's WWII.

It's available on Amazon. The war's still on. (OIF, the
early decades.)

 

[Malcolm McLean]

Since you accept that, either provide evidence that does not have those
weaknesses or accept that you are just giving your opinion.

You don't get it.
Bloggs, our witness, is a drugs dealer and has a grudge against the accused,
Muggins. However he says he saw Muggins do it.
Defence naturally points out Bloggs' character. However the prosecution's
case does not thereby dissolve into a "no evidence" position. Nor do they
need to try to pretend that Bloggs is some paragon of virtue. You don't get
many chartered accountants hanging about where drugs dealers murder each
other.

To send Muggins to the electric chair we need a bit more than just Bloggs,
but Bloggs' testimony can still be an important part of the case. To tell
our children that it might be best to steer clear of Muggins' company, we've
got enough evidence until someone conclusively proves that Bloggs is lying.

 

[Richard Heathfield]

Ian Collins said:

The bulk of code currently running on desktop/server 64 bit platforms
is
code written on 32 bit systems that has been recompiled for 64 bit.
It just isn't practical to go through and change all the uses of int.

If the code was written properly, this won't be necessary anyway.

 

[Ian Collins]

Ian Collins said:




If the code was written properly, this won't be necessary anyway.

If the world were a perfect place, I could live on ale and curry and not
get fat!

Maybe the correctness of a platform's code an be judged by the 64 bit
model it adopted?

 

[Richard Heathfield]

Ian Collins said:

Richard Heathfield wrote:

If the world were a perfect place, I could live on ale and curry and
not get fat!

If the world were a perfect place, there would be no such thing as
curry.

Maybe the correctness of a platform's code an be judged by the 64 bit
model it adopted?

I'd have thought that ISO/IEC 9899 would be a better yardstick.

 

[Flash Gordon]

Malcolm McLean wrote, On 15/04/07 00:16:

You don't get it.
Bloggs, our witness, is a drugs dealer and has a grudge against the
accused, Muggins. However he says he saw Muggins do it.

<snip>

I understand perfectly what you are saying, I just happen not to agree
with it being a valid analogy for reasons I stated. The study you quoted
does not make the same claim integers are mainly used for indexing.

You also don't seem to get that if you want people to accept you have a
valid point you actually have to properly address weaknesses in what you
present as evidence, so far you have not done that.

I'm also inclined to suspect the MS know a bit more about the typical
usage of its compilers than you and that the Unix standards body know a
bit more about what is done under Unix than your, someone even posted in
this thread a link to a document which explained why they made the
choice they did.

 

[Mark McIntyre]

Ian Collins said:

If the world were a perfect place, there would be no such thing as
curry.

Que?

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan