TUHS

tuhs@tuhs.org

19 participants
6471 discussions

by ron minnich

I got a note about excessive bounces. Can you give me more info? I think somebody is up to something but can't be sure what.

7 years, 7 months

Re: [TUHS] PDP-10 UNIX?

by 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(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

7 years, 7 months

V7 chroot author?

by Warren Toomey

All, I just had this question popped into my inbox. Cheers, Warren ----- Forwarded message from Evan Koblentz <evan(a)snarc.net> ----- Hi Warren. Evan K. here from Vintage Computer Festival, etc. I'm trying to find out who invented the Chroot command in Version 7 Unix. Could you help, possibly including a post to TUHS email list on my behalf? I posted to our local (northeast US) list and also emailed Brian Kernighan and Bill Cheswick. Hoping this leads to an answer. I'm looking for a name, not just generalities. Thanks very much. ----- End forwarded message -----

7 years, 7 months

Re: [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

by norman＠oclsc.org

Random832: Just out of curiosity, where does perror(filename), quite possibly the *most* common error message on Unix as a whole, fall on your scale? It says which of the file location or permissions (or whatever else) it is, but not whether it was attempting to open it for reading or writing. ===== I never liked perror much. It's a little too primitive: you get exactly one non-formatted string; you get only stderr, so if you're sending messages separately to a log or writing them to a network connection or the like, you're out of luck. strerror(errno) hits the sweet spot for me. Until it appeared in the standard library (and until said standard spread enough that one could reasonably expect to find it anywhere) I kept writing more or less that function into program after program. I guess the problem with perror is that it isn't sufficiently UNIX-like: it bundles three jobs that are really separate (convert errno to string message, format an error message, output the message) into one function, inseparably and inflexibly. Norman Wilson Toronto ON

7 years, 7 months

B Source Code

by Robert Swierczek

Does anyone know of the existence of source code written in B (C's predecessor?) I have encountered a few snippets here and there, but nothing substantial. The only "real" program that I know of is AberMUD-1. It looks like there exists a physical print-out of it: https://dropsafe.crypticide.com/article/12714 Could it be that this is the only artifact left of this most important "missing link" of C and Unix History? How can this (and any other B source) be gathered and preserved?

7 years, 7 months

Re: [TUHS] Weird nix? Regulus

by Derek Fawcus

> What a pain, almost like Unix, and not quite. l It was a clone of Unix for the 68k. Funny, I was just poking through some ccpm68k source/tools, which happened to contain the Alcyon C compiler source, and one of the files is: $ cat v103/doc/files/Sectioname .fo 'REGULUS Reference Manual'- % -'FILES' $ The same system? DF

7 years, 7 months

PDP-10 UNIX?

by 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.

7 years, 7 months

Re: [TUHS] PDP-10 UNIX?

by jnc＠mercury.lcs.mit.edu

> 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

7 years, 7 months

Re: [TUHS] B Source Code

by jnc＠mercury.lcs.mit.edu

> From: Alec Muffett > "threaded code" in the old sense could be smaller than the equivalent > CISC binary on the same machine One can think of 'threaded code' as code for a new virtual machine, one specialized to the task at hand. > https://en.m.wikipedia.org/wiki/Threaded_code For those who really want to delve in some depth, see the chapter "Turning Cousins into Sisters" (Chapter 15, pg. 365) in "Computer Engineering: A DEC View of Hardware Systems Design", by Bell, Mudge and McNamara. Interesting factoid: The PDP-11 initially used a threaded FORTRAN implementation. In line with the observation above (about a new virtual machine), DEC actually looked into writing microcode for the -11/60 (which had a writeable control store) to implement the FORTRAN virtual machine. Noel

7 years, 7 months

Re: [TUHS] PDP-10 UNIX?

by Johnny Billquist

On 2017-09-17 18:33, Arthur Krewat <krewat(a)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(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

7 years, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS