Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!ncar!asuvax!cs.utexas.edu!rice!titan.rice.edu!preston From: preston@titan.rice.edu (Preston Briggs) Newsgroups: comp.arch Subject: Re: 64 bits--why stop there? Message-ID: <1990Sep1.062535.7541@rice.edu> Date: 1 Sep 90 06:25:35 GMT References: <41188@mips.mips.COM> <1990Aug31.174957.9612@cimage.com> Sender: news@rice.edu (News) Organization: Rice University, Houston Lines: 46 In article daveg@near.cs.caltech.edu (Dave Gillespie) writes: >[Lest I become known as the net's great champion for bit-addressing, I >think I should point out that I myself doubt it will ever really be >"justified." I just think we should keep an open mind.] Bits are sort of useful as flags and such. However, I usually want to manage my bit-vectors in large chunks (getting that 32-way parallelism when ANDing and ORing integers). But what will we do with pairs and nybbles? And will we have 1, 2, 4, 8, 16, 32, and 64 bit registers? We could perhaps manage them like the common idea of using register pairs for holding double-precision floats. So, if we have 64 x 64 bit registers, we'll need a lot of bits to specify the registers (but of course we'll have a 64 bit instruction!). 6 bits for 64 x 64 bit registers 7 128 x 32 8 256 x 16 9 512 x 8 10 1024 x 4 11 2048 x 2 12 4096 x 1 bit registers For a 3-address bit-wise instruction then, we'll need 48 bits to specify the registers, leaving 12 bits to specify the operator (and how many do we need to operate on 2 bits?). Imagine the interference graph I could build for register allocation! We'll keep track of every bit in every live value and all their interferences. Alternatively, we could take a Cray-style approach. 64 x 64 bit registers. That's it, no subdivisions. Memory is addressable in 64-bit chunks. Saves addressing bits, shifts, unaligned access traps, register specification bits, massive hardware, and massive software. Of course, it costs memory (64 bits per char), but that's cheaper every day. And it would certainly crunch floating-point, big integers, and long bit-vectors (though perhaps not AWK programs). Even without my exaggaration (did anyone notice?) of the fun of bit-addressable memory, I'd still prefer the 2nd approach. -- Preston Briggs looking for the great leap forward preston@titan.rice.edu