[TUHS] PDP-10 UNIX?

[TUHS] PDP-10 UNIX?

[Nelson H. F. Beebe]

Warner Losh <imp at bsdimp.com> kindly corrected my statement that kcc
compiler on the PDP-10 was done by Ken Harrenstien, pointing out that
it was actually begun by Kok Chen (whence, the name kcc).

I've just dug into the source tree for the compiler, and found this
leading paragraph in kcc5.vmshelp (filesystem date of 3-Sep-1988) that
provides proper credits:

>> ...
>>          KCC is a compiler for the C language on the PDP-10.  It was
>>  originally begun by Kok Chen of Stanford University around 1981 (hence
>>  the name "KCC"), improved by a number of people at Stanford and Columbia
>>  (primarily David Eppstein, KRONJ), and then adopted by Ken Harrenstien
>>  and Ian Macky of SRI International as the starting point for what is now
>>  a complete and supported implementation of C.  KCC implements C as
>>  described by the following references:
>> 
>>          H&S: Harbison and Steele, "C: A Reference Manual",
>>           HS1: (1st edition) Prentice-Hall, 1984, ISBN 0-13-110008-4
>>           HS2: (2nd edition) Prentice-Hall, 1987, ISBN 0-13-109802-0
>>          K&R: Kernighan and Ritchie, "The C Programming Language",
>>                  Prentice-Hall, 1978, ISBN 0-13-110163-3
>> 
>>          Currently KCC is only supported for TOPS-20, although there is
>>  no reason it cannot be used for other PDP-10 systems or processors.
>>  The remaining discussion assumes you are on a TOPS-20 system.
>> ...

I met Ken only once, in his office at SRI, but back in our TOPS-20
days, we had several e-mail contacts.

----------------------------------------

P.S. In these days of multi-million line compilers, it is interesting
to inspect the kcc source code line count:

	% find . -name '*.[ch]' | xargs cat | wc -l
	80298

A similar check on a 10-Oct-2016 snapshot of the actively-maintained
pcc compiler for Unix systems found 155896 lines.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

[TUHS] PDP-10 UNIX?

[arnold]

"Nelson H. F. Beebe" <beebe at math.utah.edu> wrote:

> P.S. In these days of multi-million line compilers, it is interesting
> to inspect the kcc source code line count:
>
> 	% find . -name '*.[ch]' | xargs cat | wc -l
> 	80298
>
> A similar check on a 10-Oct-2016 snapshot of the actively-maintained
> pcc compiler for Unix systems found 155896 lines.

Current PCC supports several architectures, that should be remembered.
Although the line count is relatively smal.

Arnold

[TUHS] PDP-10 UNIX?

[Warner Losh]

On Mon, Sep 18, 2017 at 12:10 PM, Lars Brinkhoff <lars at nocrew.org> wrote:

> Nelson H. F. Beebe wrote:
> > kcc was written by Ken Harrenstien from scratch
>
> Rewritten maybe?  Some KCC source code files have the comment
>
>     "Original version (c) 1981 K. Chen"
>
> which I take to mean referencing Kok Chen.


Kok Chen's work was the basis for the Greg Titis compiler. It wound up on a
bunch of DECUS tapes, but never seems to have taken off (Greg seems to
think as many as 20 copies existed in the wild). I heard from him off list.
He started with the kcc compiler, then rewrite the scanner, parser and
code-gen, leaving behind just the interfaces. Sadly, he lost all copies he
had in a flood in maybe 1988. He recommends the latter-day kcc as well as
being the best compiler to use if you want to have a more purist
experience. gcc on tops-20 just feels wrong, even to him (he's spent the
years since then doing various compiler things for Cray).

Anyway, just another bit of trivia for this wonderful thread.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170919/be1c99f8/attachment.html>

[TUHS] PDP-10 UNIX?

[Lars Brinkhoff]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 499 bytes --]

Mutiny writes:
> Clem Cole wrote:
>> ​There was a PDP-10 C compiler in the late 1970s, that was kicking
>> around CMU, MIT and Stanford
>
> there is a video on youtube about its & c-language demonstrating teco-'emacs'
> and the c-compiler.

Yes.  I have talked to the person who made it.

https://www.youtube.com/watch?v=zF-vy8b4r-Y

He also made two more about other parts of ITS, but I guess that's too
far outside the scope of this mailing list.  (So why did I write this?
Can't help myself!)

[TUHS] PDP-10 UNIX?

[Mutiny]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 688 bytes --]

