Talk:PDP-10

This is the talk page for discussing improvements to the PDP-10 article.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Infocom

The statement that "Infocom used several PDP-10s for game development and testing" should probably have a reference attached to it or be removed. It seems somewhat unlikely that they would keep a number of mainframes running for that purpose. --Khim1 (talk) 06:07, 4 May 2018 (UTC)[reply]

Characteristics

Does anyone have any information about the speed of these machines? (84.78.203.218 (talk) 21:52, 4 July 2009 (UTC))[reply]

MIT and BBN KA-10 pagers

According to Tom Knight:

Holloway designed the pager for ITS long before Tenex existed. They asked us what instructions we used, so that the XCTR instruction is semi-compatible, at least in opcode.

in case anyone wants to know what the support data is for this claim. Noel 12:50, 26 Oct 2004 (UTC)

Failure of the Jupiter project???

I was working at DEC Marlboro in 1983, when Jupiter was cancelled and the end of LCG was mandated. The Jupiter project was progressing well at that point; problems in the new system development were not the cause for the cancellation of the project or the end of LCG. I'm about to edit the page to reflect this, since there doesn't seem to have been any previous discussion of the issue here (I wanted to check in case it was controversial). Dd-b 21:51, 11 Mar 2005 (UTC)

What was the name of the Jupiter processor? Someone just edited KC10 (which sounds right) into the article and someone else reverted it right back out.

Atlant 17:49, 25 January 2006 (UTC)[reply]

To the very best of my knowledge, KC10 was the designation for what would have been the Jupiter processor/2080 (or possibly 4050 - see http://groups.google.co.uk/group/alt.sys.pdp10/browse_thread/thread/ccb4757495e65a4a/a1054421a0f21923?hl=en&ie=UTF-8&q=KC10+group:alt.sys.pdp10#a1054421a0f21923). The wise heads of the 36-bit community say so, at least, and they ought to know, many having been DEC techies back in the day. There's also plenty of documentation available about the KC10: for example, ftp://ftp.stacken.kth.se/pub/pdp10/KC10.pdf (see the Dept: header for the mention of Jupiter).

For example, take a look at Phil Budne's list of PDP-10 devices (http://www.ultimate.com/phil/pdp10/10periphs):

KA10 Original PDP-10 CPU; used in 1010/1020/1030/1040/1050/1055

KC10 "Jupiter" CPU [cancelled] to be used in 2080 (later 4050)

KI10 Second PDP-10 CPU ("I" for Integrated Circuits); used in 1070/1077

KL10 Third PDP-10 CPU (ECL logic) used in 108x/109x/2040/2050/206x

KO10 "Minnow" deskside CPU (cancelled before TOPS-20 debug complete)

KS10 Fourth PDP-10 CPU ("Small") used in 2020

On rummaging around, I've also found mention of "Dolphin", which was probably designated the KXF-10 (http://bitsavers.org/pdf/dec/pdp10/KXF10_Dolphin/Dolphin_Diagnostic_Plan_Feb78.pdf); and you might find this interesting (http://groups.google.co.uk/group/alt.sys.pdp10/browse_thread/thread/1dd9f4d09329411c/cc3450caeed66dcc?hl=en&ie=UTF-8&q=Dolphin+group:alt.sys.pdp10#cc3450caeed66dcc), since it mentions "Unicorn" (unknown designation) which preceded Dolphin.

I can't see any reason why the association of the Jupiter project with the KC10 designation should be at all contentious, given what I've supplied above, so do feel free to edit back into the article, if you wish! Kay Dekker (talk) 12:07, 18 May 2009 (UTC)[reply]

At the time of the Jupiter cancellation, however, the word-of-mouth among long-time users of PDP-10s was that there was a serious design defect. Supposedly the person primarily responsible for the Jupiter's design had been hired from IBM and didn't realize the extensive use of the indirect addressing bit. As a result, the performance of instructions using it was, umm, less than optimal and the overall system performance was only slightly better than that of a KL-10.

Seldenball 20:15, 21 August 2007 (UTC)[reply]

As owner of a both a DECSystem10 and a VAX I was participating in a non-disclosure presentation of Jupiter. My very first feeling was that the lack of extending the directly addressable memory (without memory management) would give the killing stroke to the whole product line. According to the rumours I head before I had expected a step as courageously trend-setting as that from PDP-11 to VAX.

--Jkbw (talk) 19:43, 28 January 2009 (UTC)[reply]

Just adding to this, there seems to be a couple of indications that the Jupiter project was, at least, not in the best shape:

For one thing, this planning document indicates that the CPU would have been running and debugged by Oct -81, while clearly the CPU was still under active development in -83.

This memo from very late -82 discusses the disappointing performance figures and how to improve performance testing methodology, indicating the immaturity of the project, as above.

This comp.arch thread from -92 with someone who claims to have worked at DEC mentions both the disappointing performance and the need to run over budget to overcome it, and a general feel that 18-bit addressing was a liability. The message does say that the performance issues could "probably" have been overcome, but even so it seems a stretch to say that the project was in very good shape. I do think it seems reasonable to edit the article to reflect this.

--Dolda2000 (talk) 16:36, 30 May 2017 (UTC)[reply]

Capitalization of title of system reference manual

I'm not convinced that the change in capitalization of the title of the system reference manual was appropriate; the manual cover gives the title starting with "decsystem10". The capitalization and hyphenation varied over the years. --Brouhaha 07:28, 6 September 2005 (UTC)[reply]

You may be right, now that I think of it. (It's been a long time since I JRST'ed). --Rogerd 17:39, September 6, 2005 (UTC)

I was also certain that at least some of the documentation and logos used the "decsystem" form as well, but then again, the overall form of the logo varied a lot among the -10s and -20s, and I can never remember exactly which ones used which styles ('cept that '10s were blue and 20s were "China Red" which is really orange).

Maybe someone can Google-up some pictures and check for sure?

Atlant 17:11, 7 September 2005 (UTC)[reply]

Wire wrap panels

From the article "with automated wire-wrap back panels." The back panels would be more properly called backplanes and they were made with a semi-automated process.

The backplane was positioned in front of an assembler. Between the assembler and the backplane was an arm running on an X-Y positioning system. The arm had a V-shaped groove on its end. The operator would touch a foot pedal and the arm would move to the coordinates of the first wire-wrap pin. At the same time, a lamp would light above one of many bins of different lengths of precut and stripped wire. She would take a length of wire, insert it into her wire wrap gun, place the gun onto the pin pointed to by the arm and install the wire. She would then touch the foot pedal again and the arm would move to the wire endpoint where she would secure it. She would repeat the process until the backplane was done.

I don't know if any of this is relevant to the article. Someone might find it useful. I'd like to change back panels to backplanes and automated to semi-automated if there are no objections.

I'd also point out the the phrase Wire-Wrap is a trademark of what was then Gardner-Denver, now Cooper Group and as such should at least be capitalized and hyphenated. -- Grumpyoldgeek 17:33, 13 November 2005 (UTC)[reply]

Automated wire-wrap did exist. I don't know whether DEC used automated or semi-automated. "Panel" was standard terminology for something you wire-wrapped; in this case I think either term is acceptable, but backplane is probably slightly more meaningful. --Brouhaha 07:46, 13 November 2005 (UTC)[reply]

"Automated wire-wrap did exist." No doubt. OTOH, what I described is the way the machines were built at the Mill in 1972 and that's what the article discusses. I spent several lunch breaks watching and chatting with the assemblers as they wired the backplanes. --Grumpyoldgeek 17:33, 13 November 2005 (UTC)[reply]

Images

Can we see about getting some free-use images of PDP-10 and assorted goodies? Anyone have any to share? /Blaxthos 03:07, 31 March 2007 (UTC)[reply]

I recently found a KI-10 memory bus terminator (quick latch) in my cellar. Should I ... --Jkbw (talk) 15:31, 28 January 2009 (UTC)[reply]

Go ahead! as they say, Be Bold! Kay Dekker (talk) 12:19, 18 May 2009 (UTC)[reply]

Dates

The page introduction says "The first model was delivered in 1966", while the first section of the article says "The original PDP-10 processor was the KA10, introduced in 1968". Can someone with access to contemporary records provide an unambiguous timeline? If those two dates had been reversed, I might suspect that the product was announced in one year, then delivered two years later, but the current text precludes that interpretation. 4.248.218.255 (talk) 11:42, 26 September 2010 (UTC)[reply]

This PDP_Tree_Poster_1980.jpg published by Gordon Bell suggests that 1966 is the better choice.--Jkbw (talk) 01:50, 27 September 2010 (UTC)[reply]

This document from one of the engineers involved making the PDP-10 says the first successful power on test was in March 1967. Lars Brinkhoff (talk) 10:45, 24 September 2019 (UTC)[reply]

BBN

who are/were BBN? The link to BBN needs to be targeted correctlyCecilWard (talk) 15:09, 1 March 2012 (UTC)[reply]

Bolt, Berenek & Newman (not sure of spellings) were very early pioneers of what became the Internet. — Preceding unsigned comment added by 205.153.182.171 (talk) 13:36, 17 June 2014 (UTC)[reply]

In case anyone else is still interested in this old question, there is an article on Bolt, Beranek, and Newman, although the name of the company has changed in the decades since they helped create the ARPAnet. Unician ∇ 16:04, 17 June 2014 (UTC)[reply]

Communications I/O and data paths

IIRC, asynchronous serial communications (for terminal displays, printers, and modems) was handled by the PDP-11/40 front-end in behalf of the KL10 processor. The MassBus channel was used for disk and tape transfers, and was connected directly to a controller on the KL10, bypassing the front-end. As of this writing, the article glosses over the I/O architecture and data paths, and doesn't mention async serial communications at all. I don't have access to the tech ref manuals any more, so this is just my recollection from managing a KL10 installation a quarter-century ago. If somebody has a clear diagram of the basic data paths, adding it to the article would make this more understandable. Reify-tech (talk) 03:49, 27 September 2015 (UTC)[reply]

Sounds fine to me, but that still leaves the I/O paths for the KA10, KI10, and KS10 to write about. Do all interrupt on every character of serial I/O? Gah4 (talk) 01:49, 29 September 2015 (UTC)[reply]

That would depend on the serial interface in question. The DZ11, an early Unibus multiport serial interface, did have some small FIFO buffers for both transmit and recieve, much like an 8250 or 16550 (if I remember those numbers correctly), so even the poor beleagured 11/40 was not coping with an interrupt per character except for manually-typed input... which would generally be too slow for those interrupts to matter much. I don't know if they had similarly FIFOd serial interfaces for the earlier Kx10's. But certainly it was possible to build FIFO-equipped serial interfaces even in those primitive times. :) Jeh (talk) 01:54, 29 September 2015 (UTC)[reply]

