Xref: utzoo comp.lang.c:7996 comp.arch:3893
Path: utzoo!mnetor!uunet!husc6!linus!philabs!pwa-b!mmintl!franka
From: franka@mmintl.UUCP (Frank Adams)
Newsgroups: comp.lang.c,comp.arch
Subject: Re: Bit Addressable Architectures
Message-ID: <2760@mmintl.UUCP>
Date: 9 Mar 88 14:47:24 GMT
References: <11702@brl-adm.ARPA> <243@eagle_snax.UUCP> <2245@geac.UUCP> <1988Mar6.002518.945@utzoo.uucp>
Reply-To: franka@mmintl.UUCP (Frank Adams)
Organization: Ashton-Tate Corporation, East Hartford Development Center
Lines: 22
Summary: A good idea that sounds silly

In article <1988Mar6.002518.945@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>As an extreme case,
>one can envision a bit-addressable machine -- that is, one whose pointers
>use the low-order three bits to indicate a bit within a byte -- that traps
>whenever those bits aren't zero, leaving the actual use of bit pointers
>entirely up to the software.  When all accesses were in fact aligned, this
>would incur essentially no overhead except the reduction in address space.

This may sound like an off the wall idea, but it makes a lot of sense to me.
This would mean that arithmetic on bit pointers can be done using the
standard arithmetic operations; and no special format is required for them.
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.

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

Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
Ashton-Tate          52 Oakland Ave North         E. Hartford, CT 06108