PDP-8 architecture

The PDP-8 is a 12-bit architecture from DEC; the first commercially successful minicomputer. It was a load-store architecture.

The PDP-8's basic configuration had a main memory (all core memory, in the early models) of 4,096 twelve-bit words (that is, 4K words, equivalent to 6 kilobytes). In most models, that was expandable to 32,768 words (32K words / 48 KB), which were controlled by optional additional hardware.

At its inception, the PDP-8 had only eight instructions and two registers (a 12-bit accumulator, AC; and a single-bit "link register", L). The first model used a magnetic core memory system that operated at a cycle time of 1.5 microseconds, so that a typical two-cycle (Fetch, Execute) memory-reference instruction ran at a speed of 0.333 MIPS.

Later models added a second register (the "MQ" Multiplier/Quotient Register), optional actual hardware multiply and divide instructions, and faster operation. The last models also supported optional hardware floating point.

Instruction Set

PDP-8 instructions all took this basic format:

Opcode			Indirect	Page	Address
00	01	02	03	04	05	06	07	08	09	10	11

To explain this, a special term is used with PDP-8 main memory: 'page'. This has nothing to do with the now-ubiquitous 'pages' of virtual memory; rather, it is has to do with the fact that PDP-8 instructions are 12 bits wide (the size of its words), as is its address space. It is thus impossible to fully address all the memory from a PDP-8 instruction; rather, PDP-8 instructions contain only a 7-bit offset field, the 'address' field. The visible main memory is divided into 32 (040) 'pages', each 128 (0200) words long. Another bit in each instruction, the 'memory page' bit, indicates whether the offset is in the current page (if '1'), or page 0 (if '0').

To refer to a word in another page, it was necessary to use an indirect reference (controlled by another bit in the instruction) through an address stored in either of the two directly accessible pages.

An additional 'feature' made up for the lack of index register capability; locations 010 through 017 in page 0, when used as indirect words, were 'auto-indexed': the contents were read, incremented, and the modified value stored back; the incremented value was used as the address of the target word.

Basic Instructions

The PDP-8 had only 6 basic instructions (all 8 possible types are shown in the table, and are explained below):

000 - AND - AND the memory operand with AC.

001 - TAD - Twos-complement ADd the memory operand to <L,AC> (a 13 bit value).

010 - ISZ - Increment the memory operand and Skip next instruction if result is Zero.

011 - DCA - Deposit AC into the memory operand and Clear AC.

100 - JMS - JuMp to Subroutine (storing return address in first word of subroutine!).

101 - JMP - JuMP.

110 - IOT - Input/Output Transfer.

111 - OPR - microcoded OPeRations (on/using the accumulator, link, and MQ registers).

A wide variety of operations are available through the OPR 'microcoded' instructions, including most of the conditional branch (skip) instructions. In general, the operations within each Group can be combined by OR'ing the bit patterns for the desired operations into a single instruction.

Group 1 "operate" instruction operations

CLA - clear AC

CLL - clear the L bit

CMA - ones complement AC

CML - complement L bit

IAC - increment <L,AC>

RAR - rotate <L,AC> right

RAL - rotate <L,AC> left

RTR - rotate <L,AC> right twice

RTL - rotate <L,AC> left twice

In most cases, the operations are sequenced so that they can be combined in the most-useful ways. For example, combining CLA (CLear Accumulator), CLL (CLear Link), and IAC (Increment ACcumulator) first clears the AC and Link to 0000, then increments the accumulator, leaving it set to 0001. Adding RAL to the mix (so CLA CLL IAC RAL) causes the accumulator to be cleared, incremented, then rotated left, leaving it set to 0002. In this way, small integer constants were easily placed in the accumulator.

A very useful combination was CMA IAC, which was shortened to CIA with an assember alias. This combination produced the arithmetic inverse of the 12-bit, two's complement value in the accumulator. Since there was no subtraction instruction, only the "two's complement" add instruction (TAD), computing the difference of two operands required first taking the arithmetic inverse of the subtrahend.

If none of the operation bits are set, the result is the canonical NOP instruction.

Group 2 "operate" instruction operations

SMA - skip on AC < 0 (or group)

SZA - skip on AC = 0 (or group)

SNL - skip on L /= 0 (or group)

SKP - skip unconditionally

SPA - skip on AC >= 0 (and group)

SNA - skip on AC /= 0 (and group)

SZL - skip on L = 0 (and group)

CLA - clear AC

OSR - logically 'or' front-panel switches with AC

HLT - halt

As with the Group 1 OPR instructions, if none of the operation bits are set, the result is another NOP instruction.

