PDP-11 Opcode map

683 views
Skip to first unread message

jon....@gmail.com

unread,
Jun 30, 2021, 9:12:42 AM6/30/21
to [PiDP-11]
The original 8088/8086 processor manual has a really nice 16x16 table showing which instructions have which leading bytes (with the low nybble labelling the columns and the high nybble labelling the rows). Does anybody know of a table of PDP-11 opcodes in the same format?

Craig Ruff

unread,
Jun 30, 2021, 9:59:04 AM6/30/21
to jon....@gmail.com, [PiDP-11]
There is a numerical opcode list on page D-2 of the LSI-11 PDP 11/03 Processor Handbook 1975-1976 that is pretty succinct.

Sytse van Slooten

unread,
Jun 30, 2021, 10:20:20 AM6/30/21
to [PiDP-11], jon....@gmail.com, Craig Ruff
I've always used the diagram that is in the 11/70 manual, http://bitsavers.trailing-edge.com/pdf/dec/pdp11/1170/EK-KB11C-TM-001_1170procMan.pdf page II-1-34

It's not really a table, but for me it reads easier.



--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/424F7059-4691-42A3-BEDD-B3D41192BB78%40ruffspot.net.

Clem Cole

unread,
Jun 30, 2021, 10:38:52 AM6/30/21
to Craig Ruff, jon....@gmail.com, [PiDP-11]
Craig is right that is a nice listing in a US letter format.
@Craig - This is basically a redo of the tables from the 1975 reference card.  You can find them at: https://www.montagar.com/~patj/dec/pocket/index.htm

@Jon -- remember that the OP Code layout for the PDP-11 is based on octal groupings so tables of 16 do not map as well.  

Jon Brase

unread,
Jun 30, 2021, 6:19:14 PM6/30/21
to [PiDP-11]
> @Jon -- remember that the OP Code layout for the PDP-11 is based on octal groupings so tables of 16 do not map as well.  

The specific dimensions of the table don't matter ship much, it would just be nice to have a map of the opcode space.

Though actually, 8086 opcodes are (mostly) octal as well (the opcode proper for most operations is 6-bits, so 2 octal digits), though boundaries of subsequent fields aren't on 3-bit boundaries, and hexadecimal notation is pretty much universally used when listing the x86 instruction set.

Jun 30, 2021 9:38:51 AM Clem Cole <cl...@ccc.com>:

Johnny Billquist

unread,
Jun 30, 2021, 6:49:52 PM6/30/21
to pid...@googlegroups.com
Sortof similar, but better, is the PDP-11 programming card.
http://mim.update.uu.se/manuals/pdp11/pdpcard.pdf

Also, the PDP-11 layout and usage of the bits in the opcode is way more
systematic than the x86.
You could pretty much memorize most of it with very little effort.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

Jon Brase

unread,
Jun 30, 2021, 7:49:28 PM6/30/21
to pid...@googlegroups.com
What I'm really trying to do is get a feel for the relative sizes and such of various parts of the opcode space, which is difficult to with a listing that devotes the same amount of space (one line each) to e.g, ADD and MUL.

Neil Higgins

unread,
Jul 1, 2021, 1:00:58 AM7/1/21
to [PiDP-11]
Hi. In the case of the PDP-11 there is a better way. Learn the addressing modes - because nearly every instruction uses those same modes. The PDP-11 instruction set is, by and large, a “two operand” instruction set, where each addressing mode applies to each of the two operands. Some people refer to this as an “orthogonal” instruction set. It’s very elegant and very powerful. So, for any given register, you can:
* Address the contents of the register
* Use the register as an address
* Use the register as an index to an offset value (offset follows instruction)
* Use an offset value as an address (offset follows instruction)
And as well, you can automatically pre-decrement or post-increment the register. If you use byte-mode addressing, the register auto-increments or auto-decrements by 1. If you use word-mode addressing, the register auto-increments or auto-decrements by 2.
R7 is the PC
R6 is used as the SP for CALL instructions

So for example:
CLR R1 (zeros R1) - single operand instruction
MOV R1, R2 ; copies the contents of R1 into R2
MOVB R1, R2; copies the low byte (only) of R1 to R2
MOV (R1), R2; copies the contents of the memory location at the address in R1 into R2
MOV 2(R1), R2; adds 2 to the value of R1 and uses that as the source address
MOV (R7+), R2 followed by
.WORD 1234
Loads the value 1234 into R2, which can be shortened to
MOV #1234, R2 (immediate addressing)
and so on.

This way, you can replicate all of the addressing modes found in “primitive” microprocessors like the 8080, and more!