External links modified

Hello fellow Wikipedians,

I have just modified 6 external links on PDP-10. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

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.—InternetArchiveBot (Report bug) 16:12, 26 July 2017 (UTC)[reply]

A real PDP-10.

There was a link to a site that provides free logins on an actual PDP-10. It was then removed because the site was sluggish. (I don't think there is a WP:SLUGGISH for that one.) I reverted it. I suspect that this is one of the very few PDP-10s running, and if not the only one, the only one that provides free logins. Some people interested enough to read this page, might wonder about actually using one. Also, I am not sure about the edit summary mention of simulator. The link provides for logins on a real DEC built PDP-10, not a simulator. There are also accounts on a Toad-2, which is a PDP-10 compatible machine not built by DEC. In addition, accounts for other historical actual machines are available. Obviously keeping such machines running isn't easy, and one should not be surprised that they are slow, or sometimes not available. Does anyone else believe that this link should stay? Gah4 (talk) 05:15, 21 November 2017 (UTC)[reply]

I've reverted again. The link is to the entire collection rather than content about the PDP-10. It is an advert for the museum. There is no reason for a direct link to a page that asks for personal information and has absolutely no content about the PDP-10. Glrx (talk) 05:13, 28 November 2017 (UTC)[reply]

Nothing in EL requires an EL to provide a resource that pertains ONLY to the article subject, nor requires an EL to go directly to such a page. Re "advertising", I guess that per your lights we should remove the article on the museum itself, as just "advertising for the museum"? Jeh (talk) 06:04, 28 November 2017 (UTC)[reply]

The inclusion violates WP:ELNO 6 and WP:ELREG login required. That should be a high hurdle to jump, and I don't see it here. The museum is not an official DEC link. The EL is uninteresting without logging in. The EL section is for material that would be included in the article if the article were expanded. User experience is not such an item. What encyclopedic content does the site have? Other ELs provide original documents about the PDP-10. That's an appropriate thing to add (EL has material too detailed for article). The login link was also supplied by an SPA who put it in several other PDP-10-related articles; the SPA works at the museum (i.e., purpose is to advertise what the museum offers). Focus is always good; why should a reader follow a link that is supposed to be about the PDP-10 get a lot of material about an Apple II and other random machines? That's WP:ELNO 13. Glrx (talk) 03:20, 6 December 2017 (UTC)[reply]

WP:BRD seems to say to discuss here, though it seems to suggest bold additions more than bold deletions. Still, I am happy to discuss here. I don't understand this at all. I suspect that way more than half, maybe 90%, of citations have something else besides the subject in question. The web site allows one to get an account on a real PDP-10. Normally one supplies their name, but one could give a fake name. You have to give a desired username, and e-mail address where they will send login information. It also includes much documentation on using the PDP-10, though much is also on bitsavers. But the ability to log onto a real PDP-10 is a pretty unique resource, and should be available to anyone interested in the PDP-10. Note that there is no charge for such accounts, so it isn't a commercial advertisement. You don't have to live anywhere near the museum, or actually visit, to get an account. I agree that web sites shouldn't require an account to download information, but they normally do to logon. I suppose Facebook doesn't get a page here, either? Gah4 (talk) 03:46, 6 December 2017 (UTC)[reply]

Also, note that the page doesn't require a login to access any web content, as WP:BRD indicates, but to actually login to your account in a PDP-10. All web content, including downloading any information on the PDP-10 or operating systems running on it, is free without login. Gah4 (talk) 03:57, 6 December 2017 (UTC)[reply]

I don't object to an EL that has information about the PDP-10. Even a museum link that goes to information about the PDP-10 would be fine, but that is not the case with the current text. A link to the museum's front door (http://www.livingcomputers.org/) is not OK. ELNO 13. (Although if a more focused link only provides info on the PDP-10 that duplicates of bitsavers, then the link would have little value.) A registration link that gathers email addresses is not OK. The guidelines are against it, and the guidelines make sense for the PDP-10 article. Another complaint is about advertisements; it is not restricted to commercial advertisements. The museum is advertising its services and not linking its content. That is not helping the typical reader understand the PDP-10. What? The remark about Facebook is off topic. Facebook is notable. The PDP-10 is notable. Maybe the museum is notable. If something is notable, then it can have a page here. I never said that Facebook does not get an article on WP. I am saying that WP should not be encouraging readers to go to sites that will collect email addresses no matter how altruistic those sites might be. Glrx (talk) 04:14, 6 December 2017 (UTC)[reply]

First, WP:EL is a guideline, not a strict limitation. Number 1 mentions unique resources, which, as far as I know, free accounts on a PDP-10 are unique to this site. As for ELNO 13, the subject of the article is vintage computing, with the PDP-10 being the specific case. A page describing transportation methods or cell biology would be different subjects. I have mentioned on the talk pages of many other articles that comparisons are generally useful in understanding the exact subject of an article. Mention of the PDP-6 or PDP-11 on a PDP-10 page is reasonable. Mentioning the IBM 7090, which has many similarities should also be fine. Mentioning the Boeing 787 is likely not fine. I don't know how 'typical' a reader is, but being able to actually use a PDP-10 is the best way to learn about one. I am not sure how specific different parts of the web site are. Not pointing to the base page, but to a more specific one, is fine with me. Gah4 (talk) 05:21, 6 December 2017 (UTC)[reply]

Glrx, you wrote in your edit comment "Gah did not comment on talk page." His comment is the first one in this talk page section! Your seem to have zeal-induced blindness.

The museum already has a page here. Living Computers: Museum + Labs

Not everything a SPA does here is inherently bad.

"I am saying that WP should not be encouraging readers to go to sites that will collect email addresses". Oh, please. It's not as if they're sneakily collecting email addresses without the visitor's knowing about it. Every site you visit knows, and maybe collects, your IP without asking - maybe we should just stop using web sites as references. Jeh (talk) 05:57, 6 December 2017 (UTC)[reply]

And, just to be sure, they don't spam users with e-mail. They use it to send your login information, and nothing else. I think if they change something, that they might e-mail the change, but they might not even do that. There is an e-mail newsletter that you can sign up for, which will mail you about once a month. I do agree with Glrx that I don't like sites that want your e-mail address for no reason, or require a login for no reason. But sometimes I sign up anyway, sometimes not. Gah4 (talk) 07:00, 6 December 2017 (UTC)[reply]

Yes, I was confused about comments on the talk page. However, Gah4 first comments are about sluggish. The website is sluggish; it wants to load several images and cycle them. All content free about the PDP 10.

I'm not arguing WP:N about the museum. That is irrelevant here. It has a lousy home page, but that does not affect WP:N. I suspect the Computer History Museum is a better museum, but that doesn't matter either.

Yes, SPAs can do good work, I appreciate many of them, but the SPA in question is not linking to content here. The SPA has not expanded my understanding of the PDP-10. No compare and contrast of 36-bit IBM machines. No comments about byte pointers or six-bit filenames. No comments about why the PDP-10 was chosen at schools such as CMU, Stanford, and MIT. I do not see the SPA providing content for WP's benefit; I see the SPA trying to tell the world what is available at the museum where the SPA works -- and going against a guideline while doing it. That's being subservient to the wrong master.

Citing guidelines is not a bogus argument. They don't have the authority of policy, but they are a guide.

I'm not seeing arguments that say the guidelines should be ignored. Why is this content so important that the guideline should be ignored. That involves understanding the purpose of the guideline and the benefit of overriding that guideline.

What value is linking to the museum's homepage (which has not only unrelated but also variable content)? Find a link to some PDP-10 content inside the site rather than the front door. Why do you disagree with that? Dig out the link for PDP-10 content and use that instead of the home page. Make the EL point to something the reader can use. Instead you want the reader to hunt through a lot of crap about other computers and the museum's current exhibits. The guideline does not want the reader forced to do that. That's advertising drivel and a disservice to the reader. Why ignore the whole point of ELNO 13? Why does linking to the front page make WP a better encyclopedia? It does not make sense. Or do you think the museum is a great place and readers should be subjected to whatever is on their homepage?

The "unique resource" argument is thin. How many readers have some PDP-10 code that they want to run? The article is more about the architecture than the operating system. The various PDP-10 operating systems are much different and covered in different articles. It sounds like you are enamored of being able to run an old operating system on an old computer. That's nice. I have many fond memories of KA and KLs. But WP is an encyclopedia; it is not a how-to-guide about using old operating systems. Encyclopedia articles are not about nostalgia. How many readers know about TELNET? TECO? How many readers will benefit by learning how to use an old computer? Yes, you are clearly interested in that, but I think it is a disservice to point high school students in that direction. The high school students that I've talked to are shocked that computers back then only had a megabyte (after they realize its mega not giga). One need not use a computer to understand it, and running some programs does not necessarily give a better understanding. I've read about 1401s, but I've never run a program on one. I never run a program on a 604, but I've looked at the architecture.

Uh, email addresses are different that IP addresses. That's another poor argument. You need an IP address to read WP, but you don't have to provide your email address to read WP. Access to the machine requires registration, so it is not appropriate as an EL. I don't care whether they spam or not; they have the email address, so they could ask for donations. Maybe they won't, but I don't have to go there. If registration is required, then we don't need to list it as an EL. It's another nail.

WP:CONSENSUS

Glrx (talk) 07:17, 6 December 2017 (UTC)[reply]

You have two people who disagree with you, Glrx. Per WP:CONSENSUS, that's not consensus. (Did you actually read WP:CONSENSUS? Perhaps with the same thoroughness with which you somehow missed Gah4's first comment here. You know, the one that opened the section.) Jeh (talk) 07:31, 6 December 2017 (UTC)[reply]

~~I think problem resolved itself -~~ PDP-10 is ~~no longer~~ available on livingcomputers Request-a-Login. Apparently it's DEC-10 (2065 running Tops-10). But does that count as PDP-10? --89.25.210.104 (talk) 17:28, 11 November 2018 (UTC)[reply]

I don't claim to understand DEC naming, but yes it is a real PDP-10. The naming is supposed to by DECSystem-10 for a PDP-10 running TOPS-10, and DECSystem-20 for one running TOPS-20. But you can run TOPS-10 on the hardware sold as DECSystem-20, which seems to be what they are doing. The TOAD-2 is a PDP-10 clone that was built and sold by a different company, which now runs TOPS-20. One might argue that the latter isn't a real PDP-10, as it wasn't sold by DEC, but the 2065 is real. The TOAD-2 is not, for example, an IBM PC running emulation software, but I believe is an FPGA based box. Gah4 (talk) 20:36, 11 November 2018 (UTC)[reply]

KA10 and Non Paged Virtual Memory

A small point. The section on the KA10 says "...were modified to add virtual memory and support for demand paging, as well as more physical memory." But the KA10 did offer virtual memory, but not paged virtual memory. Using the twoseg memory management in tops-10 memory was virtual, user accesses where translated on each reference, users could swap to and from disk/drum, total allocated user memory could exceed physical. I edited the sentence to say "...were modified to support demand paged virtual memory, as well as more physical memory." — Preceding unsigned comment added by 73.238.3.45 (talk) 20:54, 18 June 2018 (UTC (UTC)

I guess it depends on the definition of "virtual memory". If it's defined as "addresses within the program aren't physical addresses, thre's a map between program addresses and physical addresses", then it's virtual memory. If, however, it's defined as "parts of the address space can be marked as not present in physical memory, and a reference to an address in one of those parts will cause a trap, and the trap handler can bring the data into physical memory, map it in, and restart the trapping instruction, so that the program can, modulo the performance hit, act as if the entire address space were in physical memory", then it's not virtual memory, unlike demand-paged or demand-segmen-loaded systems. (Swapping doesn't count here, as the address space is either entirely swapped in or entirely swapped out, modulo shared segments - in order to run, the entire address space, not just the parts currently being used, must be in physical memory.) Guy Harris (talk) 06:59, 7 September 2023 (UTC)[reply]

The KA10 had address translation. This provided memory protection. It had a two-segment memory model that meant the (typically but not necessarily read only) high segment could be shared by multiple users and the low segment of a user moved out to disk. Fractional demand management isn't a requirement of virtual memory. It was a later refinement. You can reference Wikipedia's own definition of virtual memory. It was virtual memory. 149.32.192.48 (talk) 12:28, 30 April 2024 (UTC)[reply]

minicomputer

I don't want to join any edit war, but from minicomputer it should cost less than $25K in 1970, and I don't believe that was true for the PDP-10. Smaller DEC systems were close to the beginning of the minicomputer market, and VAX was sold as supermini. Note that the VAX is much more powerful than the low end of the IBM S/360 line, which we always considered mainframes. (Well, maybe not the 360/20, but at least down to the 360/30.) More than the CPU itself, it is the peripherals that you attach. Minicomputers might have one disk drive, or maybe none, but mainframes would have many of them. Gah4 (talk) 21:01, 4 October 2019 (UTC)[reply]

I agree that the PDP-10 was not a minicomputer. DEC never marketed it as a minicomputer, and frequently referred to it as a mainframe computer. Reify-tech (talk) 21:07, 4 October 2019 (UTC)[reply]

The KS-10 might qualify, though. Gah4 (talk) 21:24, 4 October 2019 (UTC)[reply]

sigh---All right, I give up; maybe I was confusing it with the PDP-11, which definitely is a 16-bit minicomputer. I give up. JustinTime55 (talk) 21:50, 4 October 2019 (UTC)[reply]

Thank you for conceding your major error. By contrast, the PDP-11 was considered a minicomputer. Several of the editors of this article have worked on both families of DEC hardware; I myself have been responsible for managing PDP-11s, a DECsystem 2065, VAXes, and various other DEC hardware. Reify-tech (talk) 22:06, 4 October 2019 (UTC)[reply]

The PDP-6/10 and the PDP-11 are very different machines. The 10 had 18-bit word addressing (~ 1mbyte memory); the 11 had 16-bit byte addressing (64k memory). The 10 was much bigger physically and much more expensive. The 10 was installed in machine rooms, the 11 was often used in lab or school spaces. In fact, in the Gordon Bell article referenced by our article, he explicitly contrasts the PDP-10 to DEC's minicomputers, though he never uses the term "mainframe". The PDP-11 was in fact used as a front-end console machine for some of the PDP-10 line (KL-10). Like Reify-tech, I used 10's, 11's, and Vaxes in the day, as well as the SDS-940 (a mainframe limited to 200kbytes!), GE-635, Honeywell/GE-645/6180, IBM 360 before PCs and workstations came along. --Macrakis (talk) 23:19, 4 October 2019 (UTC)[reply]

Allen had modified the PDP-10 assembler to become a cross assembler for the 8080 chip.

The article says Allen had modified the PDP-10 assembler to become a cross assembler for the 8080 chip. I suppose he could have done that, but more usual at the time was to write macros to do it. I do remember a macro set for the OS/360 assembler to generate 8080 code. (Along with a post processor to convert OS/360 object programs to Motorola hex format, and the listing file to look right.) I don't remember if Macro-10 is good enough to do that. Gah4 (talk) 22:05, 25 October 2019 (UTC)[reply]

Thinking about this more, it would seem convenient to generate a PDP-10 word for each byte of 8080 code output. That makes address numbering match byte numbering. Then there should be a post processor that extracts 8 bits from each word and writes them out in the appropriate form, such as hexadecimal ASCII codes. This would be more obvious of any such macro sets were still around. Gah4 (talk) 20:41, 30 August 2020 (UTC)[reply]

Any references to what he actually did? It is easier to write macros, but possible to modify the assembler. Gah4 (talk) 18:46, 12 February 2022 (UTC)[reply]

"Allen used the PDP-10 assembler to become a cross compiler..." the grammar is wrong and I don't know how to fix the grammar other than revert to the previous version which reads "Allen had modified the PDP-10 assembler to become a cross compiler" and I'm not going to do that. Please fix the grammar. Jamplevia (talk) 23:01, 12 February 2022 (UTC)[reply]

It now says "Allen used the PDP-10 assembler as a cross assembler for the 8080 chip." It also asks for a citation, both because citations would be a good idea and because the citation might indicate what Allen did. Guy Harris (talk) 00:44, 13 February 2022 (UTC)[reply]

For what it's worth, this article on the Living Computers Museum+Labs site says that:

Years before Microsoft, Paul Allen and Bill Gates started another company called Traf-o-Data, to build a traffic counter using the Intel 8008 microprocessor chip. While the Traf-o-Data hardware was being designed an built, Paul wanted to begin programming the 8008 but had no computer for the purpose, so he wrote a PDP-10 program to simulate the chip instead.

The way it worked was simple. Intel published a data sheet which described what each instruction did with every 8 bit byte decoded. Paul wrote routines to perform the same operations on data in the PDP-10, storing the 8 bits of the 8008’s words in the 36 bits of the PDP-10’s. He defined UUOs to call these routines, and wrote macros which looked like the 8008 instructions published by Intel but expanded into his PDP-10 UUOs when assembled with Macro-10. Now Paul and Bill could write 8008 code for their Traf-o-Data hardware and test the resulting program using a PDP-10!

which is a bit different from using the PDP-10 assembler as a cross-assembler; instead, it's an assembler for a pseudo-machine that sort-of works like an 8008, as long as you don't try to do self-modified code or otherwise care about the code existing in the simulated 8008's memory. The pseudo-machine's code is made out of PDP-10 instructions, so there's no need to go from 36-bit words to 8-bit bytes. Guy Harris (talk) 00:53, 13 February 2022 (UTC)[reply]

I guess you could dump the 8008 machine code into the memory of the simulated 8008 (which would require translation back from UUOs to 8008 machine code, if the "cross-assembler" was a bunch of macros to generate UUOs) to handle code that reads other code (if that was an issue for the Traf-o-Data code), and have the handlers for UUO versions of 8008 stores detect stores into a code area and do run-time translation (if the Traf-o-Data code was self-modifying), but perhaps the Traf-o-Data code avoided looking at or modifying itself. Guy Harris (talk) 02:03, 13 February 2022 (UTC)[reply]

There are 31 LUUOs, but I don't know how many 8008 instructions there are. In any case, you can map 8008 bytes into PDP-10 words in many different ways. The emulator just needs to know where those bits are. I would have used the 8 low bits of each word, but there are other ways. In any case, it isn't hard to map them back again and, usually, generate Motorola hex format object code that was popular at the time. It isn't obvious to me that using LUUOs is easier than a 256 way indexed branch, but maybe it is. In any case, once you have the 8008 version, expanding to 8080 isn't so hard. Gah4 (talk) 11:05, 13 February 2022 (UTC)[reply]

Paul Allen's memoir Idea Man says in Chapter 5 "Wazzu":

My first task was to define a set of thirty or so “macros,” the symbolic instructions that would generate bytes for the Intel 8008. Within a few days, I’d effectively performed a brain transplant. The PDP-10’s assembler didn’t know it, but it was now an 8008 assembler.

He also mentions the simulator - "Written in PDP-10 assembly language, the simulator would mimic the microchip’s instructions." - which sounds like a conventional simulator, but he also speaks of "[modifying] the PDP-10’s debugger to give Bill the ability to stop the program in midexecution and track the cause of any problem.", which I guess could mean that he modified the debugger to know about the simulator and, for example, treat "single-step" as meaning "run the simulator loop through one instruction", but it could also mean he modified the debugger to treat "single-step" as meaning "run one UUO". I'd guess that it would be easier to put debugger functionality into the simulator if it's a "read 8008 instructions and interpret them" simulator, but I could be wrong. Guy Harris (talk) 02:40, 13 February 2022 (UTC)[reply]

Should DECSYSTEM-20 be merged here?

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

No consensus for the initially proposed merge and alternatives; closing, given that the discussion is stale. Klbrain (talk) 10:52, 20 August 2021 (UTC)[reply]

The DECSYSTEM-20 systems had a KL10 or KS10 as the CPU. The KS10 was apparently only used in DECSYSTEM-2020 models, not in any DECsystem-10 model [2020-08-30 18:54 UTC edit: not true, there were KS10-based DECsystem-10s, and TOPS-10 supported them]; the KL10 appears to be the only processor used in both. The major differences between DECsystem-10s with a KL10 and DECSYSTEM-20s using a KL10 appear to be:

the color of the trim on the cabinets (blue vs. orange);
the logo (decsystem10 vs. DECSYSTEM);
the operating system shipped with the machine (TOPS-10 vs. TOPS-20);
the way the paging works (a DECsystem-10 with a "Single-section KL10" and "TOPS-10 paging" vs. a DECsystem-10 with a "Extended KL10" or a DECSYSTEM-20 and "TOPS-20 paging" - the latter is also supported by later versions of TOPS-10);
some of the external buses.

See section 1.1 "KL10-based System Organization" in the DECsystem-1 O/DECSYSTEM-20 Processor Reference Manual for the paging and external bus differences.

Are they different enough for the DECSYSTEM-20 to deserve its own page, or should it be a section of the PDP-10 page? Guy Harris (talk) 00:55, 30 August 2020 (UTC)[reply]

I'm not an expert in this topic, but from what you describe here and what I can understand from the articles, I guess it should be two separate pages. The DECSYSTEM-20 article should then describe more in detail in how it differs from the previous version (as you have done here). Content in the PDP-10 page that is more about the updated/enhanced version should be moved there. See for example all the hardware and variants in List of iOS devices. Many of these incarnations are only slight improvements or changes to the previous version and they still each have their own article. I'm curious what others think about this, though. Ghettoblaster (talk) 10:05, 30 August 2020 (UTC)[reply]

I'm not sure that the PDP-10 was the "previous version" of the platform. The trim and logo color are just marketing noise, insufficient to make it worthy of a separate article. The way the paging works isn't a difference between the "PDP-10"/"DECsystem-10" and the "DECSYSTEM-20", because there were "Extended KL10"-based "DECsystem-10"s running TOPS-10, with TOPS-10 supporting 30-bit extended addressing in user mode. There were also KS10-based DECsystem-10s as well, running TOPS-10.

So that leaves the external buses and OS. PDP-10#KL10 says:

The differences between the 10xx and 20xx models are more cosmetic than real; some 10xx systems have "20-style" internal memory and I/O, and some 20xx systems have "10-style" external memory and an I/O bus. In particular, all ARPAnet TOPS-20 systems had an I/O bus because the AN20 IMP interface was an I/O bus device. Both could run either TOPS-10 or TOPS-20 microcode and thus the corresponding operating system.

so the external bus structure sounds like a configuration option rather than an inherent DECsystem-10 vs. DECSYSTEM-20 difference.

And I don't see the OS as an inherent difference, in that there are plenty of systems shipped that could run more than one OS. The bigger difference appears to be between Model A and Model B KL10's; Model As and Model Bs could both run either TOPS-10 and TOPS-20. Guy Harris (talk) 19:00, 30 August 2020 (UTC)[reply]

Merge Yes, Decsystem was just a marketing label. --Macrakis (talk) 21:04, 30 August 2020 (UTC)[reply]

Yes, I believe they should be merged. I was trained on KL10 and TOPS-20 at the time. There were no real differences between 10's and 20's at the architecture and microcode level. Apart from the colors, 20's were packaged as low 'DECSYSTEM' cabinets with internal memory, whereas 10's could also be tall cabinets with external memory expansion. The KL10 processor could run either TOPS-10 or TOPS-20, simply via boot. The different paging was done in microcode. The main difference was the target markets - 10's being for the university segment and 20's intended to get DEC into the commercial 'mainframe' market (that strategy failed, partly because of the failure of the Jupiter project as a followup high-performance processor and the commercial success of the VAX 32-bit line. As an aside, that internal competition between the 'Large System Group' at Marlborough and the VAX group meant development funding was spread between them and was really a 'lose-lose'). --AdamsWR99 (talk) 00:16, 8 January 2021 (UTC)[reply]

As I said below, it makes more sense to merge with TOPS-20, which also happens to be a much smaller article. The difference between DECSYSTEM-10 and DECSYSTEM-20 is the OS, and TOPS-20 in the latter case. Gah4 (talk) 03:45, 8 January 2021 (UTC)[reply]

Why not merge the Foonly article into here too? Why not merge MS/DOS into Windows? Each is distinct. One part of the long of it is just that: long file names. While that's software, not hardware, anyone who remembers file names like MMSRT3.txt instead of MiniMicroSystemsMag-Article3.txt for the 10's 6.3 filenames) or MMSMART3.txt for DOS/8.3) knows that a 20 is not a 10, just like an IBM 370 is not a 360, and a 360/44 is not an IBM 1130). Maybe it takes more recognition (pressing ESCape to fill in the rest of the Filespec)? Pi314m (talk) 18:10, 13 July 2021 (UTC)[reply]

