Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/17/84; site plus5.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!plus5!eric
From: eric@plus5.UUCP (Eric W. Kiebler)
Newsgroups: net.micro.mac
Subject: Re: Re: C Compiler Benchmarks
Message-ID: <620@plus5.UUCP>
Date: Sun, 3-Mar-85 15:30:17 EST
Article-I.D.: plus5.620
Posted: Sun Mar  3 15:30:17 1985
Date-Received: Mon, 4-Mar-85 20:27:16 EST
References: <5124@ucbvax.ARPA> <189@cadtroy.UUCP>
Organization: Plus Five Computer Services, St. Louis
Lines: 88

> >     This is an excellent point.  I neglected to notice whether the other
> >     compilers used 16 or 32-bit integers.  Someone told me that the C
> >     standard stipulates that an integer's worth of bits must be able
> >     to span the entire address space.  I don't know about this.  Can
> >     someone comment?
> 
> Hmmm,  the 68000 inside the MAC has a 24bit address space.  A AT&T
> 68010 UNIX distribution C compiler believes that ints are 16bits.
> 
> marty
> schoff@cadmus.ARPA
> {wanginst,seismo}!ucadmus!schoff

Which standard?  IEEE/usr/group standard?  So what if AT&T believes ints
are 16 bits?  

White Book page 102, section 5.6, says "5.6 Pointers are not Integers".
Page 34 says:
	
	int	an integer, typically reflecting the natural size
		of integers on the host machine.

This would appear to be 16 bits, eh?  That is, of course, if you consider
MOVE.L unnatural...

Now, the C Reference Manual, section 4, states "Types CHAR and INT of 
all sizes will collectively be called INTEGRAL TYPES".  Then, section 14.4
states "An object of integral type may be explicitly converted to a
pointer.  The mapping always carries an integer converted from a pointer
back to the same pointer, but is otherwise implementation independent".

So, if we consider a long int at 32 bits to be an integral type, then 16
bit ints are swell.

Now, section 6.4 states "Two pointers to objects of the same type may be
subtracted; in this case the result is converted to an integer as specified
in the discussion of the subtraction operator."

What does this all mean?  If the result of pointer subtraction is 16 bits,
the number of objects in an array is limited to 64K. This, as it were, sucks.
The only guarantee for longs is that they aren't shorter than shorts, so they
may in fact be 16 bits.

So, a resolution of the problem for the 68K is to make the result of
pointer subtraction an integral type as opposed to an integer, and to
make ints 16 bits, chars 8 bits, and longs 32 bits.  That way, compiler
writers could still follow the standard and we could still access the entire
address space of the machine using pointer expressions.  If you don't think
that people should use arrays that big then your mom was right, you're never
going to amount to anything, and you smell bad, too :-).

On the other hand, making the result of pointer subtraction a long (which
is what would be required) makes passing the result of pointer subtraction
non-backward-compatible with existing programs.  A long does not get
converted to an int when being passed as an actual parameter, so people
who code things like

	...
	int a[100000], *pia, *pib;
	pia = a+10; pib=a+99999;
	...
	plop(pib-pia);
	...


	plop(dif)
	int dif;
	{...}

are going to be very disappointed. I am sure there are other examples of
this kind of problem.

I like 32 bit ints, myself; I don't want to fix all those old programs, and
I want to access big arrays.  I will live with the speed difference.

I don't have my copy of the proposed /usr/group standard -- did they fix this
somehow?

eric

PS.  I know this was flying around in net.unix* a while ago, but I didn't
care back then because I was using a VAX :-).

-- 
..!ihnp4!wucs!plus5!eric	
..!ihnp4!plus5!eric
(314) 725-9492