Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!lll-lcc!styx!ames!amdahl!chuck From: chuck@amdahl.UUCP Newsgroups: comp.arch Subject: Re: subroutine frequency Message-ID: <5746@amdahl.UUCP> Date: Tue, 24-Feb-87 23:28:08 EST Article-I.D.: amdahl.5746 Posted: Tue Feb 24 23:28:08 1987 Date-Received: Fri, 27-Feb-87 06:30:24 EST References: <1881@homxc.UUCP> <898@moscom.UUCP> <476@mntgfx.MENTOR.COM> <430@cpocd2.UUCP> <1093@uwmacc.UUCP> <443@cpocd2.UUCP> Reply-To: chuck@amdahl.UUCP (Charles Simmons) Organization: Amdahl Corp, Sunnyvale CA Lines: 38 In article <443@cpocd2.UUCP> howard@cpocd2.UUCP (Howard A. Landman) writes: >Some RISC machines have multiple sets of registers, organized as overlapping >windows. This approach to speeding up calls/returns was suggested to the >RISC I team at Berkeley by Forest Baskett; simulations convinced us it would >work for typical UNIX code, so we implemented it. It worked. > Howard A. Landman As I understand it, each register window is a fixed size, and each window is divided into three fixed size subwindows. (I don't remember what these three subwindows are meant to be used for.) One particular aspect of the implementation has been bothering me; namely, the amount of overlap between two windows is a constant size. This has two consequences. First, subroutines which don't use all of their window waste register storage. Typical programs that I write tend to contain short routines that use few variables and need few registers. Thus, my programs can't get the full benefits of the register windows; many of the registers remain unused. Second, subroutines that want to pass more parameters than will fit in an overlapped window, but fewer parameters than would fit in a complete window are also penalized. Not all parameters will be able to be passed inside of registers, and some must be saved in memory. So I'm wondering why the implementation of the RISC I and II don't allow the programmer to specify the number of registers that should be overlapped on the procedure call. Obviously, this would make subroutine calls more expensive and difficult to implement. The overlap size would have to be fetched from memory and added to the window pointer. Checking to see if the register stack had overflowed might be more expensive... However, these seem like trivial problems when compared to the benefit of effectively having a larger register stack. Are there reasons I am missing that make fixed sized windows extremely advantageous? thanks, Chuck