Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ptsfa!ihnp4!inuxc!pur-ee!uiucdcs!uiucdcsb!kenny
From: kenny@uiucdcsb.UUCP
Newsgroups: comp.arch
Subject: Re: An idea I'm kicking around
Message-ID: <165100007@uiucdcsb>
Date: Tue, 21-Apr-87 09:41:00 EST
Article-I.D.: uiucdcsb.165100007
Posted: Tue Apr 21 09:41:00 1987
Date-Received: Fri, 24-Apr-87 00:07:36 EST
References: <12884@watnot.UUCP>
Lines: 42
Nf-ID: #R:watnot.UUCP:12884:uiucdcsb:165100007:000:1906
Nf-From: uiucdcsb.cs.uiuc.edu!kenny    Apr 21 08:41:00 1987


/* Written 12:52 pm  Apr 20, 1987 by firth@sei.cmu.edu in uiucdcsb:comp.arch */
In article <12884@watnot.UUCP> watmath!watnot!ccplumb (Colin Plumb) writes:

>  I've been dreaming up A RISCy architecture in my spare time...
>What if JSR moved the return address into another register?

Then firth@sei.cmu.edu replies:
[arguments for storing return address for branches in register]
<Another issue is the right operand of the JSR.  Most machines seem to
<use the "effective address" as the operand, so whereas LOAD F will fetch
<the VALUE in F, JSR F will jump to the ADDRESS of F. I have never liked
<this.  You lose nothing, and gain a lot, by evaluating the operand in
<Rmode, so that JSR #F calls F, JSR F calls the thing pointed to by F,
<and JSR Reg calls the thing whose value has been computed in the register.
<But this is an eccentric view.

Not really; if you look at the PDP-11 architecture, it appears that a
jump is in fact a move-immediate to the program counter.  But why not
just treat the program counter as another register, that happens to be
used in auto-increment mode by the hardware?  The subroutine linkage
operations would expand to two-instruction pairs, with a RISC-y
flavor:

	Call			Return
	MOVE	PC, Rn		ADD	#<size of jump>, Rn
	MOVE	#<subr>, PC	MOVE	Rn, PC

If you have three-address operations, it's simpler:

	Call					Return
	ADD	#<size of jump>, PC, Rn		MOVE	Rn, PC
	MOVE	#<subr>, PC

It's probably worthwhile combining the operations in the hardware,
because procedure linkage is so expensive, *provided*, of course, that
the hardware designer can do it cheaply.  It's really nice, though,
being able to use the PC as a general register -- I can't think of
applications where I'd want to multiply or divide by it, but a
load-direct from memory is useful for branch tables and the like,
while having it available as an operand really cleans up
position-independent coding.