Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!necntc!ames!amdcad!bcase
From: bcase@amdcad.AMD.COM (Brian Case)
Newsgroups: comp.arch
Subject: Re: An idea I'm kicking around
Message-ID: <16223@amdcad.AMD.COM>
Date: Fri, 17-Apr-87 18:03:02 EST
Article-I.D.: amdcad.16223
Posted: Fri Apr 17 18:03:02 1987
Date-Received: Sun, 19-Apr-87 13:03:56 EST
References: <12884@watnot.UUCP> <137@auvax.UUCP>
Reply-To: bcase@amdcad.UUCP (Brian Case)
Distribution: comp
Organization: Advanced Micro Devices, Inc., Sunnyvale, Ca.
Lines: 28

In article <137@auvax.UUCP> rwa@auvax.UUCP (Ross Alexander) writes:
>In article <12884@watnot.UUCP>, ccplumb@watnot.UUCP writes:
>> What if JSR moved the return address into another register?
>
>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.
>
>Anyway, I think life is simpler with a conventional stack and
>JSR/RTS instructions.

Just as a data point, the Am29000 call (and call-indirect, the only
two "call" instructions) instruction has an 8-bit destination field
for specifying the general register into which the return address is
placed.  This is good in that it allows the user to define the most
appropriate procedure-call mechanism for his particular environment.
(Actually, not many people will design unique procedure-call mechanisms,
but the flexibility is important for some special applications.)

A conventional stack and jsr/rts instruction set is great as long as
it does what you want.  As soon as the match isn't right, the trouble
begins:  you're stuck with what the machine gives you.  The good ol'
calls instruction on the VAX is nice but it is too slow because it
does too much.

    bcase