Xref: utzoo comp.lang.c++:13147 comp.lang.c:38863
Newsgroups: comp.lang.c++,comp.lang.c
Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!lethe!tvcent!comspec!scocan!john
From: john@sco.COM (John R. MacMillan)
Subject: Re: 64 bit architectures and C/C++
Organization: SCO Canada, Inc.
Date: Mon, 29 Apr 1991 21:19:37 GMT
Message-ID: <1991Apr29.211937.10865@sco.COM>
References: <168@shasta.Stanford.EDU>
Sender: news@sco.COM (News administration)

shap <shap@shasta.Stanford.EDU> writes:
|Several companies have announced or are known to be working on 64 bit
|architectures. It seems to me that 64 bit architectures are going to
|introduce some nontrivial problems with C and C++ code.

In a past life I did a fair amount of work with C on a 64 bit
architecture, the C/VE compiler on NOS/VE.  C/VE was a pre-ANSI
compiler, but many of the comments I think still apply.

C/VE had 64 bit ints and longs, 32 bit shorts, 8 bit chars, and 48 bit
pointers (as an added bonus, the null pointer was not all bits zero,
but that's another headache entirely; ask me how many times I've
wanted to strangle a programmer who used bzero() to clear structures
that have pointers in them).

|I want to start a discussion going on this topic.  Here are some seed
|questions:
|
|1. Do the C/C++ standards need to be extended to cover 64-bit
|environments, or are they adequate as-is?

The C standard certainly is; it's obvious a lot of effort went into
making sure it would be.

|2. If a trade-off has to be made between compliance and ease of
|porting, what's the better way to go?

I don't think there's any reason to trade off compliance with
standards; if you want to trade off ease of porting versus exploiting
the full power of the architecture that's another question.  The
answer is going to be different for different people.

If you make the only 64 bit data type be ``long long'' or some such,
it will make life much easier on porters, but most of the things you
port then won't take advantage of having 64 bit data types...

|3. If conformance to the standard is important, then the obvious
|choices are
|
|	short	16 bits
|	int	32 bits
|	long	64 bits
|	void *	64 bits

This isn't really a conformance issue.  The idea is to make the
machine's natural types fit the C types well.  However, if the
architecture can support all these sizes easily, then for ease of
porting it would be nice to have all of the common sizes available.
Many (often poorly written) C programs depend on, say, short being 16
bits, and having a 16 bit data type is the easiest way to port such
programs.

One problem with 32 bit ints and 64 bit pointers is that a lot of
(bad) code assumes you can put a pointer into an int, and vice versa.

As an aside, using things like ``typedef int int32'', is not always
the answer, especially if you don't tell the porter (or are
inconsistent about) whether this should be an integer data type that is
_exactly_ 32 bits or _at least_ 32 bits.

|How bad is it for sizeof(int) != sizeof(long).

The C/VE compiler had sizeof(int) == sizeof(long) so I can't comment
on that one in particular, but...

|4. Would it be better not to have a 32-bit data type and to make int
|be 64 bits?  If so, how would 32- and 64- bit programs interact?

...there is a lot of badly written code out there, and no matter what
you do, you'll break somebody's bogus assumptions.  In particular a
lot of code makes assumptions about pointer sizes, whether they'll fit
in ints, and whether you can treat them like ints.

Expect porting to 64 bit architectures to be work, because it is.