Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!ames!haven!adm!lhc!usenet From: usenet@nlm.nih.gov (usenet news poster) Newsgroups: comp.arch Subject: Re: 64 bits--why stop there? Message-ID: <1990Sep3.045353.19321@nlm.nih.gov> Date: 3 Sep 90 04:53:53 GMT References: <41188@mips.mips.COM> <1990Aug31.174957.9612@cimage.com> <1990Sep1.062535.7541@rice.edu> Reply-To: states@artemis.NLM.NIH.GOV (David States) Organization: National Library of Medicine, Bethesda, Md. Lines: 34 preston@titan.rice.edu (Preston Briggs) writes: >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). Or doing long string comparisons by building a finite state machine where state transitions are taken several letters at a time. >But what will we do with pairs and nybbles? >And will we have 1, 2, 4, 8, 16, 32, and 64 bit registers? Why not just support subdivided instructions (ADD_BY_BYTES ...)? All of the logical operations can be viewed as arbitrarily divided into subfields. Adding a set of condition registers instead of a single condition code would be minimal overhead. The result would be a machine that could parallelize small integer operations. There are limits to how fast you can push clock speed. If you want to process character strings and small integer operations faster, parallelization seems like the way to go. >[...] >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. If you parallelize, it doesn't cost memory and you could potentially win big on performance. >Preston Briggs looking for the great leap forward David States