11

This question was inspired by an older question about the MARK instruction which recently bubbled up to the top of the active pile.

The VAX-11/780 and several follow-on VAXen implemented a PDP-11 compatibility mode, which supported an environment equivalent to the user mode of a mid-range PDP-11. One instruction that was not implemented, however, was the MARK instruction (see Table 3, page 10-4 - page 470 of the PDF, in the VAX System Reference manual).

The reason for this omission is unclear to me. Other omitted instructions are either privileged instructions (not applicable to the compatibility mode environment), or floating-point instructions where the entire set was omitted.

Thus: why did the VAX compatibility mode not implement the MARK instruction? Was it simply "nothing important has used it"?

As a PDP-11 programmer, I never found a reason to use MARK. But I'm assuming this has some factual answer based in how the instruction would work.

Leo B.
  • 19,082
  • 5
  • 49
  • 141
dave
  • 35,301
  • 3
  • 80
  • 160

2 Answers2

10

A valid reason is: why bother implementing something in hardware if it is very rare (perhaps only appearing in a bunch of very old executables compiled from Fortran or Pascal), and can be implemented very cheaply in software?

Out of the "later additions" to the instruction set, 4 out of 6 (SOB, XOR, SXT, RTT) are implemented directly as quite common, and the remaining 2 (MARK, SPL) are emulated.

As soon as there is a software instruction decoder for the FIS/FP11 instructions, the incremental cost to implement the functionality of MARK is negligible.

TonyM
  • 3,704
  • 1
  • 19
  • 31
Leo B.
  • 19,082
  • 5
  • 49
  • 141
  • Well, the entre instruction set is implemented in software - or at least, firmware. Unless that one last instruction would overflow the control ROM, it seems odd to omit just one. But you bring up an interesting point: what did VAX mode (in particular the AME, Application Migration Executive) do when it got a trap on MARK execution from compatibility mode? – dave Jan 25 '24 at 03:54
  • @dave Not just one, but two (out of the 6 additions to the instruction set for PDP-11/45) - MARK and SPL. Implementing MARK is quite trivial: as it does not have any addressing modes, it only takes a few instructions to perform the necessary adjustment of the stack and of the registers before returning from the interrupt. – Leo B. Jan 25 '24 at 05:33
  • 1
    SPL is part of the privileged architecture which is entirely omitted. It was a short-lived instruction: only 3 PDP-11 modes (44, 45, 70) implemented it. MARK is more interesting: it was implemented in the -11 to facilitate subroutine exit, so if it were useful at all, having it emulated via a trap to VAX mode seems to take away any advantage MARK gave you. – dave Jan 25 '24 at 09:46
  • well we previously established that it was an uncommon instruction to have - so you have an uncommon instruction in a compatibiilty mode - and if it was mainly used for FORTRAN, IIRC, well, Digital might very well have expected you to port those programs to native VAX using their very nice VAX FORTRAN compiler. – davidbak Jan 25 '24 at 16:33
  • @daveSPL was not a privileged instruction (see https://gunkies.org/wiki/PDP-11_architecture#Virtualization). As explained in https://retrocomputing.stackexchange.com/a/7057/4025 using MARK provided no advantage at all. – Leo B. Jan 25 '24 at 18:35
  • 1
    SPL was part of the privileged architecture in the sense that it did nothing in user mode; same as RESET. Which is to say, it only has any use for kernel-mode code, which is not supported by VAX compatibility mode. – dave Jan 25 '24 at 23:30
  • 1
    @dave That's exactly the point. The instructions like SPL or RESET which were no-ops in user mode but could have appeared there for some reason were trapped, because apparently the incremental cost of handling them in software was less than handling them in hardware. MARK is effectively the same: almost as unlikely to appear in user programs as SPL or RESET, and almost as trivial to support. – Leo B. Jan 25 '24 at 23:59
  • Perhaps there was an advantage to be gained by having the exit instruction trap to the sw emulator. This would allow a debugger in the emulator to execute only a subroutine, and to regain control when the subroutine exited. Just speculating. – Walter Mitty Jan 28 '24 at 11:53
  • I am leaning to accepting this answer, though I find it unsatisfying if true. Me, I would implement MARK even if 'nothing uses it', because the rest of the 11/45 additions were implemented. – dave Feb 01 '24 at 00:02
  • @dave Unless your manager would tell you to concentrate on more important projects :) – Leo B. Feb 01 '24 at 00:14
  • My manager trusts me to decide where to spend my time :-) – dave Feb 01 '24 at 00:30
  • It'd be interesting to see whether MARK was in fact interpreted in the VAX-mode code (the RSX Application Migration Executive, or AME) or whether the AME just treated it as any other illegal inst op. Alas, I have not been able to find any AME listings online. – dave Feb 03 '24 at 13:34
2

One plausible explanation is the MARK instruction was not implemented on all PDP-11 processors therefore a architectual design decision was made not to implement the MARK instruction. This is incorrect as other instructions that were not implemented on all PDP-11 family members were implemented in VAX-11 compatibility mode. There were variations in the Instruction Set of the different PDP-11 family members.

An early reference is: PDP-11/45 Processor Handbook Chapter 1 Introduction, Section 1-1 The PDP-11 Family, Page 1:

The major characteristics of PDP-ll family computers are summarized in
Table 1-1 at the end of this chapter.

Page 7, Table 1-1 PDP-11 Family Computers, Instruction Set:

PDP-11/20 Basic Set
PDP-11/05 Basic Set
PDP-11/45 Basic Set and: MUL, ... Mark, ... MFPX

It should be noted that the MARK instruction was not implemented on the PDP-11/04.

Reference is: VAX-11 Architecture Reference Manual, Chapter 10 PDP-11 Compatibility Mode, Section 10.1 Introduction, Page 10-1:

This specification is based on the behaviour of all PDP-11 implementations. Compatibility mode behaviour is defined UNPREDICTABLE where there is a difference between any two implementations.

Only on the surface does this appear to provide a plausible answer but it is shown that it is an incorrect answer. Just be aware that I have no knowledge of the design process that went into the VAX-11/780 hardware.

Just to complete this answer...

Table 10.2 lists the trap instructions that cause the machine to fault in VAX mode, where either the complete trap may be serviced, or where the instruction may be simulated.

Table 10.2
Compatibility Mode Trap Instructionns
Opcode Mnemonic
(octal)
000003        BPT
000004        IOT
104000-104377 EMT
104400-104777 TRAP

The instructions in Table 10.3 and all other opcodes not listed in Tables 10.1 or 10.2 are considered reserved instructions in compatibility mode, and fault to VAX mode. See Section 10.

Table 10.
Compatibility Mode Reserved Instructionns
Opcode Mnemonic
(octal)
000000        HALT
000001        WAIT
000005        RESET
000007        MFPT
00023N        SPL
0064NN        MARK
0070DD        CSM
07500R        FADD--FIS
07501R        FSUB--FIS
07502R        FMUL--FIS
07503R        FDIV--FIS
076XXX        Extended Instructions
1064SS        MTPS
1067DD        MFPS
17XXXX        FP11 Floating Point

Note that no floating point instructions are included in compatibility mode.

PDP11
  • 718
  • 2
  • 12
  • Yes, different 11s had different instruction sets, but the overall direction (with some oddities like EAE and FIS on the way) was that the instruction set was expanded, and that implementations from that point on implemented the expanded set. Once MARK appeared, the only processors before VAX that omitted it were the low-end 11/05 and 11/04 (and they also omitted others in the same group, which the VAX does not). – dave Jan 31 '24 at 00:05
  • 1
    The note on page 10-1 refers to two inconsistent implementations of an instruction, as discussed, for example, in https://retrocomputing.stackexchange.com/a/4665/4025 rather than a present and an absent implementation. Neither SOB nor XOR nor MUL were implemented in all processors, yet they were implemented in the compatibility mode. – Leo B. Jan 31 '24 at 01:29
  • Maybe the best table of implementation differences is in Appendix D of the 11/94 User and Maintenance Guide. It's a bit tricky to read, though ("which column is that X actually in?"). I've printed out a copy and the drawn a grid on the paper. – dave Jan 31 '24 at 23:59
  • I maintained VAX-11/780 systems down to chip level and 80s home PC was an 11/750. Knew the instruction set differences but not the why of the MARK instruction. Also is the issue of the PC modified by the contents of R5 that I didn't cover in my answer. I should have have explained the impact of the PC address modification. Used the 11/45 table as that was the first system to implement the MARK instruction. All this is why I waved the very big flag that this appears to be a plausible but it is highly likely an incorrect answer. I have no knowledge why the MARK instruction was not implemented. – PDP11 Feb 01 '24 at 03:22
  • I retyped the 11/94 'instruction differences' appendix here, for our future reference needs. – dave Feb 03 '24 at 15:21