🚀 go-pugleaf

> 2.  Bill points out that the Megamax compiler uses 16 bit integers, while
>     his compiler uses 32 bit integers.  When the Consulair compiler used
>     16 bit integers in the sieve program the run time with his old compiler
>     was 6.3 seconds.
>     
>     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

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

No 'C' standard guarantees that sizeof(int)==sizeof(char *). A 'C' compiler
for which this is true will allow you to port programs to it more easily,
though, since many, many programs in the real world make just that assumption.

For more info see net.lang.c, where there was a lot of discussion about
this point.

						Thomas.

>>     Someone told me that the C
>>     standard stipulates that an integer's worth of bits must be able
>>     to span the entire address space.
> 
> Hmmm,  the 68000 inside the MAC has a 24bit address space.  A AT&T
> 68010 UNIX distribution C compiler believes that ints are 16bits.
> 

A very lengthy, and ultimately unfruitful, discussion along these lines
occurred in the ARPA UNIX-WIZARDS conference last Spring.  The underlying
problem is that many programmers earnestly want to write portable code,
yet vehemently believe that the C "standard" should support various
programming tricks they have discovered which just as surely prevent
portable code from ever being written.

What's at issue here is that the C language will allow you to assign
pointers to integers.  The K&R language standard (which is in Appendix A
of the book) states "Certain conversions involving pointers are permitted
but have implementation-dependent aspects. ... A pointer may be converted
to any of the integral types large enough to hold it.  Whether an int or
long is required is machine dependent.  The mapping function is also
machine dependent, but is intended to be unsurprising to those who
know the addressing structure of the machine."

The essence of this statement is that assigning pointers to integers is
"implementation dependent," i.e., if you do it, the resulting programs
will be nonportable; and, although the standard uses the word "machine,"
it is far wiser to read "compiler" dependent instead.

The moral of this story is this.  If you are writing programs for yourself,
or for a particular compiler, you can do whatever you want; but if you are
writing portable programs, you should avoid such features altogether.  Doing
so prevents C from losing its expressiveness and flexibility, while avoiding
surprises when porting programs.

					Eric Roskos
					Perkin-Elmer Corp. SDC
					<jer@peora.UUCP>

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