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.