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?
Just sharing a copy of the Roff Manual that I had forgotten I scanned a little while back:
https://archive.org/details/roff_manual
This appears to be the UNIX complement to the S/360 version of the paper backed up by Doug here: https://www.cs.dartmouth.edu/~doug/roff71/roff71.pdf
From the best I could tell, this predates both 1973's V3 and the 1971 S/360 version of the paper, putting it somewhere prior to 1971. For instance, it is missing the .ar, .hx, .ig, .ix, .ni, .nx, .ro, .ta, and .tc requests found in V3. The .ar and .ro, and .ta requests pop up in the S/360 paper, the rest are in the V3 manpage (prior manpages don't list the request summary).
If anyone has some authoritative date information I can update the archive description accordingly.
Finally, this very well could be missing the last page, the Page offset, Merge patterns, and Envoi sections of Doug's paper are not reflected here, although at the very least, the .mg request is not in this paper so the Merge patterns section probably wasn't there anyway.
- Matt G.
I had meant to copy TUSH on this/
On Wed, Jul 17, 2024 at 2:41 PM Tom Lyon <pugs78(a)gmail.com> wrote:
> I got excited by your mention of a S/360 version, but Doug's link talks
> about the GECOS version (GE/Honeywell hardware).
>
> Princeton had a S/360 version at about that time, it was a re-write of a
> version for the IBM 7094 done by Kernighan after spending a summer at MIT
> with CTSS and RUNOFF. I'm very curious whether the Princeton S/360 version
> spread to other locations. Found this article in the Daily Princetonian
> about the joy and history of ROFF.
> https://photos.app.goo.gl/zMWV1GRLZdNBUuP36
>
> On Wed, Jul 17, 2024 at 1:51 PM segaloco via TUHS <tuhs(a)tuhs.org> wrote:
>
>> Just sharing a copy of the Roff Manual that I had forgotten I scanned a
>> little while back:
>>
>> https://archive.org/details/roff_manual
>>
>> This appears to be the UNIX complement to the S/360 version of the paper
>> backed up by Doug here:
>> https://www.cs.dartmouth.edu/~doug/roff71/roff71.pdf
>>
>> From the best I could tell, this predates both 1973's V3 and the 1971
>> S/360 version of the paper, putting it somewhere prior to 1971. For
>> instance, it is missing the .ar, .hx, .ig, .ix, .ni, .nx, .ro, .ta, and .tc
>> requests found in V3. The .ar and .ro, and .ta requests pop up in the
>> S/360 paper, the rest are in the V3 manpage (prior manpages don't list the
>> request summary).
>>
>> If anyone has some authoritative date information I can update the
>> archive description accordingly.
>>
>> Finally, this very well could be missing the last page, the Page offset,
>> Merge patterns, and Envoi sections of Doug's paper are not reflected here,
>> although at the very least, the .mg request is not in this paper so the
>> Merge patterns section probably wasn't there anyway.
>>
>> - Matt G.
>>
>
> Yeah, but if you do that you have to treat the places
> acquired in the Louisiana Purchase differently because
> they switched in 1582. And Puerto Rico. Bleh.
Then there are all the German city states. And the
shifting borders of Poland. (cal -s country) is a mighty
low-res "solution" to the Julian/Gregorian problem.
Doug
The manpage for "cal" used to have the comment "Try September 1752" (and
yes, I know why); it's no longer there, so when did it disappear? The
SysV fun police?
I remember it in Ed5 and Ed6, but can't remember when I last saw it.
Thanks.
-- Dave
A few folks on the PIDP mailing lists asked me to put scans of the cards I
have on-line. I included TUHS as some of the new to the PDP-11 folks might
find these interesting also.
I also included a few others from other folks. Note my scans are in 3
formats (JPG, TIFF, PDF) as each has advantages. Pick which one you
prefer. I tried to scan in as a high a resolution as I could in case some
one wants to try to print the later.
I may try adding some of my other cards, such as my microprocessor and IBM
collections. In the future
https://drive.google.com/open?id=13dPAlRMQEwNvPwLXwlOC5Q_ZrQp4IpkJ&usp=driv…
ᐧ
I subscribe to the TUHS mailing list, delivered in digest form. I do not
remember having subscribed to COFF, and am not aware of how to do so. Yet
COFF messges come in my TUHS digest. How does COFF differ from TUHS and how
does one subscibe to it (if at all)?
Doug
Just had a quick look at 'man cat' on Uixes I've got 'at hand'. Just a 'cut
and past' of the relevant parts.
SCO UNIX 3.2V4.2
Limitations
Note that ``cal 84'' refers to the year 84, not 1984.
The calendar produced is the Gregorian calendar from September 14 1752
onward. Dates up to and including September 2 1752 use the Julian calen-
dar. (England and her colonies switched from the Julian to the
Gregorian
calendar in September 1752, at which time eleven days were excised from
the year. To see the result of this switch, try cal 9 1752.)
Digital UNIX 4.0g
DESCRIPTION
The cal command writes to standard output a Gregorian calendar for the
specified year or month.
For historical reasons, the cal command's Gregorian calendar is
discontinu-
ous. The display for September 1752 (cal 9 1752) jumps from Wednesday the
2nd to Thursday the 14th.
--
The more I learn the better I understand I know nothing.
