Path: utzoo!attcan!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!think!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!ucdavis!iris.davis.EDU!lee From: lee@iris.davis.EDU (Peng Lee) Newsgroups: comp.arch Subject: Re: RISC vs CISC (rational discussion, not religious wars) Message-ID: <5952@ucdavis.ucdavis.edu> Date: 16 Nov 89 17:16:08 GMT References: <503@ctycal.UUCP> <15126@haddock.ima.isc.com> Sender: uucp@ucdavis.ucdavis.edu Reply-To: lee@iris.davis.EDU (Peng Lee) Lines: 34 In article , toms@omews44.intel.com (Tom Shott) writes: > > A novel architecture from the Computer Systems Group at UIUC published by > Dave Archer, et el used multiple task running on one CPU to hide delays. > For example w/ a 4 stage pipeline, the CPU chip would run four tasks at > once. I don't remember the details but it worked out that each task > executed at 1/4 of full speed. (I think dummy pipeline stages were used > between the stages). But during that delay time memory fetch latency was > hidden. (Also data dependices). Realistically I might expect this technique > only to be used for large systems aimed at multiuser applications. You need > four tasks always ready to run. > I have been looking at the implementation of this kind of design. By implement a task controller unit that would swap to a new register set when there is a data dependency or branch or a load (delay), you don't need 4 tasks fully utilize the excution pipe. At most two tasks should be enough to fill the pipe. And if standard RISC optimizing technique (delay branch, etc) is applied to these tasks, the single task exexution time shouldn't be slower then the regular RISC when there is only one task. This design have a advantage guarantee full utilization of execution pipling when there is two tasks. One very interesting aspect I am currently looking at is possibility of implementing at semaphore in these register sets. > > -- > ----------------------------------------------------------------------------- > Tom Shott INTeL, 2111 NE 25th Ave., Hillsboro, OR 97123, (503) 696-4520 > toms@omews44.intel.com OR toms%omews44.intel.com@csnet.relay.com > INTeL.. Designers of the 960 Superscalar uP and other uP's -Peng (lee@iris.ucdavis.edu)