Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!tmsoft!mason
From: mason@tmsoft.UUCP
Newsgroups: comp.arch
Subject: Re: An idea I'm kicking around
Message-ID: <136@tmsoft.UUCP>
Date: Wed, 15-Apr-87 21:24:00 EST
Article-I.D.: tmsoft.136
Posted: Wed Apr 15 21:24:00 1987
Date-Received: Thu, 16-Apr-87 02:05:58 EST
References: <12884@watnot.UUCP>
Reply-To: mason@tmsoft.UUCP (Dave Mason)
Distribution: comp
Organization: TM Software Associates, Toronto
Lines: 28

In article <12884@watnot.UUCP> watmath!watnot!ccplumb (Colin Plumb) writes:
>
>  I've been dreaming up A RISCy architecture in my spare time, and in the
>course of trying to minimize the number of memory accesses per instruction,
>I ran into the problem of handling JSR's.  A branch already requires an
>extra fetch to fill the pipeline, and adding a stack push would make things
>ugly.
>
>What if JSR moved the return address into another register?  If the register

I'm not sure if this is currently in use by anyone, but I've also thought of
it in a RISCy stack machine (no, I don't think a conflict in terms) that I've
been doing thought experiments with.

I don't think you want the generality of being able to save the return in
ANY register (like you can do with the PDP11 (although with a stack push)).
I foresaw 2 different save places.  This would allow the compiler to not
have to save the return register if the routine didn't call anything else
(with 2 return registers, compiler generated calls (like structure copy)
could use the second call/return pair)

This may also be advantageous for the stack machine I was thinking of
because the result on the TOS doesn't interfere with the return address
(you can get some of the advantage of a data stack+return stack with only one
real stack).
-- 
	../Dave Mason,	TM Software Associates	(Compilers & System Consulting)
	..!{utzoo seismo!mnetor utcsri utgpu lsuc}!tmsoft!mason