IOT (Input-Output Transfer) instructions

Aside from reserving the entire group of '6xxx' opcodes for I/O, the PDP-8 processor itself defined very few I/O instructions. Instead, it simply provided an I/O framework and most of the I/O instructions were then defined by the individual I/O devices.

I/O address

Within the '6xxx' IOT instruction, the middle six bits ('6AAx') selected the address of the I/O device to be accessed. While I/O devices could be designed for any of the 63 addresses (601x through 677x), some addresses were standardized by convention:

• '01' was usually the high-speed paper tape reader
• '02' was the high-speed paper tape punch
• '03' was the console keyboard (and any associated low-speed paper tape reader)
• '04' was the console printer (and any associated low-speed paper tape punch)

I/O operation

The final three bits of the IOT instruction (6xxF) then selected the specific I/O function to be performed by the selected device. For many simple devices (such as the paper tape reader and punch and the console keyboard and printer), the I/O functions were somewhat standardized:

• The '1' bit caused the processor to skip the next instruction if the I/O device was ready
• The '2' bit caused the Accumulator to be cleared
• The '4' bit caused an I/O word to be transferred to or from the Accumulator, another I/O transfer to be started, and the "device ready" flag to be cleared

As with the Operate instructions, these bit-specified operations took place in a well-defined order leading to useful results.

This strategy was inadequate for more complicated devices such as disk drives. Such devices used these 3 bits in completely device-specific fashions. Typically the bottom three bits were decoded by the peripheral, giving a total of up to eight I/O function codes.

ION and IOFF

I/O address 00 (600x) was reserved for operations that affected the processor as a whole such as turning the interrupt system on (ION, opcode 6001) and off (IOFF, opcode 6002). The PDP-8 processor directly executed these two IOT instructions by itself, with no assistance from any I/O devices.

Memory Control

The basic PDP-8 instruction set could only address 4,096 12-bit words of memory. While this was somewhat adequate for very small programs, once the price of memory came down a bit, it was desirable to increase the amount of addressable memory. The way this was done was, depending on your point of view, very clever or a huge kludge; bank switching, supported by optional hardware, was added. This approach in many ways resembles the solution chosen for the later Intel 8086 which added "segments" to a 16 bit address to create a 20 bit address, which also created problems, but was cheaper than re-engineering an entirely new instruction set.

Ideally one would expand the size of addresses, but this would require major rework of the architecture and likely make all existing programs not work. Instead the designers thought of a way of extending the address space while allowing full compatibility with existing programs.

This was done by adding a Memory Extension Controller. This controller expanded the addressable memory by 4KW blocks of memory; each 4KW block of memory was called a "field". This may sound like not too much memory, but core memory in those days cost about 50 cents a word, so a full 32K complement of memory would equal the cost of the CPU.

The current field was controlled by two three-bit registers: the DF (Data Field) and the IF (Instruction Field). These registers were grafted onto all memory accesses. For accesses from the CPU for instructions, the IF field register was grafted onto the memory request address. For data accesses with indirection, the DF register was used. With this clever combination, a program running in one field could access data in the same field by direct addressing, or data in another field with indirect addressing.

The DF and IF registers were controlled by a set of pseudo-IO instructions. The 6200 through 6277 range of IO instructions were reserved for the extended memory controller. The 62X1 instuction (CDF, Change Data Field) would set the data field to X. Similarly 62X2, CIF, set the instruction field, 62X3 set both. The instruction field change did not take effect until after the completion of the next JMP or JMS instruction, to avoid wild changes of execution. The DF and IF registers were part of the machine state, so there were also instructions for getting and setting these registers, usually used for saving the machine state on an interrupt.

While in many ways a headache, the extended memory scheme had many benefits. One could take an existing 4K program and with minimal changes move its data to another field. For example, 4K FOCAL normally had about 3K of code with only 1K left over for user program and data. With a few patches, the second 4K could be allocated for user program and data.

As another benefit, each 4K field could be allocated to separate users. In this way 4K FOCAL could, with minor changes, be turned into a multi-user time-sharing system.

On the PDP-8/E and later models the Extended Memory Controller had a few minor enhancements which made machine virtualization possible. By making all I/O instructions cause an interrupt, a virtual machine manager could do memory mapping, for instance mapping data or instruction fields on the fly. It could also redirect I/O to different devices. A rather sophisticated feature for a machine with only eight basic instructions!

