Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: comp.arch
Subject: Re: register windows
Message-ID: <8836@utzoo.UUCP>
Date: Tue, 27-Oct-87 17:03:15 EST
Article-I.D.: utzoo.8836
Posted: Tue Oct 27 17:03:15 1987
Date-Received: Tue, 27-Oct-87 17:03:15 EST
References: <201@PT.CS.CMU.EDU> <8801@utzoo.UUCP> <8758@shemp.UCLA.EDU>, <5567@jade.BERKELEY.EDU>
Organization: U of Toronto Zoology
Lines: 23
Keywords: register windows, interrupt latency

> ...you used all that chip space for a
> register-speed cache that is mapped onto memory. The mapping is tracked
> by a base/length pair. It's a write-through cache.
> The trick is that this is mapped onto the top of the stack...

How much this wins depends on details.  If the stuff is addressed as normal
memory -- remember that optimizing compilers often want to use their
temporaries in a non-LIFO pattern, so making "push" and "pop" special cases
isn't necessarily a win -- then you pay the various penalties involved in
needing memory addresses for all your temporaries.  If the cache pretends
to be registers, then what you have is register windows with a lot more
writes to memory, some small fraction of which incidentally make it
unnecessary to do writes at context-switch time.  This is probably not a
win unless you are big on interrupt latency at the expense of throughput,
because you *are* doing a lot more memory accesses, although they are less
concentrated.

It's an interesting idea that might work well if done right, but it's *not*
"all of the advantages of register windows with none of the disadvantages".
It has some of the advantages and has disadvantages of its own.
-- 
PS/2: Yesterday's hardware today.    |  Henry Spencer @ U of Toronto Zoology
OS/2: Yesterday's software tomorrow. | {allegra,ihnp4,decvax,utai}!utzoo!henry