Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!pyramid!voder!apple!bcase
From: bcase@apple.UUCP (Brian Case)
Newsgroups: comp.arch
Subject: Re: MIPS register handling question (long)
Message-ID: <6748@apple.UUCP>
Date: Mon, 16-Nov-87 13:32:45 EST
Article-I.D.: apple.6748
Posted: Mon Nov 16 13:32:45 1987
Date-Received: Wed, 18-Nov-87 04:42:43 EST
References: <166@quick.COM> <910@gumby.UUCP>
Reply-To: bcase@apple.UUCP (Brian Case)
Organization: Apple Computer Inc., Cupertino, USA
Lines: 25

In article <910@gumby.UUCP> larry@gumby.UUCP (Larry Weber) writes:

[Lots of good stuff about MIPS strategies.]  Larry, thanks so much for
posting this info.  How would you compare your link-time optimization
with that done by Wall at DEC?

>HOWEVER, should a window overflow or underflow occur,
>many registers are saved and restored.  This cost is a pure blind save, 
>registers that have nothing in them get saved, without even the benefits
>of either caller or callee save which tries to place some intelligence
>behind the which registers should be saved.  Also, windows have a larger
>cost at context switch times.

Yes, straight, fixed-size register windows (ala RISC I & II and SPARC)
have this problem:  unless the window is exactly the right size, there
will be either too few registers or too many (one or the other, usually
too many, is the case most of the time).  So, when a save happens, some
unneeded memory traffic is generated.  This is exactly why the 29K has
variable-sized "windows."  They aren't perfect, but at least the compiler
can allocate exactly what it wants.  When a save/restore happens, the
memory traffic is always transfering something "useful" and the addresses
are known to be sequential (thus enabling the use of high-bandwidth
access techniques).

I believe the link-time allocation techniques hold great promise.  Keep
us updated if possible!