Jump to content

Talk:PDP-11/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1

Instruction set orthogonality

The stuff about orthogonal addressing modes is not completely correct. I think the writer is confusing with the VAX which was (almost?) completely orthogonal. The PDP-11 was not. Most instructions were two address, with one operand (usually the source) allowing all addressing modes, but the other operand had to be a register. The MOV instruction allowed all modes for both operands. There were also some single operand instructions, some no-operand instructions, and a few weirdos that didn't fit the pattern. In all, it was a cleaner than a monstrosity like Intel 8088, but you couldn't call it completely orthogonal. (I don't think i ever wrote any PDP-11 assembler, but i recently translated some into ANSI C. I've also done minor tweaks to an emulator.)

I'm sorry, but you're incorrect. With exception of the floating point stuff and the fact that ADD and SUB must be word-oriented (and not byte-oriented), all of the two-operand PDP-11 opcodes are orthogonal, taking the general form of:
(Byte_Flag) (3-bit_opcode) (6-bit_Source_Specifier) (6-bit_Destination_Specifier)
And both specifiers took precisely the same form:
(3-bit_Mode) (3-bit_Register_Selector)
The supported opcodes were:
  • x1 MOV
  • x2 CMP
  • x3 BIT
  • x4 BIC
  • x5 BIS
  • 06 ADD (only on 16-bit word)
  • 16 SUB (only on 16-bit word)
