• MARK instruction

    From =?UTF-8?Q?Walter_F=2EJ=2E_M=C3=BCller?=@wfjm.andro@gmail.com to alt.sys.pdp11 on Mon Jul 18 03:33:47 2022
    From Newsgroup: alt.sys.pdp11

    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.
    --- Synchronet 3.21d-Linux NewsLink 1.2
  • From Johnny Billquist@bqt@softjar.se to alt.sys.pdp11 on Tue Jul 19 11:05:48 2022
    From Newsgroup: alt.sys.pdp11

    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
    --- Synchronet 3.21d-Linux NewsLink 1.2
  • From =?UTF-8?Q?Walter_F=2EJ=2E_M=C3=BCller?=@wfjm.andro@gmail.com to alt.sys.pdp11 on Wed Jul 20 03:32:46 2022
    From Newsgroup: alt.sys.pdp11

    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.
    --- Synchronet 3.21d-Linux NewsLink 1.2
  • From Jonathan Harston@jgh@mdfs.net to alt.sys.pdp11 on Wed Jul 20 06:42:54 2022
    From Newsgroup: alt.sys.pdp11

    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!

    --- Synchronet 3.21d-Linux NewsLink 1.2
  • From Johnny Billquist@bqt@softjar.se to alt.sys.pdp11 on Wed Jul 20 15:59:37 2022
    From Newsgroup: alt.sys.pdp11

    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
    --- Synchronet 3.21d-Linux NewsLink 1.2
  • From =?UTF-8?Q?Walter_F=2EJ=2E_M=C3=BCller?=@wfjm.andro@gmail.com to alt.sys.pdp11 on Wed Jul 20 08:39:28 2022
    From Newsgroup: alt.sys.pdp11

    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 :).
    --- Synchronet 3.21d-Linux NewsLink 1.2