THE EVOLUTION OF THE PDP-11 407

shared data segments) and instructions (subroutine addresses, for example). Names seen by an individual program are part of a larger name space - that managed by an operating system and its associated language translators and object-time systems. An operating system provides program sharing and protection among pro grams using the name space of the architecture.

As the PDP-11/70 design progressed, it was realized that for some large applications there would soon be a bad mismatch between the 64- Kbyte name space and 4-Mbyte memory space. Two trends could be clearly seen: (1) minicomputer users would be processing large arrays of data, particularly in FORTRAN programs (only 8,096 double precision floating- point numbers are needed to fill a 16-bit name space), and (2) applications programs were growing rapidly in size, particularly large COBOL programs. Moreover, anticipated memory price declines made the problem worse. The need for a 32-bit integer data-type was felt, but this was far less important than the need for 32- bit addressing of a name space.

Thus, in 1974, architectural work began on extending the virtual address space of the PDP-11. Several proposals were made. The principal goal was compatibility with the PDP-11. In the final proposed architecture each of the eight general registers was extended to 32 bits. The addressing modes (hence, address arithmetic) inherent in the PDP-l1 allowed this to be a natural, easy extension.

The design of the structure to be placed on a 32-bit virtual address presented the most difficulty. The most PDP-l1 compatible structure would view a 32-bit address as 216 16-bit PDP 11 segments, each having the substructure of the memory management architecture presently being used. This segmented address space, al though PDP-l1 compatible, was ill-suited to FORTRAN and most other languages, which expect a linear address space.

A severe design constraint was that existing PDP-l 1 subroutines must be callable from programs which ran in the Extended Address mode. The main problem areas were in establishing a protocol for communicating addresses (between programs between the operating systems and programs on the occurrence of interrupts). Saving state (the program counter and its extension) on the stack was straightforward. However, the accessing of linkage addresses on the stack after a subroutine call instruction or interrupt event was not straightforward. Complicated sequences were necessary to ensure that the correct number of bytes (representing a 32- bit or 16-bit address) were popped from the stack.

The solution was hampered by the fact that DEC customers programmed the PDP-l1 at all levels - there was no clear user level, below which DEC had complete control, as is the case with the IBM System 360 or the PDP-l0 using the TOPS-10 or TOPS-20 monitors.

The proposed architecture was the result of work by engineers, architects, operating system designers and compiler designers. Moreover, it was subjected to close scrutiny by a wider group of engineers and programmers. Much was learned about the consequences of strict PDP-11 compatibility, the notions of degree of compatibility, and the software costs which would be incurred by an extended PDP-l 1 architecture.

Fortunately, the project was discontinued. There were many reservations about its viability. It was felt that the PDP-l1 compatibility constraint caused too much compromise. Any new architecture would require a large software investment; a quantum jump over the PDP-l 1 was needed to justify the effort.

In April 1975, work on a 32-bit architecture was started on VAX-11, with the goal of building a machine which was culturally compatible with PDP-l1. The initial group, called VAXA, consisted of Gordon Bell, Peter Conklin, Dave Cutler, Bill Demmer, Tom Hastings, Richy Lary, Dave Rodgers, Steve Rothman, and Bill Strecker as the principal architect. As a result of