[TUHS] head/sed/tail (was The Unix shell: a 50-year view)
Clem Cole
clemc at ccc.com
Fri Jul 16 10:02:41 AEST 2021
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 at 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 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/ -
>
> -------------------------------------------------------------------------------
>
--
Sent from a handheld expect more typos than usual
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20210715/98764b2b/attachment.htm>
More information about the TUHS
mailing list