Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!purdue!bu-cs!bloom-beacon!mit-eddie!uw-beaver!cornell!rochester!pt.cs.cmu.edu!sei!sei.cmu.edu!firth From: firth@sei.cmu.edu (Robert Firth) Newsgroups: comp.arch Subject: Re: Memory latency / cacheing / scientific programs Message-ID: <6070@aw.sei.cmu.edu> Date: 29 Jun 88 19:48:40 GMT References: <243@granite.dec.com> <779@garth.UUCP> <2033@pt.cs.cmu.edu> <803@garth.UUCP> <11023@ames.arc.nasa.gov> Sender: netnews@sei.cmu.edu Reply-To: firth@bd.sei.cmu.edu.UUCP (Robert Firth) Organization: Carnegie-Mellon University, SEI, Pgh, Pa Lines: 15 In article <11023@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov.UUCP (Hugh LaMaster) writes: >Neither the 205 nor the Cray has a cache. The philosophy is to put in >enough registers that a cache is unnecessary. The 256 registers on >the 205 were plenty for any module that I saw. The place where this >approach hurts is in scalar codes that have very frequent procedure >calls (typical C system and utilities code) since data has to be >saved and restored between procedure calls even if it is being reused. This is a defensible philosophy, but, as with any hardware design, it can work only with sympathetic software design. If the target machine has a large number of registers, then the codegenerator really must be prepared to perform global register allocation, and must also address the problem of register partitioning between user code and shared library code. Anything less, I would regard as an indication that the implementor hadn't bothered to understand the machine.