Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!uw-june!uw-entropy!quick!srg
From: srg@quick.COM (Spencer Garrett)
Newsgroups: comp.arch
Subject: Re: register windows
Message-ID: <131@quick.COM>
Date: Mon, 5-Oct-87 03:07:41 EDT
Article-I.D.: quick.131
Posted: Mon Oct  5 03:07:41 1987
Date-Received: Thu, 8-Oct-87 01:33:45 EDT
References: <1242@k.gp.cs.cmu.edu>
Distribution: na
Organization: Quicksilver Engineering, Seattle
Lines: 18
Summary: fly in the ointment

In article <1242@k.gp.cs.cmu.edu>, lindsay@k.gp.cs.cmu.edu (Donald Lindsay) writes:
> Register windows interest me.
> 
> 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).
> 
> I'm fond of win#3, because only windows give it, and because compilers don't
> need great subtlety to pick up the win. 

Unfortunately, it's not so simple.  When you have procedure calls in
argument lists you have to tuck away all the arguments you've already
computed while you call the next procedure.  With a stack-based arg list,
you just compute the args in reverse order and let the stack grow to
include each new one in turn.  If your compiler is good about how
it does the tucking, it's probably still a net win, but it's tricky to
do.  Pyramid, for instance, often ends up pushing registers onto the
stack to preserve their values across procedure calls, thus circumventing
one of the main advantages of their architecture.