One glitch in the virtualization was that there was one bit of machine state that was not possible to restore. When executing a CIF instruction, the change did not take place immediately, but was delayed until the next jump or call. This state was not readable or settable, so there was no way for the virtualizer to simulate a CIF and set the proper machine state. This required the virtualizer to have a complete PDP-8 code simulator in it (not that hard a task for an 8-instruction machine). Whenever a CIF instruction trapped to the virtualizer, it had to emulate the instructions between the CIF and the next JMP or JMS. Fortunately most programmers did not insert any instructions between the CIF and JMS, so the emulator did not slow things very much. Still, it's an interesting example of how just one missing bit can lead to requiring much additional code.

By the time of the PDP-8/A, memory prices had come down enough so 32K was not a huge budgetary item and more memory was desireable. The 8/A added a new set of instructions for handling more than eight fields of memory. Particularly useful were new instructions that took the field number from the AC instead of requiring the field number to be hard-coded into the instruction. Unfortunately by this time the PDP-8 was in its decline, so very little standard system software was modified to take advantage of these new instructions and extra memory.

Input/Output

The I/O systems underwent huge changes during the PDP-8 era. Early PDP-8 models used a front panel interface, a paper tape reader and a teletype printer with an optional paper tape punch. Over time I/O systems such as magnetic tape, RS-232 and current loop dumb terminals, punched card readers, and fixed-head disks were added. Toward the end of the PDP-8 era, floppy disks and moving-head cartridge disk drives were popular I/O devices. Modern enthusiasts have created standard PC style IDE hard disk adapters for real and simulated PDP-8 computers.

I/O was supported through several different methods, which changed over time and various PDP-8 models:

• In-backplane dedicated slots for I/O controllers
• A "Negative" I/O bus (using negative voltage signalling)
• A "Positive" I/O bus (the same architecture using TTL signalling)
• The OMNIBUS (a backplane of un-dedicated slots)

All supported DMA, called "data break" in the PDP-8's. There were two types.

In one, "three cycle data break", the buffer address and word count were kept in main memory (at an address usually specified by jumpers on the device). This required the assistance of the processor, placing the processor in charge of maintaining the DMA address and word count. This moved some of common logic (needed to implement the I/O device) from each I/O device into one common copy of the logic within the processor, reducing the device complexity (and thus cost). In three successive memory cycles, the processor would update the word count, update the transfer address, and finally store or retrieve the actual I/O data word.

The other, "single cycle data break", moved back to the individual I/O devices all the responsibility for maintaining the word count and transfer address (in registers in the device); this effectively tripled the DMA transfer rate because only the target data needed to be transferred to/from the main memory.

Programming Facilities

Software development systems for the PDP-8 series began with the most basic front panel entry of raw binary machine code. In the middle era, PAL-8 assembly language source code was often stored on paper tape, read into memory, and saved to paper tape, and later assembled from paper tape into memory. Paper tape versions of a number of programming languages were available, including DEC's FOCAL interpreter and a 4K FORTRAN compiler and runtime.

Toward the end of the PDP-8 era, operating systems such as OS/8 and COS-310 allowed a traditional line mode text editor and command-line compiler development system using languages such as PAL-III assembly language, FORTRAN, BASIC, and DIBOL.

Early PDP-8 systems did not have an operating system, just a front panel and run and halt switches. Various paper tape "operating systems" were developed, as were single user disk operating systems. Toward the end of the PDP-8 era, fairly modern and advanced RTOS and preemptive multi-tasking multi-user systems were available: a real-time system (RTS-8) was available as were multi-user commercial systems (COS-300 and COS-310) and a dedicated single-user word-processing system (WPS-8).

A time-sharing system, TSS-8, was also available. TSS-8 allowed multiple users to log into the system via 110-baud terminals, and edit/compile/debug programs. Languages included a special version of BASIC, a FORTRAN subset similar to FORTRAN-1 (no user-written subroutines or functions), an ALGOL subset, FOCAL, and an assembler called PAL-D.

A fair amount of user-donated software for the PDP-8 was available from DECUS, the Digital Equipment Corporation User Society, and often came with full source listings and documentation.== Example program ==

Here is an example of a complete PDP-8 assembly language program: "Hello, world!" written for the PAL-III assembler.

   *10                   / Set current assembly origin to address 10,
   STPTR,    0           / an auto-increment register (one of eight at 10-17)
 
   *200                  / Set current assembly origin to program text area
   HELLO,  CLA CLL       / Clear AC and Link (carry)
           TAD (STRNG-1) / Set up string pointer in PRE-auto-increment register
           DCA STPTR     /   :
   NEXT,   CLA CLL       / Clear AC and Link again (needed when we loop back from tls)
           TAD I STPTR   / Get next character, indirect via PRE-auto-increment address
           SNA           / Skip if non-zero (not end of string)
           HLT           / Else halt on zero (end of string)
           TLS           / Output the character in the AC to the teleprinter
           TSF           / Skip if teleprinter ready for character
           JMP .-1       / Else jump back and try again
           JMP NEXT      / Jump back for the next character
 
   STRNG,  310           / H
           345           / e
           354           / l
           354           / l
           357           / o
           254           / ,
           240           / (space)
           367           / w
           357           / o
           362           / r
           354           / l
           344           / d
           241           / !
           0             / End of string

