Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!samsung!umich!dgsi!paulh
From: paulh@cimage.com (Paul Haas/1000000)
Newsgroups: comp.arch
Subject: Re: 64 bits--why stop there?
Message-ID: <1990Aug31.174957.9612@cimage.com>
Date: 31 Aug 90 17:49:57 GMT
References: <6106@vanuata.cs.glasgow.ac.uk> <2437@crdos1.crd.ge.COM> <631@array.UUCP> <225@csinc.UUCP> <1372@svin02.info.win.tue.nl> <41188@mips.mips.COM>
Reply-To: paulh@dgsi.UUCP (Paul Haas/1000000)
Organization: Cimage Corp, Ann Arbor, MI
Lines: 49

In article <41188@mips.mips.COM> you write:
>However, it is still clear that bit-addressing would break more programs
>than byte-addressing, so all I wanted was for someone to work through
>a complete example to show why it would be A Good Thing on balance.

I think you are proposing an impossible task.  As there is evidence
that bit-addressing is not a "A Good Thing" on balance at the present
time.

If bit addressing is "A Good Thing" aka. someone has a need for it,
they will add it to their compiler or cause their compiler vendor to
add it.  For example, some people have a real need for 64 bit integers,
thus many C compilers support type "long long".

Adding bit pointers to C compilers would be easy on machines which
already have multiple incompatible pointer types.  Bit-pointers would
be just one more type.  On nicer machines, you have to teach the
compiler about multiple pointer types, but that has been done before.
In either case emulating bit-addressing hardware is straight forward.
A few months ago, I needed to emulate an array of bits.  It took half a
day to write the appropriate bits of code.

Actually, having bit-pointers would not have saved me much time, as
most of the time was spent trying to speed up my find_next_set_bit()
function, and figuring out how to handle malloc() or realloc()
failures.  Neither of which are affected by bit-pointers.  Assume,
though that bit-pointers could save me half a days work, five times a
year.  That works out to a one percent productivity improvement.

I used to use PR1ME 50 series processors from about 1979 to about
1985.  They had many pointer formats, including a bit pointer.  It was
not supported by any of their compilers except as a character pointer.
In case you haven't had the pleasure of using a Prime 750 or similar
processor, this format of pointer used 3 sixteen bit words.  The first
word held the segment number, 2 bit ring number and a bit indicating
whether it was a 2 word or three word pointer.  The second word was
word pointer for the segment (segments held 64k 16 bit words).  The
third word held the bit offset.  Later processors in that line added
yet another pointer format that put a even/odd byte bit into the
segment word, to produce a 4 byte pointer which could point to
arbitrary characters.  If they felt a need, they could have easily
improved the bit pointer support, but they did not bother.

Actually, I like the concept of bit-addressing.  I just can't think
of a justification.  I certainly wouldn't spend extra money on it
at this time.
---
Paul Haas  paulh@cimage.com
I am not a spokesperson for Cimage Corporation.