🚀 go-pugleaf

In article <15695@winchester.mips.COM> mash@mips.COM (John Mashey) writes:
>faster, make FP go faster, and maybe put in some multiple FP units,
>a la CDC 6600s [and these things chew up area]. Note that Intel, with
>a million transistors, said the space budget didn't leave room for
>an IEEE divide..... (Compcon paper).

Things are getting to a very interesting stage, however.  I guess it is just
my big machine history showing again, but I keep wondering why, with a decent
sized register file, it wouldn't make more sense to put all FP/ALU hardware on
the same chip as the control unit, along with the instruction cache, 
and leave the MMU, and the data cache (which is almost always going to be 
larger than what you can put
on a chip no matter how large the chips get), to an external implementation.
This also leaves more flexibility in cache design/choice, which is reasonable
since data cache design is very dependent on what the chip is going to be used
for anyway.  I would expect to see a second MMU/cache chip available also for 
people who want to use it. Also, it would make some graphics/vector designs
easier to deal with also (at least potentially).

Last year, the answer always was: "High speed arithmetic (integer and/or FP)
is a specialty area."  I would think that the success of this years crop of
high-arithmetic-performance systems would have dispelled that notion by now.

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?

  Hugh LaMaster, m/s 233-9,  UUCP ames!lamaster
  NASA Ames Research Center  ARPA lamaster@ames.arc.nasa.gov
  Moffett Field, CA 94035     
  Phone:  (415)694-6117