Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.arch
Subject: Re: 64 bits--why stop there?
Message-ID: <3644@goanna.cs.rmit.oz.au>
Date: 31 Aug 90 01:10:32 GMT
References: <6106@vanuata.cs.glasgow.ac.uk> <2437@crdos1.crd.ge.COM> <141569@sun.Eng.Sun.COM>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 52

In article <141569@sun.Eng.Sun.COM>, lm@snafu.Sun.COM (Larry McVoy) writes:
> (1)  Unix has reached the age where it has what can be called dusty deck code.
>      And this code frequently does stuff like
> 
> 	 char *bar = (char*)malloc(100);

>     which doesn't work under Rob's machine.  Do we want to support this code?

But it *does* work under Rob's machine!  C's malloc() is defined to take an
argument in *bytes*, not in hardware addressable units.  If malloc() has to
multiply its argument by 8 (or for that matter, by 137) to determine the
number of hardware addressable units to allocate, that's _malloc's_
business.  The C code doesn't notice.

What's more, code that does
	long *w; char *p; ...
	p = (char *)w + 1; ...
	w = (long *)(p - 1); ...
will work exactly as before.  Adding or subtracting 1 to a char pointer
will _really_ add or subtract 8 to a bit pointer, but the C code won't know.
	
The main thing that will break is
	long w; char *p;
	w = (long)p;
	w++;
	p = (char *)w;
which will no longer have the same effect as p++;
On the other hand, this never _was_ portable.  Consider a machine which
normally uses pointers to 16-bit words, where byte pointers use the top
(sign) bit to indicate even/odd byte within word.  On such a machine (I
have a real machine in mind) this C fragment would increment p by 2.

But even that can be fixed.  There is no way for existing C code to get
its hands on a bit pointer.  So if a C compiler for a bit-addressable
machine implements			as
	w = (long)p;			movw	p,w;	shli $-8,w
	p = (char *)w;			movw	w,p;	shli $8,p
then everything will continue to work as before.  The only case which will
_still_ break is
	union { char *p; long w; } pun;
	pun.p = p;
	pun.w++;
	p = pun.p;
but that is _already_ non-portable.

Note that this approach allows all C pointers to be bit pointers, and
it even allows pointers to objects smaller than chars -- which would have
to be an extension to C.  The only thing that bends is casting between
pointers and ints, which is already known to be non-portable; casting
between char*/void* and other pointers would be no problem.
-- 
You can lie with statistics ... but not to a statistician.