Subroutines on the PDP-8

The PDP-8 did not implement any general-purpose stack so there was no stack upon which to store the PC, AC, or any other context when a subroutine was called or an interrupt occurred. Instead, the updated PC simply replaced the first word of the targeted subroutine. An indirect JMP instruction was then used to exit from the subroutine.

For example, here is "Hello, World!" re-written to use a subroutine:

   *200                    / Set assembly origin (load address)

   HELLO,  CLA CLL         / Clear the AC and the Link bit
           TAD (DATA-1)    / Point AC just *BEFORE* the data (accounting for later pre-increment behavior)
           DCA 10          / Put that into one of ten auto-pre-increment memory locations
   LOOP,   TAD I 10        / Pre-increment mem location 10, fetch indirect to get the next character of our message
           SNA             / Skip on non-zero AC
           HLT             / Else halt at end of message
           JMS OUT1        / Write out one character
           JMP LOOP        / And loop back for more

   OUT1,   0               / Will be replaced by caller's updated PC
           TSF             / Skip if printer ready
           JMP .-1         / Wait for flag
           TLS             / Send the character in the AC
           CLA CLL         / Clear AC and Link for next pass
           JMP I OUT1      / Return to caller

   DATA,  "H               / A well-known message
          "e               /
          "l               / NOTE:
          "l               /
          "o               /   Strings in PAL-8 and PAL-III were "sixbit"
          ",               /   To use ASCII, we'll have to spell that out, character by character
          "                /
          "w               /
          "o               /
          "r               /
          "l               /
          "d               /
          "!               /
          015              /
          012              /
          0                / Mark the end of our .ASCIZ string ('cause .ASCIZ hadn't been invented yet!)

This dedicated storage for the return address made the use of reentrancy and recursion difficult because the programmer would have needed to explicitly store away the return address onto a programmer-maintained stack. It also made it difficult to use ROM with the PDP-8 because read-write return-address storage was commingled with read-only code storage in the address space. Programs intended to be placed into ROMs approached this problem in several ways:

• They avoided the use of subroutines,
• They copied themselves to core memory before execution, or
• They were placed into special ROM cards that provided a few words of read/write memory, accessed indirectly through the use of a thirteenth flag bit in each ROM word.

Interrupts

There was a single interrupt line on the PDP-8 I/O bus and interrupts were processed identically to having called a subroutine at location 0000 except that the interrupt system was also automatically disabled. Just as it was difficult to reentrantly call subroutines, it was difficult to nest interrupts and this was usually not done; each interrupt ran to completion and re-enabled the interrupt system just before executing the JMP I 0 instruction which acted as the exit from the interrupt.

Because there was only a single interrupt line on the I/O bus, the occurrence of an interrupt conveyed no information to the processor about the source of the interrupt. Instead, the interrupt service routine had to serially poll each active I/O device to see if it was the source of the interrupt; the code that did this was usually referred to as a skip chain because it consisted of a lot of PDP-8 "test and skip if flag set" I/O instructions. (It was also not unheard-of for a skip chain to reach its end and not have found any device in need of service.) The relative interrupt priority of the I/O devices was determined by their position in the skip chain with devices nearer the front of the skip chain having higher priority for service.

• They were placed into special ROM cards that provided a few words of read/write memory, accessed indirectly through the use of a thirteenth flag bit in each ROM word.

Concurrency

Because Dijkstra's notion of semaphores had not been invented at the time the PDP-8 was designed, the designers saw no need for an atomic test-and-set instruction. The result was that concurrency problems could not be solved by the use of semaphores.

Use of PDP-8 architecture today

The stark simplicity of the architecture and the instruction set make the PDP-8 valuable as a mental model for teaching the rudiments of architecture and of assembly language to beginners. A complete lesson, requiring no lecture notes, can be delivered in 15 minutes by anyone who ever programmed in PDP-8 assembler. The same cannot be said for most of the more recent architectures.

See also

• PDP-8 family

External links

• PDP8 - documentation at Bitsavers
• Another Real Machine: The DEC PDP-8