there is a video on youtube about its & c-language demonstrating teco-'emacs'  and the c-compiler.From: Lars Brinkhoff <lars at nocrew.org>Sent: Tue, 19 Sep 2017 01:29:13To: Clem Cole <clemc at ccc.com>Cc: TUHS main list <tuhs at minnie.tuhs.org>Subject: Re: [TUHS] PDP-10 UNIX?Clem Cole wrote:> ​There was a PDP-10 C compiler in the late 1970s, that was kicking> around CMU, MIT and StanfordWhen you say MIT, do you know if that was at the AI lab (i.e. ITS), orelsewhere?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170919/ab3bf4f4/attachment-0001.html>

[TUHS] PDP-10 UNIX?

[Lars Brinkhoff]

Noel Chiappa writes:
> > That makes sense if it's '73.  That would be the Ritchie front end
> > and v5/v6 syntax as I remember=20
>
> Here:
>
>   http://publications.csail.mit.edu/lcs/specpub.php?id=717
>
> is the TR describing it (well, this report covers one by him for the
> Honeywell 6000 series, but IIRC it's the same compiler).

It mentions a PDP-10 version on page 5.

> I didn't read the whole thing slowly, but glancing quickly at it, it
> sounds like it's possible a 'from scratch' thing?

That's my impression.  Various places claim this compiler was an
inspiration for PCC.  Also, Snyder was the one to suggest a preprocessor
and the && and || operators.

I'm in touch with someone who has the source code for the compiler, but
we can't release it to the public without consent from Alan.

[TUHS] PDP-10 UNIX?

[Noel Chiappa]

    > That makes sense if it's '73.  That would be the Ritchie front end and
    > v5/v6 syntax as I remember=20

Here:

  http://publications.csail.mit.edu/lcs/specpub.php?id=717

is the TR describing it (well, this report covers one by him for the Honeywell
6000 series, but IIRC it's the same compiler). I didn't read the whole thing
slowly, but glancing quickly at it, it sounds like it's possible a 'from
scratch' thing?

	 Noel

[TUHS] PDP-10 UNIX?

[Clem cole]

I would bet it was the Snyder compiler. 


That makes sense if it's '73.   That would be the Ritchie front end and v5/v6 syntax as I remember 


Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Sep 18, 2017, at 4:22 PM, Lars Brinkhoff <lars at nocrew.org> wrote:
> 
> Clem Cole wrote:
>>>> There was a PDP-10 C compiler in the late 1970s, that was kicking
>>>> around CMU, MIT and Stanford
>>> When you say MIT, do you know if that was at the AI lab (i.e. ITS),
>>> or elsewhere?
>> I thought there was a copy on ITS at one point. You tell me. I know it
>> was at CMU as I used it there. Many/Most of the compilers we had we
>> also at Stanford and MIT modulo differences in the OS environments.
> 
> In the ITS files from 1990, I have found two C compilers:
> - C10 by Alan Snyder,
> - and an incomplete port of KCC.
> 
> The KCC files seem to be from the late 80s.  Alan Snyders thesis is from
> 1973 and mentions the PDP-10.  So I wonder C10 if went from MIT to CMU
> and Stanford, or if there's some other compiler which came to MIT?

[TUHS] PDP-10 UNIX?

[Lars Brinkhoff]

Clem Cole wrote:
> > > There was a PDP-10 C compiler in the late 1970s, that was kicking
> > > around CMU, MIT and Stanford
> > When you say MIT, do you know if that was at the AI lab (i.e. ITS),
> > or elsewhere?
> I thought there was a copy on ITS at one point. You tell me. I know it
> was at CMU as I used it there. Many/Most of the compilers we had we
> also at Stanford and MIT modulo differences in the OS environments.

In the ITS files from 1990, I have found two C compilers:
- C10 by Alan Snyder,
- and an incomplete port of KCC.

The KCC files seem to be from the late 80s.  Alan Snyders thesis is from
1973 and mentions the PDP-10.  So I wonder C10 if went from MIT to CMU
and Stanford, or if there's some other compiler which came to MIT?

[TUHS] PDP-10 UNIX?

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 683 bytes --]

I thought there was a copy on ITS at one point.  You tell me.   I know it
was at CMU as I used it there.   Many/Most of the compilers we had we also
at Stanford and MIT modulo differences in the OS environments.

Clem

On Mon, Sep 18, 2017 at 3:58 PM, Lars Brinkhoff <lars at nocrew.org> wrote:

> Clem Cole wrote:
> > ​There was a PDP-10 C compiler in the late 1970s, that was kicking
> > around CMU, MIT and Stanford
>
> When you say MIT, do you know if that was at the AI lab (i.e. ITS), or
> elsewhere?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170918/4b233ca5/attachment-0001.html>

[TUHS] PDP-10 UNIX?

[Chris Torek]

>> After the first time, there is little to learn, and the tedium of
>> debugging a compiler and OS on a bare machine, when the documentation of
>> the machine was hastily written and often incomplete, was frustrating
>> almost beyond describing.

>+1  And the HW does [not] quite work the way it claimed too....
>It's fun ... once  :-)

I've done more than one, although it was the "same machine" in
various ways: SPARC v7, v8, and v9, on sun4c, sun4m, and sun4u.

The sun4u was the most frustrating hardware-bug-wise.  The
architecture book specifically said that the indexing in the cache
(left vs right half, as it were) was strictly based on the virtual
address bits, but in fact, this wasn't true: the hardware looked
in both halves and would return data from the "wrong half" if it
was still present there.  (It would only store *new* cache entries
in the correct half, so if you did eager flush it would work the
same way, but if you did lazy flush like we did, well...)

There was also an ALU forwarding bug.  If you took a trap, and in
the trap handler, computed values in the right (wrong) order, a
register could get the wrong result stored in it.  This only
happened after traps, but I proved it using a software trap.  It
was hitting my interrupt handler about 1 out of every few hundred
thousand times (resulting in kernel panic); using the software trap
I could see it less dramatically, and prove that re-ordering the
instructions or adding a NOP in the pipeline would fix it.

Chris

[TUHS] PDP-10 UNIX?

[Lars Brinkhoff]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 203 bytes --]

