\documentstyle{article}
\pagestyle{empty}
\begin{document}
Twenty-seven years ago, Digital Equipment Corporation -- DEC if you prefer
-- introduced their first and only range of 16 bit computers, the PDP11.
This is one of the most famous and successful ranges of computers ever
sold -- out of interest, how many people here had heard of it before
this talk? 

\noindent 
\{ Expect a massive show of hands! \}

Two years later, in 1972, DEC introduced the PDP11/45, which was the first
of the `high-end' PDP11s. 

\noindent
\{ Show 1st slide - the PDP11/45 system \}

Since this machine is now exactly 25 years old, it seemed an appropriate
subject for this evening's talk. It's obviously impossible to cover all
the details of such a complex machine in 1 hour, so what I will do is give
a general overview of the PDP11 family and then describe some of the
optimisations that were made in the PDP11/45 CPU.

Looking at that picture of a PDP11/45 machine (That's serial number 315,
by the way, and is still operational), it's obviously impossible to bring
it along this evening. However, I have brought a smaller PDP11 system -
the PDP11/10 which I can use to demonstrate some of the features. 

We can consider a processor from either the hardware or software
viewpoints. The hardware people describe the bus, the I/O architecture,
and related issues. To the software people, the important things are the
instruction set, the data registers, the memory addressing, etc. In both
cases the PDP11 was significantly different from most other machines of
the period

Firstly the bus. The PDP11 has a single bus, called the `UNIBUS' that
links the processor, the memory, and all the peripherals. 

\noindent
\{ Put up OHP of the Unibus transactions \}

A bus transaction is performed by the `master' device asserting the
address on the 18 address lines, seting up the 2 control lines to say what
sort of transaction (read, word write, byte write) it wishes to perform,
asserting the data lines if necessary and then asserting the master
synchronise line. The `slave' device responds by asserting the slave
synchronise signal, and the transaction is completed

What is rather unusual is that the processor has no special status on the
bus, other than being the `default' master. If, say, the disk controller
wishes to transfer data to memory, it can request the bus and become bus
master. Then, the disk controller has to drive the address and control
lines, and data is transfered without the use of any part of the
processor. There is no limit to the number of peripherals that can contain
their own DMA controllers, and the issues of 'limited DMA channels' that
occur with some lesser machines simply don't arrise.

Now, I've said nothing about the actual way that I/O devices are addressed
and used. The reason for that is that there's nothing special about it.
By convention, the I/O devices are simply mapped to the top 4096 words of
the 32K word processor address space and are accessed using the same
instructions that operate on memory. Any operation that can be performed
on a memory location can also be performed on an I/O register. This was
rather unusual at the time, and many contemporary machines had a special
set of I/O instruction that were, in general, limited compared to the
memory reference instructions.

The software considerations were also rather different from those of other
small minicomputers of the time. Most of those machines had an
accumulator-based architecture, where one arguement (and the result) of
any arithmetic operation had to be stored in a special CPU register called
the accumulator. On the other hand, the PDP11 operands were defined by a
6-bit field where 3 of the bits specified the addressing mode and the
other 3 specified 1 of 8 CPU registers, as shown on the next OHP. 

\noindent
\{ Put up the OHP slide of the PDP11 operands \}

Note that apart from R7 being the system program counter and R6 being used
as a stack pointer by the interrupt system, all registers are entirely
equivalent. Also note that there are no special addressing modes for
'immediate' and 'absolute' -- those are simply autoincrement and
autoincrememnt indirect using the PC as the register. PDP11 instructions
that had operands were either a 4 bit opcode followed by the 2 operands,
or a 10 bit opcode with a single operand. 

I can illustrate the use of the PDP11 instruction set by demonstrating the
following 2 trivial programs. 

\noindent
\{ Put up OHP side of the 2 trivial programs \}

I have loaded them both (I hope) into the non-volatile core memory of the
PDP11/10 I brought along, so here's what they do

\noindent
\{ Demonstrate the PDP11/10 \}

I'm often asked if core memory is still in operation anywhere, and of
course the answer is `yes'. Here's the core plane from the PDP11/10, and I
don't mind passing it round if you've never seen one.

\noindent
\{ Remove and pass round the core memory board \}

So that's why PDP11's were different from other machines of the early
1970's. Now for why the PDP11/45 is a rather special PDP11. It was the
first PDP11 to have memory management, which extended the memory map from
28K words to 124K words. It was also the first PDP11 to have a floating
point coprocessor. However, rather than describe those features, I intend
to concentrate on the normal PDP11/45 CPU.

 You see, there are 2 ways of making a fast computer -- you either take a
poor design and speed up the master clock, or you stick to a reasonable
clock rate and optimise the design. The PDP11/45 did the latter. Not many
people realise you can cut a processor in half. I did it the other day
when one wouldn't fit where I wanted it to. I'll do it again now... 

\noindent
\{ Pick up hacksaw or similar and advance towards the PDP11/10 \}

Of course, if you do this to a Pentium, you end up with a rather expensive
mess.

\noindent
\{ Put down hacksaw, pull the 2 CPU boards \}

The PDP11/10 CPU is built on 2 circuit boards, and each contains one of
the major sections of the processor. This \{ wave it about \}\ is the data
path, and this \{ wave the other one about \}\ is the control logic

Now, the PDP11/45 has the same 2 sections, but they're rather more
complex. They are 3 boards each. Here's a picture of the insides of the
machine 

\noindent
\{ Show next 35mm slide, the insides of the processor, and point out the
CPU boards \}

