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=-1.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,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 B8E89268BB for ; Thu, 9 May 2024 22:41:13 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 859AB43319; Fri, 10 May 2024 06:41:06 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuhs.org; s=dkim; t=1715287266; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-owner:list-unsubscribe:list-subscribe:list-post; bh=fJy/Wu7Kj6BnRTQ+ZFORjuJe3+nlsLqxkdMj+lEHNmI=; b=36B+BH9FvhGawJJ9BLynPuXF2jEq6wpnaUTlMq+bglU4LpzucTQKIEVcUalOXKTUmvwxiS 39ytb9m7tewWFLb/aUOPhwJ/88bZ5MmkV6b8CLpmlNfomHdn1NC2O2exyx6bYeRjZ7/GNa 4UTspEHs4MeRFZuvHGhwBjRY9ltJrb0= Received: from ewsoutbound.kpnmail.nl (unknown [195.121.94.167]) by minnie.tuhs.org (Postfix) with ESMTPS id 7E09743318 for ; Fri, 10 May 2024 06:40:42 +1000 (AEST) X-KPN-MessageId: 5c60f575-0e44-11ef-93a8-005056abbe64 Received: from smtp.kpnmail.nl (unknown [10.31.155.38]) by ewsoutbound.so.kpn.org (Halon) with ESMTPS id 5c60f575-0e44-11ef-93a8-005056abbe64; Thu, 09 May 2024 22:40:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=planet.nl; s=planet01; h=message-id:to:date:subject:mime-version:content-type:from; bh=fJy/Wu7Kj6BnRTQ+ZFORjuJe3+nlsLqxkdMj+lEHNmI=; b=NCd2qd+ka+wT45Obpum8lN5UCKaATGiI8aT8E6w2+rfIcB74qHEdk+IwswRsKzpQ6T03M9PKvph9T pwlsyJPPo4mBOr+lBdSe+Kjs0rlHi0Pcqvg7fCMQw3u1VOgrJ4jM5mSLnxG8oEhW2J4gHuzlP2m9Py KLcOtriWxIMkul3Q= X-KPN-MID: 33|aFUy4rwtsDwXN/spuw1RXhXoEq7kmo7V6yHg2Rgl40ntUY5iP9gsMEtKxMAut1h uwBwpHD+oDoL997gM0qBpCQZZ1KlrCN10HLUY/nDD0SE= X-KPN-VerifiedSender: Yes X-CMASSUN: 33|kZeV8cAokNJp2hni4zpRsinkNiAIG+/XTG8aq8EOKoxPKIEYTfrxU/63QhmhYXA 60Kw6IZT0jmW2Wr6OdROQhQ== X-Originating-IP: 77.172.38.96 Received: from smtpclient.apple (77-172-38-96.fixed.kpn.net [77.172.38.96]) by smtp.kpnmail.nl (Halon) with ESMTPSA id 5f8903f9-0e44-11ef-a072-005056abf0db; Thu, 09 May 2024 22:40:30 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) Date: Thu, 9 May 2024 22:40:28 +0200 References: <18efd14f-4da6-4771-ad6a-901c6cb6105d@planet.nl> To: "tuhs@tuhs.org" In-Reply-To: <18efd14f-4da6-4771-ad6a-901c6cb6105d@planet.nl> Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.15) Message-ID-Hash: SSHCDVMD7W3MNB7IAMOODVYZ5WRM2DQE X-Message-ID-Hash: SSHCDVMD7W3MNB7IAMOODVYZ5WRM2DQE 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: From: Paul Ruizendaal via TUHS Reply-To: Paul Ruizendaal Thanks everybody for the feedback and pointers, much appreciated! The main point is clear: the premise that the DMR C compiler had unique = (native, small machine) code generation during most of the 70=E2=80=99s = does not hold up. Clean Cole is correct in observing that (certainly for the 70=E2=80=99s) = I=E2=80=99m skewed to stuff from academia with a blind spot for the = commercial compilers of that era. Doug McIlroy=E2=80=99s remarks on Digitek were most helpful and I=E2=80=99= ll expand a bit on that below. I was aware of the Digitek / Ryan-Macfarland compilers before, but in my = mind they compiled to a virtual machine (mis-understanding a description = of =E2=80=9Cprogrammed operators=E2=80=9D and because their compilers = for microcomputers did so in the 80=E2=80=99s). Digging into this more = led me to a 1970 report "Programming Languages and their Compilers, = Preliminary Notes=E2=80=9D by John Cocke and J.T. Schwartz: = https://www.softwarepreservation.org/projects/FORTRAN/paper/Bright-FORTRAN= ComesToWestinghouseBettis-1971.pdf It is a nearly 800 page review of then current languages and compilers = and it includes some discussion of the Digitek compilers as the state of = the art for small machines and has some further description of how they = worked (pp. 233-237, 749). It also mentions their PL/1 for Multics = fiasco (for background https://www.multicians.org/pl1.html). - The Digitek compilers were indeed small enough to run on PDP-11 class = machines and even smaller, and they produced quite reasonable native = code. In this sense, they were in the same spot as the DMR C compiler = which was hence not unique in this regard -- as Doug points out. - They consisted of two parts: a front end coded in =E2=80=9CProgrammed = Operators" (POPS) generating an intermediate language, and a custom = coded back-end that converted the IL to native code. - POPS were in effect a VM for compiler construction (although expressed = as assembler operations). To move a compiler to a new machine only the = POPS VM had to be recoded, which was a very manageable job. =46rom the = description in the above book it sounds very similar to the META 3 = compiler generator setup, but expressed in a different form. - Unfortunately, I have not been able to find a description of the POPS = IL. - The smaller Digitek compilers had a limited level of optimisations, = carried out at the code generation phase. The optimisations described = sound quite similar to what the DMR C compiler did in its c1 phase = (special casing +1 and -1, combining constants, mul/div to shift, etc.) - Code generation seems to have been through code snippets for each IL = operation, selecting from one of 3 addressing modes: register, memory = and indexed; the text isn=E2=80=99t quite clear. It sounds reasonable = for small machines in the 60=E2=80=99s. - The later Ryan-MacFarland microcomputer compilers seem to have used = the same POPS based front-end technology, but using an interpreter to = execute the IL directly. Interestingly, the above book has a final chapter about =E2=80=9Cthe = self-compiling compiler=E2=80=9D. To quote: =E2=80=9CThe scheme to be = described is one which has often been considered, and in some cases even = implemented. It involves the use of a compiler written in its own = language, and capable therefore of compiling itself over to a new = machine.=E2=80=9D It proceeds to describe such a compiler in quite some = detail, including using a table driven code generator. Seen through this lens, the DMR C compiler could be viewed as a = re-imagining of the Digitek small system compilers using a = self-compiling lexer/parser instead of POPS (or TMG or META) and a (also = self-compiling) code generator evolved to handle the richer PDP-11 = addressing modes. The concept seems to have been in the air at that = time. Now I am left wondering why the IL-to-native back-ends were not more = used in academic small machine compilers in the 70=E2=80=99s -- but this = too may be the result of a skewed view on my part.