Nelson thanks. Excellent bit of snooping. I wonder why Jay did his version? Maybe he wanted a more modern C features since the Snyder compiler would been based on a very early C dialect. Steve Johnson do you have any insight? As I understand it, Alan started his work by rewritting your Honeywell B compiler to be a C compiler when the C language was quite young and many features we take for granted were not yet created. Clem On Thu, Jul 15, 2021 at 6:26 PM Nelson H. F. Beebe wrote: > Clem Cole asks: > > >> Did you know that before PCC the 'second' C compiler was a PDP-10 > >> target Alan Snyder did for his MIT Thesis? > >> [https://github.com/PDP-10/Snyder-C-compiler] > > I was unaware of that compiler until sometime in the 21st Century, > long after our PDP-10 was retired on 31-Oct-1990. > > The site > > https://github.com/PDP-10/Snyder-C-compiler/tree/master/tops20 > > supplies a list of some of Snyder's files, but they don't match > anything in our TOPS-20 archives of almost 180,000 files. > > I then looked into our 1980s-vintage pcc source tree and compared > it with a snapshot of the current pcc source code taken three > weeks ago. The latter has support for these architectures > > aarch64 hppa m16c mips64 pdp11 sparc64 > amd64 i386 m68k nova pdp7 superh > arm i86 mips pdp10 powerpc vax > > and the pdp10 directory contains these files: > > CVS README code.c local.c local2.c macdefs.h order.c table.c > > All 5 of those *.c files are present in our TOPS-20 archives. I then > grepped those archives for familiar strings: > > % find . -name '*.[ch]' | sort | \ > xargs egrep -n -i > 'scj|feldman|johnson|snyder|bell|at[&]t|mit|m.i.t.' > ./code.c:8: * Based on Steve Johnson's pdp-11 version > ./code2.c:19: * Based on Steve Johnson's pdp-11 version > ./cpp.c:1678: stsym("TOPS20"); /* for > compatibility with Snyder */ > ./local.c:4: * Based on Steve Johnson's pdp-11 version > ./local2.c:4: * Based on Steve Johnson's pdp-11 version > ./local2.c:209: case 'A': /* emit a label */ > ./match.c:2: * match.c - based on Steve Johnson's pdp11 version > ./optim.c:318: * Turn > 'em into regular PCONV's > ./order.c:5: * Based on Steve Johnson's pdp-11 version > ./pftn.c:967: * fill out previous word, to > permit pointer > ./pftn.c:1458: register commflag = 0; /* flag for > labelled common declarations */ > ./pftn2.c:1011: * fill out previous word, to > permit pointer > ./pftn2.c:1502: register commflag = 0; /* flag for > labelled common declarations */ > ./reader.c:632: p2->op = NOASG p2->op; /* this was > omitted in 11 & /6 !! */ > ./table.c:128: " movei A1,1\nZN", /* ZN = > emit branch */ > ./xdefs.c:13: * symbol table maintainence > > Thus, I'm confident that Jay's work was based on Steve Johnson's > compiler, rather than Alan Snyder's. > > Norman Wilson asks: > > >> ... > >> How did that C implementation handle ASCII text on the DEC-10? > >> Were it a from-scratch UNIX port it might make sense to store > >> four eight- or nine-bit bytes to a word, but if (as I sense it > >> was) it was C running on TOPS-10 or TOPS-20, it would have had > >> to work comfortably with DEC's convention of five 7-bit characters > >> (plus a spare bit used by some programs as a flag). > >> ... > > Our pcc compiler treated char* as a pointer to 7-bit ASCII strings, > stored in the top 35 bits of a word, with the low-order bit normally > zero; a 1-bit there meant that the word contained a 5-digit line > number that some compilers and editors would report. Of course, that > low-order non-character bit meant that memset(), memcpy(), and > memmove() had somewhat dicey semantics, but I no longer recall their > specs. > > kcc later gave us access to the PDP-10's 1- to 36-bit byte > instructions. > > For text processing, 5 x 7b + 1b bits matched the conventions for all > other programming languages on the PDP-10. When it came time to > implement NFS, and exchange files and data with 32-bit-word machines, > we needed the ability to handle files of 4 x 8b + 4b and 9 x 8b (in > two 36-bit words), and kcc provided that. > > The one's-complement 36-bit Univac 1108 machines chose instead to > store text in a 4 x 9b format, because that architecture had > quarter-word load/store instructions, but not the general variable > byte instructions of the PDP-10. Our campus had an 1108 at the > University of Utah Computer Center, but I chose to avoid it, because > it was run in batch mode with punched cards, and never got networking. > By contrast, our TOPS-20, BSD, RSX-11, SunOS, and VMS systems all had > interactive serial-line terminals, and there was no punched card > support at all. > > > ------------------------------------------------------------------------------- > - 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@math.utah.edu - > - 155 S 1400 E RM 233 beebe@acm.org > beebe@computer.org - > - Salt Lake City, UT 84112-0090, USA URL: > http://www.math.utah.edu/~beebe/ - > > ------------------------------------------------------------------------------- > -- Sent from a handheld expect more typos than usual