Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!ames!uhccux!munnari.oz.au!mimir!hugin!augean!idall
From: idall@augean.OZ (Ian Dall)
Newsgroups: comp.arch
Subject: RISCs Register sets and PDP 10/20s
Message-ID: <550@augean.OZ>
Date: 27 Jul 89 08:43:00 GMT
Reply-To: idall@augean.OZ (Ian Dall)
Organization: Engineering Faculty, University of Adelaide, Australia
Lines: 29


All this talk of PDP 10s aliasing memory to the first locations of memory
reminded me of something I was thinking about some time ago.

The tendency is to go for large register sets. Large register sets have a
penalty in context switch time (and possibly in proceedure calls of
seperately compiled code). Various people have claimed that with a suitable
cache, memory bandwidth is "not a problem".

So why not put the "registers" in memory? If the "registers" are the
first n locations of the virtual address space then they will not have
to be saved and restored on context switches or interrupts. There are
a few ways to think of this. It is either memory mapped registers or
(because these are in effect just scratchpad memory locations) it is
equivalently a zero register machine. The data cache is essential to
the scheme. Because the scratchpad locations are accessed frequently
the probability of a cache hit is very high. The compiler would have
to know something of the cache dynamics so that it could decide
whether it is better to keep something in a temporary register
location (which is almost certain to be a cache hit) or to access
directly a possibly distant location.

I suspect the problem is that there is still a significant gap between
the access times of a register and of a cache location. Still, I kind
of like the idea of an infinitly large demand paged register set!
-- 
 Ian Dall           life (n). A sexually transmitted disease which afflicts
                              some people more severely than others.
idall@augean.oz