Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!mit-eddie!uw-beaver!ubc-vision!alberta!auvax!rwa
From: rwa@auvax.UUCP (Ross Alexander)
Newsgroups: comp.arch
Subject: Re: An idea I'm kicking around
Message-ID: <137@auvax.UUCP>
Date: Thu, 16-Apr-87 17:03:48 EST
Article-I.D.: auvax.137
Posted: Thu Apr 16 17:03:48 1987
Date-Received: Sun, 19-Apr-87 10:44:52 EST
References: <12884@watnot.UUCP>
Distribution: comp
Organization: Athabasca U., Alberta, Canada
Lines: 27
Summary: already invented, I'm afraid

In article <12884@watnot.UUCP>, ccplumb@watnot.UUCP writes:
>   I've been dreaming up A RISCy architecture in my spare time, and [...]
> I ran into the problem of handling JSR's.
> [ ... ]
> What if JSR moved the return address into another register?
> 	-Colin Plumb (watmath!watnot!ccplumb)

As all old Waterloo MFCF hackers know ( :-) please!  ) that's the
way that Honeywell 6000's do (did?)  things - the JSR analogue
was an instruction called Transfer-Set-indeX (tsx) which jumped
and dropped the return address out into an index register of
your choice.  So if you called subr A via 'tsx 1,a' and A called
B via 'tsx 2,b' then the returns would be 'tra 0,2' and 'tra
0,1' in that order without any stack operations.  The fly was
that there were only 8 index registers, so one ended up using
one (the B compiler used index reg 7 (?)) to act as a stack
pointer, and doing loads and stores to fake pushing and poping
the return addresses.  Grotty.

Of course, in hand written assembler (William Ince's APL
interpreter comes to mind) this trick worked very well.  But I
wouldn't care to maintain that code.  

Anyway, I think life is simpler with a conventional stack and
JSR/RTS instructions.

...!alberta!auvax!aubade!rwa  Ross Alexander, Athabasca University