Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!genrad!decvax!ucbvax!amdcad!bcase
From: bcase@amdcad.UUCP
Newsgroups: comp.arch
Subject: Re: RISC register windows
Message-ID: <14964@amdcad.UUCP>
Date: Wed, 25-Feb-87 12:57:50 EST
Article-I.D.: amdcad.14964
Posted: Wed Feb 25 12:57:50 1987
Date-Received: Fri, 27-Feb-87 21:12:32 EST
References: <1881@homxc.UUCP> <898@moscom.UUCP> <476@mntgfx.MENTOR.COM>
Reply-To: bcase@amdcad.UUCP (Brian Case)
Organization: Advanced Micro Devices, Sunnyvale, California
Lines: 21

In article <1335@Shasta.STANFORD.EDU> andy@Shasta.UUCP (Andy Freeman) writes:
>One argument for fixed window sizes is that register access
>shouldn't require an addition.  Bit-wise or is one thing (or the
>register number with the current base to determine the register);
>addition is an expensive operation to put on the register access
>data path.  This basically restricts window sizes to powers of two.
>
>Then again, I seem to remember that the window size wasn't a power
>of two on the Berkeley RISC, which surprised me.  Maybe I'm wrong.
>
True, the entire window in the Berkeley scheme (and Pyramid) isn't a power
of two in size, but the amount allocated/deallocated on call/return *is*
a power of two:  6 in, 10 local, 6 out = 22.  But 6 of those are overlapped
and aren't allocated on call, thus, 16 is the allocation size.

Also, the Berkeley scheme requires more than a simple or function; see
Katevenis' thesis.

    bcase
---------
It'll be worth it.  Keep watching this space.