In the last months, I've spent a little time on curating John Walker's Unix clone and software stack, including an emulator to run it:
https://gitlab.com/marinchip
After creating a basic tool chain (edit, asm, link and a simple executive), John set out to find a compiler. Among the first programs were a port of the META 3 compiler-generator (similar to TMG on early Unix) and a port of Birch-Hansen’s Pascal compiler. META was used to create a compiler that generated threaded code. He found neither compiler good enough for his goals and settled on writing his Unix-like OS in assembler. As the 9900 architecture withered after 1980, this sealed the fate of this OS early on -- had he found a good compiler, the code might have competed alongside Coherent, Idris, and Minix during the 80’s.
This made me realise once more how unique the Ritchie C compiler was. In my view its uniqueness combines three aspects:
1. The C language itself
2. The ability to run natively on small hardware (even an LSI-11 system)
3. Generating code with modest overhead versus handwritten assembler (say 30%)
As has been observed before, working at a higher abstraction level makes it easier to work on algorithms and on refactoring, often earning back the efficiency loss. John Walkers work may be case in point: I estimate that his hand-coded kernel is 10% larger than an equivalent V6 Unix kernel (as compiled for the 9900 architecture).
There are three papers on DMR’s website about the history of the compiler and a compare-and-contrast with other compilers of the era:
https://www.bell-labs.com/usr/dmr/www/primevalC.htmlhttps://www.bell-labs.com/usr/dmr/www/chist.htmlhttps://www.bell-labs.com/usr/dmr/www/hopl.html
It seems to me that these papers rather understate the importance of generating good quality code. As far as I can tell, BCPL and BLISS came close, but were too large to run on a PDP-11 and only existed as cross-compilers. PL/M was a cross-compiler and generated poorer code. Pascal on small machines compiled to a virtual machine. As far as I can tell, during most of the 70s there was no other compiler that generated good quality code and ran natively on a small (i.e. PDP-11 class) machine.
As far as I can tell the uniqueness was mostly in the “c1” phase of the compiler. The front-end code of the “c0” phase seems to use more or less similar techniques as many contemporary compilers. The “c1” phase seems to have been unique in that it managed to do register allocation and instruction selection with a pattern matcher and associated code tables squeezed into a small address space. On a small machine, other native compilers of the era typically proceeded to generate threaded code, code for a virtual machine or poor quality native code that evaluated expressions using stack operations rather than registers.
I am not sure why DMR's approach was not more widely used in the 1970’s. The algorithms he used do not seem to be new and appear to have their roots in other (larger) compilers of the 1960’s. The basic design seems to have been in place from the very first iterations of his compiler in 1972 (see V2 tree on TUHS) and he does not mention these algorithms as being special or innovative in his later papers.
Any observations / opinions on why DMR’s approach was not more widely used in the 1970’s?
Every so often I want to compare files on remote machines, but all I can
do is to fetch them first (usually into /tmp); I'd like to do something
like:
rdiff host1:file1 host2:file2
Breathes there such a beast? I see that Penguin/OS has already taken
"rdiff" which doesn't seem to do what I want.
Think of it as an extension to the Unix philosophy of "Everything looks
like a file"...
-- Dave
A few years ago, someone -- and I've forgotten who, forgive me -- kindly gave me a copy of the source code for a UNIX for the AT&T PC6300 called IN/ix, developed by INTERACTIVE Systems. I have found precious little about this system online. Apparently the PC/ix UNIX for the IBM PC XT is fairly well preserved, but I can't find much about IN/ix.
For what it's worth, the login herald in the source code reads:
"IN/ix Office System (c) Copyright INTERACTIVE Systems Corp. 1983, 1988"
Presumably this was PC/ix, but targeting the AT&T 6300? Does anyone have any more knowledge of IN/ix?
If you're interested in digging into it yourself, I've dropped the source here:
https://archives.loomcom.com/pc6300/
(N.B.: All the files inside the zip are compressed, that's just how I got it)
-Seth
--
Seth Morabito * Poulsbo, WA * https://loomcom.com/
> Does anyone here have any source material they can point me to
> documenting the existence of a port of BSD curses to Unix Version 7?
Curses appears in the v8 manual but not v7. Of course a
conclusion that it was not ported to v7 turns on dates. Does
v7 refer to a point in time or an interval that extended until we
undertook to prepare the v8 manual? Obviously curses was
ported during or before that interval. If curses was available
when the v7 manual was prepared, I (who edited both editions)
evidently was unaware of any dependence on it then.
Doug
So I've been doing a bit of reading on 1A and 4ESS technologies lately, getting
a feel for the state of things just prior to 3B and 5ESS popping onto the scene,
and came across some BSTJ references to the programming environments involved
in the 4ESS and TSPS No. 1 systems.
The general assembly system targeting the 1A machine language was known as
SPC-SWAP (SWitching Assembly Program)[1](p. 206) and ran under OS/360/370, with
editing typically performed in QED. This then gave way to the EPL (ESS
Programming Language) and ultimately EPLX (EPL eXtra)[2](p. 1)[3](p. 8)
languages which, among other things, were used for later 4ESS work with cross-
compilers for at least TSS/360 by the sounds of it.
Are there any recollections of attempts by the Bell System to rebase any of
these 1A-targeting environments into UNIX, or by the time UNIX was being
considered more broadly for Bell System projects, was 3B/5ESS technology well on
the way, rendering attempting to move entrenched IBM-based environments for the
older switching computation systems moot?
For the record, in addition to the evolution of ESS to the 5ESS generation, a
revision of TSPS, 1B, was also introduced which was rebased on the 3B20D
processor and utilized the same 3B cross-compilation SGS under UNIX as other 3B-
targeted applications[4]. Interestingly, the paper on software development
in [4](p. 109) still makes reference to Programmer's Workbench as of 1982,
implying that nomenclature may have still been the norm at some Bell Labs sites
such as Naperville, Illinois, although I can't tell if they're referring to
PWB as in the branch of UNIX or the environment of make, sccs, etc.
Additionally, is anyone aware of surviving accessible specimens of SWAP
assembly, EPL, or EPLX code or literature beyond the BSTJ references and paper
referenced in the IEEE library below? Thanks for any insights!
- Matt G.
[1] - https://bitsavers.org/magazines/Bell_System_Technical_Journal/BSTJ_V58N06_1…
[2] - https://ieeexplore.ieee.org/document/810323
[3] - https://bitsavers.org/magazines/Bell_System_Technical_Journal/BSTJ_V60N06_1…
[4] - https://bitsavers.org/magazines/Bell_System_Technical_Journal/BSTJ_V62N03_1…
> Doug McIlroy was generating random regular expressions
Actually not. I exhaustively (within limits) tested an RE recognizer
without knowingly generating any RE either mechanically or by hand.
The trick: From recursive equations (easily derived from the grammar of
REs), I counted how many REs exist up to various limits on token counts,
Then I generated all strings that satisfied those limits, turned the
recognizer loose on them and counted how many it accepted. Any disagreement
of counts revealed the existence (but not any symptom) of bugs.
Unlike most diagnostic techniques, this scheme produces a certificate of
(very high odds on) correctness over a representative subdomain. The scheme
also agnostically checks behavior on bad inputs as well as good. It does
not, however, provide a stress test of a recognizer's capacity limits. And
its exponential nature limits its applicability to rather small domains.
(REs have only 5 distinct kinds of token.)
Doug
Hi folks,
I'm finding it difficult to find any direct sources on the question in
the subject line.
Does anyone here have any source material they can point me to
documenting the existence of a port of BSD curses to Unix Version 7?
I know that curses made it into 2.9BSD for the PDP-11, but that's not
quite the same thing.
There are comments in System V Release 2's curses.h file[1][2] (very
different from 4BSD's[3]) that suggest some effort to accommodate
Version 7's terminal driver. So I would _presume_ that curses got
ported to Version 7. But that's System V, right when it started
diverging from BSD curses, and moreover, presumption is not evidence.
Even personal accounts/anecdotes would be helpful. Maybe some of you
_wrote_ curses applications for Version 7 machines.
Regards,
Branden
[1] System III apparently did not have curses at all. Both it and 4BSD
were released in 1980. System V Release 1 doesn't seem to, either.
[2] https://github.com/ryanwoodsmall/oldsysv/blob/master/sysvr2-vax/include/cur…
[3] https://minnie.tuhs.org/cgi-bin/utree.pl?file=4BSD/usr/include/curses.h
with my pedantic head on…
The “7th Edition” was the name of the Perkin Elmer port (nee Interdata), derived from Richard Miller’s work.
This was Unix Version 7 from the labs, with a v6 C compiler, with vi, csh, and curses from 2.4BSD (though we where never 100% sure about this version).
You never forget your first Unix :-)
-Steve