Clem Cole wrote:
> ​There was a PDP-10 C compiler in the late 1970s, that was kicking
> around CMU, MIT and Stanford

When you say MIT, do you know if that was at the AI lab (i.e. ITS), or
elsewhere?

[TUHS] PDP-10 UNIX?

[Lars Brinkhoff]

Nelson H. F. Beebe wrote:
> kcc was written by Ken Harrenstien from scratch

Rewritten maybe?  Some KCC source code files have the comment

    "Original version (c) 1981 K. Chen"

which I take to mean referencing Kok Chen.


> P.S. I'll be happy to entertain further questions about these two C
> compilers on the PDP-10, offline if you prefer, or on this list.

You never heard about one by Alan Snyder?

[TUHS] PDP-10 UNIX?

[Larry McVoy]

On Mon, Sep 18, 2017 at 01:25:41PM -0400, Clem Cole wrote:
> On Mon, Sep 18, 2017 at 12:46 PM, Steve Johnson <scj at yaccman.com> wrote:
> 
> >
> >
> > ???...
> >  After the first time, there is little to learn, and the tedium of
> > debugging a compiler and OS on a bare machine, when the documentation of
> > the machine was hastily written and often incomplete, was frustrating
> > almost beyond describing.
> >
> 
> ???+1??? And the HW does quite work the way it claimed too....
> It's fun ... once  :-)

Wussies, I did it twice :)  Not really true, I worked a port to the ETA-10
and managed a group that was doing a bringup on a MIPS chip (Cobalt Qube).
I had more of a clue the second time around, actually quit over it.

The details, if you care, were that I was brought in as the director
of software, there was no VP, I reported to the CEO.  I was assured 
that I would be treated like a founder, yada yada.

OK, some time goes by and the CEO wants a schedule.  Be aware that
things were a mess, no backups, no nightly builds, no source control,
engineers were hoarding "their" code on their machines.  It was little
disfunctional, but I was straightening all that out, had it pretty
much under control by the time they asked for a schedule.

We were using GCC which hadn't had a ton of MIPS time under its belt,
and Linux, which was in the same state.  We could boot a kernel but
it crashed (I think, this was a long time ago).

