64 bit linux on Intel T9600

[Lennart Sorensen]

On Fri, Jun 19, 2009 at 05:45:01PM -0400, D. Hugh Redelmeier wrote:
> | 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

Well K&R did many stupid things that people have since realized and
tried to fix.  That was probably one of them.

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

Well that's not how any modern system treats it.

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

Sometimes that is what you require for the ability to control structs,
packing of data in files, on network links, etc.

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

Pascal is a higher level language than C.

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

If i and j are both MAXINT, then it doesn't fit and loss will happen.

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

Well at least the bits left over after throwing away the overflow.

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

Which involves serious hardware changes in which case why not just make
everything in the machine wider.  Of course then someone will want a
wider one still.

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

And it still can cause overflow, so what's your point?

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

Well modern use of C seems to expect sizeof(long) == sizeof(void*)
except on windows 64bit.

> When I learned C, there was no "long".  When long was introduced, it
> was twice as wide as a pointer (PDP-11).

Must be a long time ago.

I am rather pleased that linux has tried to make some sanity of things
by standardizing the size of most of the types on linux.  The only
one that varies is long, and it is defined as the size of a pointer,
so even it is rather standard.  The only other one that varies is the sign
of char when not specified.  Some systems are signed, some are unsigned,
although apparently C now says that char isn't the same as unsigned char
or signed char but is its own third type for string use.

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