Path: utzoo!utgpu!watserv1!watmath!att!rutgers!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: <1990Sep2.201943.3670@rice.edu> Date: 2 Sep 90 20:19:43 GMT References: <1990Sep1.062535.7541@rice.edu> <1990Sep2.015030.4135@portia.Stanford.EDU> Sender: news@rice.edu (News) Organization: Rice University, Houston Lines: 68 >In article <1990Sep1.062535.7541@rice.edu> I wrote: >>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. In article <1990Sep2.015030.4135@portia.Stanford.EDU> dhinds@portia.Stanford.EDU (David Hinds) writes: > Isn't it obvious how you would manage registers? The register store >would also be bit-addressable. So, a 64x64-bit block of registers would >be just like a 4096-bit block of memory, and an instruction specifying >a register would just need to give a 12-bit short address and a size field. >You might require that the alignment of any pseudo-register be at least >its own size, but you wouldn't have to. You've over-trimmed my post. I suggested a bit addressable register set, but wanted alignment. Without alignment, I expect the hardware becomes far more complex (and I'm certain the register allocator does). Hinds also suggests a size field to accompany each register number. Why? The instruction usually implies the operand size. For example, we don't say FADD r0.double, r2.double, r4.double We say instead FADD.double r0, r2, r4 effectively saving 2 size specifications. And I still think the whole thing is a mess. Too much hardware and software expended for very little return. Design should proceed top-down. You decide what problem you need to solve (or class of problems) and you build a solution. If you over-generalize, your solution will be slower and/or more expensive than necessary. If all you need is to shift left 1 bit, you don't build a multiplier. If all you need is to find the smallest element in an array, you don't bother building a quicksort. If you need to run C fast, you don't support bit, pair, or nibble addressing. If you intend to run Fortran, you don't bother with 8 or 16 bit addressing either. Of course, this kind of thinking is the sort Rubin rails against. Languages are (often) designed to run on available machine and then later machines are designed to supprot the languages *and nothing else*. This leads to certain ideas or paradigms being unsupported. I guess I'd like to see high-level expressions of the problems that aren't well supported. If an adequate form of expression can be invented (this is probably hard -- good notation is very hard), then we can see about supporting it on different machines. For example, a "typical Rubin problem" (based on limit observations) is usually expressed in terms of random bit strings. But what's really going on? Can we get a little more abstract, away from the "bit string" part. How about "a stream of random boolean values" or something. As far as implementation, why use a bit string? Why not a linked list or some combination of linked list and array. There are a lot of choices of structure that significantly influence the algorithmic complexity of solutions. -- Preston Briggs looking for the great leap forward preston@titan.rice.edu