Anyway, they wanted a fast schedule (don't they always?) and I looked
around and said "6 months".  Which was aggressive but I felt it was
doable, the kernel was booting, once you get that stable, userland tends
to fall into place.  We were also developing a web interface to the box,
that was the whole point, it was a "web server in a box" with a web UI,
no login for you (well there was but we weren't supposed to use it).

They freaked at the schedule.  "The board will never go for that!"

So I called Bill Earl, who has done more bringups on MIPS chips than
anyone, period.  At least so far as I knew at the time, still don't
know of anyone who has done more.  He asked a bunch thoughtful questions
and said "weeeeell, maybe you could do it in 3 months.  If you don't hit
any bugs."  I asked "Would you bet your kids college education on it?"
He said "Oh, hell no, I wouldn't bet $20 that you'll make it in 3 months.
You hit one compiler bug, that could blow the whole schedule easy."

So I go back to the CEO and said "6 months".  He's all pissed and says
he'll take it to the board.  I say I want to be there to make my case.
He says "Nope, you aren't an executive."  I handed in my resignation.
Founder my ass.

--lm

[TUHS] PDP-10 UNIX?

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 596 bytes --]

On Mon, Sep 18, 2017 at 12:46 PM, Steve Johnson <scj at yaccman.com> wrote:

>
>
> ​...
>  After the first time, there is little to learn, and the tedium of
> debugging a compiler and OS on a bare machine, when the documentation of
> the machine was hastily written and often incomplete, was frustrating
> almost beyond describing.
>

​+1​ And the HW does quite work the way it claimed too....
It's fun ... once  :-)

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170918/fcf10080/attachment.html>

[TUHS] PDP-10 UNIX?

[Nelson H. F. Beebe]

I worked on, and co-managed, TOPS-20 on DECsystem 20/40 and 20/60
systems with the PDP-10 KL-10 CPU from September 1978 to 31 October
1990, when our 20/60 was retired.  (A second 20/60 on our campus in
the Department of Computer Science had been retired a year or two
earlier).

There were two C compilers on the system, Ken Harrenstien's kcc, and
Steve Johnson's pcc, the latter ported to TOPS-20 by my late friend
Jay Lepreau (1952--2008).

pcc was a straightforward port intended to make C programming, and
porting of C software, fairly easy on the PDP-10, but without
addressing many of the architectural features of that CPU.

kcc was written by Ken Harrenstien from scratch, and designed
explicitly for support of the PDP-10 architecture.  In particular, it
included an O/S system call interface (the JSYS instruction), and
support for pointers to all byte sizes from 1 to 36.  Normal
addressing on the PDP-10 is by word, with an 18-bit address space.
Thus, two 18-bit fields fit in a 36-bit word, ideally suited for
Lisp's CAR and CDR (contents of address/decrement register, used for
first and rest addressing of lists).  However, PDP-10 byte pointers
encode the byte size and offset in the second half of a word.

Pointer words could contain an indirect bit, which caused the CPU to
automatically load a memory word at that address, and repeat if that
word was found to be an indirect pointer.  That processing was handled
by the LOAD instructions, so it worked for all programming languages.

Characters on the ten-or-so different PDP-10 operating systems were
normally 7-bit ASCII, stored left to right in a word, with the
right-most low-order bit set to 0, UNLESS the word was intended to be
a 5-decimal-digit line number, in which case, that bit was set to 1.
Compilers and some other tools ignored line-number words.

As the need to communicate with other systems with 8-, 16-, and 32-bit
words grew, we had to accommodate files with 8-bit characters, which
could be stored as four left-adjusted characters with 4 rightmost zero
bits, or handled as 9 consecutive 8-bit characters in two adjacent
36-bit words.  That was convenient for binary file transfer, but I
don't recall ever seeing 9-bit characters used for text files.

By contrast, on the contemporary 36-bit Univac 11xx systems running
EXEC-8, the O/S was extended from 6 six-bit Fieldata chararacters per
word to 9-bit extended ASCII (and ISO 8859-n Latin-n) characters: the
reason was that the Univac CPU had quarterword access instructions,
but not arbitrary byte-size instructions like the PDP-10.  I don't
think that there ever was a C compiler on those Univac systems.

On the PDP-10, memory locations 0--15 are mapped to machine registers
of those numbers: short loops could be copied into those locations and
would then run about 3x faster, if there weren't too many memory
references.  Register 0 was not hardwired to a zero value, so
dereferencing a NULL pointer could return any address, and could even
be legitimate in some code.  The kcc documentation reports:

>> ...
>> 	The "NULL" pointer is represented internally as a zero word,
>> i.e. the same representation as the integer value 0, regardless of
>> the type of the pointer.  The PDP-10 address 0 (AC 0) is zeroed and
>> never used by KCC, in order to help catch any use of NULL pointers.
>> ...

In kcc, the C fopen() call second argument was extended with extra
flag letters:

