NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/arch/9020

Internet Message Format | 1992-08-22 | 3.5 KB

Path: sparky!uunet!haven.umd.edu!darwin.sura.net!mips!swrinde!news.dell.com!uudell!bigtex!texsun!cronkite.Central.Sun.COM!news2me.ebay.sun.com!exodus.Eng.Sun.COM!rbbb.Eng.Sun.COM!chased
From: [e-mail] (David Chase)
Newsgroups: comp.arch
Subject: Re: 32 => 64 Transition
Message-ID: <[e-mail]>
Date: 22 Aug 92 00:18:36 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Sun Microsystems, Mt. View, Ca.
Lines: 65
NNTP-Posting-Host: rbbb

[e-mail] (Guy Dawson) writes:
>Reading K&R2, section 2.2 Data Types and Sizes, for a '64 bit' CPU I
>would expect the following sizes :

>char        8 bits
>short        32 bits
>int        64 bits
>long        128 bits

>For me, the key phrase is given in the short table of sizes :-

>int    an integer, typically reflecting the natural size of integers on the
>host machine

The talk of "natural size" on the host machine is a little misguided,
if you ask me.  There's not an appreciable performance penalty in
having an integer be smaller than the register width on a machine
(consider the Macintosh, where many C compilers give you 16-bit
integers).  In the case where you need a big integer, and you need
portable code, saying "int" won't help you, because the size isn't
portable -- better to punt and say "long long" (yes, I know it is not
strictly compliant -- a true standards weenie would whip up a typedef
and do it all with subroutines, providng a portability package that
used structures for strict compliance, and long long for speed where
it is supported.  However, since you can get compilers that support
long long, I'd have to say that I've got better ways to spend my
time).

There are other issues besides naturalness.  Here are a few
that seem to matter to various (different) people:

* Fortran compatibility.  Fortran 77 (yeah, I know that '90 is
different) mandates that

    sizeof(INTEGER) = sizeof(REAL) = sizeof(DOUBLE PRECISION)/2.

A corollary of this is that there had better be a 32-bit integer data
type in C, unless your hardware implements quad-word floating point.

* Common descriptions of data structures.  On almost all machines in
the world (PC, Mac, 32-bit workstations) char, short, and long have
the same size, though "int" floats.  In theory, clean coding avoids
this problem.  Theory and practice diverge somewhat, unfortunately.
Even so, this doesn't solve endianness problems.

* (strict) Standard compliance.  This means that (for instance) adding
new type names is not allowed (whether "long long" or "__int32"), and
that "int" cannot be larger than "long".  A more relaxed notion of
compliance (defined in the standard) allows the introduction of new
type names provided that they take certain forms ("long long" or
"__int32" are both admissable).

* The naturalness argument reappears when people who "know" that the
underlying machine is a 64-bit machine get their arithmetic truncated
accidentally to 32-bits in some intermediate step, and are unhappy
about it.  It certainly doesn't help speed to force the truncation,
though optimizer writers will do their best to hide the cost.

My opinion on what is the right decision has changed sufficiently many
times that it would probably be stupid to state it publicly, because I
might well find myself arguing with myself (which happens often enough
as is, but it's much less embarrassing in private).

David Chase
Sun