Path: utzoo!utgpu!water!watmath!clyde!att-cb!ihnp4!ptsfa!ames!ll-xn!husc6!ut-sally!utah-cs!utah-gr!stride!mitch
From: mitch@Stride.COM (Thomas Mitchell)
Newsgroups: comp.arch
Subject: Re: Cycle stretching
Summary: Not just in the processor
Message-ID: <719@stride.Stride.COM>
Date: 19 Feb 88 21:38:50 GMT
References: <844@daisy.UUCP>
Reply-To: mitch@stride.stride.COM (Thomas Mitchell)
Organization: MicroSage, 680 S. Rock Blvd, Reno, NV 89502
Lines: 25

In article <844@daisy.UUCP> david@daisy.UUCP (David Schachter) writes:
>
>Here is a dumb question.  Say I have a CPU where 99 percent of 
           ^^^ Not dumb.
>the instructions
>take, say, one clock.  The remaining instructions need just a little longer--
>one clock plus a few nanoseconds.  Why not stretch the clock 
>a bit when executing those instructions, instead of wasting most
>of a second clock period?

David;

That is the same question we asked when were selecting a clock
rate for our 400 series custom MMU.  We could have clocked that
processor (MC68010) at 12 MHz but that would have required an
extra state on each memory cycle.  At 10MHz that extra state was
not required.  The result was the same throughput at 10MHz as
12MHz in most cases.

The hard part is finding the knee in the curve.  If the extra
state instructions are used rarely then adding the state to all
operations is a loss.  If few but commonly used then it is a
gain.

Well thanks for the Soap Box,