Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!unm-la!lanl!cmcl2!yale!mfci!rodman
From: rodman@mfci.UUCP (Paul Rodman)
Newsgroups: comp.arch
Subject: Re: When is RISC not RISC?
Message-ID: <649@m3.mfci.UUCP>
Date: 16 Feb 89 19:00:42 GMT
References: <747@atanasoff.cs.iastate.edu> <28200275@mcdurb>
Sender: rodman@mfci.UUCP
Reply-To: rodman@mfci.UUCP (Paul Rodman)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 34

In article <28200275@mcdurb> aglew@mcdurb.Urbana.Gould.COM writes:
>
>>Why not have a *real* pipelined memory system and a compiler than can
>>handle more than one miserable outstanding load in flight? Or have both.
>>
>>
>>    Paul Rodman
>
>Denelcore's HEP.
>

Yuk. Please don't bring up that pile of junk. 

I was referring more to our machine, where the compiler sees an exposed 
pipeline  several beats long to main memory.  In some 
cases a data cache is useful for reducing latency if the hit rate will be
high enough. Of course, your compiler must do a good job
about deciding when to go for the cache. 

...I'm  disgusted at these piddly RISC chips that brag about register
scoreboarding of one lousy outstanding load at a time. Great for use
with data caches, not much use for high performance computation on large
data sets (where I'd much rather not use the cache, but want to get decent
bandwidth). If you want to do a daxpy, for example, you need two loads
and a store per 2 flops. What good are floating point chips if you can't
feed 'em? 

The architecture is broken if I can't at least do 1 load/store 
(from memory,please) per flop. :-)  



    Paul Rodman
    rodman@mfci.uucp