Slashdot Mirror
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."
May I ask what you mean by "real OS". Could it be Windows 95?
No, I was thinking along the lines of ITS or TOPS-10. I guess you are really new to copmputers since (a) you don't know the native software of a PDP-10 and (b) you aren't aware of any OS'es besides Linux and Windows 95.
-Doug Humphrey (aka DIGEX), pissing off the Vax weenies at DECUS
-Don
Take a look and feel free: http://www.PieMenu.com
The complete system is called a DECsystem-10 or a DECSYSTEM-20, depending on whether it ran TOPS-10 or TOPS-20.
Your friend was much more likely talking about a small PDP-11. Even the big PDP-11s (e.g., 11/70) were not suited to running in extreme environmental conditions.
When we unloaded the machine we were somewhat pressed for time, but Mike Cheponis managed to take a few photos.
There's apparently another 2065 still running in a school district in or around Boston.
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.
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.
They weren't lightening -- but they scaled well.
They ran TOPS-10 or TOPS-20 and did real nice SMP with more than 3 cpu's supported (even back in the old days).
I guess they were in the 1 mips range (KL10) or less (KA cpu, KI cpu, KS cpu) -- but with much more load handling than the 11/780 which really was less powerful than the KL10.
The TOPS-10 and TOPS-20 operating systems (both were available for the PDP10) were easy to use, friendly and WAS NOT UNIX like in the slightest.
They handled a ton of timeshared users efficiently and reliably and made IBM take notice of timeshared use. The OS was written in Macro10
(macro assembler) and the instruction set was RISC-like.
Microsoft did most of it's development cross developing on this CPU type. (As did DEC -- which used them for emulation of new CPU designs and for cross development of software for the PDP8 at times).
GCC would be interesting -- remember this isn't just another a POSIX box.
This is the CPU where EMACS really was born as editing MACROS for TECO (Tape--er Text Editor and Corrector).
Had Kernighan, Thompson and Richie gotten one of these they wouldn't have developed Unix in the first place.
These machines were used as some of the first machines on the internet. They were heavy crunching boxes at Western Electric for engineering time sharing.
Rutgers University had three that I knew of,
Columbia, Rider College, Johnson and Johnson...
These were CLASSIC Machines.
See alt.sys.pdp10.
--Bill
If you're not part of the solution, you're part of the precipitate.
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.
Brackets contain world's first nanosig, highly magnified:[.]
While it isn't a PDP-10, I did help write a PDP-11 emulator, assembler and debugger.
check it out:
http://www.csc.uvic.ca/~rrabien/
oh ya, it requires unix or linux, open source too.
The PDP-10 was most definitely a mainframe, or at least it was by far the largest computer that DEC made, and it was made expressly to compete with IBM in that space. It has nothing to do with the PDP-11 or -8, which were mini's.