>> ...
>>          The user can override either the bytesize or the conversion
>>  by adding explicit specification characters, which should come after
>>  any regular specification characters:
>>          "C"     Force LF-conversion.
>>          "C-"    Force NO LF-conversion.
>>          "7"     Force 7-bit bytesize.
>>          "8"     Force 8-bit bytesize.
>>          "9"     Force 9-bit bytesize.
>>          "T"     Open for thawed access (TOPS-10/TENEX only)
>> 
>>          These are KCC-specific however, and are not portable to other
>>  systems.  Note that the actual LF conversion is done by the USYS (Unix
>>  simulation) level calls (read() and write()) rather than STDIO.
>> ...

As the PDP-10 evolved, addressing was extended from 18 bits to 22
bits, and kcc had support for such extended addresses.

Inside the kcc compiler,

>> ...
>> 	Chars are aligned on 9-bit byte boundaries, shorts on halfword
>> boundaries, and all other data types on word boundaries (with the
>> exception of bitfields and the _KCCtype_charN types).  Converting any
>> pointer to a (char *) and back is always possible, as a char is the
>> smallest possible object.  If the original object was larger than a
>> char, the char pointer will point to the first byte of the object; this
>> is the leftmost 9-bit byte in a word (if word-aligned) or in the halfword
>> (if a short).
>> ...

That design choice meant that the common assumption that a 32-bit word
holds 4 characters remained true on the PDP-10.  The _KCCtype_charN
types could have N from 1 to 36.  The case N = 6 was special: it
handled the SIXBIT character representation used by compilers,
linkers, and the O/S to encode external function names mapped to a
6-bit character set unique to the PDP-10, allowing 6-character unique
names for symbols.

I didn't readily find documentation of kcc features on the Web, so for
those who would like to learn more about support of C and Unix code on
the PDP-10, I created this FTP/Web site today:

	http://www.math.utah.edu/pub/kcc
	 ftp://ftp.math.utah.edu/pub/kcc

It supplies several *.doc files; the user.doc file is likely the one
of most interest for this discussion.

Getting C onto TOP-20 was hugely important for us, because it gave us
access to many Unix tools (I was the first to port Brian Kernighan's
awk language to the PDP-10, and also to the VAX VMS native C
compiler), and eased the transition from TOPS-20 to Unix that began
for our users about 1984, and continued until our complete move in
summer 1991, when we retired our last VAX VMS systems.

Finally, here is a pointer to a document that I wrote about that
transition:

	http://www.math.utah.edu/~beebe/reports/1987/t20unix.pdf

P.S. I'll be happy to entertain further questions about these two C
compilers on the PDP-10, offline if you prefer, or on this list.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

[TUHS] PDP-10 UNIX?

[Steve Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5794 bytes --]

When we decided to port Unix to 32-bits, there were a number of
candidates we looked at, including the IBM-360, the DEC-20, and the
Interdata.   The Vax was barely there at the time, and we also felt
a bit of pressure to use a non-Dec machine because some manufacturers
were muttering about a too-close association of ATT & Dec that was
incompatible with our status as a regulated monopoly.  It was also
clear that being able to buy compatible Unix machines from several
different manufacturers would ultimately drive the prices down and be
good for ATT.

Dennis hated the channel I/O on the 360, and I hated the little
pinhole glimpses of memory that could only be seen by loading a
register--that really clashed with the "one flat memory" model in C. 
For the DEC-20, the word size was indeed a problem.  We had built a C
compiler for the 36-bit Honeywell machine, and it was quite happy to
have 9-bit bytes (in fact, their OS supported this).  But at the
time, tape drives were the major way large data got into and out of a
machine, and they all liked 8-bit bytes.  And there were issues in
both C and Unix if the byte size didn't evenly divide the word size
(think malloc, unions, sizeof, etc.).  So the 20 was out.

The Interdata was a good compromise.  The machine had been used in a
lot of flight simulators, etc., so it had a track record.  It was
similar to an IBM-360, but had an address mode for addressing memory
directly with no base registers.  And we bought the machine with
writable microcode, which we had some ideas of playing with.

As it turned out, the biggest problems in porting were taking
little-endian code and data and putting it on a big-endian machine,
dealing with the consequences of having more registers, and the effect
of this on process switching and debugging (stack traces, etc.).  The
pre-V7 system calls liked to return -1 when there was an error -- V7
wanted to see nulls.  This turned out to be a critical problem -- if
an old-style call with -1 got returned and taken to be a pointer, the
Interdata generated a double fault--trying to read a word with an
odd-byte address, and memory out of bounds.  Sadly, these faults came
in several subtics apart, and the result was that the address of the
fault got trashed, leaving the machine to resume at location 0 with no
hint about how it got there.

