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