From: shap@xanadu.com (Jonathan Shapiro)
Newsgroups: comp.lang.c,comp.std.c,comp.arch
Subject: Re: "long long" for 64 bits
Summary: The choice isn't obvious
Date: 10 Apr 92 07:10:07 GMT
Organization: Xanadu Operating Company

In article <ktf7loINNq8a@spim.mips.com> mash@mips.com (John Mashey) writes:
>In article <1992Mar30.145144.4717@webo.dg.com> lewine@cheshirecat.webo.dg.com writes:
>
>>After reading this thread for a while my only request is that the
>>for of you (at least) get together and pick some common scheme.  The
>>worst of all worlds would be for MIPS, Alpha, PowerPC and SPARC to
>>have different incompatible ways of dealing with 64-bit things.
>
>Yes.  Of course, I cannot speak for any of these vendors.  However,
>there have been, for quite some time, informal email discussions
>among a bunch of the vendors interested in this topic, and this was
>*before* MIPS put long long in.  The purpose ofthe discussions was
>exactly the goal of above: maybe we can do it the same way, or
>maybe not [the different approaches sometimes have different tradeoffs],
>but let's at least not do thigns randomly different for no good reason.

As the person who created the mailing list I think John is referring to, let
me throw out a couple of issues that arise in trying to choose a sysem
here.

When we first started looking at 64 bit environments at HaL, it seemed
pretty clear that pointers ought to be 64 bits.  The question was how to
deal with integers.  There seemed to be two "obvious" answers:

	1. Make longs be 64 bits.
	2. Use long long and leave the rest alone.

The arguments, as best I can recall them, went something like:

	Making long 64 bits:
	1. Doesn't violate any significant existing standards.
	2. Already is this way for some platforms.
	3. Simplest change to the compiler.
	4. Well defined what it means.

	Using long long as 64 bits.
	1. A lot of code knows about long longs already.
	2. Leaves int/long the same size, which resolves a major
	   compatibility problem.
	3. Makes it possible to have a binary interface compatible with
	   both 32 and 64 bit code for many cases.

The problems, of course, were:

	Making long 64 bits:
	1. So much code makes the int=long assumption that the engineering
	   cost of this decision may not be survivable.
	2. Most binary interfaces get broken.
	3. Violates alignment assumptions every which way but loose.

	Using long long as 64 bits:
	1. Almost all standards are broken.
	2. Semantics poorly defined.

After much debate, we decided to look at making both int and long be 64
bits.  It wasn't obvious whether short should be 16 or 32 bits if we did
this, but it WAS obvious that doubling the size of all the integers would
leave most code that made bad assumptions about sizes and alignments still
runnable.

All of these problems are ugly.  Finding some is easier to automate than
others.  Any way you do it you break a lot of existing code, which is
terribly expensive.

I don't know where HaL ended up.  I don't know what I think the right
answer here is.  I do know that all of the answers are prohibitively
expensive.  You only get to choose which prohibitively expensive answer you
intend to implement.

Jonathan Shapiro
Independent Consultant
Newsgroups: comp.lang.c