[net.unix-wizards] Curiosity

geacc022%timevx@lbl.arpa (02/23/85)

All right, you guys!  I've been watching this conversation fly by for
some weeks now, and I have one burning question to ask:

	What the #%$@ does the MARK instruction do??!?

			Gary Ansok
			GEACC022%TIMEVX%CITHEX @ LBL-G.ARPA
			GEA @ CALTECH.BITNET
			...ucbvax!cithep!timevx#geacc022

"All the world loves a straight man."

ron@BRL-TGR (Ron Natalie) (02/25/85)

MARK is part of a bozo subroutine instruction linkage that no one
uses.

You push it on the stack after all the parameters to a subroutine
and then call the subroutine.  When you return from the subroutine
rather that return to the called address you return to the MARK
instruction, which pops everything back of the stack and then
continues execution with the address that was pushed by the JSR.

What it really does (from the Processor Handbook) is:

sp <- pc + 2 + 2n
pc <- r5
r5 <- (sp)+

Great? Right.  A thousand and one uses.

henry@utzoo.UUCP (Henry Spencer) (02/25/85)

>	What the #%$@ does the MARK instruction do??!?

The fast answer is "nothing useful".  More specifically, it was an
attempt at making stack cleanup after procedure calls easier.  It was
so fearfully botched that nobody has ever found a real use for it.
In fact, it is difficult to understand how anyone would think it was
useful at all.  My personal guess is that it was intended to speed up
some bizarre interpretive implementation of some language.  (This sort
of thing is not unknown elsewhere; the reason why the System V IPC
stuff is such a kitchen-sink mix of different approaches is that it's
the union of the wishlists of several major AT&T internal projects.)
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry

john@x.UUCP (John Woods) (02/26/85)

> All right, you guys!  I've been watching this conversation fly by for
> some weeks now, and I have one burning question to ask:
> 	What the #%$@ does the MARK instruction do??!?

[Hoping no one else answers...]
MARK N (bit pattern 0064NN) does the following:

SP <- PC + 2 x NN
PC <- R5
R5 <- (SP) + NN	= number of parameters
		(This according to my Microcomputer Processor Handbook.
		 I think the + on the last line may be spurious)
		 
The way to use this instruction to facilitate function return is "obvious".
(and if you believe THAT, I have this bridge...:-)

Having never seen it used, I can't offer examples of how to use it (and
thinking about it makes my brain hurt!), but a hint: the MARK N instruction
goes somewhere in the stack frame, and you return directly to it, rather
than directly to the subroutine did the calling.

Just goes to show you what happens when you use microcode roms that are too
big :-)
-- 
John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101
...!decvax!frog!john, ...!mit-eddie!jfw, jfw%mit-ccc@MIT-XX.ARPA

Sorry, I don't feel deep right now.

john@x.UUCP (John Woods) (02/26/85)

Having gone home and gotten a USEFUL Processor Handbook (pdp11/45, 1973,
back when computers were REAL computers), I beg to correct and supplement
my MARK posting:

SP <- PC + 2xNN		NN = number of parameters
PC <- R5
R5 <- (SP)^		(The + wasn't spurious, the NN was; see 408@x)

TO USE THIS BEAST (oh my God, you mean you *can*?):

	; subroutine calling sequence:
	MOV	R5,-(SP)		; place old R5 on stack
	MOV	parm1,-(SP)		; place N parameters
	MOV	parm2,-(SP)		; on the stack to be used
	...				; for the subroutine's
	MOV	parmn,-(SP)		; nefarious purposes
	MOV	#MARKN,-(SP)		; place MARK N on the stack
					; of all places!
	MOV	SP,R5			; point R5 to that MARK instruction
	JSR	PC,SUBROUTINE

SUBROUTINE:
	;;;;;;;;;
	RTS	R5			; returns to MARK N, which pops
					; crud off the stack, then pops
					; R5 off the stack.  The return address
					; on the stack went briefly into
					; R5, and then straight into the PC.

Now, wasn't that simple?

Just remember, this is (nearly) useless with separate I/D spaces, so it
is interesting that the 11/45 handbook told me about it.

Now, does anyone want to start a roaring flame session about how the
information in DEC handbooks is a decaying exponential in time...:-?

-- 
John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101
...!decvax!frog!john, ...!mit-eddie!jfw, jfw%mit-ccc@MIT-XX.ARPA

Sorry, I don't feel deep right now.