Path: utzoo!mnetor!uunet!husc6!mailrus!nrl-cmf!cmcl2!brl-adm!adm!MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU From: MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU Newsgroups: comp.lang.c Subject: Undelivered mail Message-ID: <12299@brl-adm.ARPA> Date: 12 Mar 88 11:42:00 GMT Sender: news@brl-adm.ARPA Lines: 40 Subject: Re: Bit Addressable Architectures [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 7433 for SXJVK@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@BRL.ARPA Sender: Info-C List From: Frank Adams Subject: Re: Bit Addressable Architectures Comments: To: info-c@BRL-SMOKE.arpa To: Vic Kapella 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