For this and other reasons, Ken and Dennis invented the header file
concept -- previously, the structs that described data structures like
inodes were printed in the manual, and copied out by hand when they
were used.  By this point, Lint was a going concern, and I hacked a
version of Lint that insisted that when a structure was declared more
than once, the declarations must come from the same physical
location.  This was a big help in rooting out hidden obsolete
structure definitions and forcing the use of header files.

The port ended up being fairly successful.  The connection with
Interdata less so.  At one point there was a meeting attended by me,
Dennis, Ken, and several managers.  We went to Interdata and met in a
building that used to be a bank -- the meeting room was in the old
vault.  We told Interdata what we had done, and  gave them some
information about the growth of Interest in Unix.  We then said that
the machine needed some fixes before we could deploy a general-purpose
system on it -- the -1 botch was the biggie, because we could not have
a broken user program turn the machine into a stone.  Interdata
listened politely.  Several days later they said 'not interested".

One thing I noticed over the years is that there are very few people
who, having done one Unix port, were willing to do another.  I
certainly wasn't interested.  After the first time, there is little
to learn, and the tedium of debugging a compiler and OS on a bare
machine, when the documentation of the machine was hastily written and
often incomplete, was frustrating almost beyond describing.  So it
was another group in Bell Labs that jumped on the Vax and made an
effective and lasting 32-bit port.

Steve

----- Original Message -----
From: "Arthur Krewat" <krewat@kilonet.net>
To:<tuhs at minnie.tuhs.org>
Cc:
Sent:Mon, 18 Sep 2017 11:30:19 -0400
Subject:Re: [TUHS] PDP-10 UNIX?

 On 9/17/2017 10:34 PM, Johnny Billquist wrote:
 > On 2017-09-17 18:33, Arthur Krewat <krewat at kilonet.net> wrote:
 >
 >> Was there ever a UNIX or even the thought of porting one to a
PDP-10?
 >
 > Definitely a thought. An attempt was started on NetBSD for the
PDP-10, 
 > and it sortof got halfway of getting into single-user, but I'm not 
 > sure if the person who worked on it just got distracted, or if he
hit 
 > problems that were really hard to solve. I certainly know the
person, 
 > and can find out more if people really are interested.
 >
 I for one would be VERY interested. It would be an interesting
exercise 
 to try it out on a SIMH emulator.
 >> 8-bit bytes would have been a wasteful exercise, but you never
know.
 >> (losing 4 bits of every 36-bit word)
 >
 > Uh... Why 8 bit bytes? That way lies madness. There exists a really

 > good C compiler for TOPS-20 - KCC. It uses 9 bits per byte. Works
like 
 > a charm, except when some people write portable code that is not so

 > portable. ;-)
 >
 > KCC was written by KLH, unless I remember wrong. Same guy who also 
 > wrote the KLH-10 emulator.
 9 bits would work - and still, waste 4 bits of the 36-bit word ...
any 
 code carried over from elsewhere would never use the 9th bit unless
you 
 know of stuff that does?

 And yup, I remember KLH, not personally, but as the KLH-10 author :)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170918/fb60ed1f/attachment-0001.html>

[TUHS] PDP-10 UNIX?

[Arthur Krewat]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2225 bytes --]

The MACRO-10 assembler used a keyword ASCIIZ to store that 
7-bit/1-bit-wasted ASCII format.

MOVEI 0,[ASCIIZ /Hello there
/]

for example. It was the defacto standard for null-terminated ASCII strings.

When I later moved to C on 8/16-bit computers, I remember thinking 
"what's with this signed 8-bit char thing?" ;)

There was also SIXBIT - almost everything ASCII had, but only upper 
case. The filesystem used that for filenames and extensions, and it was 
used in a few other areas. So any library calls like open() would have 
had to convert the ASCII filename to SIXBIT before doing any monitor calls.

