Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!rochester!PT!k.gp.cs.cmu.edu!lindsay
From: lindsay@k.gp.cs.cmu.edu.UUCP
Newsgroups: comp.arch
Subject: register windows
Message-ID: <1242@k.gp.cs.cmu.edu>
Date: Sat, 3-Oct-87 00:01:06 EDT
Article-I.D.: k.1242
Posted: Sat Oct  3 00:01:06 1987
Date-Received: Sun, 4-Oct-87 02:04:46 EDT
Distribution: na
Organization: Carnegie-Mellon University, CS/RI
Lines: 33

References:

Register windows interest me.

Win#1:  less memory traffic to save/restore registers at procedure 
	call/returns. (Caches get some of this win.)
Win#2:  less memory traffic to build/access subroutine argument lists.
	(Caches get some of this win.) (Non-window machines can have
	much of this win by changing their calling convention.)
Win#3:  more likely that a compiler can "target" (compute a value in the
	place where it is to be used, thus saving "move" instructions).
Win#4:  hardware is dense and regular. (Caches are too, but are more complex.)
Lose#1: more state to be saved/restored at task switches. (Caches can
	be just declared invalid, or have tags.)
Lose#2: more hardware that can be on the ALU critical path. (Longer R bus,
	deeper R decode ). 
Lose#3: the extra chip area could have been doing something else, like,
	being a cache, which you wanted anyway.
Lose#4: Some programs (particularly Unix's "printf" ) want their parameter
	list to be at an address.

I'm fond of win#3, because only windows give it, and because compilers don't
need great subtlety to pick up the win. 

There are some ways to ways to fix things up. For example, instead of a
call sliding  by (say) 8 registers, slide by a program-supplied distance.
The average slide might then be (say) 3. This economy helps lose#1, and
changes lose#2 in very implementation-specific ways. Another fixup is to
"dribble" the state out to memory as a background activity. It's more
complex, but if it uses spare memory cycles, then task switches get a
"free" win.

What ways have been used around lose#4 ?
-- 
	Don		lindsay@k.gp.cs.cmu.edu    CMU Computer Science