Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!sdd.hp.com!wuarchive!uunet!tut.cis.ohio-state.edu!ucbvax!hplabs!hpfcso!hplvec!boyne
From: boyne@hplvec.LVLD.HP.COM (Art Boyne)
Newsgroups: comp.lang.c
Subject: Re: 64 bit architectures and C/C++
Message-ID: <690007@hplvec.LVLD.HP.COM>
Date: 6 May 91 14:25:46 GMT
References: <168@shasta.Stanford.EDU>
Organization: Hewlett-Packard Co., Loveland, CO
Lines: 27

In comp.lang.c, bhoughto@pima.intel.com (Blair P. Houghton) writes:

    There's no reason for an int to be less than the full
    register-width, and no reason for an address to be limited
    to the register width.

Wrong!  There is a *good* reason.  On processors whose data bus width
is less than the register width (eg., 68000/8/10), the performance penalty
for the extra data fetches may be significant.  And since these processors
have only 16x16 multiplies and 32x16 divides, a 16-bit "int" type may make
a lot more sense than a 32-bit "int".

Typical applications also should have an impact on the choice.  If the
compiler is intended to support general-purpose applications running on
a family of processors (eg., 680x0), then perhaps it should be tailored
to somewhere mid- to high-range.  On the other hand, one intended to
support imbedded applications only (like the instrument controllers I
work with), had better look at the low end *very* carefully.  68000's
as instrument controllers are common here.  68020's are almost unheard-of.
32-bit ints are a detriment for typical instrument control application,
in terms of RAM usage, ROM size, *and* performance.

For such CPU's and applications, it would *really* helpful for the
compiler to support a 16 or 32 bit "int" switch.  I wish the compiler
we use did.

Art Boyne, boyne@hplvla.hp.com