Stack-pointer-relative addressing is the common way of accessing arguments in subroutines after arguments have been pushed onto the stack by the caller.

Have fun. Read some code. You’ll get the hang of it very quickly.

a...@papnet.eu

unread,
Jul 1, 2021, 2:24:08 AM7/1/21
to [PiDP-11]
Since everyone is posting their favourite opcode table, here's mine: http://aap.papnet.eu/pub/pdp/11/pdp1140_inst.pdf
It's the 11/40 instruction set from PDP-11_40_Processor_Handbook_1972.pdf
If you want a full table for all 2^16 instructions, you'll probably have to do that yourself. I don't think I've seen such a thing before.

Anton Lavrentiev

unread,
Jul 1, 2021, 9:59:17 AM7/1/21
to Neil Higgins, [PiDP-11]
Sorry for a bit of a nit picking but:

> MOVB R1, R2; copies the low byte (only) of R1 to R2

Incorrect. Moving a byte to a register sign-extends in the destination (so the former contents of the "upper" part of R2 is always lost: either cleared or set to all 1s, depending on value of the bit 7 of R1)... That's a special rule, and is different from moving to memory (including I/O space) where indeed only the byte specified by the destination is updated.

MOV (R7+), R2 followed by
> .WORD 1234

The correct syntax is "MOV (R7)+, R2"

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.

Johnny Billquist

unread,
Jul 1, 2021, 2:01:23 PM7/1/21
to pid...@googlegroups.com
On 2021-07-01 01:49, Jon Brase wrote:
> What I'm really trying to do is get a feel for the relative sizes and such of various parts of the opcode space, which is difficult to with a listing that devotes the same amount of space (one line each) to e.g, ADD and MUL.

Well, first of all, the opcode space is pretty full on the PDP-11. The
basic instruction set still had a fair amount of space left, but then
came additions like EIS, FPP and CIS.

I would say the PDP-11 programming reference card is still the best
place to find the information, although it does not include CIS.

You have the numerical opcode list on the second page of the card, which
covers the full range. However, it will not give you a good visual feel
of the space left, as it isn't trying to do any kind of proportional
view of it all.

But you don't really want a 256x256 table, since it would be huge, and
not very interesting on a PDP-11. Since so much of the space is used up
by all the different variants of addressing for sources and
destinations, it would become very boring. Also, since the opcodes makes
very little sense to split along the two bytes, such a table would be
more confusing than the opcodes themselves.

Take MOV(B) for example.
There are actually 8192 different variants of it. So that one alone
takes up 1/8 of the whole opcode space. There are in fact 6 instructions
that take two arguments, and all in all, that covers 6/8ths of the
opcode space (MOV, CMP, BIT, BIS, BIC, ADD/SUB).

Basically, the opcodes on the PDP-11 were designed with more of a system
to it than on the x86, and therefore it makes less sense to just make a
matrix with all possible opcodes.

The VAX extended on that idea even further, where the opcodes and
arguments were fully split apart. So there is only one MOVL instruction
on the VAX, and it has only one opcode, and every instruction (almost)
takes just one byte. But then you have a variable number of bytes
following which builds the arguments. And of course, there is also a
MOVW and MOVB (and also MOVQ, can't remember if there is also a MOVO).

Neil Higgins

unread,
Jul 1, 2021, 7:33:49 PM7/1/21
to [PiDP-11]
Thanks for the pickup. My 40yo memories have picked up some bit rot! :-(

On Thursday, 1 July 2021 at 23:59:17 UTC+10 anton.la...@gmail.com wrote:
Sorry for a bit of a nit picking but:

> MOVB R1, R2; copies the low byte (only) of R1 to R2
> Incorrect
… 

Andrew Yeomans

unread,
Jul 9, 2021, 9:01:58 AM7/9/21
to [PiDP-11]
Here's one I prepared earlier. About 35 years earlier!
As others have commented, it's not actually that useful, compared with a simple table, but does demonstrate clearly the orthogonal design.

Another table I used to use came from Jonathan Bowen - now at http://mdfs.net/Docs/Comp/DataSheet/PDP-11.
With "pr -l80 -w 200 -3 -t PDP-11.txt" and the appropriate print scaling, it can fit as 3 columns on an A4 page.
There are many similar pages at http://mdfs.net/Docs/Comp/DataSheet/ for other microprocessors.
pdp11.png

jon....@gmail.com

unread,
Jul 13, 2021, 1:17:21 PM7/13/21
to [PiDP-11]
Excellent! That's exactly what I was looking for, and for my part I find it quite useful. Thank you.
Reply all
Reply to author
Forward
0 new messages