PDP-10 Revival

Lars Brinkhoff writes: "Remember the PDP-10 mainframe, the machine that ran the first version of EMACS and helped foster the Free Software movement? Now a company called XKL, LCC is funding a PDP-10 port of GCC. There's also a project to create a PDP-10 processor in an FPGA."

Comments

C on the PDP-10 is a *bitch*

[eschasi]

I have fond memories of the PDP-10, a machine on which I did far too much assembler hacking. Not to mention editing in TECO, debugging with DDT (dynamic debugging tool), and playing Adventure over a 300-baud line on a DECWriter (a paper trail was worth its weight in gold for that game.) A year of programming in BLISS-10 was great preparation for my first exposure to C.

We (ADP Network Services) had a C compiler for it back in late '82 or early '83. We'd started doing some UNIX work on 8086s, liked it and C, and management wanted to know if we could back-port some of our C stuff to TOPS-10. BLISS-10 seemed kind of an existence proof that C was possible for PDP-10s. So fella named Don Wakelin ported one from (I think) a Harris mini. We picked that one because the Harris had 18-bit words and the PDP-10 had 36.

36 bit words, 18-bit word addresses, and bit-addressable memory made for a rather, er, idiosyncratic C compiler. We chose to use 7bit characters (a stock PDP-10 type), which meant each word had one bit left over. If you think the assumption that (sizeof)* == (sizeof)int broke a lot of programs, you should *see* what happens when characters weren't 8 bits and were immutably unsigned. For the record, most ASCII data on PDP-10s was stored as 7bit characters packed five per 36-bit word with one bit left over.

The only reason that worked well (and yes, it worked quite well) was because memory on the 10 was bit-addressable. It had these peculiar things called `byte pointers'. An 18-bit word address was stuck into a 36-bit word. The other 18 bits indicated the number of bits offset into the word, and the number of bits to be obtained on a fetch. Good byte pointer users could fetch 1 bit, then the next 5, then 3, etc, etc. Brought a whole new level of complexity to incrementing your pointers. Most folks just used them for characters, tho, setting fetch size to 7. Machine-level instructions did the heavy lifting on pointer incrementing - take code like

char *i = "abcefg" ;
char c;
c = *i++ ;

The first line caused a byte pointer to be created with the address of the word containing the start of the string. The offset was 0, the fetch size was 7. The last line was done with just two assembler instructions. One fetched 7 bits from the address pointed to into a register and incremented the offset portion of the byte pointer by seven bits; the second just stored the register contents into the variable c. After you fetch the fifth character using i, the auto-increment instruction added 1 to the 18-bit address and reset the offset to 0.

Address zero was addressable -- it happened to be register zero. In fact, all the registers were addressable as 0-15. But when the null pointer successfully loaded and stored data, programs did a whole 'nuther set of interesting things.

Another fellow at ADP successfully headed a project to port University Ingres to TOPS-10. He told the most amazing horror stories for years afterwards...

And will the true story ever be told of PDP-10 follow-on machine, the Jupiter? It was supposed to be a truly huge (for the day) PDP-10, intended to compete with the IBM System 370. It was constantly started and cancelled and started and cancelled. We (ADP) finally concluded that it was just a feint so we wouldn't switch to some other hardware before DEC got the equally-late Venus project done. When Venus finally did ship, DEC called it the VAX. At an East Coast SF convention in the late '80s I bumped into someone wearing a faded `36 bits forever' t-shirt. When I asked what happened to the 10 projects, she refused to answer and looked *really* pissed.

There have been a number of PDP-10 clones built over the years, at least two companies are still making them. One of them is the company sponsoring the port; big surprise, eh? The target customers are folks who wants to run TENEX (UNIX-alike for PDP-10s) or ITS (Incompatible Timesharing System), MIT LISP refugees, and hardcore TOPS-10/TOPS-20 sites, maybe including ADP.

PDP 10 hacks

[swinge]

some interesting hacks on the PDP-10:

because it was a 36bit machine, it was particularly good for LISP, or better than the alternatives. Because you could divide a 36bit word into two 18-bit pointers, you could implement a LISP cons cell in one word, and thus handle cons cells fairly quickly. The same hack with competing 32bit machines, 16bit ob references just didn't provide a big enough data space.

The PDP-10 had its registers mapped into memory as the first 16 words starting with 0. But, being registers, they were really fast. So the text editor TECO (daddy to EMACS) would "compile" a search command into a tiny little program stored in the registers. Executing the code in the fast registers made for really quick (for the time) text searching.

Um, the world isn't quite so simple.

[Christopher B. Brown]

There are, after all, other OSes out there.

• The Unix-Haters largely come out of the community of users of Lisp machines, with a few "X haters" that preferred NeXTstep and NeWS;
• You probably don't work with mainframe folk; they are pretty desparaging of Unix-like stuff as being "toyish;"
• VMS users are a similarly proud (albeit seemingly fading) group that generally aren't big fans of Linux
• Then there's Multics ...
• Fewer people remember GECOS, Stratus, and such...
• PDP-10's ran such notable OSes as TOPS-10, ITS, all vastly not Unix.

Re:how fast were these things?

[localroger]

Not very. The PDP-10 had magnetic core memory, which means it could not have cycled much faster than 1 MHz. It also did not have modern features like pipeline caches, etc. all of which would have required an astronomical number of the low density silicon chips available at the time. I used a DEC System 10 at university. It had a massively multiplayer (by those days' standards) Star Trek game called DECwar. If you have ever played the original text-based Star Trek game you know what this looked like, otherwise you cannot IMAGINE how primitive it was; yet the engineering students would spend hours after hours playing this thing. Simple as it was, with a few dozen users on the system the task-switching delays were *very* noticeable. IIRC the our mainframe had 256K of RAM, then considered an astronomical amount, and the 5-30 Mb "layer cake" cartridge hard drives someone else mentioned. It was in a glass room so you could ogle it and the observant priesthood of the computer dept who serviced your Hollerith card batch jobs. It was 6 or 7 cabinets, several with rows of incandescent pilot lights displaying the current address and register. You could, with practice, learn to interpret those flickers and tell how fast it was switching jobs and whether one job was hogging the machine. It was that slow. It would have been much slower if programmed in today's style. But almost all DEC software was written in a macro-assembler style language which resulted in very efficient code. Although the basic core was RISClike most of those old CPU's all supported processor extensions in the form of cards added to a rack, which could actually add microcode and new registers to the CPU. (Not at all like the FPU on an x86, which is more like an outboard processor.) Yep, those were the days; when you signed up for class you were allotted a certain number of seconds of computer time and if you used them up (difficult, but possible) your account shut down automatically. The CPU actually kept track of your real usage as tasks were swapped, and the OS bailed your app if it looked like it had gotten hung in a loop or something. And then there was the joy that is FORTRAN -- such a great language that I used to prewrite and debug everything in BASIC before converting it over. Yep, definitely memories to savor as I pat the side of my 450MHz pentium.