On 9/18/2017 9:50 AM, Clem Cole wrote:
>
>
> On Sun, Sep 17, 2017 at 11:22 AM, Arthur Krewat <krewat at kilonet.net 
> <mailto:krewat at kilonet.net>> wrote:
>
>     I have a C compiler for TOPS-10 that I got off the Internet back
>     in 1988. Still haven't messed around with it enough to get it to
>     run, but ...
>
> ​There was a PDP-10 C compiler in the late 1970s, that was kicking 
> around CMU, MIT and Stanford which we used to write backup10 and ​and 
> an implementation of tar.   IIRC, it was based on the the Ritchie 
> front end and was V6 in syntax (i.e. pre-V7 or typesetter C - aka 
> 'White Book).   I've forgotten the rules of chars, but I remember you 
> had to be careful.   I think it was 4 9-bit chars to transfer things 
> (4*9=36 bits), but I think I remember there were cases on output that 
> it wanted to wash it through a 7-bit PDP-10 char (5*7+1 =36bits) which 
> was the 'norm' for most languages like SAIL, BLISS et al.
>
> I did not mess with much, but that time, I was transitioning from the 
> 10's to UNIX by that time.   I added support for the -20's dumper 
> tapes to backup10 which were almost but not quite the same.  But that 
> was the last I messed with it. Mike Accetta and Fil Aliva (of CMU Mach 
> fame) I remember had their had in that subsystem, at one point.  And 
> of course Danny Klein is always a good one from those days to ask too. 
> I'll see if I can dig them up and ask.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170918/26ad8ccd/attachment.html>

[TUHS] PDP-10 UNIX?

[Arthur Krewat]

On 9/17/2017 10:34 PM, Johnny Billquist wrote:
> On 2017-09-17 18:33, Arthur Krewat <krewat at kilonet.net> wrote:
>
>> Was there ever a UNIX or even the thought of porting one to a PDP-10?
>
> Definitely a thought. An attempt was started on NetBSD for the PDP-10, 
> and it sortof got halfway of getting into single-user, but I'm not 
> sure if the person who worked on it just got distracted, or if he hit 
> problems that were really hard to solve. I certainly know the person, 
> and can find out more if people really are interested.
>
I for one would be VERY interested. It would be an interesting exercise 
to try it out on a SIMH emulator.
>> 8-bit bytes would have been a wasteful exercise, but you never know.
>> (losing 4 bits of every 36-bit word)
>
> Uh... Why 8 bit bytes? That way lies madness. There exists a really 
> good C compiler for TOPS-20 - KCC. It uses 9 bits per byte. Works like 
> a charm, except when some people write portable code that is not so 
> portable. ;-)
>
> KCC was written by KLH, unless I remember wrong. Same guy who also 
> wrote the KLH-10 emulator.
9 bits would work - and still, waste 4 bits of the 36-bit word ... any 
code carried over from elsewhere would never use the 9th bit unless you 
know of stuff that does?

And yup, I remember KLH, not personally, but as the KLH-10 author :)

[TUHS] PDP-10 UNIX?

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1464 bytes --]

On Sun, Sep 17, 2017 at 11:22 AM, Arthur Krewat <krewat at kilonet.net> wrote:

> I have a C compiler for TOPS-10 that I got off the Internet back in 1988.
> Still haven't messed around with it enough to get it to run, but ...
>
> ​There was a PDP-10 C compiler in the late 1970s, that was kicking around
CMU, MIT and Stanford which we used to write backup10 and ​and an
implementation of tar.   IIRC, it was based on the the Ritchie front end
and was V6 in syntax (i.e. pre-V7 or typesetter C - aka 'White Book).
I've forgotten the rules of chars, but I remember you had to be careful.
I think it was 4 9-bit chars to transfer things (4*9=36 bits), but I think
I remember there were cases on output that it wanted to wash it through a
7-bit PDP-10 char (5*7+1 =36bits) which was the 'norm' for most languages
like SAIL, BLISS et al.

I did not mess with much, but that time, I was transitioning from the 10's
to UNIX by that time.   I added support for the -20's dumper tapes to
backup10 which were almost but not quite the same.  But that was the last I
messed with it.   Mike Accetta and Fil Aliva (of CMU Mach fame) I remember
had their had in that subsystem, at one point.  And of course Danny Klein
is always a good one from those days to ask too. I'll see if I can dig them
up and ask.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170918/accf550f/attachment.html>

[TUHS] PDP-10 UNIX?

[Johnny Billquist]

On 2017-09-17 18:33, Arthur Krewat <krewat at kilonet.net> wrote:

> Was there ever a UNIX or even the thought of porting one to a PDP-10?

Definitely a thought. An attempt was started on NetBSD for the PDP-10, 
and it sortof got halfway of getting into single-user, but I'm not sure 
if the person who worked on it just got distracted, or if he hit 
problems that were really hard to solve. I certainly know the person, 
and can find out more if people really are interested.

> 36-bit machine, 18-bit addresses (more on KL10 and KS10), and:
> 
> *0 would return register 0 instead of a SIGSEGV ;)

