[TUHS] PDP-11 MARK (was: Early Unix function calls: expensive?)

[TUHS] PDP-11 MARK (was: Early Unix function calls: expensive?)

[Johnny Billquist]

On 2016-01-06 01:54, Dave Horsfall <dave at horsfall.org> wrote:
>  On Mon, 4 Jan 2016, Ronald Natalie wrote:
>> >Just never figured out how to make good use of the MARK instruction on
>> >the PDP-11.
> RSX-11 probably used it, though, as could've RSTS...

Nope. Nothing in RSX uses it. As others said, probably nothing anywhere 
used it.
And, as I pointed out, if you use MARK, then you cannot really use split 
I/D-space, since the stack (data) needs to be in instruction space.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[TUHS] PDP-11 MARK (was: Early Unix function calls: expensive?)

[Johnny Billquist]

On 2016-01-05 18:43, Ronald Natalie<ron at ronnatalie.com> wrote:
>
> Just never figured out how to make good use of the MARK instruction on the PDP-11.

Not surprising. As others noted, few ever did. And apparently none 
responding actually do either.

It *is* a stupid instruction in many ways. And it's not for multiple 
returns either.

It's an odd way of handling stack cleanup without a frame pointer.

It's extremely bad, since it actually requires the stack to be in 
instruction space. And yes, you are expected to execute on the stack.

The idea is that the caller pushes arguments on the stack, but the 
cleanup of the stack is implicitly done in the subroutine itself, and at 
the same time you get an argument pointer.

Example:

Calling:

     MOV R5,-(SP)       ; Save old R5
     MOV <argn>,-(SP)
     MOV <argn-1>,-(SP)
     .
     MOV <arg1>,-(SP)
     MOV #MARKN,-(SP)   ; Where the N in MARK N is the number of 
arguments you just pushed.
     MOV SP,R5
     JSR PC,SUB
     .
     .

In the subroutine you then have the arguments available relative to R5. 
So that arg1 is available at 2(R5) for example.

SUB: .
      .
      .
      RTS  R5


There is a lot going on at this point. The trick is to note that the 
code does an RTS R5 to return. If people remember what happens at that 
point, PC gets loaded with R5, while R5 gets loaded with the PC that we 
actually would like to return to (since that's what is at the top of the 
stack).
And R5 is pointing into the stack, at the MARK instruction, so execution 
continues with actually performing the MARK.
MARK, in turn, will case SP <- PC + 2*N, thus restoring the stack 
pointer to point to the place where the original R5 was stored.
Next, it does a PC <- R5, so that we now have the PC point to where we 
actually want to return.
Next it does a R5 <- (SP)+, meaning we actually restored the original R5.

And so we have cleaned up the stack, preserved R5, and returned to the 
caller again.

Also notice that the subroutine could have pushed any amount of data on 
the stack before the return, and I suspect the idea was that the process 
would not have needed to clean that up either. However, that fails, 
since the RTS needs the return address at the top. But you can 
essentially solve that by pushing -2(R5) before returning.

Ugly, isn't it? :-)

	Johnny

[TUHS] PDP-11 MARK (was: Early Unix function calls: expensive?)

[Greg 'groggy' Lehey]

On Tuesday,  5 January 2016 at 21:35:47 +0100, Johnny Billquist wrote:
> On 2016-01-05 18:43, Ronald Natalie<ron at ronnatalie.com> wrote:
>>
>> Just never figured out how to make good use of the MARK instruction on the PDP-11.
>
> Not surprising. As others noted, few ever did. And apparently none
> responding actually do either.
>
> It *is* a stupid instruction in many ways. And it's not for multiple
> returns either.
>
> It's an odd way of handling stack cleanup without a frame pointer.

Thanks for the (omitted) explanation.  At first sight, the instruction
almost seems to make sense for functions with a variable number of
parameters, but of course there are simpler ways to do it.

I wonder if this is a case of "it sounded like a good idea at the
time" (when the instruction set was being designed), and it took a
while for people to realize that it wasn't of any use.

I recall a similar issue with the Siemens 306, their first stack-based
machine, round about 1975.  They had function call and return
instructions which manipulated the stack pointer, but it seemed that
nobody used them: they didn't work.  From memory, the call instruction
incremented the stack pointer and stored PC.  The return call
instruction decemented the stack pointer and loaded PC--from the wrong
location.

I never used the 306 myself, but I often wondered if they modified one
of the instructions to DTRT.

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160106/691b97e6/attachment.sig>