Updated PDP-11 references

This commit is contained in:
Jeff Parsons 2016-09-12 15:17:17 -07:00
commit 1bbd9b5295
4 changed files with 326 additions and 0 deletions

View file

@ -0,0 +1,144 @@
---
layout: page
title: What Have We Learned From The PDP-11? (1975)
permalink: /pubs/dec/pdp11/papers/1975_what_have_we_learned/
---
Computer Structures: What Have We Learned From The PDP-11?
---
By Gordon Bell, William D. Strecker
November 8, 1975
Over the PDP-11's six year life about 20,000 specimens have been built based on 10 species (models). Although
range was a design goal, it was unquantified; the actual range has exceeded expectations (500:1 in memory size and
system price). The range has stressed the basic mini(mal) computer architecture along all dimensions. The main
PMS structure, i.e. the UNIBUS, has been adopted as a de facto standard of interconnection for many micro and
minicomputer systems. The architectural experience gained in the design and use of the PDP-11 will be described
in terms of its environment (initial goals and constraints, technology, and the organization that designs, builds
and distributes the machine).
1.0 INTRODUCTION
---
Although one might think that computer architecture is the sole determinant of a machine, it is merely the focal point
for a specification. A computer is a product of its total environment. Thus to fully understand the PDP-11, it is
necessary to understand the environment.
Figure Org. shows the various groups (factors) affecting a computer. The lines indicate the primary flow of
information for product functional behavior and for product specifications. The physical flow of goods is nearly
along the same lines, but more direct: starting with applied technology (e.g., semiconductor manufacturers), going
through computer manufacturing, and finally to the service personnel before being turned over to the final user.
The relevant parts, as they affect the design are:
1. The basic technology--it is important to understand the components that are available to build from, as they
directly affect the resultant designs.
2. The development organization--what is the fundamental nature of the organization that makes it behave in a
particular way? Where does it get inputs? How does it formulate and solve problems?
3. The rest of the DEC organization--this includes applications groups associated with market groups, sales, service
and manufacturing.
4. The user, who receives the final output.
Note, that if we assume that a product is done sequentially, and each stage has a gestation time of about two years,
it takes roughly eight years for an idea from basic research to finally appear at the user's site. Other organizations
also affect the design: competitors (they establish a design level and determine the product life); and government(s)
and standards.
There are an ever increasing number of groups who feel compelled to control all products bringing them all to a common
norm: the government(s), testing groups such as Underwriters Laboratory, and the voluntary standards groups such as
ANSI and CBEMA. Nearly all these groups affect the design in some way or another (e.g. by requiring time).
2.0 BACKGROUND
---
It is the nature of engineering projects to be goal-oriented--the 11 is no exception, with much pressure on
deliverable products. Hence, it is difficult to plan for a long and extensive lifetime. Nevertheless, the 11
evolved more rapidly and over a wider range than we expected, placing unusual stress on even a carefully planned
system. The 11 family has evolved under market and implementation group pressure to build new machines. In this way
the planning has been asynchronous and diffuse, with distributed development. A decentralized organization provide
checks and balances since it is not all under a single control point, often at the expense of compatibility.
Usually, the hardware has been designed, and the software is modified to provide compatibility.
Independent of the planning, the machine has been very successful in the marketplace, and with the systems programs
written for it. In the paper (Bell et al, 1970) we are first concerned with market acceptance and use. Features
carried to other designs are also a measure of how it contributes to computer structures and are of secondary
importance.
The PDP-11 has been successful in the marketplace with over 20,0000 computers in use (1970-1975). It is unclear how
rigid a test (aside from the marketplace) we have given the design since a large and aggressive marketing and sales
organization, coupled with software to cover the architectural inconsistencies and omissions, can save almost any
design. There was difficulty in teaching the machine to new users; this required a large sales effort. On the
other hand, various machine and operating systems capabilities still are to be used.
2.1 GOALS AND CONSTRAINTS - 1970
---
The paper (Bell et al, 1970) described the design, beginning with weaknesses of minicomputers to remedy other goals
and constraints. These will be described briefly in this section, to provide a framework, but most discussion of
the individual aspects of the machine will be described later.
Weakness 1, that of limited address capability, was solved for its immediate future, but not with the finesse it might
have been. Indeed, this has been a costly oversight in redundant development and sales.
There is only one mistake that can be made in a computer design that is difficult to recover from--not providing enough
address bits for memory addressing and memory management. The PDP-11 followed the unbroken tradition of nearly every
known computer. Of course, there is a fundamental rule of computer (and perhaps other) designs which helps to alleviate
this problem: any well-designed machine can be evolved through at least one major change. It is extremely embarrassing
that the 11 had to be evolved with memory management only two years after the paper was written outlining the goal of
providing increased address space. All predecessor DEC designs have suffered the same problem, and only the PDP-10
evolved over a ten year period before a change was made to increase its address space. In retrospect, it is clear
that since memory prices decline at 26% to 41% per year, and many users tend to buy constant dollar systems, then every
two or three years another bit is required for the physical address space.
Weakness 2 of not enough registers was solved by providing eight 16-bit registers; subsequently six more 32-bit
registers were added for floating point arithmetic. The number of registers has proven adequate. More registers
would just increase the context switching time, and also perhaps the programming time by posing the allocation dilemma
for a compiler or a programmer.
Lack of stacks (weakness 3) has been solved, uniquely, with the auto-increment/auto-decrement addressing mechanism.
Stacks are used extensively in some languages, and generally by most programs.
Weakness 4, limited interrupts and slow context switching has been generally solved by the 11 UNIBUS vectors which
direct interrupts when a request occurs from a given I/O device.
Byte handling (weakness 5) was provided by direct byte addressing.
Read-only memory (weakness 6) can be used directly without special programming since all procedures tend to be pure
(and reentrant) and can be programmed to be recursive (or multiply reentrant). Read-only memories are used extensively
for bootstrap loaders, debugging programs, and now provide normal console functions (in program) using a standard
terminal.
Very elementary I/O processing (weakness 7) is partially provided by a better interrupt structure, but so far, I/O
processors per se have not been implemented.
Weakness 8 suggested that we must have a family. Users would like to move about over a range of models.
High programming costs (weakness 9) should be addressed because users program in machine language. Here we have no
data to suggest improvement. A reasonable comparison would be programming costs on an 11 versus other machines. We
built more complex systems (e.g., operating systems, computers) with the 11 than with simpler structures (e.g. PDP-8
or 15). Also, some systems programming is done using higher level languages.
Another constraint was the word length had to be in multiples of eight bits. While this has been expensive within DEC
because of our investment in 12, 18 and 36 bit systems, the net effect has probably been worthwhile. The notion of
word length is quite meaningless in machines like the 11 and the IBM 360 because data-types are of varying lengths,
and instructions tend to be in multiples of 16 bits. However, the addressing of memory for floating point is
inconsistent.
Structural flexibility (modularity) was an important goal. This succeeded beyond expectations, and is discussed
extensively in the part on PMS, in particular the UNIBUS section.
There was not an explicit goal of microprogrammed implementation. Since large read-only memories were not available
at the time of the Model 20 implementation, microprogramming was not used. Unfortunately, all subsequent machines
have been microprogrammed but with some additional difficulty and expense because the initial design had poorly
allocated opcodes, but more important the condition codes behavior was over specified.
Understandability was also stated to be a goal, that seems to have been missed. The initial handbook was terse and as
such the machine was only saleable to those really understood computers. It is not clear what the distribution of
first users was, but probably all had previous computing experience. A large number of machines were sold to
extremely knowledgeable users in the universities and laboratories. The second handbook came out in 1972 and helped
the learning problem somewhat, but it is still not clear whether a user with no previous computer experience can
determine how to use a machine from the information in the handbooks. Fortunately, two computer science textbooks
(Eckhouse, 75; and Stone and Siewiorek, 75) have been written based on the 11 to assist in the learning problem.
...