Undelivered mail

[MAILER%ALASKA.BITNET at CUNYVM.CUNY.EDU]

Subject:  Re: Bit Addressable Architectures

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C at BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 7433
          for SXJVK at ALASKA; Sat, 12 Mar 88 02:19 AST
Received: by UWAVM (Mailer X1.25) id 5069; Sat, 12 Mar 88 03:18:26 PST
Date:         Wed, 9 Mar 88 14:47:24 GMT
Reply-To:     Info-C at BRL.ARPA
Sender:       Info-C List <INFO-C at NDSUVM1>
From:         Frank Adams <franka at mmintl.uucp>
Subject:      Re: Bit Addressable Architectures
Comments: To: info-c at BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK at ALASKA>

In article <1988Mar6.002518.945 at utzoo.uucp> henry at 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