64 bit linux on Intel T9600

[D. Hugh Redelmeier]

| From: Lennart Sorensen <lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org>

| On Fri, Jun 19, 2009 at 02:39:18PM -0400, D. Hugh Redelmeier wrote:

| >  Unfortunately the x86-64 ABI panders to this 
| > disease (evidence: sizeof(int) == 4!).
|  
| How is that a problem?  As long as size(long) == 8 on a 64bit machine,
| then you should be happy.  Windows unfortunately does NOT do that.
| They have a special long type for storing pointer size things on 64bt
| systems.

K&R, first edition, describes int as:
	an integer, typically reflecting the natural size of integers
	on the host machine

Furthermore, in describing short and long, it says:

	The intent is that short and long should provide different
	lengths of integers where practical; in will normally reflect
	the most ``natural'' size for a particular machine.

To me, on a machine that I think of as 64-bit, that would be 64 bits.

To be honest, I think that the structure of integral types in C are a
mess.  One fix-up adopted by the C Committee looks ugly too: adding
types with explicit widths in bits.

Pascal's subranges are more natural.  You get to specify the range in
terms that are relevant to your problem.  Intermediate expressions should
be as-if calculated in infinite width.  If a programmer knows that
an intermediate expression won't overflow a narrower type, and the
compiler cannot know that, the programmer can add a cast to help the
compiler.  The default is then correct, if possibly inefficient,
instead of efficient, if possibly incorrect.

Examples of the as-if rule in practice:

	int i, j, k;
	long m, n;

	m = i + j;

Now, if i + j does not fit in int, but does fit long, overflow occurs.
With my rule, the correct result will be calculated.

	i = i + j;
No difference: since the result is stored in int, the calculation can
be done in int without loss.

	i = i + j + 1;
This case is interesting because, for certain values of i and j, i + j
could overflow int and yet have i + j + 1 still representable as int.

Most current hardware silently ignores overflow (essentially copying
the PDP-11).  I've found this to be unfortunate: overflow is generally
a sign of a bug.  It is legal for a C implementation to consider this
an error.

With existing C, the program could fail due to overflow whereas my
rule would make this correct.  The cost is that, under my rules, on a
machine with trapping overflow, the calculation must be done with
wider intermediate results.

The programmer could have written i = (int) (i + j) + 1;
thus allowing the calculation to be done in int under my rule.

| After all, short int and int just have to be at least 16bit, and long
| has to be at least 32bit.  long long has to be at least 64bit if it is
| even supported on a system.  Linux seems to have decided to make it:
| short is 16bit
| int is 32bit
| long is equal in size to pointers (so 32 or 64bit depending on cpu)
| long long is 64bit

As far as whether pointers should be able to be stored in int or long,
I don't have an expectation.  I have an anti-expectation: code that
depends on this is suspect.

When I learned C, there was no "long".  When long was introduced, it
was twice as wide as a pointer (PDP-11).
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists