On the PDP11/70, in the XXDP BKTCB0.BIC program I saw the following code:

012716 177777    mov #-1,(KSP)
006627           MTPI (PC)+

According to the comments in the source-code, this triggers a trap. (source code: http://www.bitsavers.org/pdf/dec/pdp11/microfiche/Diagnostic_Program_Listings/Listings/MD-11-DBKTC-B__KT11-D__MTPI-MFPI_WITH_MEM_MGT__EP-DBKTC-B-DL-A__APR_1977_gray.pdf page 27, line 1173 or see the screendump below).

Why it does so? If I understood it correctly, it pushes -1 on the stack. Then MTPI pulls it off the stack and then overwrites the word just behind MTPI itself. Yet in e.g. simh it continues at address 004646.

sourcecode fragment

1 Answer 1


It's a move to the I-space in the previous mode, in this case user mode.

From the processor handbook:

The address of the destination operand is determined in the current address space. MTPI then pops a word off the current stack and stores that word in the destination address in the previous mode's I space (bits 13, 12 of PS).

So, the virtual address of the destination is the instruction stream after the MTPI instruction. Presumably this address is not mapped in user mode, thus it cannot be written to in user space. Like any access to non-existent virtual addresses (when the KT11 is enabled), the access is aborted.

This is not specific to MTPI, etc.; it is general memory management. The only thing specific to MTPI, etc., is the use of the previous-mode bits in the PS, rather than the current-mode bits, to select the address map to be used.

Looking at the program initialization code, it is apparently setting the user address space up to have only one block in virtual page 4 and one block in virtual page 5. I suppose the kernel mapping to be virtual = physical, at least for the code pages, otherwise flipping the KT11 on and off would wreak havoc with execution.

So, the MTPI access to user space is intended to abort without writing -1 to the destination. An MMU abort may or may not result in a CPU trap.

The HLT after MTPI is skipped because PC has already been incremented before the abort. The second HLT is supposed to be skipped under program control.

The diagnostic has a mechanism to handle memory management traps. Prior to triggering the trap, the memory management trap vector (address 250, MMVEC) is set up with the address to jump to when the trap occurs. In this case it is label KU11A, address 004646. So, if we get a memory management trap, we pass over the second HLT.

At this point it is important to note that the diagnostic describes itself as an 11/40 diagnostic. 11/70 and 11/40 memory management are different. In particular, the 11/40 cannot disable traps for MMU aborts; the 11/70 requires such traps to be explicitly enabled (by setting bit 9 in SR0; it is not set).

So: on an 11/40, the MTPI instruction aborts, we take an MMU trap to 250, and jump to 004646. On an 11/70, the MTPI instruction aborts, there is no MMU trap, so we execute the HLT at 004644.

Are you saying that simh jumps to 004646? What CPU does simh think it is emulating?

The 11/40 MMU is the 'KT11-D'. I don't recall whether the MMU in the 11/70 was known by a KT11 designator (it was not optional).

The 11/45 uses the 'KT11-C', and since the 11/70 has similar MMU functionality to the 11/45, except for 22-bit physical addressing, I assume the 11/45 MTPI diagnostics here will be broadly applicable to the 11/70. I could not see anything specific to the 11/70 for MTPI.

  • Thank you for the explanation. What I'm looking for though, is the reason that the trap occurs. And if that reason is specific for MTPI & friends (MTPD, MFTI, etc) Commented Apr 7 at 8:13
  • 1
    I misread the code before; answer updated. My take is that there is supposed to be an MMU abort trap taken on an 11/40, but there is no trap on an 11/70, so the second HLT is executed.
    – dave
    Commented Apr 7 at 13:19
  • Are you saying that the MMU trap does occur, such that we execute at 004646, on an actual 11/70?
    – dave
    Commented Apr 7 at 13:38
  • 2
    Oh, you're writing an 11/70 emulator (by reference to previous posts). You probably need to find the correct diagnostic for the 11/70 MMU.
    – dave
    Commented Apr 7 at 14:45
  • yes, it does indeed. I verified that by "e mmr0" which returns "000340" so with bit 0 set to 0. And you're indeed right about BKTCB0 being for 11/40. I was hoping it would be compatible enough :-) Otoh with simh it runs as it is expected... Commented Apr 7 at 19:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .