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 <beebe(a)math.utah.edu>
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(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/ -
-------------------------------------------------------------------------------