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