Path: utzoo!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!hellgate.utah.edu!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.arch
Subject: Re: register save
Message-ID: <10896@dog.ee.lbl.gov>
Date: 13 Mar 91 16:59:12 GMT
References: <1991Mar11.192116.1974@dgbt.doc.ca> <912@spim.mips.COM> <3255@crdos1.crd.ge.COM>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 23
X-Local-Date: Wed, 13 Mar 91 08:59:12 PST

In article <3255@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com
(bill davidsen) writes:
>... in systems which use register windows, does someone have a good
>handle on the cost of doing all the register to register I see just
>before a call?

In many (yeah sure :-/ ) cases you can put the values in the windowed
registers in the first place, and/or leaf functions (those again!) can
avoid using a new window (doing everything in the caller's window and
any `callee saves' temporary registers).

>  Obviously there's a win in register windows if their large enough, but
>I know know it isn't as big as the papers on RISC claim.

Depending on your compiler and applications, it may even be zero or
negative.  Applications which have a lot of `up-down' motion over a
small call stack range, and which thus fit perfectly in the windows,
will get either large gains, or (if your register allocation is good
enough) none at all, on machines with register windows (SPARC) vs
machines with `just a lot of registers' (AM29000).
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov