[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