"knows that a 20 is not a 10, just like an IBM 370 is not a 360, and a 360/44 is not an IBM 1130)"

No, not at all like a 360/44 is not an 1130. The 360/44 had a radically different instruction set from the 1130; the biggest thing they had in common was power-of-2 data unit sizes. At least one model of 20 had an instruction set so similar to a 10 that it could run TOPS-10 - according to page 34 of the July 1981 Large Computer Group Product Summary, the DECSYSTEM-2020 is offered both with TOPS-10 and with TOPS-20.

That means that 2020's file name length depends on, err, umm, the software you order it with; nobody's advocated merging TOPS-10 with TOPS-20.

"370 is not a 360" may be closer, although please read PDP-10#KL10 to see more than a bit of blur in the 10/20 distinction. Guy Harris (talk) 19:34, 13 July 2021 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

numbering

It seems to me that DEC confused the numbering of systems. This article should be about the PDP-10 architecture (though it varies among models more than it should), and other hardware features. There is no PDP-20. It seems to me, then, that DECSYSTEM-20 makes more sense as a redirect to TOPS-20. That is, the distinction is mostly software. (Unfortunately not completely, which complicates things.) PDP-10 processors are used to run both TOPS-10 and TOPS-20, and some non-DEC systems. There should be separate articles for the software that makes each system run, and gives it its identity. Gah4 (talk) 20:37, 30 August 2020 (UTC)[reply]