Yes. Not the first machine that would be true for. You don't have 
address 0 unmapped on a PDP-11 either.

> 8-bit bytes would have been a wasteful exercise, but you never know.
> (losing 4 bits of every 36-bit word)

Uh... Why 8 bit bytes? That way lies madness. There exists a really good 
C compiler for TOPS-20 - KCC. It uses 9 bits per byte. Works like a 
charm, except when some people write portable code that is not so 
portable. ;-)

KCC was written by KLH, unless I remember wrong. Same guy who also wrote 
the KLH-10 emulator.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[TUHS] PDP-10 UNIX?

[Warner Losh]

On Sun, Sep 17, 2017 at 9:01 AM, Lars Brinkhoff <lars at nocrew.org> wrote:

> Warner Losh writes:
> > Arthur Krewat wrote:
> >> Was there ever a UNIX or even the thought of porting one
> >> to a PDP-10?
> > IIRC, there was a NetBSD/pdp10. Don't know how far it got.
>
> Not far enough.  I was a little bit involved when there was talk of
> using GCC.
>
> > The instructor of my first C course in college wrote a very
> > good C compiler for TOPS-10/TOPS-20.
>
> Which one?
>
> I have found remnants of a compiler called C10 by Alan Snyder.  I have
> tried to reach him without result.
>

His name was Greg Titus. It was installed on the TOPS-20 boxes we had at
school as cc20. Don't know more than that. I've lost touch with Greg over
the years and some professional wrestler has popped in his name...  I'll
see if I can find him...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170917/a6ccc795/attachment-0001.html>

[TUHS] PDP-10 UNIX?

[Arthur Krewat]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 901 bytes --]

I have a C compiler for TOPS-10 that I got off the Internet back in 
1988. Still haven't messed around with it enough to get it to run, but ...

The only string in it that means anything is this:

File:  %s, compiled by Sargasso C v. %c

And a discussion I started a long time ago:

https://groups.google.com/forum/#!topic/alt.sys.pdp10/gc2avXfEJMg



On 9/17/2017 11:01 AM, Lars Brinkhoff wrote:
> Warner Losh writes:
>> Arthur Krewat wrote:
>>> Was there ever a UNIX or even the thought of porting one
>>> to a PDP-10?
>> IIRC, there was a NetBSD/pdp10. Don't know how far it got.
> Not far enough.  I was a little bit involved when there was talk of
> using GCC.
>
>> The instructor of my first C course in college wrote a very
>> good C compiler for TOPS-10/TOPS-20.
> Which one?
>
> I have found remnants of a compiler called C10 by Alan Snyder.  I have
> tried to reach him without result.
>

[TUHS] PDP-10 UNIX?

[Lars Brinkhoff]

Warner Losh writes:
> Arthur Krewat wrote:
>> Was there ever a UNIX or even the thought of porting one
>> to a PDP-10?
> IIRC, there was a NetBSD/pdp10. Don't know how far it got.

Not far enough.  I was a little bit involved when there was talk of
using GCC.

> The instructor of my first C course in college wrote a very
> good C compiler for TOPS-10/TOPS-20.

Which one?

I have found remnants of a compiler called C10 by Alan Snyder.  I have
tried to reach him without result.

[TUHS] PDP-10 UNIX?

[Warner Losh]

On Sun, Sep 17, 2017 at 8:28 AM, Arthur Krewat <krewat at kilonet.net> wrote:

> Was there ever a UNIX or even the thought of porting one to a PDP-10?
>
> 36-bit machine, 18-bit addresses (more on KL10 and KS10), and:
>
> *0 would return register 0 instead of a SIGSEGV ;)
>
> 8-bit bytes would have been a wasteful exercise, but you never know.
> (losing 4 bits of every 36-bit word)
>

IIRC, there was a NetBSD/pdp10. Don't know how far it got.

The instructor of my first C course in college wrote a very good C compiler
for TOPS-10/TOPS-20.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170917/65341082/attachment.html>

[TUHS] PDP-10 UNIX?

[Arthur Krewat]

Was there ever a UNIX or even the thought of porting one to a PDP-10?

36-bit machine, 18-bit addresses (more on KL10 and KS10), and:

*0 would return register 0 instead of a SIGSEGV ;)

8-bit bytes would have been a wasteful exercise, but you never know. 
(losing 4 bits of every 36-bit word)

thanks!
art k.