[TUHS] 11/40E and 11/60 (was: speaking of early C compilers)

[Johnny Billquist]

On 2014-10-28 13:42, Clem Cole <clemc at ccc.com> wrote:

> yes:
> http://repository.cmu.edu/cgi/viewcontent.cgi?article=3241&context=compsci

Cool. I knew CMU did a lot of things with 11/40 machines. I didn't know 
they had modified them to be able to write their own microcode, but 
thinking about it, it should have been obvious. As they did 
multiprocessor systems based on the 11/40, they would have had to modify 
the microcode anyway.

> I had a 60 running v7 years later. we also toyed with adding CSV/CRET
> but never did it because we got an 11/70
>> >On Oct 27, 2014, at 9:09 PM, Dave Horsfall<dave at horsfall.org>  wrote:
>> >
>>> >>On Mon, 27 Oct 2014, Clem Cole wrote:
>>> >>
>>> >>[...] because the CMU 11/40E had special CSV/CRET microcode which we
>>> >>could not use on the 11/34.
>> >
>> >The 40E had microcode whilst the vanilla 40 didn't?  I thought only the 60
>> >was micro-programmable; I never did get around to implementing CSV/CRET on
>> >our 60 (Digital had a bunch of them when a contract with a publishing
>> >house fell through).

DEC actually made two PDP-11s that were micro programmable. The 11/60 
and the 11/03 (if I remember right). DEC never had microprogramming for 
the 11/40, but obviously CMU did that.

Ronald Natalie<ron at ronnatalie.com> wrote:

>> >On Oct 27, 2014, at 10:06 PM, Clem Cole<clemc at ccc.com>  wrote:
>> >
>> >yes:http://repository.cmu.edu/cgi/viewcontent.cgi?article=3241&context=compsci  <http://repository.cmu.edu/cgi/viewcontent.cgi?article=3241&context=compsci>
>> >
>> >I had a 60 running v7 years later.   we also toyed with adding CSV/CRET but never did it because we got an 11/70
> Problem with the 60 was it lacked Split I/D (as did the 40's).    We kind of relied on that for the kernels towards the end of the PDP-11 days,
> We struggled with the lack of I/D on the 11/34 and 11/23 at BRL but finally gave up when TCP came along.   We just didn't have enough segments to handle all the overlaying needed to do.    I recycled all the non split-I/D machines into BRL GATEWAYS.
>
> Of course, there was the famous (or imfamous) MARK instruction.   This thing was sort of a kludge, you actually pushed the instruction on the stack and then did the RTS into the stack to execute the MARK to pop the stack and jump back to the caller.      I know of no compiler (either DEC-written or UNIX) that used the silly thing.    It obviously wouldn't work in split I/D mode anyhow.   Years later while sitting in some DEC product announcement presentation, they announced the new T-11 chip (the single chip PDP-11) and the speaker said that it supported the entire instruction set with the exception of MARK.    Me and one other PDP-11 trivia guy are going "What?  No mark instruction?" in the back of the room.

Yurg... The MARK instruction was just silly. I never knew of anyone who 
actually used it. Rumors have it that DEC just came up with it to be 
able to extend some patent for a few more years related to the whole 
PDP-11 architecture.

Clem Cole<clemc at ccc.com> wrote:

>> >Problem with the 60 was it lacked Split I/D (as did the 40's).
>
> ?A problem was that it was 40 class processor and as you says that means it
> was shared I/D (i.e. pure 16 bits) - so it lacked the 45 class 17th bit.
>    The 60 has went into history as the machine that went from product to
> "traditional products" faster than any other DEC product (IIRC 9 months).
> I'm always surprised to hear of folks that had them because so few were
> actually made.

I picked up four 11/60 machines from a place in the late 80s. I still 
have a complete set of CPU cards, but threw the last machine away about 
10 years ago.

> I've forgotten the details nows, but they also had some issues when running
> UNIX.  Steve Glaser and I chased those for a long time.  The 60 had the HCM
> instruction sequences (halt a confuse microcode) which were some what
> random although UNIX seemed to hit them.  DEC envisioned it as a commercial
> machine and added decimal arithmetic to it for RSTS Cobol.?  I'm not sure
> RSX was even supported on it.

RSX-11M supports it. So do RSTS/E and RT-11. RSX-11M-PLUS obviously 
don't, since it have a minimal requirement of 22-bit addressing.

The microcode specific instructions are interesting. But in general 
shouldn't crash things, but of course kernel is a different story. :-)

	Johnny