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: <1040@valid.UUCP>
Date: Sun, 1-Mar-87 23:58:59 EST
Article-I.D.: valid.1040
Posted: Sun Mar  1 23:58:59 1987
Date-Received: Wed, 4-Mar-87 20:41:45 EST
References: <4376@columbia.UUCP> <7284@boring.mcvax.cwi.nl> <14986@amdcad.UUCP>
Organization: Valid Logic, San Jose, CA
Lines: 55

Incidentally, another good reference in the area of register windows is:

"Analyzing Multiple Register Sets" by Hitchcock and Sprunt from CMU

Unfortunately, I neglected to write on my copy the publication from which
it came, but judging from "1985 IEEE," it's either the 1985 Architecture
conference or Transactions.

At any rate, the premise behind the paper is to decouple the effects of
multiple register sets and register windows from the architecture of the
machine.  To do this, the authors constructed simulators for RISC I, a 68000,
and a VAX and compared the number of memory references generated by
applications running with no multiple register sets, with multiple register
sets (no overlap), and with overlapped register windows.  The decrease in
memory references was as great as 2:1 for the VAX with windows as compared
to the normal VAX.  In one case (Ackerman's function, a pathological program
for any subroutine-call benchmark), register windows actually behaved WORSE
than a conventional register set due to the constant overflows and underflows.
The severity of this problem obviously depends on the number of windows
provided in the register file and the size of each window.  The reduction
in memory references for the 3 architectures varied from very little (25%)
to a factor of 7, depending on the application.  The RISC I fared particularly
poorly without its register windows.  The actual payoff is influenced by the
frequency of register variable access, overflow/underflow rate, and compiler
smartness.  In addition, some program constructs such as up-level references
in Pascal code can generate tremendous headaches for register-window
architectures.

Considering the results of this study, it is a rational conclusion that
register windows do not necessarily imply RISC, and should be considered
as a viable architectural parameter in any machine, subject to the usual
tradeoffs.  BTW- I could not find any indication in the paper of what the
relative sizes were of the normal and overlapped register files.  If indeed
(as I suspect) the overlapped register file was substantially larger than
the normal register file, then similar performance gains could probably be
attained through use of a large register file and a very good register
allocation scheme in the compiler/optimizer.  Actual performance comparison
of these 2 approaches with the same size register file is WAY beyond the
scope of this posting! (although I would LOVE to see some numbers and/or
references, with an indication of just how bad [in practice] the compiler
complexity issues are between the two approaches)

An earlier poster maintained that a primary purpose of register windows was
to allow operation without a cache.  This is not strictly true.  In fact,
register windows can function even better WITH a cache since it generates
block write and read requests on overflows and underflows.  Furthermore,
it is impractical to maintain a large enough register file to function as
an effective data cache.  In the interest of calling a certain class of
gardening tools "spades", register windows should be regarded as no more
and no less than they are: a clever architectural mechanism to decrease
the register-related overhead of subroutine call and return.

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