The sections of DECSYSTEM-20 are:

Lead - I could see that as a section of PDP-10 that discusses both the introduction of the "DECsystem-10" name and the "DECSYSTEM-20" name.
"Models" - that says nothing about the OS, and I see it as fitting in PDP-10 as well, except for the last paragraph, at least some of which is about TOPS-20. I'm not sure what "The DECSYSTEM-20 was primarily designed and used as a small mainframe for timesharing." means - does it mean the hardware differs from the hardware of equivalent DECsystem-10 models in ways that better fits time-sharing, or does it mean TOPS-20 is more timesharing-oriented than TOPS-10?
"Remaining machines" - that could go into a section of PDP-10 that covers remaining machines regardless of what the cabinets have painted on them (and what color the decorative parts are :-)).
"References" - that'd go to whichever page the text that used it went.
"Further reading" - the first of those belongs on TENEX (operating system) as it's about TENEX (before it became TOPS-20), and the rest could go on PDP-10.
"External links" - the first of those belongs on PDP-10, given that the title is "PDP-10 Models". The others might belong there to.

So I'm not seeing much that really belongs in TOPS-20, but I am seeing things that might fit in PDP-10. If we merged the "Models" section into PDP-10#Models and technical evolution, we could add PDP-10/DECsystem-10 products as well - "Models" in the latter section refers to CPU models (microarchitectures), such as KA10, KI10, etc., rather than product-line models; under each CPU we'd put the product-line models using that CPU. Guy Harris (talk) 06:32, 8 January 2021 (UTC)[reply]