No, I guess most of you are programmers, and thus you're more familiar
with the elements of the data path - the registers, ALU, and related bits.
Here's a block diagram of the PDP11/45's data path

\noindent
\{ Put up the obvious page from the printset \}

It consists of 3 basic types of block -- blocks that modify data, like the
ALU here, blocks that store data -- not only the registers, program
counter, etc that are familiar to machine language programmers, but also
the internal CPU registers like the SR and DR here, and finally
multiplexer switches to link it all together. It looks complicated, but
that's because, in general, there's a direct link between any 2 blocks
that need to communicate. For example, there's a bus from the output of
the program counter to the AMUX switch and thence to the ALU. There's
another possible route, via the shiufter, SRMUX, SR and AMUX, but that
would (a) take longer and (b) change the contents of the temporary
register SR.

Now for the more interesting control section. Here's the block diagram of
that. 

\noindent
{Show the other obvious page from the printset}

The control logic is based around a 256 location microcode ROM containing
64 bit words. The last 8 bits of each location \{point them out on the
diagram \}\ are fed through some address gating \{used for conditional
branches in the microcode \}\ and then back into the microcode program
counter here. Thus, every microcode instruction ends with a `Goto'

The best way to explain the operation of the control logic is by tracing
the operation of an instruction. I'm going to choose a particularly simple
one -- 060102. It's a simple add between 2 registers. I'm also going to
assume that this is the first instruction to be executed. In following
this description you should keep this optimisation in mind. 

The technical manual refers to as 'pipelining'. The idea is that if you
can move data over a bus without damaging some data that might be needed
later, and if the data you move might possibly be needed in the
destination, then you should do the transfer. After all, it can't ever be
a waste of time. 

Of course this is quite common on modern processors, but it was very rare
on small machines in 1972. In fact it took over 10 years for this to
appear in common micros.

\noindent
\{ Put up FLOWS1. Also put up the cut-and-paste microcode binary if
possible \}

OK, we start here, in state FET00, location 217. We start by fetching the
instruction. We output the PC to the address bus, clear the Instruction
Register, and start a bus read cycle. This instruction ends with address
240, but note that the BEN field is set to 12 Octal. The CPU logic (and
there's no way you'd be expected to deduce this) then sets the '20' bit of
the address if there's no external bus request. I'm going to assume
there's not, so we actually end up at location 260.

Location 260 is FET10. We complete the bus cycle and read the instruction
into the Instruction Register. We also incrememnt the program counter -
note how the fact that the program counter is duplicated (PCA and PCB)
allows us to do this in the same machine cycle. This instruction ends with
address 343, so we go there next. 

OK, We're now at IRD00. This instruction contains 2 optimisations.
Firstly, we start a second bus cycle to get the word following the
instruction. Now, in many cases this is a waste of time, but in the case
of an indexed operand, or an instruction with no memory references (like
the one we're discussing), we've actually overlapped the next fetch with
the current execution. We also do a partial incrememnt of the PC (or at
least, we store the incremented value) so as to point to the word
following the one we've just started to fetch

The other thing we do here is make the assumption that bits 2:0 and 10:8
of the instruction specify the registers to be used. Again this may be a
false assumpion (it may be a single operand instruction or something like
a branch), but the action taken - to copy those 2 registers into the
tempory registers SR and DR can do no harm, and may save time later.

Incidentally, note that the microcode is not affected (yet) by the
particular registers used. The register selection is hardwired via these
multiplexers \{ Put up sheet GRAC \}\ from the instruction register to the
register adress lines here \{ Put up sheet GRAD \}\

OK, so we've possibly got the data into the right place. Now to continue
with the microcode. The observant ones amongst you will have notices that
state IRD00 ends with address 377 but that the next state we end up in
according to my extract from the microcode is state 020. The reason for
this is simple, we've hit the A-Fork.

A Fork is a multi-way conditional branch, in this case conditional on the
current instruction value. I'm sure some of you have come across
sum-of-products notation - a way of writing logical functions as a number
of AND terms all ORed together. I'm equally sure that you thought this was
some kind of torture thought up for undergraduates. 

Well, the fork logic is SOP gone mad. I'll show you the relevant terms
that may pass as true for this instruction 

\noindent
\{ Put up the extracts from RACH and RACF \}

I've annotated those with the 0's and 1's for this instruction. The final
outputs are inverted and then ANDed with the microcode address by some
more logic that I'm not going to show you. There are 2 cases to consider.

Firstly, the simpler one. The program counter is not modified by the
instruction, so DF7+BRQ os a 0. Then RACF A2 RAB03L is a 1, and we end up
in state 020 -- EXC.80. Here, we do 2 things : We perform the ALU
operation (We first store the result in the SHFR register, and then
transfer that into the appropriate destination register. We also complete
the fetch of the word from the next location (remember we started that in
the previous machine instruction) and, since we've now fetched the next
instruction, we can go back to IRD.00 (state 343). Notice that a chain of
these ADD instructions would be fetched and executed in 2 microcycles
each.

The sequence I have just described would have been used for other
2-register instructions, like subtract or XOR. The particular function
that the ALU performs is not controlled by the microcode in that sequence,
but instead the instruction register is decoded by a PROM on one of the
circuit boards \{\ put up GRAA if there's time \}\ which provides the ALU
control signals.

The more complex case occurs when the Destination Register is register 7 -
the program counter. In that case, we end up in state 030 -- EXC.90. We
then abort the previous bus transfer (since we don't need the word that
would be fetched), perform the ALU operation as before, and go back to
FET00 (state 217) to fetch the next instruction. That's where we began
this discussion, and it seems like a good place to end the tour of the
microcode.


\end{document}

