Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site mips.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!harpo!decvax!decwrl!Glacier!mips!mash
From: mash@mips.UUCP (John Mashey)
Newsgroups: net.arch
Subject: Re: RISC
Message-ID: <142@mips.UUCP>
Date: Sun, 9-Jun-85 15:24:32 EDT
Article-I.D.: mips.142
Posted: Sun Jun  9 15:24:32 1985
Date-Received: Tue, 11-Jun-85 07:48:28 EDT
References: <639@vax2.fluke.UUCP> <2743@nsc.UUCP>
Organization: MIPS Computer Systems, Mountain View, CA
Lines: 21

Eric C. Brown ..!{decvax, ihnp4, seismo}!utah-cs!brownc writes:
> I would agree with you to a point:  the return address should be saved on
> a stack.  Jamming it into a register only means you blow an instruction
> inside the subroutine saving the old pc anyway.  (Recursion? recursion?
> all I want to do is call another routine inside the first...)

Not necessarily: 1) Leaf routines (i.e., those that make no further calls)
might not want to burn memory references for saving/restoring the register
when it need not be saved/restored at all.  2)  As usual, one must make
all sorts of design tradeoffs - simplifying something somewhere may
complexify something else.  In this case, one must carefully weigh the
usefullness of having subroutine call/return save/restore regs, versus
complexity of fault-handling and slowdown of basic cycle to allow for it,
especially in heavily pipelined designs.  This is not to say that
that mechanism is a bad idea, merely that the ramifications can surprise you
and must be taken into account.
-- 
-john mashey
UUCP: 	{decvax,ucbvax,ihnp4}!decwrl!mips!mash
DDD:  	415-960-1200
USPS: 	MIPS Computer Systems, 1330 Charleston Rd, Mtn View, CA 94043