Path: utzoo!attcan!uunet!hsi!mfci!colwell From: colwell@mfci.UUCP (Robert Colwell) Newsgroups: comp.arch Subject: Re: penalty for microcode Message-ID: <568@m3.mfci.UUCP> Date: 29 Nov 88 02:57:12 GMT References: <3290@ucdavis.ucdavis.edu> <28200241@urbsdc> Sender: colwell@mfci.UUCP Reply-To: colwell@mfci.UUCP (Robert Colwell) Organization: Multiflow Computer Inc., Branford Ct. 06405 Lines: 27 In article <28200241@urbsdc> aglew@urbsdc.Urbana.Gould.COM writes: >>There's a definite appeal to having one-cycle instructions, but i think it's >>mostly illusory. If an in-place complement takes less time than a three-operand >>add-with-shift, they shouldn't be forced to take the same amount of time. In >>other words, if most of your instructions take one cycle, your cycles are too >>long. >>So what do y'all think about this? Are one-cycle instructions a good thing? > >Cycles are a bad thing! The universe is not discrete. >All instructions should be self-timed, to precisely the length of >time required to do the operation. > >:-) I left in your smiley, Andy, but it's not all that nutty. There is a certain appeal to making a machine where the clock cycle doesn't have to be "one-size-fits-all". Apart from the added complexity, the problem is that when you're juggling multiple CPU pipes, you have to either control each pipe individually in this fashion, or you control them all (allowing enough time in the current clock cycle for the slowest pending pipe stage to complete). That's a mess, and I doubt it would ever pay. Bob Colwell ..!uunet!mfci!colwell Multiflow Computer or colwell@multiflow.com 175 N. Main St. Branford, CT 06405 203-488-6090