Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-winken!uunet!mfci!rodman
From: rodman@mfci.UUCP (Paul Rodman)
Newsgroups: comp.arch
Subject: Re: RISC as a "technology window"?
Message-ID: <727@m3.mfci.UUCP>
Date: 26 Mar 89 03:39:42 GMT
References: <1552@vicom.COM> <15690@cup.portal.com> <1562@vicom.COM> <15702@clover.ICO.ISC.COM> <27681@apple.Apple.COM> <15695@winchester.mips.COM> <22974@ames.arc.nasa.gov> <51@microsoft.UUCP> <22202@shemp.CS.UCLA.EDU> <726@m3.mfci.UUCP>
Sender: rodman@mfci.UUCP
Reply-To: rodman@mfci.UUCP (Paul Rodman)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 24

In article <726@m3.mfci.UUCP> rodman@mfci.UUCP (Paul Rodman) writes:
>In article <22202@shemp.CS.UCLA.EDU> marc@cs.ucla.edu (Marc Tremblay) writes:
>
>>I also believe that putting the Integer unit and the FPU on the same 
>>chip makes sense. These two units have to communicate quickly....
>                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>I don't understand why.
>
>In most f.p. codes the integer unit generates 
>addresses and program counter values, neither of which are needed
>by the f.p. unit.  

And before millions of people trash on me, let me clairify by saying that
obviously an f.p. unit needs a source of control. Marc seems to value
a low latency path between the control part of the machine and the f.p. unit.

Given that the original request was for a partitioning that would lead to
high performance, I think that some of this latency is best traded off for
better bandwidth. For example, one might pipeline the icache address to
the f.p. unit, causing instruction issue to be delayed by a beat for 
f.p. ops. This increases the f.p. latency with respect to the pc, but
does not increase it with respect to other flops or memory loads/stores.

pkr