Path: utzoo!utgpu!watserv1!watmath!att!tut.cis.ohio-state.edu!cs.utexas.edu!usc!wuarchive!emory!mephisto!mcnc!rti!sheol!throopw From: throopw@sheol.UUCP (Wayne Throop) Newsgroups: comp.arch Subject: Re: What *should* architectural pointers point at? Summary: still bits Message-ID: <0923@sheol.UUCP> Date: 9 Sep 90 20:54:39 GMT References: <0887@sheol.UUCP> <11192@celit.fps.com> <2504@l.cc.purdue.edu> <11201@celit.fps.com> <10057@goofy.Apple.COM> Lines: 31 > From: pauls@apple.com (Paul Sweazey) > It is obvious to most that todays computing systems would not get faster > by having the hardware support bit-level addressing, much less an infinite > number of data types. I slightly disagree. I think there are a largeish class of things that would get faster just by having the architectural address format be bit granular, thus avoiding hauling around and paying for loading and storing pointer-plus-bit-descriptor instead of just pointers. Such as packed subrange integer types or boolean types, as might be used in compression schemes, in symbol tables, in graphics applications, in hardware descriptors, and so on and on. Note well, I'm not necessarily supposing that the memory system per se needs to support bit granular access. Just that the standard pointer format ought to be able to indicate any bit in the virtual address space. Because otherwise, bit entities must live in a restricted part of the address space, or it becomes much more costly than necessary to represent bit granular or bit aligned entities. I claim that such entities are artificially less common than they "ought" to be, simply because putting them into byte granular and byte aligned containers, while wasting memory (sometimes a significant amount of memory), is currently more convenient. I therefore think there is a significant class of algorithms which would indeed get faster... perhaps a couple of tens of percent faster, perhaps even a couple of times faster. And along with that is a significant class of algorighms which would consume significantly less memory. -- Wayne Throop !mcnc!rti!sheol!throopw or sheol!throopw@rti.rti.org