From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from minnie.tuhs.org (minnie.tuhs.org [IPv6:2600:3c01:e000:146::1]) by inbox.vuxu.org (Postfix) with ESMTP id D723B240D7 for ; Wed, 8 May 2024 11:35:57 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 9F788432C5; Wed, 8 May 2024 19:35:48 +1000 (AEST) Received: from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl [195.121.94.186]) by minnie.tuhs.org (Postfix) with ESMTPS id 45EE2432B7 for ; Wed, 8 May 2024 19:35:34 +1000 (AEST) X-KPN-MessageId: 4bc5b8a6-0d1e-11ef-959b-00505699b430 Received: from smtp.kpnmail.nl (unknown [10.31.155.8]) by ewsoutbound.so.kpn.org (Halon) with ESMTPS id 4bc5b8a6-0d1e-11ef-959b-00505699b430; Wed, 08 May 2024 11:35:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=planet.nl; s=planet01; h=content-type:mime-version:subject:message-id:to:from:date; bh=vnGnCiFMcscRoZyNx5LWCZjDYXkSTS/6/kwc1Io998A=; b=rR1FMf2EKwSPdMM1NbqiuGaOveMyln9qXFP8xkNdEh2EiSIf5WLVtHOr5g+5tnyy09eYqXOkMpKP+ y6wtRSFfrrLi8nAnVQ1pr3nR3qek2JzkDBTzGONRuqo9W2gxUz4iXPLjFvlHmXvv4TfE8UQjy5GHPf 7bZPEGCN/EsWw0Hw= X-KPN-MID: 33|yRIU5FWhu2GwYXjAiPLBloFP2uxA0Fbecpf0KTPIcBazhvVPx0+YYfLlYaWTILY s7uy/bglDh1f12AxukscVgXszTYgvwsXI0hTiSGzldn0= X-KPN-VerifiedSender: Yes X-CMASSUN: 33|8g9nQTDkbqnbijavYPqw3es53Hd8twrmRvtScV1HLnAIZCHDbnOZa2+23Sq+MOb TYGKRFVhu/5sFqb5fwv4A9A== X-Originating-IP: 105.67.0.68 Received: from dummy.faircode.eu (unknown [105.67.0.68]) by smtp.kpnmail.nl (Halon) with ESMTPSA id 4b25c73d-0d1e-11ef-8afb-00505699d6e5; Wed, 08 May 2024 11:35:24 +0200 (CEST) Date: Wed, 8 May 2024 10:35:21 +0100 (GMT+01:00) From: Paul Ruizendaal To: tuhs@tuhs.org Message-ID: <57a37626-728c-4f34-b08b-a4f521f1db03@planet.nl> In-Reply-To: References: <18efd14f-4da6-4771-ad6a-901c6cb6105d@planet.nl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_12_100621303.1715160921084" X-Correlation-ID: <57a37626-728c-4f34-b08b-a4f521f1db03@planet.nl> Message-ID-Hash: DZPXLNXID77GDEZ56TJCRK5S37MTD6HC X-Message-ID-Hash: DZPXLNXID77GDEZ56TJCRK5S37MTD6HC X-MailFrom: pnr@planet.nl X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: On the uniqueness of DMR's C compiler List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: ------=_Part_12_100621303.1715160921084 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for pointing that out. Here's an interesting paper on the DEC PDP11 = Fortran compilers: http://forum.6502.org/download/file.php?id=3D1724&sid=3Df6a721f3e05774cff07= 6da72f5a731a6 Before 1975 they used direct threading, thereafter there was a native compi= ler 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 "intc= ode" in the early 70s, native thereafter -- still have to find source for t= he latter. Still, I should have first asked: Does anyone have pointers to small machin= e 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 : > I'm not sure I accept your starting position. There were several compiler= s 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? >=20 > And there were other small machines from other manufacturers, all of whic= h had some form of Fortran and other bespoke things, such as RPG on the sma= ll IBMs. I think the uniqueness was in the set of conditions more than in t= he Unix C compiler itself. >=20 > But you may be right. >=20 > -rob >=20 >=20 >=20 >=20 > On Wed, May 8, 2024 at 6:59=E2=80=AFAM Paul Ruizendaal wr= ote: >> In the last months, I've spent a little time on curating John Walker's U= nix clone and software stack, including an emulator to run it: >> https://gitlab.com/marinchip >>=20 >> After creating a basic tool chain (edit, asm, link and a simple executiv= e), John=C2=A0 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=E2=80=99s Pascal compiler. META was used to create a c= ompiler 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 ear= ly on -- had he found a good compiler, the code might have competed alongsi= de Coherent, Idris, and Minix during the 80=E2=80=99s. >>=20 >> 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 (sa= y 30%) >>=20 >> 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 h= is hand-coded kernel is 10% larger than an equivalent V6 Unix kernel (as co= mpiled for the 9900 architecture). >>=20 >> There are three papers on DMR=E2=80=99s 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 >>=20 >> It seems to me that these papers rather understate the importance of gen= erating 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 machi= nes 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 n= atively on a small (i.e. PDP-11 class)=C2=A0machine. >>=20 >> As far as I can tell the uniqueness was mostly in the =E2=80=9Cc1=E2=80= =9D phase of the compiler. The front-end code of the =E2=80=9Cc0=E2=80=9D p= hase seems to use more or less similar techniques as many contemporary comp= ilers. The =E2=80=9Cc1=E2=80=9D 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 g= enerate threaded code, code for a virtual machine or poor quality native co= de that evaluated expressions using stack operations rather than registers. >>=20 >> I am not sure why DMR's approach was not more widely used in the 1970=E2= =80=99s. The algorithms he used do not seem to be new and appear to have th= eir roots in other (larger) compilers of the 1960=E2=80=99s. The basic desi= gn seems to have been in place from the very first iterations of his compil= er in 1972 (see V2 tree on TUHS) and he does not mention these algorithms a= s being special or innovative in his later papers. >>=20 >> Any observations / opinions on why DMR=E2=80=99s approach was not more w= idely used in the 1970=E2=80=99s? ------=_Part_12_100621303.1715160921084 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for po= inting that out. Here's an interesting paper on the DEC PDP11 Fortran compi= lers:
http://fo= rum.6502.org/download/file.php?id=3D1724&sid=3Df6a721f3e05774cff076da72= f5a731a6

