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