Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!ptsfa!lll-lcc!pyramid!pesnta!valid!markp
From: markp@valid.UUCP
Newsgroups: comp.arch
Subject: Re: register window machine questions
Message-ID: <1034@valid.UUCP>
Date: Sun, 1-Mar-87 03:26:33 EST
Article-I.D.: valid.1034
Posted: Sun Mar  1 03:26:33 1987
Date-Received: Wed, 4-Mar-87 20:40:43 EST
References: <4376@columbia.UUCP>
Organization: Valid Logic, San Jose, CA
Lines: 49

> Register window machines such as the Berkeley RISCs have been discussed
> recently in this group.  I have some questions about these architectures:
> 
> (1) Has anyone tried making the window block size be just one register,
> i.e. the window can have an arbitrary alignment in relation to memory?
> I would expect this to be more efficient in terms of registers used (and
> therefore also memory), but register access time might suffer.
> 

I believe that the "Strategies for Managing the Register file in RISC"
paper, mentioned earlier, concluded that fully-programmble register window
size had very low marginal utility over a small variety of fixed sizes (i.e.
4/8/12 registers), and would probably be a lose considering the additional
complexity and critical path effects.  (i.e. you're better off making a
larger file with less control complexity)

The other significant conclusion that I recall they made was that the
most effective overflow/underflow handling mechanism (averaged across
many applications) is to save exactly one context on demand (subroutine
call overflows), and to restore exactly one context on demand (subroutine
return underflows).

Overflow/underflow problems are correlated with the subroutine nesting
depth over time of an application.  Programs which go down and come back
up several levels with few repetitions at any given level (i.e. Ackerman's
function) tend to be pathological overflowers, while programs which spend
a great deal of time at or near a particular nesting depth practically never
overflow.  The point here is that sensible thinking about the calling pattern
of your program can dramatically improve performance in a register-window
machine.  This isn't really a very difficult concept, but people don't always
think about it.

> (3) Are there machines with both dynamic (windowed) and static (normal)
> registers?  For instance it might be useful for quick O.S. interrupts to
> use only statics and not go to the trouble of setting up a register
> window stack (which would involve lots of reads and writes moving the
> old stack completely out to memory and then back again later).  Static
> registers could also be useful for non-local variables.

Absolutely.  A register window implementation generally maintains a set of
global registers which are accessible from any context (i.e. rM-rN are always
global registers).  Non-register window RISC machines must make a distinction
between globals, locals, and parameter registers in order to make the best
use of the register file, though the allocation is done by the smart
compiler/optimizer.  I'm sure John can speak more specifically.

	Mark Papamarcos
	Valid Logic
	{ihnp4,hplabs}!pesnta!valid!markp