MARK instruction

[Walter F.J. Müller]

I'm reviewing and updating the verification suite for my w11 FPGA project. And stumbled again over the MARK instruction. This instruction is as ugly as it is useless (will not work with I/D space enabled). I really wonder why it was added to the instruction set at all. MARK adds nothing which couldn't be done with the basic instruction set. Does anybody know why MARK was added and whether it was ever used by DEC ? Just for curiosity.

[Johnny Billquist]

On 2022-07-18 12:33, Walter F.J. Müller wrote:
> I'm reviewing and updating the verification suite for my w11 FPGA project. And stumbled again over the MARK instruction. This instruction is as ugly as it is useless (will not work with I/D space enabled). I really wonder why it was added to the instruction set at all. MARK adds nothing which couldn't be done with the basic instruction set. Does anybody know why MARK was added and whether it was ever used by DEC ? Just for curiosity.

I guess you know the story/speculation that it was added (among some
other things) to enable DEC to extend some patent or whatever, to
protect the PDP-11 from being cloned for a while longer?

Apart from that, one could of course speculate that it was an attempt at
making function call return cleanup automated in a "nice" way. But as
you observe, the MARK instruction is as ugle as it is useless. I don't
know of any software that ever used it.

It is not that it won't work with I/D space, though. It's just that the
stack needs to be mapped in both I and D space for it to work. The rest
can still be split. But of course, having the stack non-executable is
actually a good thing, which other architectures have realized more
recently... ;)

Johnny

[Walter F.J. Müller]

On Tuesday, July 19, 2022 at 11:05:50 AM UTC+2, Johnny Billquist wrote:
> I guess you know the story/speculation that it was added (among some
> other things) to enable DEC to extend some patent or whatever, to
> protect the PDP-11 from being cloned for a while longer?

No, I didn't know about that story/speculation.Do you have a URL to a source where this is discussed ?

> Apart from that, one could of course speculate that it was an attempt at
> making function call return cleanup automated in a "nice" way. But as
> you observe, the MARK instruction is as ugle as it is useless. I don't
> know of any software that ever used it.

The MARK is pushed by the caller to the stack. The caller could do an "ADD #2*NPAR, SP" as well.
I really can't come up with a single argument in favor of this instruction.
So as you said, the deeper reason is most likely non-technical.

[Jonathan Harston]

> I really can't come up with a single argument in favor of this instruction.

It's so fiddly I still, after almost 20 years, haven't added it to my emulator,
and nothing's fallen over so far!

[Johnny Billquist]

On 2022-07-20 12:32, Walter F.J. Müller wrote:
> On Tuesday, July 19, 2022 at 11:05:50 AM UTC+2, Johnny Billquist wrote:
>> I guess you know the story/speculation that it was added (among some
>> other things) to enable DEC to extend some patent or whatever, to
>> protect the PDP-11 from being cloned for a while longer?
>
> No, I didn't know about that story/speculation.Do you have a URL to a source where this is discussed ?

That could require some digging. I might try to find references when I
have some time...

>> Apart from that, one could of course speculate that it was an attempt at
>> making function call return cleanup automated in a "nice" way. But as
>> you observe, the MARK instruction is as ugle as it is useless. I don't
>> know of any software that ever used it.
>
> The MARK is pushed by the caller to the stack. The caller could do an "ADD #2*NPAR, SP" as well.
> I really can't come up with a single argument in favor of this instruction.
> So as you said, the deeper reason is most likely non-technical.

Um. No. MARK is about cleanup, not making space on the stack. Not sure
if you've read the full explanation of the instruction and how it was/is
supposed to be used. But here is an example (from a manual):

Caller does:

MOV R5,-(SP) ; Save old R5
MOV P1,-(SP) ; Save N parameters on stack
MOV P2,-(SP) ; .
. ; .
MOV PN,-(SP) ; .
MOV #MARKN,-(SP) ; Push MARK N on stack.
MOV SP,R5 ; Setup R5 as argument pointer
JSR PC,SUB ; Call subroutine


at this point, the stack looks as follows:

: Old R5
: P1
: P2
: .
: .
: PN
: MARK N
: Old PC


The subroutine then do whatever it wants. At the end of the subroutine,
the subroutine does

RTS R5

Note that different registers are used for the JSR and the RTS here!

And what happens then is that R5 gets copied to PC, which means the PC
now points to the MARK instruction, while R5 gets the address of "Old
PC" (this is what RTS does). Next the CPU will now execute the MARK
instruction, which will adjust the SP to point at "Old R5". PC gets
loaded with R5, which means PC now contains "Old PC", and finally the
top of the stack gets popped and placed in R5, meaning R5 contains "Old
R5". Stack is back where it started, all arguments in the call were
cleaned out, and all is back to proper and the call have been completed.
The called routine does not need to know how many arguments were placed
on the stack, and will work correctly if called with different number of
arguments, while the caller also do not have to do the cleaning.
In addition, you do get R5 setup as the argument pointer, with a
correctly formatted argument block (which says the low byte where R5
points to should tell how many arguments you have, and the high byte
should be ignored, and all the following values after that, which R5
points to, are the actual arguments).
The R5 argument pointer convention are used by lots of compilers and
libraries on the PDP-11.

And they would continue working without problems if the caller used MARK
as well. But, as noted, it requires that you have the stack in I-space,
and doing the setup before the call.

Johnny

[Walter F.J. Müller]

On Wednesday, July 20, 2022 at 3:59:39 PM UTC+2, Johnny Billquist wrote:
> That could require some digging. I might try to find references when I have some time...

Thanks, but don't loose time on that.

> Um. No. MARK is about cleanup, not making space on the stack. Not sure
> if you've read the full explanation of the instruction and how it was/is
> supposed to be used. But here is an example (from a manual):

Sure I read the manual, after all I implemented this instruction in the w11 FPGA implementation.
I had to add 4 states in the main sequencer just for MARK, see
https://github.com/wfjm/w11/blob/c14eddd0/rtl/w11a/pdp11_sequencer.vhd#L1692
And I use the processor handbook example as test case :).