The following was part of a quiz posted in a Newsgroup:
3. Tom Farrin is famous for a hack he did to DEC's PDP-11/70.
This was a trace cut and jump inside the CPU which:
a) increased the system clock speed by 12.5%
b) enabled IEEE-compatible floating-point arithmetic
c) froze the contents of the cache
d) disabled the Unibus reset that occurs automatically on a bus error
e) made separate instruction and data space available in user mode
[....]
to which Robert Herndon provided additional insight:
"and the answer is listed as `E'". I was present at a lecture he gave at the 1978 Unix Users Group Conference in NYC (this was just before they asked BTL for official permission to call themselves this, and were turned down, after which the conferences became "Usenix" conferences). In it, he described how he needed the MFPI instruction (move from previous instruction space; it gets a word of data from the "previous mode"'s instruction space) in order to efficiently determine the number of arguments pushed on the stack.
This was because his Lisp interpreter was too big to run without running in separate I & D spaces (type 411 binary, as opposed to 407 (unshareable), or 410 (shareable, but common address space). Running programs in separate I & D spaces was an everyday event on PDP-11s at the time, but separate I&D binaries could not use the nargs() procedure (which looked at the caller's instructions).
Since his program was running in separate I & D spaces, any loads to look at the caller's instructions would simply load a word from the data space at the same address. DEC, in their wisdom, had made the MFPI and MFPD instructions privileged, so he couldn't use them to look at his instruction space. So he made a system call available to do this function, but found that it was very slow. And as he put it, that wasn't very satisfactory, and "Well, there's this NAND gate, and if you cut this wire...", and the room dissolved in laughter. And then he told us that this cut was available as a DEC field mod and gave us its number...
If you want another bit of trivia in this vein, the 407 header number for Unix binaries is an artifact of the PDP-11's instruction set. This is a 'branch forward 7 words'. In case you installed your block-zero bootstrap without first stripping off the eight-word header, this allowed it to run anyway (since the code was position independent). Other machines have used 407 headers ever since for no good reason... [rh]
John Shelton writes:
In 1978 or so, I was running a Heathkit version of the LSI-11 at home, and was unsatisfied with the memory limitation of 28kb (4kb reserved for I/O space). Since I didn't have a lot of peripherals, I made sure all their I/O addresses were in the top 1k of address space, then constructed a 3kb memory card, thus having the largest memory LSI-11 around: 31kb!
Trivia item: did you note anywhere that the 11/60 was used to implement the world's fastest PDP-8? The 8 support group for years used an 11/60 RSTS system down the hall, running custom microcode addons to implement a high speed PDP8 emulator. (Paul Koning)
Rumour has it that some hacker also did this on a VAX-11/780, which would definitely out-run the 11/60 version. However, I don't believe this was used in production anywhere, and the 11/60 definitely was.
And of course, 'kill-the-rotating-bit' games on the console were a blast. These could be run from user mode, certainly under unix, and probably under the other OSes as well. The game put an initial bit in R0 and executed a wait (instruction 1). It then made a getcsw() call to the kernel to get the state of the console switch register, and XORed this result into R0. If R0 == 0, then it would flash the lights for a bit, reload R0 with a nice new value, and restart the game. Otherwise, it would rotate R0 one position and go on. (The 'wait' instruction halted the CPU until the next interrupt. Bizarrely, it was executable from user mode.)
In nearly all PDP11s, the GPR "addresses" work only from the console, you can't use them in a program. But they *do* work in the PDP11/05 and /10. In fact, you can put code in the GPRs. And if you do, the PC will increment by 1 rather than by 2! (It seems someone had a few spare words in the microprogram and figured this would be a useful hack. Yes indeed, it lets you test the CPU without having any working memory.)