The (rather limited) Floating Instruction Set, by comparison, implements a stack-oriented machine that always has one of its operands on the R6 stack. And the Floating Point Processor instruction set is, as you say, non-orthogonal, generally having one operand specified by generalized specifier and one operand that must be in a Floating Register. But please realize that both of these were options to the basic PDP-11 instruction set and were designed to fit into the rather-small opcode space allowed by the 16-bit wordlength. (As mentioned in the Orthogonal instruction set article, a fully-orthogonal instruction set isn't very bit-efficient.)
Atlant 13:48, 22 Mar 2005 (UTC)
Things get somewhat less orthogonal with the opcodes added later on, like MUL and XOR; those take a register plus a general operand. Paul Koning 20:00, 17 March 2007 (UTC)

Is that the index addressing mode, which uses an index word following the instruction word, can only be applied to only one operand? enjoy

No, it could be applied to either operand. Guy Harris 01:34, 16 March 2006 (UTC)
Not just either, but both operands. Constructs such as MOV 2(R2),4(R3) were entirely valid, and would assemble (in octal) as 016263; 000002; 000004 Xarqi 11:53, 2 October 2007 (UTC)
FIS has both operands on a stack, and delivers the result on the same stack. The register operand just denotes which register holds the stack pointer. There is a different instruction set extension EIS, which is implemented in all processors since the 11/40, which fits the above description of non-orthogonality. EIS contains fixed point multiplication and divison, and arithmetic shift. The register operand of MUL and DIV instructions is a set of 2 registers, if the register is an even numbered one. --Glasreiniger 08:12, 16 March 2006 (UTC)

Cleanup?

PDP-11 was flagged as needing attention because "this needs to be more easily understood".

Though it is a bit dry, I had no trouble understanding the article. Its terms appear to be well-defined.

What parts must be more easily understood??

[207.112.115.248]

If you are an assembly language programmer, it is perfectly clear. But most folks are not.

I think PDP-11 needs two more sections:

  • On the social significance of the machine. Who used it? What did they do with it? What new feats did it enable? What was its market niche?
  • Why did DEC build it? (The article almost answers this.) Why did they drop it? Is it associated with struggles within DEC? Did it make money for DEC? (Those of us who were fondly dependent on one or more DEC machines are deeply interested in this sort of thing.)

[207.172.11.147]

The section "Decline of the PDP-11" asserts a design deficiency that eventually made the model uncompetitive. The second, parenthesized, paragraph gives details of a programming project (too detailed for this location, I think) for the purpose of providing a counterexample. I'm too new here to delete someone else's contribution, but the solution seems to be for the statement in the first paragraph to be less categorical. --Spike, Brentwood NH

—Preceding unsigned comment added by 24.60.78.79 (talk) 15:33, 18 October 2008 (UTC)

Hearing no objection, (!) I'll tackle this today. --Spike-from-NH (talk) 19:14, 27 October 2008 (UTC)

I've finished sprucing up architectural details of the PDP-11 and PDP-8. I found text in the present and past tense; my guess is that the present is used for implementation facts (which would still be true if you were to locate a machine) and the past is used for conventions and implications on programmers (who presumably are mostly in the past). Not sure this guess is correct, nor that my additions are totally consistent. --Spike, Brentwood NH

PDP-11 application areas

I am aware that the PDP-11 had the following types of applications in the 1980's:

  • Academic institutions used them to train scientists and engineers in computer programming. The PDP-11 had a great little Fortran compiler and could service multiple terminals in a computer lab.
  • They got used as remote communications processors to control printers etc. connected to mainframe computers.
  • Siemens used duplicated-redundant PDP-11's to operate their telex exchanges.

I suspect that they also got a lot of use in industry as numerical machine or industrial process controllers. Basically the PC became more powerful and cheaper for the single user and industrial applications and the VAX was the natural upgrade path before computer servers came along. kiwiinapanic 10:19 Jan 20, 2003 (UTC)

That's a tiny fraction of the applications. Here are some more:
  • General timesharing (e.g., RSTS/E, IAS
  • Process control systems
  • Embedded controllers
  • Turnkey applications (e.g., Typeset-11)
  • Commercial data processing systems (CTS-300, CTS-500)

and so on. Paul Koning 20:00, 17 March 2007 (UTC)

I agree that it could use the sections suggested above (significance, and why it died). Alas, I don't have time to add them now - I just used my quota fixing the technical content! I'll add a bit about the second, though.

As to the technical content, a couple of fixes: the devices really did put an address on the bus (at least on the Unibus, haven't checked my Q-bus manuals); manuals show the interrupt vector being gated onto lines D02 through D08. The Unibus was a real bus, not just a backplane (old-timers will remember those long flat white Unibus cables), and although I don't recall using them for the Q-bus (perhaps for analog reasons), the Qbus really was a bus, not just a backplane. There were also 4 interrupt levels, BR4 through BR7; there was also the DMA-only NPR (you could do DMA on BR levels, but I don't know of any devices that did).

Sorry about all the extra RETURNs, and the numerous versions to fix them; I can't break the automatic habit of typing RETURN when I get near the end of a line!

Noel 16:06, 2 Mar 2004 (UTC)

I added information on interrupts (and many other things), but today checked my PDP-11 Reference Card, which lists no device that used BR7. Was about to "correct" the article, until reading your comment. Was there a BR7/BG7? Did any device use it?

--Spike-from-NH (talk) 20:38, 26 October 2008 (UTC)

Physical packaging

The article contains the following text:

Finally, the PDP-11 was designed to be produced in a factory by semiskilled labor. All of the dimensions of its pieces were relatively noncritical. All parts of the computer chassis were constructed from injection-molded plastic, or bent steel rod (lighter than sheet metal). It used a push-bonded backplane. That is, the printed circuit board plugged into a backplane connector. The backplane connector had terminals that could be connected by pushing wires into them. The terminal would cut the insulation around the wire and bite into the wire to for a gas-tight (i.e. corrosion-proof, therefore reliable) connection. The connector blocks were very similar to telephone connection blocks. The case was injection-molded plastic that snapped over the steel-rod chassis.

Does anyone have any idea what that paragraph is trying to talk about? It clearly contains a few things that are true; some '11s did use a bent-wire frame, many '11s used automatic wire-wrapping for some portion of their backplane wiring, etc., but the paragraph as a whole seems to have a fairly loose grip on reality, and certainly doesn't reflect the original PDP-11 implementation.

If no one chimes in, I'll eventually take a crack at cleaning it up, but the whole topic will be somewhat lengthy as a number of radically different packaging technologies were used by the various PDP-11 models.

Atlant 17:15, 8 Feb 2005 (UTC)

Iskra Delta 800: Clandestine clone or not?

I started collecting information about historical computers and creating related articles. So I stumbled upon Iskra Delta 800, which is said to be PDP-11/34 compatible with some extensions, developed by Iskra Delta but using actual J11.

Iskra Delta was a company from Yugoslavia, which was not behind the "iron curtain". I do not recall making completely unlicensed clones (like behind the curtain), although it is quite possible that using original components one would make a compatible computer (the components themselves were not copied). Peripheral devices were often not produced at all and originals were used. Read about that just a tad bit more in History of computer hardware in the SFRY.

Does anyone have more information on this or can provide some guidance? My searches for PDP 11 "compatibles" yielded no results other than Iskra Delta 800 - was it really the only official non-clandestine one?

--Aleksandar Šušnjar 15:21, 14 April 2006 (UTC)

As far as I know Digital never licensed the PDP-11 to anyone, so all clones are clandestine. Paul Koning 20:00, 17 March 2007 (UTC)

PDP-11's Influence on the Design of C

At the top of the article, it is mentioned that the PDP-11's instruction set influenced the design of C. However, I do not see any evidence to support this claim given in the article. Could someone who knows what these alleged connections are possibly add a section about them?

Done! -- RoySmith (talk) 22:08, 26 June 2006 (UTC)
You're mistaken[1]. --StuartBrady 22:59, 26 June 2006 (UTC)
Thanks for the correction. -- RoySmith (talk) 23:57, 26 June 2006 (UTC)
Thanks. It's been reverted, though!
Just to clarify: the ++ and -- operators were a feature of B (C's predecessor), which was developed on the PDP-7. Dennis Ritchie himself says this (see under "More History") on the page that I linked to above. --StuartBrady 11:59, 30 June 2006 (UTC)
There are several possibilities. Of course, it is not the ++ and -- operators, which are suspect to be inspired from the PDP11, but the idiom of using the autoincrement/decrement modes for pointers like *p++ and *--p (and to avoid the syntactically valid *p-- and *++p). Probably more characteristic is the omission of single precision floating point numbers in C. This was due to the fact, that the whole machine has to be switched between single and double (via PSW flag). --Glasreiniger 12:36, 30 June 2006 (UTC)
The point about *p++ is nonsense. C has "float" and "double". --StuartBrady (Talk) 13:00, 30 June 2006 (UTC)
Cool down, please. C has float, but only for storing single precision. In V6 C, FP operations are done in double, always. --Glasreiniger 19:27, 30 June 2006 (UTC)
I'm quite calm. As far as I can tell, that simply not true anymore. --StuartBrady (Talk) 21:31, 30 June 2006 (UTC)
It's not true anymore, but the PDP-11 isn't the primarily platform for C anymore, either. :-) It was true at the time that the PDP-11 was the primary platform, and the PDP-11 might have influenced that aspect of C. The ANSI C standard was developed at a time when PDP-11's were no longer the primary platform for C, so the standards folk might have decided it was time to allow float arithmetic to be done in single precision. (My copy of the standard is at home, so I don't have it handy, but I can check whether the Rationale discusses that.) Guy Harris 22:30, 30 June 2006 (UTC)
Right. :-) I was reading section 6.3.1.8 in C99, and it appears that the implementation is still free to do arithmetic in double precision.
It doesn't seem fair to say that the PDP-11's instruction set has any influence on modern C (which is currently implied)... and I don't think the instruction set's influence on early implementations is especially noteworthy, as all implementations of C are influenced by whatever architecture(s) they run on. --StuartBrady (Talk) 23:11, 30 June 2006 (UTC)
I just looked at my pdp 11/45 processor handbook; the 11/45 at least, had float and double versions of most of the floating point instructions. There were some of the earlier machines that had a less sophisticated FPU; it's possible they had a PSW mode bit to switch precisions, but the 11/45 certainly didn't. -- RoySmith (talk) 23:56, 30 June 2006 (UTC)
So what did the SETF and SETD instructions do? Guy Harris 01:25, 1 July 2006 (UTC)
Sigh. I should have read the book more carefully. SETF and SETD do indeed set/clear a bit in the FPP status register (not the PSW). This bit then determines whether FP math is done single or double. -- RoySmith (talk) 02:24, 1 July 2006 (UTC)
IMHO it is self-evident that any modern C development is not influenced by the PDP-11. Nobody has implied this. But in the early development phase, the embryonic state of C, the PDP-11 was the most influent of the machines used for C and Unix development. Another point, where the PDP-11 heritage is clearly visible, is the rule that only 3 register declarations were effective in a function body. IRC these were the PDP-11 R2,R3,R4, as R0,R1 were reserved for scratch, R5 for global addressing, and R6, R7 for stack and programcounter. Nowadays register declarations are faily useless. --Glasreiniger 18:00, 3 July 2006 (UTC)

I'll apologize here for reverting StuartBrady's note regarding this. I did not see the reference, was working quickly, and should not have reverted. I was wrong, he was right, and I apologize. -- Gnetwerker 19:27, 10 July 2006 (UTC)

This discussion resolved the issue incorrectly. Quoting Dennis Ritchie from http://cm.bell-labs.com/cm/cs/who/dmr/chist.html:

"People often guess that they were created to use the auto-increment and auto-decrement address modes provided by the DEC PDP-11 on which C and Unix first became popular. This is historically impossible, since there was no PDP-11 when B was developed."
"Even the alleged similarity between PDP-11 assembly and C is apparently "a folk myth, pure and simple, which continues propagating because its a handy sound bite, not because there is any truth to it whatsoever."

Any other conclusion not supported by citation not only contradicts the creator of C, but also constitutes original research.

However, since the folk myth is so widespread, it would be appropriate for the article to specifically say that it is a folk myth, rather than go through a predictably infinite process of revert/unrevert.

Still, the main point is that Dennis Ritchie says that C was not influenced by the PDP-11 assembly, which contradicts what the article has been saying since July. Dougmerritt 3:48, 19 December 2006

Let me cite from Ritchie:
Second, although the original PDP-11 did not provide for floating-point arithmetic, the manufacturer promised that it would soon be available. Floating-point operations had been added to BCPL in our Multics and GCOS compilers by defining special operators, but the mechanism was possible only because on the relevant machines, a single word was large enough to contain a floating-point number; this was not true on the 16-bit PDP-11.
Finally, the B and BCPL model implied overhead in dealing with pointers: the language rules, by defining a pointer as an index in an array of words, forced pointers to be represented as word indices. Each pointer reference generated a run-time scale conversion from the pointer to the byte address expected by the hardware.
For all these reasons, it seemed that a typing scheme was necessary to cope with characters and byte addressing, and to prepare for the coming floating-point hardware. Other issues, particularly type safety and interface checking, did not seem as important then as they became later.
This looks pretty much like a manifest influence from PDP-11 to some C developments. —The preceding unsigned comment was added by Glasreiniger (talk • contribs) 10:04, 5 January 2007 (UTC).
Well, not exactly, at least not as previously claimed. Carefully reading the quote you provided, it seems clear that Ritchie is saying that consideration of several issues lead to C being typed, rather than untyped as was BCPL. Yes, the issues in question were hardware related, but note that none of that is what the main article was saying. The latter was indeed a folk myth. If you are saying that you would like to add to the main article a note saying that C became a typed language due to consideration of PDP 11 architectural issues, that seems potentially supported by the above quote (but is a different issue, at least in its particulars, than previously discussed).
What fits and does not fit in a machine word has been historically important in many contexts, e.g. the fact that "two (18-bit) machine addresses fit in one (36-bit) machine word" had a very, very important influence on Lisp, much more centrally important than the historical accident that lead to the infamous names "car" and cdr". Similarly here with C: it would have been literally unfeasibly inefficient to ignore the issue that the target architecture had byte-oriented pointers and that high precision floating point required two machine words rather than one -- true enough, but rather different than the usual claims about C increment/decrement etc. being derived from the PDP 11 instruction set (which, as mentioned at top of page, previously appeared in B on the PDP 7). Dougmerritt 04:17, 23 January 2007 (UTC)
Ritchie's article directly contradicts the "myth" of the increment/decrement operators. It does not address the "myth" about float vs. double. It may be that the "myth" is in fact true, or it may be false, but a different citation would be needed to settle that. For what it's worth, the PDP-11 floating point processor supports both types, but it requires a mode switch instruction to select the one or the other. Paul Koning 21:42, 5 September 2007 (UTC)

"Last Remaining" PDP-11

An anon inserted a claim that an Australian transit system was the "last remaining" PDP-11 installation. I know personally that there are many PDP-11s in process-control systems that are still in service, but this is OR, as was the original insertion. I have edited it to simply state that the system in question is still in service (though this is unsourced) rather than remove it. Feel free to provide cites, revert, whatever. -- Gnetwerker 17:22, 5 October 2006 (UTC)

The section mentions something called "Swedish PASCAL". Being Swedish, I can't help wondering what this is. Is that some variant of PASCAL that's not widely known, or is it just some editor that confused Sweden and Switzerland? (which would not be very rare) —The preceding unsigned comment was added by 83.248.152.18 (talk • contribs) 15:48, 11 October 2006 (UTC).

It's "the first public domain Pascal compiler for the DEC PDP11/70 minicomputer", according to http://www.uni-koeln.de/~al001/basp5.html. Given that its author's name was Seved Torstendahl, according to http://www.ibiblio.org/pub/academic/computer-science/history/pdp-11/decus/11s007.html, I suspect the "Swedish" refers to the nationality of the author.
(Google is your friend.) Guy Harris 23:20, 11 October 2006 (UTC)

I added some "citation needed" tags -- this isn't meant as a black mark, just a note to all of us here that we need to try to find some sources. I think the additions are, in general, good. -- Gnetwerker 23:45, 17 November 2006 (UTC)

PDP-11 Self-Propagating Instruction

I have fond memories of the PDP-11. As a consequence of the architecture, the instruction set contained as a valid instruction, "MOV -(PC),-(PC)". When encountered, this instruction propagated itself backwards through the machine's memory, all the way to Address 0. Sometimes, this complicated debugging, since the offending code could be wiped out. On the other hand, it made a handy memory diagnostic. You toggled an "012727" into the highest location in memory, and hit "Run". If there was a serious memory failure, you could find it by toggling in various addresses to examine, and seeing how far down the "012727's" had propagated.

Alan Hochberg 19:17, 12 July 2007 (UTC)hochbeam

It's 014747, but apart from that, yes indeed, that was a neat trick. Paul Koning 21:44, 5 September 2007 (UTC)

Difference between EMT and TRAP?

So the one is called "trap", and the other "emulator trap". What is the actual difference here? Also, how do these traps work? The 68k will take a value from the trap you specify and stick it into the PC to that the cpu effectively enters an error handling routine. Does the PDP-11 do a similar thing? Wilsonsamm (talk) 10:44, 15 February 2008 (UTC)

It uses the same stack mechanism as interrupts - which was a feature that the 69k imitated. Tedickey (talk) 12:00, 15 February 2008 (UTC)
From a hardware point of view, there was no difference between TRAP and EMT. But the software typically used them for different purposes.
Atlant (talk) 13:14, 15 February 2008 (UTC)
There is one difference: they trigger different vectors. If I recall correctly, there is also a very small obscure difference: something like the priority of interrupts taken if several pending interrupts are present differs between the two instructions. —EncMstr 17:07, 15 February 2008 (UTC)
Yes, of course the vectors vary. And I'm sorry, but I don't have my microcode listings handy so I can't say whether there is a definite "interrupt priority" between the two. (I wonder if I still have my 11/34A and 11/23/24 microcode listings...)
Atlant (talk) 17:44, 15 February 2008 (UTC)
The notion of "priority" doesn't really apply here. They are exceptions, not interrupts, in the sense that some other computer architectures make the distinction. Or "synchronous traps" vs. "asynchronous traps/interrupts". Any one instruction can only be an EMT or a TRAP, not both, so there isn't any priority. Indeed, the hardware difference is that they go to different vectors (EMT to 030, TRAP to 034). What happens then is up to software. The low byte is ignored by the hardware. Software typically uses it as a request code; it picks up the saved PC, subtracts 2, and reads that word (that's the instruction) to get the low byte. Paul Koning (talk) 22:46, 15 February 2008 (UTC)
Yeah, it was a priority thing, but not that kind. It was that either EMT or TRAP, but not the other, would execute the instruction first, then field any pending interrupt. Or maybe it was the order of the trap status word flag was altered? Whatever it was, it almost never mattered what the distinction was in a real application. 22:52, 15 February 2008 (UTC) —Preceding unsigned comment added by EncMstr (talk • contribs)
Trap status word flag -- that's the trace trap. Are you thinking about the distinction between the RTI and RTT instructions? They are the same except for the treatment of the T bit. Paul Koning (talk) 22:55, 17 February 2008 (UTC)

What? EMT and TRAP trigger different vectors? I was under the impression that you could specify the vector to use by doing EMT 277 or TRAP 277. Now when the CPU encounters these traps, what actually happens? does it simply pop R7 onto -(R6) before moving the word in (say) o277 into R7? —Preceding unsigned comment added by 86.144.16.111 (talk) 17:03, 20 March 2008 (UTC)

No, the trap vectors for each kind of trap or interrupt were fixed (by a combination of hardware and microcode). But the low byte of the TRAP and EMT instructions wasn't interpreted by the hardware so by referencing -2(SP) the TRAP- or EMT-servicing routine could read the opcode that invoked the TRAP or EMT. It could then dispatch ("case") based on the low-byte of that opcode. Typically, IIRC, the operating system used the EMT instructions and TRAP was available to the user.
(Note that the access to the opcode was more-complex when memory management was in use as it usually had to refer back to the processor mode that was in effect when the TRAP or EMT was executed, not the processor mode of the TRAP- or EMT-servicing routine.)
Atlant (talk) 17:13, 20 March 2008 (UTC)

Use of term "virtual address space" for 64k addresses

Applied to the 128k (and higher), it's easy to see. But applying it to the 64k address space requires some better explanation than "no", as expressed by User:Jeh Tedickey (talk) 11:22, 16 September 2008 (UTC)

Can anyone explain this comment to me? :) (bqt@softjar.se) --212.112.174.86 (talk) 17:44, 23 September 2008 (UTC)
Well I did write more than "no" in the summary, but on later read the summary says nothing the text didn't. My bad.
Sure... First, "physical address space" always means the actual, directly-addressable RAM addresses, after translation, mapping, whatever—the bits that go out on the memory bus. Now when memory mapping is turned on, the 64K worth of addresses that can be asserted by a running program, the addresses that appear in the 16-bit Program Counter or Stack Pointer register or any register used for deferred addressing, pointers stored in memory, etc., are before translation or mapping. Therefore we can't call those physical addresses. So we need a different word for them.
It's true that the PDP-11 architecture handbook doesn't use the term "virtual" there. But "virtual" is what we always called the pre-translation addresses in the PDP-11 forums around DECUS. In fact it was a point of some amusement that the machine's virtual address space was smaller than the typical installed RAM, the opposite of the (much better) situation on the VAX.
I frankly don't remember what the official name was, and it's possible DEC didn't come up with one. I have emailed the question to a PDP-11 expert and amateur computer archivist; he should know.
I'm thinking that the term "logical address space" might be better here, though, as it doesn't imply the possibility of paging (as "virtual" does)...and of course the PDP-11 did not have paging, i.e., there was no concept of a virtual or logical address being mapped to a page not currently resident in RAM.
The separate I & D space feature of course gives you two 64K virtual, or logical, address spaces, one for instruction references and one for data. The MMU automatically selects the "I map" or the "D map" depending on where the address came from: If from the PC, that's of course the I map; if the SP, the D map; I don't remember the other rules.
One other point: I removed the comment about 8 KB I/O space because that encroaches upon the physical address space, not the virtual (or logical). A program running with mapping enabled on a PDP-11 really can see a full 64KB (wow! a whole 64K?! :) ) linear address space that is mapped to 64K of RAM. (Or 64K I space plus 64K D space, on processors capable of that.) There's no need for the I/O space to be mapped into your task's address space as long as you rely on the O/S and drivers to do your I/O for you.
I hope all this helps; if not, please ask further.
So... shall we change it from "virtual" to "logical"? Jeh (talk) 19:14, 23 September 2008 (UTC)
Looks like the answer is "virtual" after all! My memory was flawed. My friend replied with this quote from the doc:

"When the PDP-11/45 Memory Management Unit is operating, the normal

16 bit direct byte address is no longer interpreted as a direct Physical Address (PA) but as a Virtual Address (VA) containing information to be used in constructing a new 18-bit physical address. The information contained in the Virtual Address (VA) is combined with relocation information contained in the Page Address Register (PAR) (see 6.4) to yield an 18-bit Physical Address (PA)."

That's from the PDP-11/45 Processor Handbook (1975), chapter 6, "Memory Management", section 6.2, "Virtual Addressing". Later PDP-11's of course supported up to 22-bit physical addresses. So there you have it. Jeh (talk) 05:39, 24 September 2008 (UTC)
That's more/less what I pointed out first (for 128Kb configurations, it's virtual). But the base configuration had 64k addressing, 56Kb memory. (Most of the PDP-11's I used had only that - or less). Tedickey (talk) 15:41, 24 September 2008 (UTC)
But even on a system without separate I & D space (or without that feature enabled) you can have your 64K virtual mapped to an assortment of 8K pages somewhere in a larger physical space - assuming the system supported more than 16 bits of physical address space, of course. If the 11's you worked on had 64K or less RAM they may have been 16 bit physical. Jeh (talk) 16:01, 24 September 2008 (UTC)
yes - most of them were 16-bit physical addresses, e.g., running RT-11 Tedickey (talk) 16:08, 24 September 2008 (UTC)
And to just make one point clear here. The PDP-11 could very well support a demand paged system (which is a different topic than virtual memory). The MMU have pages, and you can have pages that are invalid, and which causes a trap to the OS when referred to. And the OS can then change the mapping information for that page and restart the instruction. Hmm, maybe a clarification of the difference between virtual memory and demand paging should be written (or maybe one exists, I haven't checked). Lots of people seem to confuse the two nowadays. But I don't think that topic strictly belongs in an article about the PDP-11. However, several PDP-11 operating systems supported the use of virtual memory, but none ever implemented demand paging (as far as I know). The hardware could however do it. /bqt@softjar.se --212.112.174.86 (talk) 16:42, 30 September 2008 (UTC)
Demand paging a PDP-11 was dependent on which model you were using. Not all PDP-11s provided a "dirty" bit for each page. The J11 did, and I did implement demand paging on a Q-Bus system with a PDP-11/73 board as a side project while working at DEC in the early 1980s. It didn't work well because I had a rather slow winchester disk and I suspect my page replacement strategy was not very good. I forget all the details, and the BLISS-16 code I wrote was lost when I left DEC. Filker0 (talk) 00:08, 9 June 2018 (UTC)

"No dedicated I/O bus" is inaccurate

That statement is true for a few of the early models, like the 11/20. It is not true for the later, higher performance, models, starting with the 11/45 and much more obviously so for the 11/70. In the 11/70 there are two I/O buses (Unibus and Massbus), plus a memory bus.

That said, it is true for all of them that there are no dedicated I/O instructions and the I/O devices are memory-mapped. The same is true in many other processor architectures, whether they have a unified bus or not. Paul Koning 20:00, 17 March 2007 (UTC)

PDP-11s still in service?

Per previous editors comments I'm removied the following section from the article. I'd love to know if any of these stories are true, but they need verification to be in the article.--agr 15:28, 8 July 2007 (UTC)

The computer system in the METROL metropolitan train control centre in Melbourne, Australia is still in regular commercial service[citation needed]. This system runs an operating system coded in Swedish PASCAL for the creation of train timetables, fleet management and passenger information displays. Several nuclear plants around the world, including Canada, the Netherlands and Sweden, still run PDP-11s.[citation needed] Many research institutions still regularly run PDP-11s for data collection or instrumentation control[citation needed]. Australia Post still use PDP-11/93's running RSX-11 on some of their older Optical Character Recognition machinery[citation needed]. Flight simulators (such as the 747 operated by MK Airlines) use a PDP-11[citation needed]. Computer Organization and Programming course at the Technion is still being taught using PDP-11 Assembly[citation needed].

Some number of years ago, 2007 I think, the actual DEC PDP-11s were replaced with Strobe Data's (strobedata.com) Osprey Co-processor series, a PDP-11 "clone" authorized initially by none other than Ken Olsen himself. Metro currently uses approximately 20 Osprey/DX Co-processors, ISA, 2X PDP-11/93-94 instruction throughput, Legacy Unibus I/O supported.

Metro now considering upgrading to Osprey/Qxp ("p" for PCI), 4X instruction execution rate of PDP-11/93-94.

TFL, Transport For London, currently considering upgrading to the very same Co-processor HARDWARE, reconfigured, Kestrel/Qxp (FPGA, WCS) for replacing HP-1000 mini-computer, A600, etc. Wwest40 (talk) 18:06, 18 January 2013 (UTC)

for the last one, see #2 at http://webcourse.cs.technion.ac.il/234118/Spring2007/en/syllabus.html also see the literature and FAQ sections for further proof — Preceding unsigned comment added by 132.68.204.215 (talk • contribs) 09:16, 9 July 2007 (UTC)

The last PDP11/44 running in Canada (confirmed 2007 by HP) was stopped July 2009. Réjean Fournier Rio Tinto Alcan coordinator. We still have others models in process control. — Preceding unsigned comment added by 57.77.11.4 (talk • contribs) 15:55, 17 July 2009 (UTC)

Just last year, 2012, Rio Tinto replaced their PDP-11s with Osprey Co-processors. — Preceding unsigned comment added by Wwest40 (talk • contribs) 18:04, 18 January 2013 (UTC)

A PDP-11/23 runs the cyclotron in the University of Washington's nuclear medicine lab as of 2011. I've seen it with my own eyes. — Preceding unsigned comment added by 50.78.42.81 (talk • contribs) 21:58, 29 August 2012 (UTC)

Thanks for the sales lead. WWest — Preceding unsigned comment added by Wwest40 (talk • contribs) 18:04, 18 January 2013 (UTC)

Macro-11 article

I just reverted a merge with MACRO-11 for two reasons: (1) I think merges should be proposed first, (2) in this particular case, merging a programming language with a hardware article isn't necessarily a good idea.

Admittedly the MACRO-11 article is short, but that could be cured by expanding it.

Paul Koning (talk) 23:02, 17 February 2008 (UTC)

My main concern with the MACRO-11 article is that it is not notable enough to carry its own article; it has no application or context outside of its use in PDP-11 systems, especially since both are defunct and only of historical interest. The alternative that I will pursue is deletion. I also don't see how or why PDP-11 should be a hardware article. First, it already contains an assembly programming section which I expanded to merge the MACRO-11 content. Secondly, the PDP-11 refers to a system, not exclusively the hardware, which would be a different article, PDP-11 hardware. To put it another way, a discussion of TiVo includes both the hardware and software -- and there is no separate article to discuss its software. If MACRO-11 were independent of the PDP-11, I would agree that it would warrant its own article; as it is, however, MACRO-11 is merely a sub-topic of the PDP-11, and as you admit, it doesn't contain enough content to justify a split on organizational grounds. Ham Pastrami (talk) 00:08, 18 February 2008 (UTC)
Ah, not to mention the list of operating systems, which is also not hardware. Ham Pastrami (talk) 00:11, 18 February 2008 (UTC)
I don't agree with the "notable" argument, especially since Macro-11 clearly serves as the template for many other assembly languages. Apart from that, I still don't understand why that justifies skipping the normal process -- discuss first, act after there is time to see that there is consensus. Paul Koning (talk) 15:26, 18 February 2008 (UTC)
I also do not agree with the "notable argument"!--Tim32 (talk) 01:06, 8 May 2008 (UTC)
Me either. The Tivo analogy is wildly off point: Tivo is an appliance, inseparable from its built-in software. That's not the case with a general-purpose computer. Now if there was a separate article on the PDP-11 instruction set, I would agree that that material belongs here. But a macro assembly language is far, far more than a representation of the computer's instruction set. Jeh (talk) 07:25, 8 May 2008 (UTC)
It really bugs me that the merge of "MACRO-11" was done again, even after I pointed out that there is a process to follow for this (which wasn't followed) and after there were several objections and no one speaking up in favor. Why was this done? Paul Koning (talk) 21:28, 19 May 2008 (UTC)
I'd just like to comment that IMHO, the native assembly language of one of the most influential architectures in computer history should be notable enough for Wikipedia. Also, from experience of reading and editing similar articles, I would expect an article entitled "PDP-11" to focus mainly on the hardware, with in-depth descriptions of associated operating systems, assembly languages etc. to be delegated to other articles. Letdorf (talk) 09:48, 20 May 2008 (UTC).
So, revert the merge. The merge obviously flies in the face of consensus. It wouldn't hurt to flesh out the Macro-11 article with more information about directives, lexical operators, etc. Jeh (talk) 14:22, 21 May 2008 (UTC)

I have done the deed. I think one way to avoid similar future well-meaning mistakes would be to expand and change the "Macro-11" section here into "available programming languages." Jeh (talk) 00:59, 22 May 2008 (UTC)

Time span

The article says that DEC sold the PDP-11 in the 70s and 80s. I think that is slightly misleading. The last PDP-11 model from DEC, the PDP-11/93 and PDP-11/94 were introduced in 1990. Note that this was a new model. That would imply that they still had a fairly acceptable business into the 90s as well. /bqt (bqt@softjar.se) --213.65.173.92 (talk) 12:43, 26 July 2008 (UTC)

Maybe, but everyone was more focused on VAXes, SPARCstations, high end PCs, etc. by then. Even though I was a PDP nut, I didn't pay any attention to the 90 series, and it was barely mentioned at DECus meetings. —EncMstr (talk) 16:21, 26 July 2008 (UTC)
If reliable references can be supplied, I think this should be mentioned. Stating that DEC was selling the PDP-11 in the 70s and 80s when in fact sales continued through to the 90s makes the statement inaccurate. Rilak (talk) 06:57, 27 July 2008 (UTC)
Reliable references? The 11/93 and 11/94 was introduced in 1990 (anyone have any marketing material? Otherwise, how about the manuals for the new machines, dated 1990, and marked as new material, which are available at bitsavers?). What more do you need? I don't really know what kind of references are acceptable, and available. This is as close to a known fact as anything I can think of. What references do we have that the PDP-11 started selling in 1970? Anyway, DEC then sold the (almost) whole PDP-11 software business to Mentec in 1994. In 1998 DEC made available firmware upgrades for the 11/93 and 11/94 to cope with a Y2K issue (I have the upgrade on my systems, and it have a copyright notice saying 1998). Mentec continued to sell new PDP-11 systems will into the 21st century. In fact, there is still atleast one company making new PDP-11 processors. /bqt (bqt@softjar.se) 212.112.174.86 (talk) 08:54, 20 August 2008 (UTC)
I was not questioning the truthfulness of your edits, I'm just saying that any statement or claim needs to be referenced (it is standard Wikipedia policy). Go ahead, edit the article to make it more complete. I have found a reliable reference here: [2] (bottom of page) quote: "May 1990: The 20th anniversary of the first PDP-11 computer is marked by the introduction of two new PDP-11 systems: the MicroPDP-11/93 and the PDP-11/94." Rilak (talk) 11:45, 20 August 2008 (UTC)
:) I didn't think you were questioning the truthfulness as such. I just asked about the need for references. After all, the original claim of the PDP-11 being sold in the 70s and 80s didn't have any references either. It's just that it feels like the need for references sometimes seems excessive. And especially when it comes to some information while other information that appears to be on the same level are provided without references. Where should the line be drawn? It feels a little arbitrary, and perhaps wrong at times. /bqt (bqt@softjar.se) --212.112.174.86 (talk) 17:44, 23 September 2008 (UTC)
The reason why I said it needs references when adding such facts is more important as most editors will find that a computer sold in the 70s and 80s was still around in the 90s to be highly dubious, and therefore there is a risk it will be removed. Adding references stops that from happening. Rilak (talk) 08:56, 24 September 2008 (UTC)
Who makes new PDP-11 processors? There are lots of people in the classic computer crowd who'd like to know. We've been trying to contact Mentec about PDP-11 things to no avail. Frotz (talk) 01:35, 21 August 2008 (UTC)
I don't know how much "advertisement" is okay. But right now, the last manufacturer of PDP-11 processors that you can stick in your old backplane are Quickware (that I know of). And then of course you also have different levels of emulation, from Strobe who makes some hardware to pure software implementations. (bqt@softjar.se) --212.112.174.86 (talk) 17:44, 23 September 2008 (UTC)

Hello fellow Wikipedians,

I have just added archive links to 2 external links on PDP-11. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers. —cyberbot IITalk to my owner:Online 10:48, 27 August 2015 (UTC)

hampage.hu

Oko5ekmi5 (talk) 07:24, 26 September 2020 (UTC)

It seems that these are references for the Hungarian PDP-11 clones. Since talk pages are to discuss improvements to the page, we should discuss the applicablity of such references. Gah4 (talk) 21:04, 5 October 2020 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:PDP-11/Archive_1&oldid=1232046799"