Skip to content
Tech HistoryDeep Dive Published Updated 5 min readViews unavailable

TENEX: The BBN Pager and Interactive Time-Sharing on the PDP-10

Trace TENEX's BBN pager, per-process virtual memory, page-fault path, and terminal-first Executive without confusing the system with later TOPS-20.

TENEX was a time-sharing operating system built at Bolt Beranek and Newman (BBN) for Digital Equipment Corporation’s PDP-10. Its defining move was not replacing the host processor with a wholly new machine. BBN placed a paging device between the processor and core memory, then organized the operating system around protected virtual address spaces, multiple processes, an integrated file and I/O model, and a responsive Executive. That combination made TENEX a particularly clear example of system architecture adapting a commercial computer to interactive, shared use.

The central source for this account is BBN Report 2180, dated 15 August 1971, by Daniel G. Bobrow, Jerry D. Burchfiel, Daniel L. Murphy, and Raymond S. Tomlinson. The report describes the design and implementation, not every later TENEX release. The examples below explain its documented address translation model; they are not a claim that a modern workstation can reproduce the historical machine’s timing or behavior.

Keep the PDP-10 and the BBN pager distinct

The PDP-10 processor supplied the instruction set and its word-addressed memory references. The BBN pager handled translation and protection at the memory interface. The TENEX authors describe the pager as an interface between the processor and the memory bus, with separate mapping for user and monitor address spaces. Hardware changes were deliberately constrained: the paper says the design had to permit standard DEC time-sharing software and diagnostics to run, and that the basic address computation was not to be changed.

That division matters when describing the machine. TENEX was not a software-only simulation of virtual memory, but neither was it a replacement CPU. The additional paging hardware let the operating system present processes with virtual memory while mediating access to physical core. The system paper frames this as a design for a multiprocess virtual machine with protection and sharing, not as a feature of every unmodified PDP-10 configuration.

A page was 512 PDP-10 words

The paper specifies 512-word pages. PDP-10 word addresses were 18 bits in the described arrangement, so the high nine address bits selected a page and the low nine bits selected a word within that page. The pager compared the high-order address and the requested access type (read, write, or execute) against associative registers holding recent translations. The page table in core memory remained the backing source for those translations.

For a small arithmetic illustration, divide a decimal virtual word address of 12,345 by 512. It falls in virtual page 24 at word offset 57. The low nine bits preserve the offset; the page mapping determines which physical page, if any, supplies that word. This calculation is explanatory rather than a literal octal command or a captured TENEX trace. The important architectural separation is between the virtual page number and the offset inside that page.

TENEX page-table entries could describe private mappings and shared mappings. A private entry could point to physical core; a shared pointer referred through a system table to shared-page information. The pager’s associative registers accelerated recent translations, while page tables described the process’s virtual memory. This is a hardware-assisted translation path with operating-system-managed structures, not a modern CPU’s multi-level page-table format transplanted backward onto a PDP-10.

A fault was a controlled transfer to the monitor

The BBN paper lists several cases the pager could not complete directly: a page was not resident in core, the requested access was protected, or the page did not exist. Those conditions caused a page-fault trap. The monitor could then decide what the mapping meant and what work was needed before the process could continue. A missing page could require storage I/O; an access violation or nonexistent mapping could instead be an error. “Page fault” therefore names the hardware-to-monitor boundary, not a guarantee that every fault is a harmless disk read.

The paper’s account of the page table also shows why sharing was an explicit system capability. A process could refer to a shared page through a system-maintained mapping, while the pager still checked the access type. Mapping and protection were connected parts of the virtual-memory mechanism; sharing did not mean that every process received unrestricted access to the same physical word.

Terminal interaction was part of the operating-system design

The authors’ design goals include a command-language Executive, direct access to common system functions, extensive interrupt capability, and interactive terminal behavior. That interface belongs to the operating system’s user-facing design, alongside paging and file management, rather than being an unrelated shell layered over a conventional batch system.

It is useful to compare this with CTSS and Multics without collapsing them into one lineage. CTSS is an earlier time-sharing system with its own command and scheduling model; Multics explored a different protected, segmented architecture. TENEX’s BBN pager and PDP-10 implementation form their own engineering response. The sources establish that the TENEX designers knew and evaluated earlier systems; they do not justify saying that TENEX invented virtual memory or that it was simply a precursor renamed as TOPS-20.

What the design made possible, and what it did not

TENEX joined hardware translation, monitor-managed page tables, shared mappings, and an interactive Executive into a coherent time-sharing system. It illustrates how a specialized memory device could expand the operating-system model of an existing processor while constraining changes to the machine. The historical evidence is strongest when the paper’s design goals and mechanisms are read directly, rather than inferred from later systems with similar names.

The limits are equally important. A paper describing TENEX’s design does not show that every installation used identical hardware or software revisions. A 1973 Executive manual documents a particular Executive version, not all TENEX command behavior across the system’s lifetime. The BBN report alone does not establish the details or release history of DEC’s later TOPS-20; use TOPS-20 primary manuals or DEC documentation for that comparison. Keep author, implementation, hardware, and later product history separate.

Related:

Sources:

Comments