From pnr at planet.nl Wed May 8 06:59:17 2024 From: pnr at planet.nl (Paul Ruizendaal) Date: Tue, 7 May 2024 21:59:17 +0100 (GMT+01:00) Subject: [TUHS] On the uniqueness of DMR's C compiler Message-ID: <18efd14f-4da6-4771-ad6a-901c6cb6105d@planet.nl> 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? -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Wed May 8 08:07:44 2024 From: robpike at gmail.com (Rob Pike) Date: Wed, 8 May 2024 08:07:44 +1000 Subject: [TUHS] On the uniqueness of DMR's C compiler In-Reply-To: <18efd14f-4da6-4771-ad6a-901c6cb6105d@planet.nl> References: <18efd14f-4da6-4771-ad6a-901c6cb6105d@planet.nl> Message-ID: 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 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? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Wed May 8 19:35:21 2024 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 8 May 2024 10:35:21 +0100 (GMT+01:00) Subject: [TUHS] On the uniqueness of DMR's C compiler In-Reply-To: References: <18efd14f-4da6-4771-ad6a-901c6cb6105d@planet.nl> Message-ID: <57a37626-728c-4f34-b08b-a4f521f1db03@planet.nl> 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 : > 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 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? -------------- next part -------------- An HTML attachment was scrubbed... URL: From e5655f30a07f at ewoof.net Wed May 8 21:09:29 2024 From: e5655f30a07f at ewoof.net (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Wed, 8 May 2024 11:09:29 +0000 Subject: [TUHS] On the uniqueness of DMR's C compiler In-Reply-To: <18efd14f-4da6-4771-ad6a-901c6cb6105d@planet.nl> References: <18efd14f-4da6-4771-ad6a-901c6cb6105d@planet.nl> Message-ID: <33ca504d-5167-4796-a277-b9d2865b7fb1@home.arpa> On 7 May 2024 21:59 +0100, from pnr at planet.nl (Paul Ruizendaal): > 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. https://www.softwarepreservation.org/projects/BCPL/index.html#York appears to indicate that by 1974 there existed a native PDP-11 (/40 or /45) BCPL compiler which ran under RSX-11. -- Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From robpike at gmail.com Wed May 8 23:12:28 2024 From: robpike at gmail.com (Rob Pike) Date: Wed, 8 May 2024 23:12:28 +1000 Subject: [TUHS] On the uniqueness of DMR's C compiler In-Reply-To: <57a37626-728c-4f34-b08b-a4f521f1db03@planet.nl> References: <18efd14f-4da6-4771-ad6a-901c6cb6105d@planet.nl> <57a37626-728c-4f34-b08b-a4f521f1db03@planet.nl> Message-ID: 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 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 : > > 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 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? >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu May 9 01:51:11 2024 From: clemc at ccc.com (Clem Cole) Date: Wed, 8 May 2024 11:51:11 -0400 Subject: [TUHS] On the uniqueness of DMR's C compiler In-Reply-To: <57a37626-728c-4f34-b08b-a4f521f1db03@planet.nl> References: <18efd14f-4da6-4771-ad6a-901c6cb6105d@planet.nl> <57a37626-728c-4f34-b08b-a4f521f1db03@planet.nl> Message-ID: I agree with Rob. I fear the OP might have more limited experience with what was available at the time and how it was developed. The following is undoubtedly incomplete. It is what I could remember quickly to answer the question of real compilers for the PDP-11. As others have pointed out, the original DEC PDP-11 FTN, like the original PDP-6 and PDP-8, was based on threaded DEC F4 technology. After introducing the PDP-10, the 36-bit compiler team at DEC started a project to rewrite FORTRAN (in BLISS) as a true compiler. As was reminded at lunch last week (I still eat weekly with many of the DEC TLG folks), DEC had two groups -- a development team and a support team. I think some of the external confusion comes from both teams releasing products to the world, and the outside world did not always understand the differences. So, when I say the "compiler" group, I generally refer to the former - although many people started in the latter and eventually became part of the former. They key point here is that F4 (which was from the support folks), lived for a while in parallel with stuff coming from what eventually would become TLG [Technical Languages (and tools) Group]. The primary DEC-supported technical languages were all written in BLISS-11 and cross-compiled from the PDP-10 (originally). However, they could run in 11/40 class (shared I/D) space machines. Remember, DEC operating systems could do overlays - although there were probably some differences with what could be generated [I'd need to pull the old RT11 manuals for each]. Yes, FORTRAN was the primary technical language, but DEC's TLG supported other languages for the PDP-11 from COBOL to BASIC, and 3rd parties filled out the available suite. Probably the #1 3rd party, PDP-11 compiler, is (was) the OMSI Pascal compiler (which generated direct PDP-11 code) for all classes of PDP-11s [the OP referred to the Pascal that generated P4 code and ran interpreter for same. The UCSD Pascal worked this way, but I never saw anything other than students use it for teaching, while the OMSI compiler was a force for PDP-11 programmers, and you saw it in many PDP-11 shops - including some I worked]. I'm pretty sure the RT11 and RSX11 versions of this can be easily found in the wild, but I have not looked for the UNIX version (note that there was one). Note - from a SW marketplace for PDP-11s, the money was on the DEC operating systems, not UNIX. So, there was little incentive to move those tools, which I think is why the OP may not have experienced them. Another important political thing to consider is that TLG did their development on PDP-10s and later Vaxen inside DEC. Since everything was written in BLISS and DEC marketing 100% missed/sunk that boat, the concept of self-hosting the compiler was not taken seriously (ISTR: there was a project to make it self-host on RSX, but it was abandoned since customers were not beating DEC's door down for BLISS on many PDP-11 systems). Besides DMR's compiler for the PDP-11. Steve Johnson developed PCC and later PCC2. Both ran on all flavors of PDP-11s, although I believe since the lack of support for overlays in the research UNIX editions limited the compilers and ISTR, there were both 11/40 and 11/45 class binaries with different-sized tables. On our Unix boxes, we also had a PDP-11 Pascal compiler from Free University in Europe (VU) - I don't remember much about it nor can I find it in a quick search of my currently online stuff. ISTR That one may have been 11/45 class - we had it on the TekLabs 11/70 and I don't remember having in on any of our 40-class systems. The Whitesmith's C has been mentioned. That compiler ran on all the PDP-11 UNIXs of the day, plus its native Idris, as well as the DEC OSs. It did not use an interpreter per se, but instead compiled to something Plauger called 'ANAT" - a natural assembler. He then ran an optimizer over this output and his final pass converted from ANAT code to the PDP-11 (or Z80 as it turns out). I argue that ANAT was what we now think of in modern compilers as the IL, but others might argue differently. We ran it on our RT-11 systems, although ISTR came with the UNIX version, so we had it on the 11/70, too. That may have been because we used it to cross-compile for the Z80. Tannabaum and the team have the Amsterdam compiler toolkit. This had front ends for C and Pascal and could generate code for PDP-11s and several other microprocessors. I do not know how widely it was used for the PDP11s. Per Brinch, Hansen also implemented Parallel Pascal and his own OS for the 40-class PDP-11s. He talks about this in his book Pascal on Small Systems. Holt and team wrote Concurrent Euclid and TUNIS for the 40-class machines. Wirth released a Modula for the 11, although we mostly ran it on the 68000s and a Lilith system. IIRC, Mike Malcom and the team built a true B compiler so they could develop Thoth. As the 11/40 was one of the original Thoth target systems, I would have expected that to exist, but I have never used it. As was mentioned before, there was BCPL for the PDP-11. I believe that a BCPL compiler can even be found on one of the USENIX tapes in the TUHS archives, but I have not looked. Finally, ISTR, in the mid-late 1970s one of the Universities in Europe (??Edinburgh, maybe??), developed and released an Algol flavor for the PDP-11, but I never used it. Again, you might want to check the TUHS archives. In my own case, while I had used Algol on the PDP-8s and 10s, plus the IBM systems, and by then Pascal had become the hot alternative language and was close enough I never had a desire/need for it. Plus since there were a number of Pascal implementations available for 11s and no one in Teklabs was asking for it, I never chased it down. To quote Tom Lehrer .. "*These are the only ones that the news has come to Huvrd. There may be many others ..*." Clem ᐧ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nobozo at gmail.com Thu May 9 02:07:47 2024 From: nobozo at gmail.com (Jon Forrest) Date: Wed, 8 May 2024 09:07:47 -0700 Subject: [TUHS] On the uniqueness of DMR's C compiler In-Reply-To: References: <18efd14f-4da6-4771-ad6a-901c6cb6105d@planet.nl> <57a37626-728c-4f34-b08b-a4f521f1db03@planet.nl> Message-ID: There was also a Modula2 compiler for the PDP-11 from a university in the UK, propably York. It was used to some degree at Ford Aerospace for the KSOS secure Unix project. I think it required separate I&D. Jon From ats at offog.org Thu May 9 03:05:51 2024 From: ats at offog.org (Adam Sampson) Date: Wed, 08 May 2024 18:05:51 +0100 Subject: [TUHS] On the uniqueness of DMR's C compiler In-Reply-To: (Clem Cole's message of "Wed, 8 May 2024 11:51:11 -0400") References: <18efd14f-4da6-4771-ad6a-901c6cb6105d@planet.nl> <57a37626-728c-4f34-b08b-a4f521f1db03@planet.nl> Message-ID: Clem Cole writes: > Finally, ISTR, in the mid-late 1970s one of the Universities in Europe > (??Edinburgh, maybe??), developed and released an Algol flavor for the > PDP-11, but I never used it. That sounds like Edinburgh's IMP, which eventually had backends for a very wide variety of platforms. Several versions are available here: https://history.dcs.ed.ac.uk/archive/languages/ -- Adam Sampson From aek at bitsavers.org Thu May 9 03:45:47 2024 From: aek at bitsavers.org (Al Kossow) Date: Wed, 8 May 2024 10:45:47 -0700 Subject: [TUHS] On the uniqueness of DMR's C compiler In-Reply-To: References: <18efd14f-4da6-4771-ad6a-901c6cb6105d@planet.nl> <57a37626-728c-4f34-b08b-a4f521f1db03@planet.nl> Message-ID: <517e03bf-09d2-9e5e-fe21-df17318d4080@bitsavers.org> On 5/8/24 8:51 AM, Clem Cole wrote: > IIRC, Mike Malcom and the team built a true B compiler so they could develop Thoth.   As the 11/40 was one of the original Thoth target > systems,  I would have expected that to exist, but I have never used it. > Thoth has been a white whale for me for decades. AFAIK nothing has survived from it. "Decus" (Conroy's) C (transliteration of the assembler Unix C) should also be mentioned. From tom.perrine+tuhs at gmail.com Thu May 9 03:49:02 2024 From: tom.perrine+tuhs at gmail.com (Tom Perrine) Date: Wed, 8 May 2024 10:49:02 -0700 Subject: [TUHS] On the uniqueness of DMR's C compiler In-Reply-To: References: <18efd14f-4da6-4771-ad6a-901c6cb6105d@planet.nl> <57a37626-728c-4f34-b08b-a4f521f1db03@planet.nl> Message-ID: Hi Jon (and others), I was part of the KSOS (later KSOS-11 and KSOS-32) team at LOGICON, which picked up a follow-on contract to use KSOS-11 in a true multi-level-secure production environment. Our target was SYSTEM_LOW as TOP SECRET. Yes, we used that compiler for all the KSOS kernel and all the trusted user-space code. KSOS-11 only ran on PDP-11/70, and it did use split I&D. I have access to the KSOS-11 source code, and have been trying to rebuild that OS, BUT I haven't been able to find that Modula compiler. KSOS-11 was a very small kernel, but there was a set of libraries that presented a UNIX system call interface, so it could run some PWB userspace tools, if they were re-compiled. I'm using the term KSOS-11, as there was a follow-on project (KSOS-32) that ported the original PDP KSOS to 11/780. I wrote a completely new (simpler) scheduler, the bootstrap and memory management layer for that one. And, for "reasons", the entire KSOS project at Logicon was shut down just a week or so after the first user login to KSOS-32. KSOS-11 itself and some multi-level applications did ship to DoD customers, and it ran MLS applications for the Navy and USAFE. --tep ps. Jon was kind enough to remind me that we had corresponded about this in the past -and- to remind me to send to the list, and not just him :-) On Wed, May 8, 2024 at 9:08 AM Jon Forrest wrote: > There was also a Modula2 compiler for the PDP-11 from a university in the > UK, > propably York. It was used to some degree at Ford Aerospace for the > KSOS secure Unix project. I think it required separate I&D. > > Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu May 9 04:12:15 2024 From: clemc at ccc.com (Clem Cole) Date: Wed, 8 May 2024 14:12:15 -0400 Subject: [TUHS] On the uniqueness of DMR's C compiler In-Reply-To: <517e03bf-09d2-9e5e-fe21-df17318d4080@bitsavers.org> References: <18efd14f-4da6-4771-ad6a-901c6cb6105d@planet.nl> <57a37626-728c-4f34-b08b-a4f521f1db03@planet.nl> <517e03bf-09d2-9e5e-fe21-df17318d4080@bitsavers.org> Message-ID: On Wed, May 8, 2024 at 1:46 PM Al Kossow wrote: > Thoth has been a white whale for me for decades. Ditto. Although, I believe the late John Beety had his 'Thoth Thucks" tee shirt for years. I believe Kelly Booth still does. > AFAIK nothing has survived from it. > You can argue that V-Kernel and QNX are children of Thoth - but they were both in a flavor of Waterloo C that did not think ever targeted the PDP-11 [that might be a misunderstanding WRT Waterloo C]. > > "Decus" (Conroy's) C (transliteration of the assembler Unix C) should also > be mentioned. > Hmmmm, it's a flavor of Dennis' compiler in disguise and was sort of an end-around for the AT&T lawyers by taking the *.s files, and converting them to MACRO11, and then redoing the assembler code to use originally RT11 I/O and later RSX11. That said, it had its own life and ran on the DEC OSses, not UNIX, so it probably counts. That said, I thought Paul was asking about different core compiler implementations, and I would argue the DECUS/Conroy compiler is the DMR compiler, while the list I offered was all different core implementations. I'm curious about Jon and Tom's MOD2 compiler. Other than Wirth's, which targeted the 68000, Lilith, and VAX, I did not know of another for the PDP-11. Any idea of its origin story? I would have expected it to have derived from Wirth's Modula subsystem. FWIW: The DEC Mod-II and Mod-III were new implementations from DEC WRL or SRC (I forget). They targeted Alpha and I, maybe Vax. I'd have to ask someone like Larry Stewart or Jeff Mogul who might know/remember, but I thought that the font end to the DEC MOD2 compiler might have been partly based on Wirths but rewritten and by the time of the MOD3 FE was a new one originally written using the previous MOD2 compiler -- but I don't remember that detail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu May 9 04:12:55 2024 From: clemc at ccc.com (Clem Cole) Date: Wed, 8 May 2024 14:12:55 -0400 Subject: [TUHS] On the uniqueness of DMR's C compiler In-Reply-To: References: <18efd14f-4da6-4771-ad6a-901c6cb6105d@planet.nl> <57a37626-728c-4f34-b08b-a4f521f1db03@planet.nl> <517e03bf-09d2-9e5e-fe21-df17318d4080@bitsavers.org> Message-ID: s/Beety/Beatty/ -- sorry ᐧ On Wed, May 8, 2024 at 2:12 PM Clem Cole wrote: > > > On Wed, May 8, 2024 at 1:46 PM Al Kossow wrote: > >> Thoth has been a white whale for me for decades. > > Ditto. Although, I believe the late John Beety had his 'Thoth Thucks" tee > shirt for years. I believe Kelly Booth still does. > > > >> AFAIK nothing has survived from it. >> > You can argue that V-Kernel and QNX are children of Thoth - but they were > both in a flavor of Waterloo C that did not think ever targeted the PDP-11 > [that might be a misunderstanding WRT Waterloo C]. > >> >> "Decus" (Conroy's) C (transliteration of the assembler Unix C) should >> also be mentioned. >> > Hmmmm, it's a flavor of Dennis' compiler in disguise and was sort of an > end-around for the AT&T lawyers by taking the *.s files, and converting > them to MACRO11, and then > redoing the assembler code to use originally RT11 I/O and later RSX11. > That said, it had its own life and ran on the DEC OSses, not UNIX, so it > probably counts. > That said, I thought Paul was asking about different core compiler > implementations, and I would argue the DECUS/Conroy compiler is the DMR > compiler, while the list I offered was all different core implementations. > > I'm curious about Jon and Tom's MOD2 compiler. Other than Wirth's, which > targeted the 68000, Lilith, and VAX, I did not know of another for the > PDP-11. Any idea of its origin story? I would have expected it to have > derived from Wirth's Modula subsystem. FWIW: The DEC Mod-II and Mod-III > were new implementations from DEC WRL or SRC (I forget). They targeted > Alpha and I, maybe Vax. I'd have to ask someone like Larry Stewart or Jeff > Mogul who might know/remember, but I thought that the font end to the DEC > MOD2 compiler might have been partly based on Wirths but rewritten and by > the time of the MOD3 FE was a new one originally written using the previous > MOD2 compiler -- but I don't remember that detail. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Thu May 9 04:29:19 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Wed, 8 May 2024 14:29:19 -0400 Subject: [TUHS] On the uniqueness of DMR's C compiler Message-ID: There was nothing unique about the size or the object code of Dennis's C compiler. In the 1960s, Digitek had a thriving business of making Fortran compilers for all manner of machines. To optimize space usage, the compilers' internal memory model comprised variable-size movable tables, called "rolls". To exploit this non-native architecture, the compilers themselves were interpreted, although they generated native code. Bob McClure tells me he used one on an SDS910 that had 8K 16-bit words. Dennis was one-up on Digitek in having a self-maintaining compiler. Thus, when he implemented an optimization, the source would grow, but the compiler binary might even shrink thanks to self-application. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From stewart at serissa.com Thu May 9 11:27:41 2024 From: stewart at serissa.com (Lawrence Stewart) Date: Wed, 8 May 2024 21:27:41 -0400 Subject: [TUHS] On the uniqueness of DMR's C compiler In-Reply-To: References: <18efd14f-4da6-4771-ad6a-901c6cb6105d@planet.nl> <57a37626-728c-4f34-b08b-a4f521f1db03@planet.nl> <517e03bf-09d2-9e5e-fe21-df17318d4080@bitsavers.org> Message-ID: <24A2FC48-8720-49B3-BF85-E53C9B09B32A@serissa.com> Regarding the Dec Research Modula-X compilers, I am fairly sure that Modula-2 for the VAX was a WRL (Digital Western Research Lab) thing, because it was used for the WRL CAD tool suite used to design the WRL Titan and the SRC (Systems Research Center) Firefly machines. SRC did the Modula-2-Plus compiler for the VAX, which added garbage collection. The Firefly OS was Modula, but included an Ultrix system call set so it could run Ultrix binaries. I may be wrong about this, but I think Wirth then did Modula-3 and then Oberon. WRL and SRC never had any PDP-11’s as far as I know. -L > On May 8, 2024, at 2:12 PM, Clem Cole wrote: > > > > On Wed, May 8, 2024 at 1:46 PM Al Kossow > wrote: >> Thoth has been a white whale for me for decades. > Ditto. Although, I believe the late John Beety had his 'Thoth Thucks" tee shirt for years. I believe Kelly Booth still does. > > >> AFAIK nothing has survived from it. > You can argue that V-Kernel and QNX are children of Thoth - but they were both in a flavor of Waterloo C that did not think ever targeted the PDP-11 [that might be a misunderstanding WRT Waterloo C]. >> >> "Decus" (Conroy's) C (transliteration of the assembler Unix C) should also be mentioned. > Hmmmm, it's a flavor of Dennis' compiler in disguise and was sort of an end-around for the AT&T lawyers by taking the *.s files, and converting them to MACRO11, and then > redoing the assembler code to use originally RT11 I/O and later RSX11. That said, it had its own life and ran on the DEC OSses, not UNIX, so it probably counts. > That said, I thought Paul was asking about different core compiler implementations, and I would argue the DECUS/Conroy compiler is the DMR compiler, while the list I offered was all different core implementations. > > I'm curious about Jon and Tom's MOD2 compiler. Other than Wirth's, which targeted the 68000, Lilith, and VAX, I did not know of another for the PDP-11. Any idea of its origin story? I would have expected it to have derived from Wirth's Modula subsystem. FWIW: The DEC Mod-II and Mod-III were new implementations from DEC WRL or SRC (I forget). They targeted Alpha and I, maybe Vax. I'd have to ask someone like Larry Stewart or Jeff Mogul who might know/remember, but I thought that the font end to the DEC MOD2 compiler might have been partly based on Wirths but rewritten and by the time of the MOD3 FE was a new one originally written using the previous MOD2 compiler -- but I don't remember that detail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at mcjones.org Thu May 9 13:39:32 2024 From: paul at mcjones.org (Paul McJones) Date: Wed, 8 May 2024 20:39:32 -0700 Subject: [TUHS] On the uniqueness of DMR's C compiler In-Reply-To: <171519201646.4052234.694570138790187562@minnie.tuhs.org> References: <171519201646.4052234.694570138790187562@minnie.tuhs.org> Message-ID: <6CFD774F-F714-4AD0-A37E-E40013B8A281@mcjones.org> > On Wed, 8 May 2024 14:12:15 -0400,Clem Cole > wrote: > > FWIW: The DEC Mod-II and Mod-III > were new implementations from DEC WRL or SRC (I forget). They targeted > Alpha and I, maybe Vax. I'd have to ask someone like Larry Stewart or Jeff > Mogul who might know/remember, but I thought that the font end to the DEC > MOD2 compiler might have been partly based on Wirths but rewritten and by > the time of the MOD3 FE was a new one originally written using the previous > MOD2 compiler -- but I don't remember that detail. Michael Powell at DEC WRL wrote a Modula 2 compiler that generated VAX code. Here’s an extract from announcement.d accompanying a 1992 release of the compiler from gatekeeper.dec.com : The compiler was designed and built by Michael L. Powell, and originally released in 1984. Joel McCormack sped the compiler up, fixed lots of bugs, and swiped/wrote a User's Manual. Len Lattanzi ported the compiler to the MIPS. Later, Paul Rovner and others at DEC SRC designed Modula-2+ (a language extension with exceptions, threads, garbage collection, and runtime type dispatch). The Modula-2+ compiler was originally based on Powell’s compiler. Modula-2+ ran on the VAX. Here’s a DEC SRC research report on Modula-2+: http://www.bitsavers.org/pdf/dec/tech_reports/SRC-RR-3.pdf Modula-3 was designed at DEC SRC and Olivetti Labs. It had a portable implementation (using the GCC back end) and ran on a number of machines including Alpha. Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu May 9 13:46:20 2024 From: imp at bsdimp.com (Warner Losh) Date: Wed, 8 May 2024 21:46:20 -0600 Subject: [TUHS] On the uniqueness of DMR's C compiler In-Reply-To: <6CFD774F-F714-4AD0-A37E-E40013B8A281@mcjones.org> References: <171519201646.4052234.694570138790187562@minnie.tuhs.org> <6CFD774F-F714-4AD0-A37E-E40013B8A281@mcjones.org> Message-ID: On Wed, May 8, 2024, 9:39 PM Paul McJones wrote: > On Wed, 8 May 2024 14:12:15 -0400,Clem Cole wrote: > > > FWIW: The DEC Mod-II and Mod-III > were new implementations from DEC WRL or SRC (I forget). They targeted > Alpha and I, maybe Vax. I'd have to ask someone like Larry Stewart or Jeff > Mogul who might know/remember, but I thought that the font end to the DEC > MOD2 compiler might have been partly based on Wirths but rewritten and by > the time of the MOD3 FE was a new one originally written using the previous > MOD2 compiler -- but I don't remember that detail. > > > Michael Powell at DEC WRL wrote a Modula 2 compiler that generated VAX > code. Here’s an extract from announcement.d accompanying a 1992 release of > the compiler from gatekeeper.dec.com: > > The compiler was designed and built by Michael L. Powell, and originally > released in 1984. Joel McCormack sped the compiler up, fixed lots of > bugs, and > swiped/wrote a User's Manual. Len Lattanzi ported the compiler to the > MIPS. > > > Later, Paul Rovner and others at DEC SRC designed Modula-2+ (a language > extension with exceptions, threads, garbage collection, and runtime type > dispatch). The Modula-2+ compiler was originally based on Powell’s > compiler. Modula-2+ ran on the VAX. > > Here’s a DEC SRC research report on Modula-2+: > http://www.bitsavers.org/pdf/dec/tech_reports/SRC-RR-3.pdf > > Modula-3 was designed at DEC SRC and Olivetti Labs. It had a portable > implementation (using the GCC back end) and ran on a number of machines > including Alpha. > FreeBSD's cvsup was written using it. The threading made it possible to make maximum use of the 56k modems of the time and speed downloads of the source changes. The port for modula-3 changed a number of time from gcc to egcs back to gcc before running out of steam... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: