Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bbn!rochester!cornell!uw-beaver!mit-eddie!rutgers!sri-spam!mordor!lll-lcc!pyramid!voder!apple!bcase
From: bcase@apple.UUCP (Brian Case)
Newsgroups: comp.arch
Subject: Re: register windows
Message-ID: <6432@apple.UUCP>
Date: Wed, 7-Oct-87 00:18:53 EDT
Article-I.D.: apple.6432
Posted: Wed Oct  7 00:18:53 1987
Date-Received: Sat, 10-Oct-87 07:14:38 EDT
References: <1242@k.gp.cs.cmu.edu> <131@quick.COM>
Reply-To: bcase@apple.UUCP (Brian Case)
Distribution: na
Organization: Apple Computer Inc., Cupertino, USA
Lines: 20

In article <131@quick.COM> srg@quick.COM (Spencer Garrett) writes:
>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.

Well, first of all, I doubt that the registers are pushed onto the stack
*often.*  I can see it happening in some cases, but this doesn't sound
like the common case.

Further, C doesn't specify the order of evaluation of arguments; I used
this to advantage in the compiler a RISC compiler that I wrote:  the
compiler analyzes the parse tree so that inner-most calls (if any,
typically there are none) are done first.  This is neither hard nor
time-consuming.