Retro/pcjs
Watch
1
0
Fork
You've already forked pcjs
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Updated PDP-11 references

Browse source
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
Download patch file Download diff file Expand all files Collapse all files

15
pubs/dec/pdp11/README.md Normal file
View file

@ -0,0 +1,15 @@
---
layout: page
title: DEC PDP-11 Publications and Papers
permalink: /pubs/dec/pdp11/
---
DEC PDP-11 Publications
---
* [PDP-11/10](1110/)
* [PDP-11/20](1120/)
* [PDP-11/40](1140/)
* [PDP-11/45](1145/)
* [PDP-11/70](1170/)
* [Assorted PDP-11 Papers](papers/)

144
pubs/dec/pdp11/papers/1975_what_have_we_learned/README.md Normal file
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.
...

153
pubs/dec/pdp11/papers/1977_what_have_we_learned/README.md Normal file
View file

@ -0,0 +1,153 @@
---
layout: page
title: What Have We Learned From The PDP-11? (1977)
permalink: /pubs/dec/pdp11/papers/1977_what_have_we_learned/
---
What Have We Learned From The PDP-11?
---
By C. Gordon Bell
1977
In the six years that the PDP-11 has been on the market, more than 20,000 units in 10 different models have been
sold. Although one of the original system design goals was a broad range of models, the actual range of 500 to 1
(in cost and memory size) has exceeded the design goals.
The PDP-11 was designed to be a small computer, yet its design has been successfully extended to high-performance
models. This paper recollects the experience of designing the PDP-11, commenting on its success from the point of
view of its goals, its use of technology, and on the people who designed, built and marketed it.
1. INTRODUCTION
---
A computer is not solely determined by its architecture; it reflects the technological, economic, and human aspects
of the environment in which it was designed and built. Most of the non-architectural design factors lie outside the
control of the designer: the availability and price of the basic electronic technology, the various government and
industry rules and standards, the current and future market conditions. The finished computer is a product of the
total design environment.
In this chapter, we reflect on the PDP-11: its goals, its architecture, its various implementations, and the people
who designed it. We examine the design, beginning with the architectural specifications, and observe how it was
affected by technology, by the development organization, the sales, application, and manufacturing organizations, and
the nature of the final users. Figure 1 shows the various factors affecting the design of a computer. The lines
indicate the primary flow of information for product behavior and specifications. The physical flow of materials is
along nearly the same lines, but more direct: beginning with the applied technology manufacturers, material moves
through computer manufacturing and then to service personnel before delivery to the end user.
2. BACKGROUND: THOUGHTS BEHIND THE DESIGN
---
It is the nature of computer engineering to be goal-oriented, with pressure to produce deliverable products.
It is therefore difficult to plan for an extensive lifetime. Nevertheless, the PDP-11 evolved rapidly, and over
a much wider range than we expected. This rapid evolution would have placed unusual stress even on a carefully
planned system. The PDP-11 was not extremely well planned or controlled; rather it evolved under pressure from
implementation and marketing groups.
Because of the many pressures on the design, the planning was asynchronous and diffuse; development was distributed
throughout the company. This sort of decentralized design organization provides a system of checks and balances,
but often at the expense of perfect hardware compatibility. This compatibility can hopefully be provided in the
software, and at lower cost to the user.
Despite its evolutionary planning, the PDP-11 has been quite successful in the marketplace: over 20,000 have been
sold in the six years that it has been on the market (1970-1975). It is not clear how rigorous a test (aside from
the marketplace) we have given the design, since a large and aggressive marketing organization, armed with software
to correct architectural inconsistencies and omissions, can save almost any design.
It has been interesting to watch as ideas from the PDP-11 migrate to other computers in newer designs. Although
some of the features of the PDP-11 are patented, machines have been made with similar bus and ISP structures.
One company has manufactured a machine said to be "plug compatible" with a PDP-11/40. Many designers have adopted
the UNIBUS as their fundamental architectural component. Many microprocessor designs incorporate the UNIBUS notion
of mapping I/O and control registers into the memory address space, eliminating the need for I/O instructions without
complicating the I/O control logic. When the LSI-11 was being designed, no alternative to the UNIBUS-style architecture
was even considered.
An earlier paper [Bell et al. 701 described the design goals and constraints for the PDP-11, beginning with a
discussion of the weaknesses frequently found in minicomputers. The designers of the PDP-11 faced each of these
known minicomputer weaknesses, and our goals included a solution to each one. In this section we shall review the
original design goals and constraints, commenting on the success or failure of the PDP-11 at meeting each of them.
The first weakness of minicomputers was their limited addressing capability. The biggest (and most common) mistake
that can be made in a computer design is that of not providing enough address bits for memory addressing and management.
The PDP-11 followed this hallowed tradition of skimping on address bits, but it was saved by the principle that a good
design can evolve through at least one major change.
For the PDP-11, the limited-address problem was solved for the short run, but not with enough finesse to support a
large family of minicomputers. That was indeed a costly oversight, resulting in both redundant development and lost
sales. It is extremely embarrassing that the PDP-11 had to be redesigned with memory management only two years after
writing the paper that outlined the goal of providing increased address space. All predecessor DEC designs have suffered
the same problem, and only the PDP-10 evolved over a long period (ten years) before a change was needed to increase its
address space. In retrospect, it is clear that since memory prices decline 26 to 41% yearly, and users tend to buy
"constant-dollar" systems, then every two or three years another address bit will be required.
A second weakness of minicomputers was their tendency not to have enough registers. This was corrected for the PDP-11
by providing eight 16-bit registers. Later, six 32-bit registers were added for floating-point arithmetic. This number
seems to be adequate: there are enough registers to allocate two or three (beyond those already dedicated to program
counter and stack pointer) for program global purposes and still have registers for local statement computation. More
registers would increase the multiprogramming context switch time and confuse the user.
A third weakness of minicomputers was their lack of hardware stack capability. In the PDP-11, this was solved with the
autoincrement/autodecrement addressing mechanism. This solution is unique to the PDP-11 and has proven to be
exceptionally useful. (In fact, it has been copied by other designers.)
A fourth weakness, limited interrupt capability and slow context switching, was essentially solved with the device of
UNIBUS interrupt vectors, which direct device interrupts. Implementations could go further by providing automatic
context saving in memory or in special registers. This detail was not specified in the architecture, nor has it evolved
from any of the implementations to date. The basic mechanism is very fast, requiring only four memory cycles from the
time an interrupt request is issued until the first instruction of the interrupt routine begins execution.
A fifth weakness of prior minicomputers, inadequate character-handling capability, was met in the PDP-11 by providing
direct byte addressing capability. Although string instructions are not yet provided in the hardware, the common string
operations (move, compare, concatenate) can be programmed with very short loops. Benchmarks have shown that systems
which depend on this string-handling mechanism do not suffer for it.
A sixth weakness, the inability to use read-only memories, was avoided in the PDP-11. Most code written for the PDP-11
tends to be pure and reentrant without special effort by the programmer, allowing a read-only memory (ROM) to be used
directly. ROMs are used extensively for bootstrap loaders, program debuggers, and for normal simple functions. Because
large ROMs were not available at the time of the original design, there are no architectural components designed
specifically with large ROMs in mind.
A seventh weakness, one common to many minicomputers, was primitive I/O capabilities. The PDP-11 answers this to a
certain extent with its improved interrupt structure, but the more general solution of I/O processors has not yet been
implemented. The I/O-processor concept is used extensively in the GT4X display series, and for signal processing. Having
a single machine instruction that would transmit a block of data at the interrupt level would decrease the CPU overhead
per character by a factor of three, and perhaps should have been added to the PDP-11 instruction set.
Another common minicomputer weakness was the lack of system range. If a user had a system running on a minicomputer and
wanted to expand it or produce a cheaper turnkey version, he frequently had no recourse, since there were often no
larger and smaller models with the same architecture. The problem of range and how it is handled in the PDP-11 is
discussed extensively in a later section.
A ninth weakness of minicomputers was the high cost of programming them. Many users program in assembly language,
without the comfortable environment of editors, file systems, and debuggers available on bigger systems. The PDP-11
does not seem to have overcome this weakness, although it appears that more complex systems are being built successfully
with the PDP-11 than with its predecessors, the PDP-8 and PDP-15. Some systems programming is done using higher-level
languages; the optimizing compiler for BLISS-11, however, runs only on the PDP-10.
One design constraint that turned out to be expensive, but probably worth it in the long run, was that the word length
had to be a multiple of eight bits. Previous DEC designs were oriented toward 6-bit characters, and DEC has a large
investment in 12-, 18-, and 36-bit systems. The notion of word length is somewhat meaningless in machines like the
PDP-11 and the IBM System/360, because data types are of varying length, and instructions tend to be multiples of 16
bits.
Microprogrammability was not an explicit design goal, partially since the large ROMs which make it feasible were not
available at the time of the original Model 20 implementation. All subsequent machines have been microprogrammed, but
with some difficulty and expense.
Understandability as a design goal seems to have been minimized. The PDP-11 was initially a hard machine to understand,
and was marketable only to those who really understood computers. Most of the first machines were sold to knowledgeable
users in universities and research laboratories. The first programmers' handbook was not very helpful, and the second,
arriving in 1972, helped only to a limited extent. It is still not clear whether a user with no previous computer
experience can figure out how to use the machine from the information in the handbooks. Fortunately, several computer
science textbooks [Gear 74, Eckhouse 75, and Stone and Siewiorek 75] have been written based on the PDP-11; their
existence should assist the learning process.
We do not have a very good understanding of the style of programming our users have adopted. Since the machine can be
used so many ways, there have been many programming styles. Former PDP-8 users adopt a one-accumulator convention;
novices use the two-address form; some compilers use it as a stack machine; probably most of the time it is used as
a memory-to-register machine with a stack for procedure calling.
Structural flexibility (modularity) was an important goal. This succeeded beyond expectations, and is discussed
extensively in the UNIBUS section.
...

14
pubs/dec/pdp11/papers/README.md Normal file
View file

@ -0,0 +1,14 @@
---
layout: page
title: Assorted PDP-11 Papers
permalink: /pubs/dec/pdp11/papers/
---
Assorted PDP-11 Papers
---
* [A New Architecture for Mini-Computers: The DEC PDP-11](archive/1970--A_New_Architecture_For_Mini-Computers--The_DEC_PDP-11.pdf)
* [PMS (Processor-Memory-Switch) and ISP (Instruction Set Processor) Descriptive Systems for Computer Structure](archive/1970--PMS_and_ISP_Descriptive_Systems.pdf)
* [What Have We Learned From The PDP-11? (1975)](1975_what_have_we_learned/) ([PDF](archive/1975--Computer_Structures_What_Have_We_Learned.pdf))
* [What Have We Learned From The PDP-11? (1977)](1977_what_have_we_learned/) ([PDF](archive/1975--What_Have_We_Learned_From_the_PDP-11.pdf))