OK, I said it wrong. It should be based on TOPS-20. OK, after enough things that go to the PDP-10 page get moved, then the redirect can go to TOPS-20. That isn't the usual way to do a merge, but it seems right to me. I presume there are links from TOPS-20 to this page, so that won't be a problem. Gah4 (talk) 10:09, 8 January 2021 (UTC)[reply]

"OK, after enough things that go to the PDP-10 page get moved, then the redirect can go to TOPS-20." Why TOPS-20? Most of the page would be moved to PDP-10 rather than TOPS-20, so why would the appropriate target be TOPS-20? Guy Harris (talk) 10:39, 8 January 2021 (UTC)[reply]

Because TOPS-20 is what makes a DECSYSTEM-20 a DECSYSTEM-20. Actually, I am not sure how DEC sold them and licensed them, but one assumes that someone buys one to run it that way. One could buy a Chevrolet and replace the engine with a Ford engine, but it would still look like a Chevrolet on the outside, and that is what everyone would call it. The outside view of a computer system is its OS. Some years ago, someone sued a car company for putting the wrong engines in the cars. Gah4 (talk) 11:29, 8 January 2021 (UTC)[reply]

So what is a DECSYSTEM-2020 running TOPS-10? A DECsystem-10 or a DECSYSTEM-20?

