64 bit linux on Intel T9600

[Lennart Sorensen]

On Mon, Jun 22, 2009 at 04:18:21PM -0400, D. Hugh Redelmeier wrote:
> I consider it quite sensible.  Remember, C evolved from a "typeless" 
> language, B (which evolved from BCPL, a typeless variant of CPL).  
> Everything was a machine word.  "int" was how this was spelled in C.
> 
> "int" is the type to be used when you don't have any reason to demand
> special properties.

Yet I suspect most programmers assume they know what they are getting
when they ask for int.  They certainly tend not to remember that they
might only be getting 16 bits.

> It is true that LP64 rather than ILP64 was adopted by most
> implementations.  See
>   http://www.unix.org/version2/whatsnew/lp64_wp.html
> and
>   http://gcc.gnu.org/ml/gcc-help/2009-02/msg00030.html
> (The first place I noticed this discussion and terminology was in the
> C Standards working paper 92-038 from 1992 April 1 (oops).  It seemed
> to recommend ILP64, but certainly not as a requirement.)
> 
> At the root, this was for the pragmatic reason that it made old C
> programs work more often.  On the other hand, it was neither in the
> Spirit of C, nor did it maximize the benefit of the transition to
> 64-bit.
> 
> This was particularly sad on the Alpha, the first version of which
> didn't even have partial word instructions (if I rememeber correctly).
> 
> The trade off was: less short term pain for less long term gain.
> 
> I will admit that the change of dynamic range from 16-bit to 32-bit
> was way more important than the change from 32 to 64.

Certainly.

> That is a sin.  C structs are not correctly used for layout.

Well if you are talking to hardware in a driver, you need to do things
somehow.  I have seen quite a few drivers use a struct to map onto the
hardware registers, although I haven't ever done it that way myself
(probably haven't written a driver for a complex enough device yet).

> Sure, but that's not the issue.  Subrange specification of integral
> types is actually simpler than the weird integral-type mixed-up
> partial order and easier to implement.
> - simpler to specify sanely
> - simpler for the programmer to understand
> - simpler to handle syntactically.
> - fewer keywords
> - fewer symbols to define in <inttypes.h>
> - simpler to write portable code.

Well C is just vaguely portable assembly after all.

> Quiz: does char promote to int or unsigned int?

I would guess it promotes to whichever matches the system's signed'ness
of char.  So unsigned on arm, signed on i386 (on linux that is).
No idea though.

> One reason that it is easy to assume that addition is commutative is
> that it is associative if the hardware silently wraps on overflow, and
> that is what most hardware does these days.
> 
> BTW, I have written IBM/360 assembly programs where I could decide
> what to do with overflow: ignore or trap.  I found that trapping was
> the best choice because most overflows detected actual errors.

Certainly a good idea.

> Just as silent buffer overflow has lead to bugs in C code, some with
> security implications, silent integer overflow has lead to bugs and
> vulnerabilities.

Makes sense yes.  I have encountered problems with:
somefloat = someint / someotherint;
Doesn't do what one might hope it would do.

C = gun pointed at foot.  Very easy to shoot yourself in the foot.

> My first public exploit (1976, I'd guess) was based on undetected
> integer overflow.
> 
> No, the case presupposes hardware that already does it.  I'm not
> demanding such hardware, only talking about how to deal with it.

Well I certainly don't think C deals with it.  Hopefully some languages
do.

> The point is that the programmer can cause the efficient-but-risky
> code to be generated, even if it isn't the default behaviour.

Well that's fair I suppose.

> That isn't modern, that is broken.  The C standard does not support
> such usage, nor should it.  The modern use of C is to get the types
> right (and the C standard tries to provide the necessary types).

People do lots of stupid things.  Like some early Mac developers that
decided to store type information in the unused 8 bits of their 32bit
address pointers on the 68000 based machines even though Apple said
"Don't ever do that they are reserved for future use", and then the
68020 based machines came out and the code when splat.

> Linus can require that of the environment in which the kernel lives.

Hmm, well I guess so.  I prefer to store addresses in pointer types
personally.

> Why would you want this feature?  Would intptr_t satisfy that
> requirement?

Probably.

> That attitude would have left us stuck with PDP-11 representations:
>     char 8
>     short 16
>     int 16
>     long 32

Well Linux doesn't run on anything smaller than 32bit, so that's what
they used for int, and then long 32 or 64bit (with long long being always
64bit I believe, unless there are systems that handle 128bit types)

The C standard types do seem like a better idea if you care about the
size of your types.  Probably also makes for clearer code to read.
int8_t is hard to misunderstand.

> I can tell you that folks learned lessons on cleaner coding during
> each transition.  The main ones seem to have been:
>     PDP-11 => IBM/370, GE635
>     PDP-11 => VAX
>     DOS => Win32 (?  I wasn't involved)

DOS => Win16 => Win32?  Amazingly they are still having trouble going
to Win64.  You would think they would have figured it out by now.

>     VAX => 68k (different endian)
>     68k => i386 (different endian)
>     => Alpha, itanium SPARC64 (almost all stayed at 32, I think), PPC 64,
>     i386 => x86_64.

Certainly a lot of linux code was cleaned up by the alpha port due to
the 64bit versus 32bit changes.  I don't remember which was the first
big endian port of linux.

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