[comp.arch] multiple register windows

colwell@mfci.UUCP (Robert Colwell) (10/28/88)

In article <16054@agate.BERKELEY.EDU> matloff@iris.ucdavis.edu (Norm Matloff) writes:
>*If I remember the arguments from MIPS correctly (want to help me out
>*John?), there's a stronger objection to multiple-window-register-files.
>*I think it's something to the effect that register-windows cause the
>*load/store access time to be slower.  I think there also may be some
>*argument that a good compiler makes multiple-windows relatively
>*unnecessary.
>
>A compiler which automatically inlines procedure calls might be able
>to do what you are saying.  However, there may be some unpleasant
>side effects, depending on the language.  Actually, one of my grad
>students in making a thesis out of this, so I'll try to report more
>on it later.

Don't forget that one of the side effects of having your registers
arranged into windows is that you don't have access to very many 
registers from within any given procedure.  There are routines
that need lots of them, and there are routines that need very
few.  The one-size-fits-all approach is not what a good compiler
wants; it would rather see them all at once and do the management
explicitly.  The windowing is just a hack to make parameter-passing
cheap, which a compiler can do just as well or better.

Bob Colwell            mfci!colwell@uunet.uucp
Multiflow Computer
175 N. Main St.
Branford, CT 06405     203-488-6090

matloff@bizet.Berkeley.EDU (Norman Matloff) (10/29/88)

In article <536@m3.mfci.UUCP> colwell@mfci.UUCP (Robert Colwell) writes:
*In article <16054@agate.BERKELEY.EDU> matloff@iris.ucdavis.edu (Norm Matloff) writes:

*>A compiler which automatically inlines procedure calls might be able
*>to do what you are saying.  However, there may be some unpleasant
*>side effects, depending on the language.  Actually, one of my grad
*>students in making a thesis out of this, so I'll try to report more
*>on it later.

*Don't forget that one of the side effects of having your registers
*arranged into windows is that you don't have access to very many 
*registers from within any given procedure.  There are routines
*that need lots of them, and there are routines that need very
*few.  The one-size-fits-all approach is not what a good compiler
*wants; it would rather see them all at once and do the management
*explicitly.  The windowing is just a hack to make parameter-passing
*cheap, which a compiler can do just as well or better.

There was a good suggestion (I don't remember the reference, maybe
the Huguet and Lang paper) to have variable-size windows, but only
in a FEW sizes, solving the one-size-fits-all problem at a low time
cost (as I recall, this was achieved by restricting window sizes to
powers of 2).

   Norm

pardo@june.cs.washington.edu (David Keppel) (10/29/88)

colwell@mfci.UUCP (Robert Colwell) writes:
>[ Problem w/ reg windows: one size fits all *only* ]

There have been several studies of variable-sized windows, and I
believe that somebody put an 4-size scheme into hardware.

	;-D on  ( Just another blithe assertion )  Pardo
-- 
		    pardo@cs.washington.edu
    {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo

henry@utzoo.uucp (Henry Spencer) (10/30/88)

In article <536@m3.mfci.UUCP> colwell@mfci.UUCP (Robert Colwell) writes:
>Don't forget that one of the side effects of having your registers
>arranged into windows is that you don't have access to very many 
>registers from within any given procedure...
>... The one-size-fits-all approach is not what a good compiler
>wants...

Register windows don't imply one-size-fits-all.  See the AMD 29000
for an example; it has completely variable window size, up to a limit
of 128 set by the size of its "local register" bank.
-- 
The dream *IS* alive...         |    Henry Spencer at U of Toronto Zoology
but not at NASA.                |uunet!attcan!utzoo!henry henry@zoo.toronto.edu