According to page 34 of the July 1981 Large Computer Group Product Summary, the DECSYSTEM-2020 is offered both with TOPS-10 and with TOPS-20. Guy Harris (talk) 08:29, 15 January 2021 (UTC)[reply]

unique byte instructions

The spirit of the statement in the intro about the pdp10 having a unique set if byte-within-word instructions is certainly correct, but it needs a note to point out that other machines have instructions that operate on bitfields within machine words, the Vax for example iirc, albeit without the sequential bitfield iteration support of the pdp10. Is there a way I could put in a suitable footnote, without disturbing the intro as it stands?CecilWard (talk) 15:06, 1 March 2012 (UTC)[reply]

The term "byte" originated at IBM prior to 1960 in connection with the 7030 "Stretch" computer, in exactly the meaning of an addressable bit field (not necessarily 8 bits). In addition to the 7030's inherent byte-processing capability, the "Harvest" attachment provided autonomous byte-stream processing. Mdmi (talk) 12:10, 15 April 2021 (UTC)[reply]

Many machines can do bit fields with shift and AND/OR instructions. As well as I know, though, the 7030 has something more specific than that, and maybe more like the PDP-10. The IBM 36 bit machines used a 6 bit character code, with, as well as I know, no specific instructions for working with them. The IBM 704 reads cards in row by row, with 72 positions in each row going into two 36 bit words. It then has to convert that to characters in software. They didn't make things easy in those days. Gah4 (talk) 20:41, 15 April 2021 (UTC)[reply]

As per the 7030 reference manual, integer arithmetic instructions have a 24-bit memory address, which points to a particular bit in memory, with the width of the operand, in bits, being a field in the instruction. This is similar to the PDP-6/PDP-10 in that fields can start at any bit in memory, but it's different in that 1) there are no "bit pointers" containing size information, there are just 24 bit long bit addresses, with a size fixed by the instruction, and 2) bytes can only be of a length between 1 and 8 bits but a field can be an arbitrary number of bits long. It's not as simple to explain as byte-pointer instructions. Guy Harris (talk) 07:29, 7 September 2023 (UTC)[reply]

Time sharing

"The PDP-10 is the machine that made time-sharing common". I agree with the statement that it looms large in hacker lore. But the IBM 360/67 surfaced only a year after the PDP-10, running MTS (Michigan Time Sharing) and eventually IBM TSS. Does the comparative market share of these two machines justify the main claim? Mdmi (talk) 12:29, 15 April 2021 (UTC)[reply]

I might have thought it was the HP 2116, running HP Time-Shared BASIC, that made time-sharing common. How many 67's ran MTS, and how many OS/360? Gah4 (talk) 20:24, 15 April 2021 (UTC)[reply]

Good question, although that raises another question - to what extent is a 360/67 running OS/360 anything more than "an overpriced 360/65"? I.e., why buy a /67 if you're not going to run an OS that uses the DAT box, for which you presumably paid extra money (if purchased) or are paying extra money (if leased)?

Of course, you could be running CP/CMS, in which case you might be running CMS in a bunch of the VMs and OS/360 in another, but that's Yet Another Flavor Of Time-Sharing. How many /67's were running that? Guy Harris (talk) 20:45, 15 April 2021 (UTC)[reply]

