Xref: utzoo comp.lang.c:8142 comp.arch:3919
Path: utzoo!utgpu!water!watmath!ccplumb
From: ccplumb@watmath.waterloo.edu (Colin Plumb)
Newsgroups: comp.lang.c,comp.arch
Subject: Re: Bit Addressable Architectures
Message-ID: <17458@watmath.waterloo.edu>
Date: 13 Mar 88 22:50:59 GMT
References: <11702@brl-adm.ARPA> <243@eagle_snax.UUCP> <2245@geac.UUCP> <1988Mar6.002518.945@utzoo.uucp> <2760@mmintl.UUCP>
Reply-To: ccplumb@watmath.waterloo.edu (Colin Plumb)
Organization: U of Waterloo, Ontario
Lines: 61
Confusion: U. of Waterloo, Ontario

franka@mmintl.UUCP (Frank Adams) wrote:
>henry@utzoo.uucp (Henry Spencer) writes:
>>... a bit-addressable machine ...
>
>This may sound like an off the wall idea, but it makes a lot of sense to me.

How is this off the wall?  I think it's a wonderful idea.  It seems
more sensible than having pointers on 32-bit machines count 8-bit hunks
of memory.  We have already observed that pointers based on the
machine's word length are a lose - we want to be able to address bytes,
at least.  With 64-bit machines, you want to use something smaller than
a full word for most things.  The other logical extreme is bit
addressability.  With 64-bit pointers, this reduces our address space
from 18,446,744,073,709,551,616 bytes to 2,305,843,009,213,693,952.
Big deal.  Call me a pessimist, but I don't think a single processor,
in any sense we use today, will be able to use this much memory.

Backwards compatibility?  With a C compiler insulating the user, the
only change is that sizeof(char) is now 8.  Pointer arithmetic still
works fine.  And, as all the processor architects here have based their
expectations of success on, if it doesn't uncover bugs in existing C
code, everybody likes it.

Theoretically, we want a pointer to be able to address any object we
can manipulate.  Even if the architecture does not directly support bit
operations, we can twiddle single bits.

>Note that the software need not wait for a trap to deal with unaligned data
>-- if it knows it is dealing with a bit pointer, it can extract and deal
>with the low order bits itself.

... In the spirit of RISC processors which ignore the low two bits of
the address in a word access.

>As for the address space issue: I personally believe that 32 bit addresses
>are too short, and that this will become apparent fairly quickly.  With a 64
>bit address, one can afford to use 3 bits this way.

Well, I think 32 bits will hold single-user computers for a while yet,
but I can see some uses for such a huge virtual address space, and I'm
sure its availability will spark more.  (I remember someone from the
New OED project pinting out that he was manipulating a 550 Meg
database, soon to grow to 800 and beyond, and having a pointer as an
atomic unit which could address any byte in this huge string simplified
many algorithms significantly.)

Of course, MMU designers will hate us for needing more tag bits. :-}


This can't be a new idea.  Why has no one implemented it before, when
32-bit pointers seemed infinite?  Perhaps that will uncover a flaw in
my reasoning.

>-- 
>Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
>Ashton-Tate          52 Oakland Ave North         E. Hartford, CT 06108
--
	-Colin (watmath!ccplumb)

Zippy says:
Everywhere I look I see NEGATIVITY and ASPHALT...