Path: utzoo!attcan!uunet!ubvax!ames!lamaster
From: lamaster@ames.arc.nasa.gov (Hugh LaMaster)
Newsgroups: comp.arch
Subject: Re: Memory latency / cacheing / scientific programs
Message-ID: <11052@ames.arc.nasa.gov>
Date: 30 Jun 88 00:22:53 GMT
References: <243@granite.dec.com> <779@garth.UUCP> <2033@pt.cs.cmu.edu> <803@garth.UUCP> <11023@ames.arc.nasa.gov> <6070@aw.sei.cmu.edu>
Reply-To: lamaster@ames.arc.nasa.gov.UUCP (Hugh LaMaster)
Organization: NASA Ames Research Center, Moffett Field, Calif.
Lines: 30

In article <6070@aw.sei.cmu.edu> firth@bd.sei.cmu.edu.UUCP (Robert Firth) writes:

>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

If by "global" you mean, at the module level, then the answer is yes.  The
optimizers go far beyond peephole type optimizations.  But if you mean
global for an entire process, no.  Which is why all registers that are
used in a module have to be restored.

>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.

This, I don't understand.  Shared library modules are called just like
any other modules, so they do saves and restores.  But, even if you
do global global optimization for an entire process, you wouldn't
normally assume anything about a shared library - after all, the code
changes from release to release.  You wouldn't want to assume that
shared library code never changed...  P.S.  Crays don't have memory
mapping, so they don't do shared libraries.  Cyber 205's do both...


-- 
  Hugh LaMaster, m/s 233-9,  UUCP ames!lamaster
  NASA Ames Research Center  ARPA lamaster@ames.arc.nasa.gov
  Moffett Field, CA 94035     
  Phone:  (415)694-6117