The only 360/67 I knew was at Stanford, and ran OS/360 MFT. It also ran WYLBUR as a time-shared text editor and job submission system, which doesn't require virtual addressing. But also ORVYL, Stanford's own time-share system for it, running under OS/360. I suspect Stanford had more plans for time-sharing, or expected it to be more popular than it was. Or maybe IBM gave them a good price. ORVYL was later ported to IBM S/370 systems with similar virtual addressing. (The 360/67 was IBM's practice for virtual addressing for S/370.) Gah4 (talk) 21:00, 15 April 2021 (UTC)[reply]

I don't even know how you'd prove that "The PDP-10 is the machine that made time-sharing common". The SDS 940 had something like 80 installations, a lot less than the 10, but earlier. The 360/67 was roughly contemporary, but I don't know how many installations it had. The HP 2000 came later, and was cheaper, so I would guess that it had more installations. What about the PDP-7/9? What counts as "common" and how does a particular model "make" time-sharing common? --Macrakis (talk) 23:26, 12 February 2022 (UTC)[reply]

I still vote for TSB 2000, which got people used to BASIC, and a market for Altair BASIC. Gah4 (talk) 10:35, 13 February 2022 (UTC)[reply]

The claim was about time-sharing, not about BASIC, so I don't see how that's relevant.

As for popularizing time-sharing, here's one quote I found: "GE, SDS, and DEC played early leadership roles with time-sharing hardware, GE standing out in becoming the first major time-sharing services provider.... By late 1968, GEIS had secured 40 percent of the $70 million time-sharing market..." (Jeffrey R. Yost, Making IT Work: A History of the Computer Services Industry, 2017, ISBN 0262342197 p. 158)

So I will remove the claim. --Macrakis (talk) 16:52, 13 February 2022 (UTC)[reply]

Popular culture that needs citations?

This was removed from the article. I am putting it here in case anyone wants to find references and put it back:

== In popular culture ==

Swordfish – Hugh Jackman's character accesses "The only PDP10 active and on the internet" which is in the basement of a Caltech building where he hides his worm creation program.
The Americans season 2, episode 7 ("Arpanet") – Kate relays orders for Philip to bug the PDP10 based ARPANET, which he accomplishes with the help of Duluth.

Adding a few more. Lars Brinkhoff (talk) 11:48, 23 August 2021 (UTC)[reply]

Hackers: Heroes of the Computer Revolution – Part one is almost all about PDP-6 and 10 hackers.
The Hacker's Dictionary – The jargon of PDP-10 hackers.

— Preceding unsigned comment added by Gah4 (talk • contribs) 05:45, 22 April 2021 (UTC)[reply]

The first two look completely incidental and unnecessary. Hackers and Hacker's Dictionary are almost entirely about ITS (and maybe SAIL) PDP-10s, not PDP-10s in general. So I don't think any of those belongs here. After all, the article already links to hacker culture. --Macrakis (talk) 23:13, 12 February 2022 (UTC)[reply]

Music video with CCRMA PDP-6 and Foonly (F2 or F4): https://www.youtube.com/watch?v=qs6iMer68co Lars Brinkhoff (talk) 11:29, 13 February 2022 (UTC)[reply]

Amusing, but obviously not relevant to the article. --Macrakis (talk) 16:54, 13 February 2022 (UTC)[reply]

the upper 18-bits (right half of the word)

The article says: the upper 18-bits (right half of the word). I haven't written Macro-10 programs for some years (decades) now, but last I remember the upper bits were the left half word, and lower bits the right half word. Gah4 (talk) 03:14, 7 September 2023 (UTC)[reply]

In documentation for most (if not all) instruction sets - including the PDP-10 instruction set - the most significant bit is on the left and the least significant bit is on the right, so I've no idea how the right half of the word became the upper 18 bits or the left half of the word became the lower 18 bits (somebody taking the bit numbering too seriously?). The page used a mix of the terminology from the 1970n DEC documentation, referring to "the left half/left N bits" and "the right half/right M bits" and "upper"/"lower", mostly using the DEC left/right terminology. I changed it to universally use the DEC terminology - and not to hyphenate "N bits". Guy Harris (talk) 06:29, 7 September 2023 (UTC)[reply]

Funny things sometimes happen for little-endian machines. At a seminar on RISC-V some years ago, I noticed that they instruction formats are all written with the opcode on the right. But most people put the opcode first, so on the left. (Including the PDP-10.) But for little-endian machines, the bits go the other way. The opcode, which comes first, is on the right. (Without looking) I believe that DEC numbers the PDP-10 bits from the MSB bit 0 on the left, and LSB bit 35 on the right. No little endian here! Gah4 (talk) 20:54, 7 September 2023 (UTC)[reply]

Funny things sometimes happen for little-endian machines. Funny things sometimes happen for big-endian machines, too. The Motorola 68000 family manuals label the least significant bit as bit 0, even though the 68k family is big-endian. See, for example, pages 1-2 and 2-3 of the April 1983 Motorola 68000 manual.

At a seminar on RISC-V some years ago, I noticed that they instruction formats are all written with the opcode on the right. I think that's because the opcode is in the low-order bits of a 32-bit instruction word. And that appears to be a consequence of, among other things, RISC-V being little-endina; to quote page 114 of Volume I: RISC-V User-Level ISA V2.2:

We use the term prefix to refer to the bits to the right of an instruction encoding space (since RISC-V is little-endian, the bits to the right are stored at earlier memory addresses, hence form a prefix in instruction-fetch order). The prefix for the standard base ISA encoding is the two-bit “11” field held in bits 1–0 of the 32-bit word, while the prefix for the standard atomic extension “A” is the seven-bit “0101111” field held in bits 6–0 of the 32-bit word representing the AMO major opcode. A quirk of the encoding format is that the 3-bit funct3 field used to encode a minor opcode is not contiguous with the major opcode bits in the 32-bit instruction format, but is considered part of the prefix for 22-bit instruction spaces.

which I think may mean "if you don't fetch an instruction in one 32-bit gulp, but fetch it a byte at a time, the first byte you fetch - which contains the low-order 8 bits, even on big-endian processors or bi-endian processors running in big-endian mode - has the bits an instruction decoder will probably want to see first". (Yes, RISC-V now specifies optional support for big-endian data.) They spent a fair bit of time and energy designing the bit encoding for instructions so as to help implementers for processors from small embedded processors to big high-performance processors.

I.e., they didn't flip the display of words to be right to left as an unusual documentation convention, they flipped the opcode from left to right in what might be considered an unusual instruction encoding convention. Unusual instruction encodings may require more work on the part of people reading ISA documentation, assembler writers, and disassembler writers, but may require less work on the part of instruction decoding hardware. (I think PA-RISC may have some unusual encoding conventions, perhaps done for the same reason, as well.)

But most people put the opcode first, so on the left. I think most word-oriented processors, and big-endian byte-addressible processors with instruction sizes that are a multiple of 2 or 4 bytes, put the opcode in the uppermost bits of the first multi-byte unit of the instruction. For byte-serial processors implementing a big-endian ISA, such as an S/360 Model 30, that means the byte that specifies the format of what follows is the first byte fetched.

As for little-endian byte-addressible instruction sets other than RISC-V:

DEC:

PDP-11 instructions are sequences of 1 or more 16-bit words, with the opcode in the upper bits of the first word, which means it's shown on the left of the word. The opcode, for most instructions, isn't neatly aligned on a byte boundary. This might get in the way of any byte-serial implementations, but I don't know the details.
VAX instructions are sequences of 1 or more bytes, with the opcode in the first byte for most instructions. If the first byte os 0xFC through 0xFF, the following byte contains the rest of the opcode; the 16-bit word (a "word", in VAXland, is 16 bits, just as it is for the PDP-11; 32 bits is a "longword") containing the opcode puts the (rest of) opcode on th eleft, as it's in the second sequential byte.
Alpha puts the opcode on the left, i.e. in the fourth sequential byte of the 4-byte instruction (the byte with 0b11 in the low-order 2 bits of its address) - but Alpha was not, as far as I know, designed with the idea that instructions might be fetched in byte-serial or word-serial fashion (a "word", in Alphaland, is again 16 bits, with 32 bits being a "longword" and 64 bits being a "quadword"), so that probably makes little if any performance difference, especially given that all instructions are 4 bytes long.

ARM:

"Original ARM"/A32 instructions are all 32 bits long, with the uppermost 4 bits of the 32-bit instruction word being the predicate condition, the next 3 bits specifying the general class of instructions and, if those bits are 0b011, the fifth bit from the bottom of the word indicating whether the instruction is a load/store instruction or a media instruction. Other bits scattered throughout the word specify more of the opcode.
Thumb/Thumb-2/T32 instructions may be 16 bits or 32 bits long; they seem to stuff the opcode in the uppermost bits of the 16-bit or 32-bit quantity.
A64 instructions are in some ways like A32 instructions, except that the uppermost 4 bits are used for various purposes, as predication is not as common as in A32.

So ARM is a bit like RISC-V in that regard; the instruction format isn't simple.

x86:

x86 is a bag of one or more instruction prefixes, 1 to 3-byte opcodes, and other stuff. The bytes that make up an instruction in various encodings (a particular instruction may be encoded in several different ways) are shown as hex values or prefix names or strings representing various types of operand bytes, going from the first byte in memory on the left to thethe last byte in memory on the right. There are no pretty pictures showing the opcode on the left or the right within a word (again, 16 bits, just like the PDP-11) or anything else, as, like the VAX, x86 instructions are just sequencs of bytes, possibly with an odd number of bytes.

The opcode, which comes first, is on the right. True for RISC-V - the opcode is in the first sequential byte of the 4-byte instruction, hene on the right - but not true, for example, for Alpha, where the opcode is in the fourth sequential byte.

I believe that DEC numbers the PDP-10 bits from the MSB bit 0 on the left, and LSB bit 35 on the right. Yes. Guy Harris (talk) 07:36, 8 September 2023 (UTC)[reply]

I was thinking not so long ago about VAX. The instruction format is very nicely designed for processing one byte at a time. Not at all for pipelined parallel processing. The first thing you want to know in a pipelined processor is where the next instruction starts. VAX has address mode bytes for operands, each of which can have an offset of the appropriate number of bytes, before the next address mode byte. A very small change would have made it a lot easier: put all the address mode bytes immediately after the opcode, then the offset or immediate bytes. There is an additional complication with indexed addressing, but maybe not so bad. The instruction decoder would then grab the first bytes of an instruction, and quickly know where the next instruction is. Just a tiny change! For comparison, OS/360 and successors, the first two bits of the opcode tell how long the instruction is. One immediately knows where the next instruction is.

I remember when Alpha was announced, and I got a nice little book about it, including instruction and data formats. I hadn't thought at the time about which end the opcode was on. Original Alpha can only fetch/store 32 bit and 64 bit words. For byte or (16 bit) word operations, you load into a register and then operate on bytes in the register. Conveniently, load/store instructions ignore the low bits, so you don't have to mask them off. Byte within register instructions ignore the high bits. I think it works well.

In Blaauw and Brooks Computer Architecture: Concepts and Evolution book, they mention the big-endian design of IBM S/360, which Blaauw helped design, as being the right way. For any processor more complicated than the 6502, big endian seems right to me. There is a tiny advantage for the 6502 in computing the carry bit. Any machine that does multiply and divide needs to be able to get bytes out of order.

Back to little-endian VAX. The VMS DUMP program, printing out hexadecimal and ASCII data from a file, prints the ASCII data left to right, and hexadecimal data right to left, with the address in between. This way words, longwords, and quadwords come out the way people expect, in big endian order! Then there is the unix od -x program, which prints out 16 bit words in hexadecimal, so the bytes are in a funny order on little endian machines. Oh well. Gah4 (talk) 07:16, 9 September 2023 (UTC)[reply]

Foo

Hack-hack^[1]

References

^ Thompson, Ken (2006). "Oral History of Ken Thompson" (PDF) (Interview). Interviewed by John Mashey. Mountain View, California: Computer History Museum. Retrieved October 18, 2023. ...the -10 is kind of a trashy machine with 36 bits – the future just left it behind.

Jamplevia (talk) 01:15, 19 October 2023 (UTC)[reply]

Museum

As well as I know, the hardware is still in the building that was the Living Computer Museum. Some will be auctioned off soon. I am not sure if any PDP-10 are on the list. Gah4 (talk) 18:11, 22 August 2024 (UTC)[reply]

If "the list" means "the list of machines that may be auctioned off", Christie's is auctioning off a KA10. Here's the full list of items for that auction, which includes a KI10 and a KS10 (DECSYSTEM-2020), as well as a System Concepts SC40 clone (and a ton of other interesting machines, including a Xerox Star, a Micral N and other early microcomputers, a Kenbak-1, an IBM 650, an IBM 7090, a UNIVAC 1004, a CDC 6500, a Cray-2, an SDS Sigma 9, some DEC and HP minis, and a paper tape with Spacewar! on it (but no PDP-1 on which to run it)).

It would be nice if some computer museum or museums could afford to buy the entire collection and to have a place or places to store the items. Guy Harris (talk) 20:21, 22 August 2024 (UTC)[reply]

OK, that is more than was on the list when I looked (weeks ago), and even more, more than I knew that they had. Some years ago, I got to tour the basement, to see the ones not on display. I do remember the ETA-10 which isn't on a list I know about, yet. Some of the ones you mention, I wouldn't expect to sell for more than the cost to move. I don't know at all how the CHM budget works, though. I was hoping for a CHM North, with some kind of complicated deal. I also don't remember the Cray 2. I do remember a CM-2, though. I was hoping to see it run, and then find some old programs to run on it. Must be someone around who has some of those. Gah4 (talk) 22:09, 22 August 2024 (UTC)[reply]

Oh, also, mentioning a ton. I think the CDC 6500 itself will be a ton or more. (Include the refrigeration system.) Maybe the Cray-1, too. Gah4 (talk) 22:15, 22 August 2024 (UTC)[reply]

[1] Thompson, Ken (2006). "Oral History of Ken Thompson" (PDF) (Interview). Interviewed by John Mashey. Mountain View, California: Computer History Museum. Retrieved October 18, 2023. ...the -10 is kind of a trashy machine with 36 bits – the future just left it behind.

[1]