Path: utzoo!utgpu!water!watmath!clyde!bellcore!decvax!decwrl!sun!pitstop!sundc!seismo!uunet!steinmetz!itsgw!imagine!pawl22.pawl.rpi.edu!kyriazis From: kyriazis@pawl22.pawl.rpi.edu (George Kyriazis) Newsgroups: comp.arch Subject: Re: Performance increase - a suggestion Keywords: bandwidth datapath 128 Message-ID: <221@imagine.PAWL.RPI.EDU> Date: 16 Jan 88 06:03:42 GMT References: <8843@steinmetz.steinmetz.UUCP> Sender: news@imagine.PAWL.RPI.EDU Reply-To: userfe0e@mts.rpi.edu (George Kyriazis) Organization: RPI Public Access Workstation Lab - Troy, NY Lines: 55 In article <8843@steinmetz.steinmetz.UUCP> sunray!oconnor@steinmetz.UUCP writes: >An article by physh@unicom.UUCP says: > [ proposes increasing computer performance by making busses > 128 bits wide, while leaving data-paths 32-bits wide ] > I don't know what he says exactly, but he mentions expanding data paths to 128 bits. I don't know, but I thought of that, just a few days ago, but for fetching instructions only. >Comments : >1. We're not talking a microcomputer here, not with current > packaging & interconnect technology. So for now this > proposal is only applicable to super-minis, mainframes > and super- or hyper-computers. > It might as well be in a micro-computer. OK, maybe something in the size of a SUN. Memories are usually what produces the bottleneck; the CPU can get data very fast. You can get 128 bits of data out of the memory at once, but give it to the CPU in 32-bit chuncks. What I state here is maybe another (slightly different) proposal. I stated before, I'd rather do it for instructions. Ok, Harvard architecture. You read 128 bits at a time, and (assuming a 32-bit CPU) you feed the CPU with 32 bits at 4 times the speed. You might as weel feed all this data in shift registers, and then shift data out to the CPU. Assuming 64K*1 chips, you will need 128 chips therefore 64K*128 = 8 megs. There are also 64K*4 chips, so minimum memory can go down by a factor of 4. A quite feasible approach for a medium sized computer (close to a micro). The only problem when doing that is jump instructions. Assume that memory operates at its fastest possible speed. If you meet a jump instruction in the middle of the 128-bit word, you'll have to (more or less) execute all the rest up till the end of the fetch. Some RISC CPU's have done this but for only one instruction. Can a compiler succesfully put 3 useful instructions after the jump?? Maybe it sounds too cheap: "After any jump the CPU executes at most three instructions after it". (Actually it turns out that the jump has to be in the first of the 4 instructions in the 128-bit word, so as the memory can get the right address.) >3. When you mentioned fetching instructions, you seemed to assume > that instruction size had to equal data word size. This isn't true. > There is no direct relation between word size and instruction > size. There is some relation between word size and address space > ( if you have n-bit data paths, you ought to have n-bit addresses, > and vice-versa. This is just a sensible opinion ? ) > I tend to agree on that. It's better to have so much memory that you can reference, not more. Not like the poor 8086 that tries to access 1Mbyte with 16 bit index registers. ******************************************************* *George C. Kyriazis * Gravity is a myth *userfe0e@mts.rpi.edu or userfe0e@rpitsmts.bitnet * \ / *Electrical and Computer Systems Engineering Dept. * \ / *Rensselear Polytechnic Institute, Troy, NY 12180 * || ******************************************************* Earth sucks.