Path: utzoo!attcan!uunet!yale!mfci!freuden
From: freuden@mfci.UUCP (Stefan Freudenberger)
Newsgroups: comp.arch
Subject: Re: Memory latency / cacheing / scientific programs
Keywords: cache latency bus memory
Message-ID: <448@m3.mfci.UUCP>
Date: 24 Jun 88 13:51:21 GMT
References: <243@granite.dec.com> <443@m3.mfci.UUCP>
Sender: root@mfci.UUCP
Reply-To: freuden@mfci.UUCP (Stefan Freudenberger)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 25

In article <443@m3.mfci.UUCP> colwell@mfci.UUCP (Robert Colwell) writes:
|In article <243@granite.dec.com> jmd@granite.dec.com (John Danskin) writes:
|>                        ...  A trace scheduling compiler could space
|>loads out through a loop so that most/all of the bus latency is
|>hidden.  The compiler still has to know what memory latency is for full
|>efficiency, but if it doesn't (numbers change) the code still works.
|I consider our VLIW a scalar machine, and our compiler does what you
|said.  I'm not sure what you meant by "if compiler doesn't know
|memory latency, the code still works" though.  If the latency becomes
|shorter, it'll still work, ...
|                       ...  Not to mention that you'd have to change
|the register files, which are already pretty crammed with gates in
|order to achieve the 4-read/4-write ports per instr that we need.

Even if the memory latency decreases, the code will *only* work if you
don't run into register write port and/or other resource conflicts.
If resource constraints are maintained by the compiler, then you are
likely :-) to have to recompile your programs when these constraints
change.  If your original code still runs, though, then it wasn't very
compact the first place.
 
Stefan Freudenberger   mfci!freuden@uunet.uucp
Multiflow Computer     freudenberger@multiflow.com
175 N. Main St.
Branford, CT 06405     203-488-6090