🚀 go-pugleaf

/* 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.