The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Rob Pike <robpike@gmail.com>
To: Paul Ruizendaal <pnr@planet.nl>
Cc: tuhs@tuhs.org
Subject: [TUHS] Re: On the uniqueness of DMR's C compiler
Date: Wed, 8 May 2024 23:12:28 +1000	[thread overview]
Message-ID: <CAKzdPgwwEXqcvFwRHyA=d-Rvo0UoNwv8JOKJanQbN2XZ+H56AQ@mail.gmail.com> (raw)
In-Reply-To: <57a37626-728c-4f34-b08b-a4f521f1db03@planet.nl>

[-- Attachment #1: Type: text/plain, Size: 5385 bytes --]

I believe Ken Thompson might have been a referee for that paper. At least,
he once mentioned to me that he had reviewed a paper about the threading in
the DEC Fortran compiler.

-rob


On Wed, May 8, 2024 at 7:35 PM Paul Ruizendaal <pnr@planet.nl> wrote:

> Thanks for pointing that out. Here's an interesting paper on the DEC PDP11
> Fortran compilers:
>
> http://forum.6502.org/download/file.php?id=1724&sid=f6a721f3e05774cff076da72f5a731a6
>
> Before 1975 they used direct threading, thereafter there was a native
> compiler for the higher-end models. I think this one may have required
> split i/d, but that is not entirely clear from the text.
>
> I think the same holds for BCPL on the PDP11: compiling to "ocode" or
> "intcode" in the early 70s, native thereafter -- still have to find source
> for the latter.
>
> Still, I should have first asked: Does anyone have pointers to small
> machine native compilers from the 1970's that produced efficient assembler
> output?
>
> I am already aware of the 1978 Whitesmith C compiler.
>
> 7 May 2024 23:07:58 Rob Pike <robpike@gmail.com>:
>
> I'm not sure I accept your starting position. There were several compilers
> for RT-11 and RSX/11-M. RSX (and perhaps RT) Fortran were threaded code,
> but I don't believe they all were. And of course there was BCPL, which was
> - and is - tiny; was it on the 11?
>
> And there were other small machines from other manufacturers, all of which
> had some form of Fortran and other bespoke things, such as RPG on the small
> IBMs. I think the uniqueness was in the set of conditions more than in the
> Unix C compiler itself.
>
> But you may be right.
>
> -rob
>
>
>
>
> On Wed, May 8, 2024 at 6:59 AM Paul Ruizendaal <pnr@planet.nl> wrote:
>
>> 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.html
>> https://www.bell-labs.com/usr/dmr/www/chist.html
>> https://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?
>>
>

[-- Attachment #2: Type: text/html, Size: 9602 bytes --]

  reply	other threads:[~2024-05-08 13:12 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-07 20:59 [TUHS] " Paul Ruizendaal
2024-05-07 22:07 ` [TUHS] " Rob Pike
2024-05-08  9:35   ` Paul Ruizendaal
2024-05-08 13:12     ` Rob Pike [this message]
2024-05-08 15:51     ` Clem Cole
2024-05-08 16:07       ` Jon Forrest
2024-05-08 17:49         ` Tom Perrine
2024-05-08 17:05       ` Adam Sampson
2024-05-08 17:45       ` Al Kossow
2024-05-08 18:12         ` Clem Cole
2024-05-08 18:12           ` Clem Cole
2024-05-09  1:27           ` Lawrence Stewart
2024-05-31 12:00       ` Paul Ruizendaal
2024-05-31 12:21         ` Peter Yardley
2024-05-08 11:09 ` Michael Kjörling
2024-05-09 20:40 ` Paul Ruizendaal via TUHS
2024-05-09 20:57   ` Al Kossow
2024-05-08 18:29 Douglas McIlroy
2024-05-10 17:28 ` Paul Winalski
2024-05-11  9:16   ` Ralph Corderoy
2024-05-11 13:42   ` G. Branden Robinson
     [not found] <171519201646.4052234.694570138790187562@minnie.tuhs.org>
2024-05-09  3:39 ` Paul McJones
2024-05-09  3:46   ` Warner Losh
     [not found] <171535904627.4052234.5321502833323676423@minnie.tuhs.org>
2024-05-10 18:55 ` Paul McJones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKzdPgwwEXqcvFwRHyA=d-Rvo0UoNwv8JOKJanQbN2XZ+H56AQ@mail.gmail.com' \
    --to=robpike@gmail.com \
    --cc=pnr@planet.nl \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).