Before 19= 75 they used direct threading, thereafter there was a native compiler for t= he higher-end models. I think this one may have required split i/d, but tha= t is not entirely clear from the text.

I think t= he same holds for BCPL on the PDP11: compiling to "ocode" or "intcode" in t= he 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 alre= ady 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 comp= ilers for RT-11 and RSX/11-M. RSX (and perhaps RT) Fortran were threaded co= de, 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=E2=80=AFAM Paul Ruizendaal <pnr@planet.nl> wrote:=20
In th= e last months, I've spent a little time on curating John Walker's Unix clon= e and software stack, including an emulator to run it:
<= a href=3D"https://gitlab.com/marinchip" target=3D"_blank">https://gitlab.co= m/marinchip

A= fter 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=E2=80=99s Pascal compiler. META was used to create a compi= ler 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 990= 0 architecture withered after 1980, this sealed the fate of this OS early o= n -- had he found a good compiler, the code might have competed alongside C= oherent, Idris, and Minix during the 80=E2=80=99s.

T= his 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= %)

A= s has been observed before, working at a higher abstraction level makes it = easier to work on algorithms and on refactoring, often earning back the eff= iciency loss. John Walkers work may be case in point: I estimate that his h= and-coded kernel is 10% larger than an equivalent V6 Unix kernel (as compil= ed for the 9900 architecture).

T= here are three papers on DMR=E2=80=99s website about the history of the com= piler and a compare-and-contrast with other compilers of the era:
<= a href=3D"https://www.bell-labs.com/usr/dmr/www/primevalC.html" target=3D"_= blank">https://www.bell-labs.com/usr/dmr/www/primevalC.html
<= a href=3D"https://www.bell-labs.com/usr/dmr/www/chist.html" target=3D"_blan= k">https://www.bell-labs.com/usr/dmr/www/chist.html
<= a href=3D"https://www.bell-labs.com/usr/dmr/www/hopl.html" target=3D"_blank= ">https://www.bell-labs.com/usr/dmr/www/hopl.html

I= t seems to me that these papers rather understate the importance of generat= ing 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 nativ= ely on a small (i.e. PDP-11 class) machine.

A= s far as I can tell the uniqueness was mostly in the =E2=80=9Cc1=E2=80=9D p= hase of the compiler. The front-end code of the =E2=80=9Cc0=E2=80=9D phase = seems to use more or less similar techniques as many contemporary compilers= . The =E2=80=9Cc1=E2=80=9D phase seems to have been unique in that it manag= ed to do register allocation and instruction selection with a pattern match= er and associated code tables squeezed into a small address space. On a sma= ll machine, other native compilers of the era typically proceeded to genera= te threaded code, code for a virtual machine or poor quality native code th= at evaluated expressions using stack operations rather than registers.

I= am not sure why DMR's approach was not more widely used in the 1970=E2=80= =99s. The algorithms he used do not seem to be new and appear to have their= roots in other (larger) compilers of the 1960=E2=80=99s. 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 b= eing special or innovative in his later papers.

A= ny observations / opinions on why DMR=E2=80=99s approach was not more widel= y used in the 1970=E2=80=99s?
------=_Part_12_100621303.1715160921084--