Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!uwm.edu!uwvax!heurikon!ex.heurikon.com!daves
From: daves@ex.heurikon.com (Dave Scidmore)
Newsgroups: comp.lang.c++
Subject: Re: 64 bit architectures and C/C++
Message-ID: <471@heurikon.heurikon.com>
Date: 1 May 91 21:21:10 GMT
Article-I.D.: heurikon.471
References: <168@shasta.Stanford.EDU> <224@tdatirv.UUCP> <1991Apr29.140256.27605@cbnewsh.att.com>
Sender: news@heurikon.heurikon.com
Reply-To: daves@ex.heurikon.com (Dave Scidmore)
Organization: Heurikon Corporation, Madison, WI
Lines: 56

warren@cbnewsh.att.com (warren.a.montgomery) writes:
>There are probably a lot of hidden assumptions in programs that
>sizeof(short)==2 and sizeof(long)==4 at this point, so any
>assignment of meanings on a 64 bit machine (unless you invent type
>"long long" for 64 bits and leave long and short at 32 and 16)
>will cause some pain.
>
>All this raises questions about C/C++'s philosophy of integer type
>specification, which no doubt dates from the days where all
>machines had only 2 and 4 byte integers.

I doubt such a day ever existed. The early K&R book refered to machines
with 9 bit chars and 36 bit integers when describing the number of bits
in various quantities.

>...  How are things like this best
>expressed in C or C++?
>Do other languages provide better overall solutions?

The important factor you have to keep in mind when dealing with C
or C++ is that they both attempt to keep the match between C expressions
and machine instructions as close as possible. This results in more
efficient code and faster execution, one of the strong points of C. In
this respect C has often been refered to as a glorified assembly language
since it allows you to do use level language constructs, but still allows
you to use types and constructs which have a high degree of coorelation
with the machine instruction set.

This approach places the burden for portability on the programmer rather than
on the compiler with the end result that the compiler need not waste time
dealing with variables that are of a size that is not a good match to
types supported by the the underlying machine. I have yet to see a piece
of code that depends on sizeof(built in type) == X that could not be written
to be portable across almost any machine (except where no machine type is
large enough to hold the range of values needed). One approach is to isolate
dependancies using typedefs like:

typedef Int32Bit long;
typedef Int16Bit short;
typedef Int8Bit char;

then use the appropriate type for the situation. This approach fails when
working on machines that are not based on 8 bit bytes, or that have odd
size integers. In this case using the header file "types.h" can help since
it tells you the size of all built in types. You can then use preproccesor
directives to choose the appropriate size for the situation.

The answer to your question is that other languages do provide a "better"
overall solution, if the performance of the compiled code is not critical.
But where the need to translate high level language statements into as few
and as fast a set of machine language instructions as possible is the goal,
C offers a reasonable approach, and maybe even the "best solution" for that
situation.
--
Dave Scidmore, Heurikon Corp.
dave.scidmore@heurikon.com