Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!yale!mfci!rodman
From: rodman@mfci.UUCP (Paul Rodman)
Newsgroups: comp.arch
Subject: Re: RISC as a "technology window"?
Message-ID: <717@m3.mfci.UUCP>
Date: 24 Mar 89 19:41:26 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>
Sender: rodman@mfci.UUCP
Reply-To: rodman@mfci.UUCP (Paul Rodman)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 42

In article <22974@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes:
>
>So, my question is:  If you ASSUME that you have to have high speed arithmetic,
>what is the best way to partition functions between chips?  I believe that the
>best way is Control, ALU/FPU, and instruction cache on one chip, and data
>cache/MMU on another chip.  Why doesn't the market agree with me?
>

Personally, I think the optimal partitioning for large f.p. problems would
be to split the f.p. unit and registers onto another chip. The amount of
comms required between the integer domain and floating domain is very
small and extra cycles to go from one to the other aren't a problem (speaking
from the our experience with partition the cpu in just this way). 

I haven't
thought about how to solve the problems in splitting integer data caches
and floating data caches, but I'm sure there would be an acceptable solution.
Assuming your compiler guys are up to it , :-)

The main advantage here are:

      - You can get more pins for the f.p. chip for more loads/stores per
        clock on the f-unit. Also you can get more than 16 d.p. registers 
        (which isn't enough, in our experience for two piped fu's). 

      - The i-chip, which made no use of the funit hardware, has more area
        for integer goodies, including a larger on-chip data cache for
        integer data. I would rather have the MMU on this chip to make sure
        that the memory pipeline for explicit loads is one cycle shorter,
        i.e. save a chip crossing here.

Now the guys that don't use floating point can just buy the i-chip, those
that want screaming f.p. perf buy both. 

I just don't see the point in doing hairy-chested cramming of f.p. hardware
on the same chip as the integer stuff, when the two functional units 
are so nicely seperable, to the benefit of each.

    Paul K. Rodman 
    rodman@mfci.uucp
    __... ...__    _.. .   _._ ._ .____ __.. ._