Homebrew digital computer system

[dfmischler]

The PDP-8 was an outgrowth of the PDP-5, which was intended to be the smallest usable computer that could be built at the time.  Programming it was *supposed* to suck  .

Lots of things could be done with the basic architecture type represented by the PDP-8.  What you have designed sounds more like some of the 18-bit machines that DEC built (PDP-4, PDP-7, PDP-9, PDP-15 all able to run programs for the earlier machines in this group; they learned how bad incompatibility was when they built the PDP-4 that wouldn't run PDP-1 code).  On those, the operate instruction included the skips, clears, complements, rotates, etc. all in one bit-programmed instruction.  DEC never did build a 16-bit machine of this type, although they discussed the PDP-X.  They effectively dropped the single accumulator architecture and built the PDP-11 instead.

Also, keep in mind the level of technology DEC was using when the PDP-5 and (follow-on) PDP-8 were designed and built.  Check out these images of PDP-8 modules made out of diodes, resistors, and transistors on tiny PC boards laid out by hand.  You needed 13 of those R210 modules for the accumulator and link bit.  The R211 modules hold a bit each of the memory buffer, memory address, and program counter registers.  There were no decoder chips, no ROMs, no programmable logic chips of any kind...

[GK]

The PDP-8 was an outgrowth of the PDP-5, which was intended to be the smallest usable computer that could be built at the time.  Programming it was *supposed* to suck  .

At least they didn't go to this extreme:

http://en.wikipedia.org/wiki/One_instruction_set_computer

[dfmischler]

After re-reading the whole thread I have discovered that you appear to have eliminated both zero-page and indirect addressing.  I understand that you believe this will simplify the machine substantially.  But if JMS works like it does on the PDP-8, PDP-15 etc (i.e. saves the return address at the jump target address and begins executing from the next word), how will you return from a subroutine without an indirect jump?  I guess you could make the JMS instruction save a JMP instruction that included the return address, instead of the bare address.  I suspect the loss of indirection will greatly reduce the power of the instruction set, since you also have no indexing capability.  How do you grab, say, the nth word from a table in a loop?  I think you will have to increment the address in an instruction, or something...  Of course, if there is more than one access then you have to fix them all.

I want to give an example of how important indirect addressing was on the PDP-8.  If I recall correctly, the PDP-8 FORTRAN system called a subroutine by using a JMS instruction followed by a list of pointers to the arguments.  So the called routine would first use the address saved by the JMS instruction to locate the address of the first argument, then increment the saved address to point to the address for the next argument, etc.  When all argument addresses had been fetched then the saved address had also been updated to point to the next instruction in the calling program.  When the subroutine was done it would return by an indirect jump through the updated address saved by the calling JMS instruction.  This would have taken a lot of instruction arithmetic and self-modifying code to do without indirect addressing.

[Kostas]

@GK

How come have you chosen a DTL implementation? Wouldn't a NMOS implementation be simpler, or am I missing something?

[GK]

After re-reading the whole thread I have discovered that you appear to have eliminated both zero-page and indirect addressing.  I understand that you believe this will simplify the machine substantially.  But if JMS works like it does on the PDP-8, PDP-15 etc (i.e. saves the return address at the jump target address and begins executing from the next word), how will you return from a subroutine without an indirect jump?  I guess you could make the JMS instruction save a JMP instruction that included the return address, instead of the bare address.  I suspect the loss of indirection will greatly reduce the power of the instruction set, since you also have no indexing capability.  How do you grab, say, the nth word from a table in a loop?  I think you will have to increment the address in an instruction, or something...  Of course, if there is more than one access then you have to fix them all.

I want to give an example of how important indirect addressing was on the PDP-8.  If I recall correctly, the PDP-8 FORTRAN system called a subroutine by using a JMS instruction followed by a list of pointers to the arguments.  So the called routine would first use the address saved by the JMS instruction to locate the address of the first argument, then increment the saved address to point to the address for the next argument, etc.  When all argument addresses had been fetched then the saved address had also been updated to point to the next instruction in the calling program.  When the subroutine was done it would return by an indirect jump through the updated address saved by the calling JMS instruction.  This would have taken a lot of instruction arithmetic and self-modifying code to do without indirect addressing.

Yes, you are right. Without indirect addressing there is no point in having the JMS command in addition to the JMP command. The return address stored at the beginning of the subroutine called by JMS cannot be shifted into the program counter register if you can't enact the JMP command with indirect addressing at the conclusion of the subroutine - so you may as well have just JMP-ed to the subroutine in the first place. Without indirect addressing JMS is redundant! I was so consumed in other parts of the hardware design I overlooked this. There is quite a bit to contemplate figuring out the whole computer down to the individual transistor level and its easy when getting thoroughly bogged down in the hardware design to start overlooking even obvious things on the abstract level.

Removing indirect addressing however did not turn out to simplify things an awful lot - just removed a handful of gates and a couple of DFF's to flag to a "defer" state, running an additional machine cycle to perform the additional operand fetch from memory.

Hardware wise, it's really not a big deal at all. I decided last night not to send my front panel design off to FPE just in case something like this comes up - good decision! I will re-implement indirect addressing. I will have to ditch one of my OPR micro instructions however, unfortunately, as I will need a free bit to specify indirect addressing. Then it probably wouldn't make sense to stick with 8192 words of addressable memory, as indirect addressing will give me access to the full 16 bits. That's not a big deal either - it just means 3 more stages to my (currently 13-bit) PC and MA (shift) registers and 6 additional LED's on the front panel (my ALU and the majority of the data busses are 1-bit serial, aka the PDP-8/S architecture).

Which micro instruction would you sacrifice? I'm thinking OSR.

-------------------------------------------------------------------------------------------------

My current memory specification is 8192 words. Words 0 through 511 being R.O.M for peripheral interface firmware (e.g. tape-drive "bootstrap" and program saving subroutines for loading and storing programs.

Words 512 through 519 being dedicated locations for memory-mapped parallel I/O - four ports having 16 dedicated digital inputs and 16 dedicated digital outputs each. Output ports are words 512, 514, 516 and 518, each mapped to an individual output register. These memory locations can be read and written to just like any other location of R.A.M., but when written to data is simultaneously written to the associated output registers. Inputs are words 513, 515, 517 and 519. These memory locations can be written to but not read. Instead of reading from memory the computer reads the status of the digital input lines. This way the computer has comprehensive parallel I/O facilities without the need for any dedicated parallel I/O instructions.

[GK]

@GK

How come have you chosen a DTL implementation? Wouldn't a NMOS implementation be simpler, or am I missing something?

The first digital computers used bipolar transistors!

[baljemmett]

(my ALU and the majority of the data busses are 1-bit serial, aka the PDP-8/S architecture).

Oh good grief - how did I not know about that machine already?  The design I'm working towards is a bit-serial contraption, too, which I knew couldn't exactly be novel - but I hadn't researched it in enough detail to discover DEC had built one...

(Actually that's cheered me up no end - they all said I was mad - well, who's mad now?!  I really must get around to typing up some notes on what I'm doing, though, since you did ask earlier in the thread and I haven't had a chance to reply properly yet.  Have been running a soak test on my 16x32-bit general-purpose register file for the last 40-odd hours, and it seems to be holding up, so it's time to crack on with building the ALU soon.)

[retrolefty]

@GK

How come have you chosen a DTL implementation? Wouldn't a NMOS implementation be simpler, or am I missing something?

The first digital computers used bipolar transistors!

 I would have thought the first 'digital computers' used vacuum tubes?

[dfmischler]

There is quite a bit to contemplate figuring out the whole computer down to the individual transistor level and its easy when getting thoroughly bogged down in the hardware design to start overlooking even obvious things on the abstract level.

Removing indirect addressing however did not turn out to simplify things an awful lot - just removed a handful of gates and a couple of DFF's to flag to a "defer" state, running an additional machine cycle to perform the additional operand fetch from memory.

Hardware wise, it's really not a big deal at all. I decided last night not to send my front panel design off to FPE just in case something like this comes up - good decision! I will re-implement indirect addressing. I will have to ditch one of my OPR micro instructions however, unfortunately, as I will need a free bit to specify indirect addressing. Then it probably wouldn't make sense to stick with 8192 words of addressable memory, as indirect addressing will give me access to the full 16 bits. That's not a big deal either - it just means 3 more stages to my (currently 13-bit) PC and MA (shift) registers and 6 additional LED's on the front panel (my ALU and the majority of the data busses are 1-bit serial, aka the PDP-8/S architecture).

Which micro instruction would you sacrifice? I'm thinking OSR.

I don't know why you need to change the operate instructions.  I think you need an indirect bit in each of the memory reference instructions.  Take the bit just right of the opcode for indirect addressing.  That would shorten the address part of each memory reference instruction to 12 bits, so I suppose you would just do current page addressing with 4KW pages (i.e. the higher order bits come from the program counter).  Here's an exercise that shows why you need indirection: write a subroutine to save 100 temperature readings in a table in memory.  Get each reading by calling a subroutine named TEMPRD that returns the latest reading in the accumulator (don't worry about writing that one).  You will discover that it is very hard to store values in consecutive memory locations on a machine that doesn't have either indexing through a register or memory indirection.

My current memory specification is 8192 words. Words 0 through 511 being R.O.M for peripheral interface firmware (e.g. tape-drive "bootstrap" and program saving subroutines for loading and storing programs.

ROM is tough on this kind of architecture because you can't save a return address in ROM.  That was one of the things that the software people liked about the PDP-11: the implied stack for return addresses means you don't have to modify the program memory area.

The PDP-8 and 4/7/9/15 basically do a JMS to location 0 for an interrupt, then you have to save everything else.  Will your machine handle interrupts?

Words 512 through 519 being dedicated locations for memory-mapped parallel I/O - four ports having 16 dedicated digital inputs and 16 dedicated digital outputs each. Output ports are words 512, 514, 516 and 518, each mapped to an individual output register. These memory locations can be read and written to just like any other location of R.A.M., but when written to data is simultaneously written to the associated output registers. Inputs are words 513, 515, 517 and 519. These memory locations can be written to but not read. Instead of reading from memory the computer reads the status of the digital input lines. This way the computer has comprehensive parallel I/O facilities without the need for any dedicated parallel I/O instructions.

So if you have these why do you need the IOT instruction?

[GK]

@GK

How come have you chosen a DTL implementation? Wouldn't a NMOS implementation be simpler, or am I missing something?

The first digital computers used bipolar transistors!

 I would have thought the first 'digital computers' used vacuum tubes?

The 1st solid state computers of course

[GK]

I don't know why you need to change the operate instructions.  I think you need an indirect bit in each of the memory reference instructions.   

Yes, of course. Posting off the cuff at ~ 1am. I will not need to sacrifice a micro instruction as indirect addressing is not used in the OPR instruction.

ROM is tough on this kind of architecture because you can't save a return address in ROM.  That was one of the things that the software people liked about the PDP-11: the implied stack for return addresses means you don't have to modify the program memory area.[/i]The PDP-8 and 4/7/9/15 basically do a JMS to location 0 for an interrupt, then you have to save everything else.  Will your machine handle interrupts?

My RAM for programs starts at location 520. It doesn't matter that return addresses cannot be stored to the ROM locations. The ROM subroutines are not intended to be called by programs being run. They are to be manually run by the user - eg to load or save a program from magnetic tape. Each firmware subroutine terminates with a HLT command. Interrupts are not included in my specification, but if I later decided to add such hardware, an interrupt would jump to location 520.

Words 512 through 519 being dedicated locations for memory-mapped parallel I/O - four ports having 16 dedicated digital inputs and 16 dedicated digital outputs each. Output ports are words 512, 514, 516 and 518, each mapped to an individual output register. These memory locations can be read and written to just like any other location of R.A.M., but when written to data is simultaneously written to the associated output registers. Inputs are words 513, 515, 517 and 519. These memory locations can be written to but not read. Instead of reading from memory the computer reads the status of the digital input lines. This way the computer has comprehensive parallel I/O facilities without the need for any dedicated parallel I/O instructions.

So if you have these why do you need the IOT instruction?

IOT is for serial communications. I have 16 serial IO ports.

[GK]

(my ALU and the majority of the data busses are 1-bit serial, aka the PDP-8/S architecture).

Oh good grief - how did I not know about that machine already?  The design I'm working towards is a bit-serial contraption, too, which I knew couldn't exactly be novel - but I hadn't researched it in enough detail to discover DEC had built one...

(Actually that's cheered me up no end - they all said I was mad - well, who's mad now?!  I really must get around to typing up some notes on what I'm doing, though, since you did ask earlier in the thread and I haven't had a chance to reply properly yet.  Have been running a soak test on my 16x32-bit general-purpose register file for the last 40-odd hours, and it seems to be holding up, so it's time to crack on with building the ALU soon.)

A predominantly serial architecture simplifies the hardware a lot, especially when your computer is 16-bits or more, though the operating speed is of course a lot slower.

Go to the siliconchip.com.au (then:>shop>books&DVDs....) website and search for EDUC-8. They have a scanned book from 1975 which you can buy for ~$20AUD and download.
The EDUC-8 is a complete 8-bit computer with a reduced PDP-8 instruction set. The computer has a serial ALU and is implemented entirely in TTL logic. The book is a compendium of magazine articles from Electronics Australia magazine, giving full technical descriptions and constructional details for the computer and a number of peripheral devices including serial IO hardware such as magnetic tape and paper punch interfaces, keyboard and keypad.

My computer (thus dubbed “EDUC16”) is based on the same basic architecture, but expanded significantly - 16-bit rather than 8-bits, a "Link" AC-carry register to facilitate multiple precision arithmetic, much expanded serial I/O facilities, the addition of memory-mapped parallel I/O, firmware R.O.M, much larger memory, a greater number of micro instructions and expanded combinations, etc, etc....

[GK]

Here's an exercise that shows why you need indirection: write a subroutine to save 100 temperature readings in a table in memory.  Get each reading by calling a subroutine named TEMPRD that returns the latest reading in the accumulator (don't worry about writing that one).  You will discover that it is very hard to store values in consecutive memory locations on a machine that doesn't have either indexing through a register or memory indirection.

Yes, I am sold on the indirect addressing. It was silly to omit the "defer" machine state used for indirect addressing anyway, as the hadware was simplified only very minimally. Although it is not in my current specification an auto indexing register may also be on the cards in the future. All that needs is an additional 16-bit counter and some minor additional control logic.

[GK]

OK, now I have completed the front panel layout:

https://www.eevblog.com/forum/projects/homebrew-digital-computer-system/?action=dlattach;attach=101246

I have increased the MA and PC counters from 13-bits to 16-bits as the memory has grown from 8192 words to 65535, adding the 3 additional indicator LEDs for both registers. I have also updated the switch register legend to indicate the indirect bit for the memory-reference instructions. A silly oversight the first time around was to forget the machine state status indicator LEDs. These (run/fetch/defer/execute) have now been added (top right hand corner of the panel).

As mentioned previously, this computer is going to be built into a 19" relay rack. There is going to be a little carpentry involved as the front panel is going to be mounted at an angle of 45 degrees, protruding from the front of the cabinet with a miniature table immediately beneath and in front of. The idea is that you can pull up a chair to the control panel and have a small space for a pen and paper.

[dfmischler]

(my ALU and the majority of the data busses are 1-bit serial, aka the PDP-8/S architecture).

Oh good grief - how did I not know about that machine already?  The design I'm working towards is a bit-serial contraption, too, which I knew couldn't exactly be novel - but I hadn't researched it in enough detail to discover DEC had built one...

(Actually that's cheered me up no end - they all said I was mad - well, who's mad now?!

The bad news is that the PDP-8/S did not do well in the marketplace.  It was not quite completely capable of running straight 8 programs, and was too slow.  In fact, it was so slow that it could not successfully operate certain common DEC mass storage peripherals (e.g. TU-55 DECtape transport).

The Data General Nova, on the other hand, was sold as a 16-bit minicomputer but the original model actually had only a 4-bit ALU which had to cycle 4 times to complete each 16-bit operation.  Due to newer technology, It was cheaper and fast emough, and beat the competition on price/performance, so it did OK.

[Dave Turner]

On a lighter note a friend of mine, in the 70's acquired an early PDP, 8 I think, which substituted as his room heater.

Ferrite core memory too no less.

[GK]

Each master-slave flipflop looks like a pair of transparent latches, and one is transparent while the other is latched i.e. one is controlled by the clock, the other by the inverted clock. The signal between these two can also be thought of as storing a bit; so effectively your 12-bit shift register clocked on one edge is a 24-bit shift register clocked on both edges. You only need one (more powerful) inverter to generate an inverted clock for every other latch.

Yes, that is how it works, but the data stored on the slave flip-flops is delayed by a clock cycle, so those 12 "extra" bits are not part of the valid output.
A data flip flop with an edge-triggered clock input is always comprised itself of a master transparent latch and one or more transparent slave latches to provide the clock-edge "instant" memory. However the composite edge-triggered flip-flop thus created (which is the building block for the synchronously-clocked shift register) is not itself transparent. The flip-flops of a synchronous shift register must not be transparent, but edge-triggered for proper operation. 

Consider the simplest shift register of them all  , a 1-bit divide by 2 counter:



At the instant the clock input goes high, the logic state of the NOTQ output, as presented to the D input, is transferred to the Q output. This simple circuit cannot work with a data flip-flop that is transparent. The state of the D input at the rising edge of the clock must be latched into a slave memory before the logic state change has a chance to propagate through to the NOTQ output. In other words, the edge-triggered flip-flop must retain a memory for the previously clocked logic state.

I should correct myself on two points here. Upon further reading the convention appears to be to use the terms "master" and "slave" the opposite way around to what I did. Also the correct name for a DFF is delay flip-flop, not data flip-flop. 

Anyway, here is the DTL positive-edge-triggered delay flip-flop with asynchronous preset and clear that I have settled on for the basis of my registers. It is functionally equivalent to the TTL 7474.



To this DTL DFF circuit I have deliberately added a controlled CLK-IN-to-Q-OUT propagation delay by means of R618/R619 and C169/C170, for reasons explained in a bit.

With the addition of 16 NAND gates and 10 inverters, 16 of the DFF building blocks form the complete register of my Program Counter. SR0 through SR15 are the parallel-load inputs from the Switch Resister (the 16 data-input toggle switches on the computers front panel). Parallel outputs PC0 through PC15 are exclusively used for illuminating the PC register LED's on the front panel. The computers architecture is serial, and communication between the PC and other registers is serial. The PC is incremented by circulating the data from the PC through the serial adder of the ALU and then back into the PC while reading the contents of the PC out into the MA (memory address register). A carry input flag for the serial adder is initially set to 1 during this process, thus the PC is re-loaded with its original data + 1.



The clock, preset (now actually parallel-load) and clear control inputs are divvied up with the inverters for fan-out/drive capability reasons. Here is a complete simulation of the register in action:




At t=0 the CLR.H control input (uppermost trace) is asserted, resetting all of the registers flip-flops. At t=3uS the PRESET.L is asserted, loading the contents of the SR (1000100010001000 bin ) into the register. At t=5uS the clock cycles begin and the data is sequentially shifted out LSB first. In this simulation I have routed the serial data output to the the serial data input, so the loaded 16-bit word just keeps circulating around the register.

The PC register complete is comprised of:
764 diodes
122 transistors
489 resistors
and 139 capacitors (not including bypass).

This is too much to fit onto a single PCB card. The reason I added the increased clock-to-Q propagation to the DFF design is to ensure that the complete logic of the register is robust when built in the real world. The potential issue is that the master clock to the DFF's, which is divvied up into to 4 sets of 4 due to fan-out, may not clock all 16 flip-flops in entire synchronicity. Suppose (just for example) you hang a 1:1 oscilloscope probe off one of the 4 clock lines. The load capacitance from the probe and lead will delay the rising edge of the clock to the associated 4 flip flops of the register. If that clock has been delayed enough such that a logic state change of the Q output (of the DFF immediately preceding the first DFF of the clock-delayed bank) has already propagated through, the first DFF of the delayed bank will latch to an incorrect logic state. Recall that the correct operation of an edge-triggered DFF relies upon the fact that the logic state of the D-input is internally committed to memory before being transmitted to the "slaved" Q (and Not-Q) outputs. There isn't an issue if you're just wiring up a single DFF, with Not-Q wired to D, to act as a divide-by two counter, but things potentially get a little more tricky when wiring up an bunch of DFF's to behave as a shift register as clock skews between DFF's can screw things up.

Adding a clock-to-Q propagation delay to each DFF sufficiently long in duration to accommodate a worse case synchronous clock skew between DFF's solves the issue. The amount of delay I have added with the component values in the presented DFF circuit is conservative. There is ample delay to cope with sever clock skew, which should, in my estimation, make the real-world implementation totally robust.

To experiment in the simulation of the register, I loaded one of the clock lines after the respective inverter with a capacitance (C7):



Recall that the DFF's are positive-edge triggered. The active positive-edge of the clock is thus delayed by C7 charging through pull-up resistor R487. I have to increase the value of C7 to 450pF before the register can be induced into shifting false logic states.

I hope that is all making sense out there  I am about to start the PCB design for the cards of this register.

[bwat]

How much effort do you reckon will be needed for test? I'll be finished with the testing of a 16-bit CISC CPU implemented in Verilog this week and the whole testing process was a grind. Testing the individual modules was easy enough but testing each instruction then all of the addressing modes - ooofffff. It seems a third of the 250-odd microinstructions were incorrect. Doing this in Verilog with a simulator was a chore so I can't imagine what it's going to be like for you. More power to your elbow!

[amyk]

Could ECL be a simpler choice of logic family? I know it uses more power, but it's much faster and the gates take fewer components; you also get inverters and OR for free. Here's D flip-flop:

[GK]

Could ECL be a simpler choice of logic family? I know it uses more power, but it's much faster and the gates take fewer components; you also get inverters and OR for free. Here's D flip-flop:

I haven't studied that circuit but is it transparent or edge-triggered? The circuit is simplified somewhat. For example the long tail pair current sources need a bias supply and emitter resistance, and the circuit would probably need to be increased in complexity significantly to add preset and clear inputs. Also for a discrete implementation the increased speed over DTL in synchronous circuits is not what you really want. For example the the clock skewing issue I mentioned in my prior post has to be handled by increasing the propagation delay of the DFF. For synchronous circuits such as shift registers the faster the DFF the greater the difficulty with clocking, timing and layout.

As a matter of fact, even in IC form it's an issue! To get around the problem I described designers of ECL IC's actually slowed down their circuits as well - but by limiting the slew rates rather than the internal gate propagation delays. From The Art of Digital Design, second edition, Prosser &Winkel, chapter 12, page 472:

"d. In the most convenient ECL family, the rise time of the gate outputs is purposely made slower than the internal propagation delay. This simplifies the clocking  of synchronous circuits and greatly reduces electrical crosstalk."

[GK]

How much effort do you reckon will be needed for test? I'll be finished with the testing of a 16-bit CISC CPU implemented in Verilog this week and the whole testing process was a grind. Testing the individual modules was easy enough but testing each instruction then all of the addressing modes - ooofffff. It seems a third of the 250-odd microinstructions were incorrect. Doing this in Verilog with a simulator was a chore so I can't imagine what it's going to be like for you. More power to your elbow!

Well I only have 13 microinstructions rather than ~250. I think writing some test programs to thoroughly test out the operations will be a lot less of a bother than actually designing and building the hardware!

[bwat]

Well I only have 13 microinstructions rather than ~250. I think writing some test programs to thoroughly test out the operations will be a lot less of a bother than actually designing and building the hardware!

Really? How many instructions then? I thought the PDP-8 had quite a few instructions and if it's a microcoded control unit it would need at least a few microinstructions per instruction and microinstructions for instruction fetch and interrupt polling. How do you get away with so few?

Edit: I've just checked and my microprogrammed GCD machine has 6 microinstructions, nearly half of your CPU.

[GK]

Well I only have 13 microinstructions rather than ~250. I think writing some test programs to thoroughly test out the operations will be a lot less of a bother than actually designing and building the hardware!

Really? How many instructions then? I thought the PDP-8 had quite a few instructions and if it's a microcoded control unit it would need at least a few microinstructions per instruction and microinstructions for instruction fetch and interrupt polling. How do you get away with so few?

I have the same 8 instructions of the PDP-8 and an only moderately reduced number of its microinstructions. To correct myself though I actually have 19 microinstructions if those of the IOT (input-output transfer) instruction are included.

Just like the PDP-8, only two of the 8 instructions have microinstructions (OPR and IOT).

The 6 memory reference instructions are:

AND
Logical and between operand and current contents of the accumulator (AC) register. Result stored in AC

TAD
Two's addition. Same as AND instruction, but performs binary addition (2's complement) rather than ANDing

ISZ
Increment and skip if zero. Content of memory location specified transferred into memory buffer (MB) register, then incremented by 1. Result transferred back to specified memory location. If result has become zero, program counter (PC register) incremented to skip next instruction in-line.

DCA
Deposit and clear AC. Stores content of AC in memory location specified, then clears AC

JMS
Jump to subroutine. Contents PC stored in specified memory location. Content of memory location specified then incremented by 1. Result transferred to PC. 

JMP
Jump instruction. Content of memory location specified transferred to PC.

The OPR instruction, which does not reference memory has the following microinstructions:

IAC
Increment AC (self explanatory)

CLA
Clear AC (self explanatory)

CMA
Complement AC (self explanatory)

RAL
Rotate accumulator left. Contents of AC bit-shifted one step left. This operation includes the 1-bit Link (L) register, treating it as combined 17-bit register with the AC

RAR
As per RAL but shifts right.

SMA
Skip on minus AC. Tests bit 16 of AC. If =1 (indicating a negative number in 2's complement) PC incremented to skip next in-line instruction.

SZA
Same as SMA but PC incremented only if all bits of AC=0

OSR
Logical OR operation between switch register (SR) and contents of AC. Result stored in AC

CLL
Clear Link (L) bit (self explanatory).

CML
Complement L bit (self explanatory).

SNL
Skip on link bit. PC incremented to skip next in-line instruction if L=1

HLT
Halt (self explanatory).


That's a "RISC  " instruction set, but sufficient, with a little coding, to perform just about any major computer operation.

[bwat]

I've done a bit of googling and it seems the PDP-8 term "microinstruction" isn't the same as the "microinstruction" term I was using, in the sense of microcoded instructions. Apples and oranges. At least I can say I've learned something today.

[dfmischler]

Well I only have 13 microinstructions rather than ~250. I think writing some test programs to thoroughly test out the operations will be a lot less of a bother than actually designing and building the hardware!

Really? How many instructions then? I thought the PDP-8 had quite a few instructions and if it's a microcoded control unit it would need at least a few microinstructions per instruction and microinstructions for instruction fetch and interrupt polling. How do you get away with so few?

Edit: I've just checked and my microprogrammed GCD machine has 6 microinstructions, nearly half of your CPU.

DEC referred to the bit-programmed operate instructions as "microprogrammed".  Several bits in the instruction directly control what value gets gated onto the accumulator bus (0, accumulator, complemented accumulator, all 1s), can add 1 to the value, inputs to the shifter for rotating right or left 1 or 2 positions, etc.  However, the CPU was implemented in random logic; there was no microprogram in the current sense of the word.

The bit programmed operate instruction concept appears on the DEC PDP-1, but the 1961 user's manual does not use the term "microprogrammed".  The 1962 PDP-4 users manual refers to the operations controlled by the individual bits as "micro-instructions", and says that they may be "microprogrammed" together.

DEC didn't build a microprogrammed computer, in the current sense of that word, until around 1972; about 10 years later than the usage for the PDP-4/5/7/8/9/12/15.