Path: utzoo!yunexus!lethe!torsqnt!jarvis.csri.toronto.edu!mailrus!ncar!asuvax!mcdphx!udc!chant!aglew From: aglew@urbana.mcd.mot.com (Andy-Krazy-Glew) Newsgroups: comp.arch Subject: Re: RISC vs CISC (rational discussion, not religious wars) Message-ID: Date: 12 Nov 89 00:33:00 GMT Article-I.D.: chant.AGLEW.89Nov11193300 References: <503@ctycal.UUCP> <15126@haddock.ima.isc.com> <28942@shemp.CS.UCLA.EDU> <31097@winchester.mips.COM> <28985@shemp.CS.UCLA.EDU> <29018@shemp.CS.UCLA.EDU> Sender: aglew@urbana.mcd.mot.com Organization: Work: Motorola MCD, Urbana Design Center; School: University of Illinois at Urbana-Champaign Lines: 28 In-reply-to: marc@oahu.cs.ucla.edu's message of 10 Nov 89 02:22:24 GMT 1) With an on-chip cache it is a lot easier to implement a wide datapath (64 or 128 bits) between the cache and the register file than it is with an off-chip cache, which requires lots of pins and lots of routing. A wide datapath allows the use of instructions that take advantage of the extra bandwidth to i) save/restore the register file quicker (for example on calls/returns) and ii) load and store double precision operands in one cycle (two double precision operands can be loaded with 128 bits). I'm a wide datapath proponent myself, but some of my contacts have responded that so many signals simulataneously changing state at the same time => huge instantaneous power demand. How much of a problem is this *really*? Can techniques such as slightly delaying groups of lines help? Eg. provide the LSBs earlier so that caries can propagate while waiting for the MSBs to arrive on different lines? -- Andy "Krazy" Glew, Motorola MCD, aglew@urbana.mcd.mot.com 1101 E. University, Urbana, IL 61801, USA. {uunet!,}uiucuxc!udc!aglew My opinions are my own; I indicate my company only so that the reader may account for any possible bias I may have towards our products.