In an answer by user RichF, it is claimed that the previous-address-space moves were able to access 'all of memory' without memory management being enabled.

The instructions MFPI (move from previous instruction space), MFPD (… previous data space), MTPI (move to previous instruction space), MTPD (… previous data space) facilitate implementation of OS kernel services; user space and kernel space are usually non-overlapping so the kernel can't immediately see user space. Memory management generally uses the current-mode (kernel/super/user) field from the processor status (PSW) to determine which map to use; these instructions use the previous-mode field instead.

I've never really thought about what the previous-mode moves would do if the MMU was not enabled. The answer I linked to above says that the previous-mode bits from the PSW are used directly as the high-order 2 bits of the 18-bit bus address (the low 16 bits are provided via the usual operand).

I've poked around the manuals I have at home, and on bitsavers, but I can't see any mention of this usage. The instruction definitions all assume the MMU is enabled. E.g., for MFPD (from the 11/70 handbook, even though it says 11/45 in the text):

This instruction is provided in order to allow interaddress space communication when the PDP-11/45 is using the Memory Management unit.

The address of the source operand is determined in the current address space. That is, the address is determined using the SP and memory pages determined by PS<15:14>. The address itself is then used in the previous D space (as determined by PS<13:12> to get the source operand. This operand is then pushed on to the current R6 stack.

OH, I'm supposed to have an actual question? OK: does anyone have documentation or actual experience to say what these 4 instructions do when memory management is not enabled? Was this 'off-label' use model-specific?


3 Answers 3


Dave, I'm not sure how it worked on every PDP-family chip. What I can tell you for certain is that, on an LSI-11/73 and Q-Bus, the MFP? and MTP? instructions did allow random access to any word in the 18-bit address space. No MMU need be involved.

Description of MFPD from the PDP-11 Architecture Handbook (c) 1983:

Pushes a word onto the current R6 stack from an address in previous space determined by PS <13:12>. The source address is computed using the current registers and memory map. When MFPI is executed and both previous mode and current mode are User, the instruction functions as thought it were MFPD.

MTPD is similar but not exactly parallel:

This instruction pops a word off the current R6 stack determined by PS bits <15:14> and stores that word into an address in previous space as determined by PS bits <13:12>. The destination address is computed using the current registers and memory map.

I never thought about it before, but if the MMU were not active, the current memory map would be the flat, actual, contiguous 18-bit address bus. An MMU would likely allow kinds of fragmented mapping, but I didn't want that.


from memory, about 40 years ago: The OS was Forth, and I was programming in Forth and Forth's embedded assembler. I did not want to calculate a 15-bit HSI (Hue, Saturation, Intensity) to RGB (Red, Green, Blue) for every pixel on the fly. Instead, as the program started, it would load three, pre-calculated, static 64kb LUTs (R, G, and B). Then, as needed, the color transform would simply be direct look-ups using the same HSI index for the 3 pixel colors. IIRC, the color DAC received 8-bit values, so only the low-order byte was used for each component.

  • That seems to be the standard description from all the handbooks. The 'not exactly specified' part is the meaning of 'current .. memory map' when the map hardware is not enabled. The strange bit, to me, is that processor-mode bits would get used directly as address bits when the MMU usage is for map selection. Not that I'm refuting your actual experience, of course. I'll go look at the 11/73 description (a latter-day PDP-11 from my viewpoint!). Thanks. Sep 21, 2019 at 20:27
  • While I haven't found a description of what exactly happens when the MMU is off, Appendix B in this J-11 manual says, point number 38, that it's processor-dependent whether or not non-kernel modes, previous-space moves, and other things exist when the MMU is off. The J-11 (as in 11/73) has 'em; I'm more of an 11/40 man myself. Sep 21, 2019 at 23:22

I asked Bob Supnik (J-11 CPU project lead, SIMH creator) about this, and this is his response.

The answer is no. If the MMU is not operating, the MT/FPI/D instructions operate on physical addresses and are limited to 16bit addresses.

The PSW mode bits (in particular, previous mode) are operative for choosing which stack pointer is used if the operand specification is R6. So MTPI SP will store the operand popped from the stack in the stack pointer selected by PSW. The address calculation on the stack is purely physical, ie, 16 bits.

If the MMU is not enabled, programs can only see memory addresses 000000 - 157777 and the IO page. DMA devices can see (on the Unibus or the original Qbus) 18 bits of memory addresses or (on the Q22 bus or a Unibus system with an IO map) 22 bits of memory addresses.

That is in fact what I suspected; if the MMU is not enabled, then the mapping is 16 bits virtual = 16 bits physical. Using two bits taken from the PS as address bits makes no sense.

So we're at an impasse here. RichF recalls accessing beyond 64KB with the MMU off on an 11/73; Bob says the CPU doesn't work like that.

  • Find someone with a real PDP-11 and try it out?
    – dirkt
    Sep 22, 2019 at 19:04
  • Heh Heh, okay then, you can believe what you want. But I happen to know that of our 256 kbytes for our LSI-11/73 system, 64 kbytes was where Forth was home, and the other three 64 kbyte regions were red, green, and blue LUTs. I guess it's possible that the authors of the Forth activated the MMU at startup to provide flat memory access, but I never noticed a sign of an MMU being involved, and I never messed with it. I'm not even sure the 11-73 board had an MMU. It probably did, because the system could boot into either RT-11 or Forth, and RT-11 probably liked having the MMU.
    – RichF
    Sep 23, 2019 at 1:41
  • 1
    The PDP-11/73 is an outlier. It was designed specifically to stretch the amount of memory available to the PDP11. You could argue it has an MMU built in.
    – JeremyP
    Sep 23, 2019 at 8:52
  • The KDJ11-A (=CPU board, though the 11/73 actually used the -B variant) says the MMU is on the CPU board. It still needs to be enabled to access more than 16 bits of physical space, though. Sep 23, 2019 at 12:12
  • 1
    I regard Supnik's position as authoritative on this, and it certainly matches my own knowledge of the PDP-11. There's no reason for having a PDP-11 able to access more than 16 bits of memory without using the device that was added to the architecture to allow it to access to more than 16 bits of memory, and the posted description of how this might have worked makes it unlike to be an accident. But I'm reluctant to claim a bounty for accepting my own answer! Dec 14, 2019 at 18:09

tabduikov's bounty led me to take another look. I did some digging and found my old copy of the KDJ11-A CPU Module User's Guide © 1984 Digital Equipment Corporation.

Dave, I'm not sure how it worked on every PDP-family chip. What I can tell you for certain is that, on an LSI-11/73 and Q-Bus, the MFP? and MTP? instructions did allow random access to any word in the 18-bit address space. No MMU need be involved.

It seems my "certainty" was in error. 🥴 This book is for the board which was in our system. Its section 1.5, MEMORY MANAGEMENT, has 16 pages, several of which contain notes which I wrote in the book and several sections show highlighting in the same sloppy traces I would make. So, even though I do not remember, I made them.

Conclusion: I did use the system's memory management unit after all. I think I mapped a flat 18-bit space and did not mess with the MMU directly after that. With Forth being the system's OS, language, application, and development environment, there was no worry of something else redefining the memory map.

Also, I did not have three 32 kword LUTs, but three 16 kword LUTs. The video cabinet (this was before such a thing could fit on a board) used 14-bit IHS (Intencity, Hue, Saturation) with two separate bit planes for overlays. So mapping from an IHS value to its R, G, and B equivalents was only a 14-bit lookup. Since the M?PD instructions moved a word at a time, I probably doubled up each byte value so I could simply access the lower byte without having to decide whether to use the upper or lower one. Note this was important because every mapping (including raw physical) reserves the top 4 kwords for the CPU's I/O space. I could not have had simple 64 Kbyte look-ups even if I had wanted them.

I apologize to another-dave and his source Bob Supnik for insisting I was correct.

  • No apology is necessary; the discussion was still interesting! Dec 14, 2019 at 18:41
  • No worries, the bounty was set to spark further interest into the issue. I'm glad you are able to help to further analyse the issue
    – tabdiukov
    Dec 17, 2019 at 8:36
  • @tabdiukov Cool, my first bounty ever. Except ... I don't deserve it. I was wrong and another_dave was correct. He should get the bounty. Thanks, though.
    – RichF
    Dec 19, 2019 at 21:17
  • Nah, you started it all off in the previous question, so consider it your reward for creating an interesting topic to explore. Jan 26, 2020 at 3:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.