Xref: utzoo comp.lang.c++:13111 comp.lang.c:38783
Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!tdatirv!sarima
From: sarima@tdatirv.UUCP (Stanley Friesen)
Newsgroups: comp.lang.c++,comp.lang.c
Subject: Re: 64 bit architectures and C/C++
Message-ID: <224@tdatirv.UUCP>
Date: 27 Apr 91 21:57:37 GMT
References: <168@shasta.Stanford.EDU>
Reply-To: sarima@tdatirv.UUCP (Stanley Friesen)
Followup-To: comp.lang.c++
Organization: Teradata Corp., Irvine
Lines: 76

In article <168@shasta.Stanford.EDU> shap@shasta.Stanford.EDU (shap) 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.
 
>1. Do the C/C++ standards need to be extended to cover 64-bit
>environments, or are they adequate as-is?

They are adequate as is.  They make only minimum requirements for a
conforming implementation.  In particular, there is no reason why you
cannot have 64 bit long's (which is what I would do) or even 64 bit int's.
And you could easily have 64 and 128 bit floating point types (either
as 'float' and 'double' or as 'double' and 'long double' - both approaches
are standard conforming).

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

In writing a new compiler from scratch (or even mostly from scratch) there
is no question, full ANSI compliance is absolutely necessary.
[An ANSI compiler may itself be less portable, but it allows the application
programers to write portable code more easily].

In porting an existing compiler, do whatever seems most practical.

>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
 
OR:
	short	32 bits
	int	64 bits
	long	64 bits

OR:
	short	32 bits
	int	32 bits
	long	64 bits

Any one of the above may be the most appropriate depending on the
instruction set.  If there are no instructions for 16 bit quantities
then using 16 bit short's is a big loss.  And if it really is set up
as a hybrid 32/64 bit architecture, even the last may be useful.
[For instance, the Intel 80X86 series chips are hybrid 16/32 bit
architectures, so both 16 and 32 bit ints make sense].

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

Not particularly.  There are already millions of machines where this is
true - on PC class machines running MS-DOS sizeof(int) == sizeof(short)
for most existing compilers, (that is the sizes are 16, 16, 32).
[And on Bull mainframes, unless things have changed, all three are the
same size].

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

Programs on different machines should not talk to each other in binary.
[See the long, acrimonious discussions about binary I/O right here].
And as long as you use either ASCII text or XDR representation for data
exchange, there is no problem.

Howver, I would be more likely to skip the 16 bit type than the 32 bit
type.  (Of course if the machine has a 16 bit add and not a 32 bit one ...).


In short the idea is that C should translate as cleanly as possible into
the most natural data types for the machine in question.  This is what the
ANSI committee had in mind.
-- 
---------------
uunet!tdatirv!sarima				(Stanley Friesen)