Was it really possible for a PDP-11 to address more than 32K words memory without an MMU?

Question

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?

Answer 1

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.

---

background

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.

Answer 2

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.

Answer 3

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.