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_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from minnie.tuhs.org (minnie.tuhs.org [50.116.15.146]) by inbox.vuxu.org (Postfix) with ESMTP id E5EB829564 for ; Tue, 12 Mar 2024 01:30:51 +0100 (CET) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 7FEBB42884; Tue, 12 Mar 2024 10:30:45 +1000 (AEST) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) by minnie.tuhs.org (Postfix) with ESMTPS id D5E5A4287D for ; Tue, 12 Mar 2024 10:30:34 +1000 (AEST) Received: by mail-lj1-x229.google.com with SMTP id 38308e7fff4ca-2d4360ab3daso27918501fa.3 for ; Mon, 11 Mar 2024 17:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710203433; x=1710808233; darn=tuhs.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=je+Rpn2dptWzR8IQU9BmBZdcjnjJ0f8Wsl8eQGhqtWk=; b=M1y5hylKTV5pNfufn1wyGWRdbV/P5+DsV43hR/EiJc9TJQAOLM+KkgbeDeUselVzTS cjuBc+RWnCwgT/WzyEbNH+FWek38QCX30wjfmUXXn3LT6iwmFk779RqRVIyVLg77lFnE mOrqAp4/AW3eWKAgN9cIgjkifGMi7SmACuo3WmFo2PYB/F9JfsrNYXWpYEILTCY33HBM +g9RL6hw26dUmedSkEDEl2Ij+6JPGOb0/ARdiNpCujy/0JPHnTmR0vD24vK+4XXhvByb Ixt+1OKJIo0C0GFbQQfGj9m8d/hzU0F2dyIGLN6JHRK77Q4SPLmBYSaKGgR+byIYU0Oi Asaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710203433; x=1710808233; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=je+Rpn2dptWzR8IQU9BmBZdcjnjJ0f8Wsl8eQGhqtWk=; b=T/q33by8MhXEdBkxBN52K+hw6G0E+MxEdxVFT1UbVvupFgqJxHvt1mPSdL9n0LTJfI uBHrKMhEfVFvRV0xAW8RvTdCe6Z8bIg2+kyQqFMa3bYSJLXuBje4WWuNV6J5H7ZGrWiS TALW5UdZcJoNJomyxjvqMWOC3vnxzu5NiA8gCj3pLFOnIZBlc6OTG8jJSY0uHZV6ctm8 SVRV9rL4B08gNWjl6i1A8w27sopMT+wPIyuVcc+WjLgepWvN3oTO8Bnp1lnBryOff9oQ b2gMuW6mGqqvCe5SlM8os5yvZQDzr/COvxl68rJ8BGLh6IophbI+j62eydVrVt77a2KD +Deg== X-Forwarded-Encrypted: i=1; AJvYcCVI21ZQ/roiV7SNst6kU7Sd04ZukpFGWEERfYBZo4D5SZLARzRGsvHyGB/Te0dg7f3dGHOK4YaEZ/MyMzOd X-Gm-Message-State: AOJu0Yyzr+mYkTvumdmG9sAbST4LsVEgJIXFksUujE7VteqhRf+YJFhh CkWIvZME0YVnMohwVUXKDxWJDgCec39/Us4ZZNeVMEwLK9ToNczO75MDYWJlfTSbGqePiA764bX Dxqb7HwZ5xtv45+J+BXeVtTf+g5WQW6IZk+Y= X-Google-Smtp-Source: AGHT+IE4b/BylpirNbBlwGGVflkOiHEvpA11sXC+VUjeGQ97IoiFt8EYCkBtEJQ/asZlfcZoNmm0Ll2gh7f4nw9VR9Q= X-Received: by 2002:ac2:4c38:0:b0:513:a83b:6761 with SMTP id u24-20020ac24c38000000b00513a83b6761mr274024lfq.18.1710203432486; Mon, 11 Mar 2024 17:30:32 -0700 (PDT) MIME-Version: 1.0 References: <12CFE503-ACC8-44B5-BA41-28DB5450E521@planet.nl> In-Reply-To: From: ron minnich Date: Mon, 11 Mar 2024 17:30:19 -0700 Message-ID: To: Peter Yardley Content-Type: multipart/alternative; boundary="000000000000164d2f06136bc490" Message-ID-Hash: K7BRMVMD2DVYY6UWUS2C7Z3I7RXWY6KZ X-Message-ID-Hash: K7BRMVMD2DVYY6UWUS2C7Z3I7RXWY6KZ X-MailFrom: rminnich@gmail.com 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 CC: Marc Rochkind , "tuhs@tuhs.org" X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: History of non-Bell C compilers? List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000164d2f06136bc490 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable One of the neatest compilers I worked with was Eric Biederman's romcc. "romcc is a C compiler which produces binaries which do not rely on RAM, bu= t instead only use CPU registers." We used romcc for 15 years or so. It was critical to getting DRAM and Hypertransport topology working on the Opteron. Remember: at power-on/reset, RAM is dead, dead, dead, and getting it going on newer systems is (literally) billions of instructions. So, no ram. The only "ram" romcc had were the general purpose registers. Later, eric added support for the SIMD registers, and "memory" grew a few hundred bytes. No memory, no stack: 100% inlining. romcc knew how to use puddle arithmetic and all the other tricks. It was amazing. It is a full ANSI C compiler (as of 2006 ANSI C) in 25KLOC code, in one file: https://github.com/wt/coreboot/blob/master/util/romcc/romcc.c The story of its creation, as told to me by the Linux NetworX CTO ca 2004: Eric worked at Linux NetworX at the time, and they were shipping LinuxBIOS-based systems. Everyone working with Opteron was suffering with assembly. Eric vanished for 30 days, and on the 31st day returned from the mountain (or his apartment I guess) with romcc, and It Was Good. Really good. The code we wrote for Opteron Hypertransport was far better than AMDs; they even admitted it to us later. We could even run with empty Socket 0; they could not. Last I checked, it still builds and 100 or so regression tests work just fine. On Mon, Mar 11, 2024 at 3:28=E2=80=AFPM Peter Yardley < peter.martin.yardley@gmail.com> wrote: > I used the DEC VMS C compiler extensively while I was at NSWIT. I ported = a > lot of Berkley (I think) C code to VMS. Some of their VLSI design suite, > KIC etc. There weren=E2=80=99t a lot of changes to make, the compiler and= library > was pretty K&R from what I remember. The usual small header issues applie= d. > VMS IO is a bit different from UNIX IO but they had a mode (stream I > think) that meant minimal changes to UNIX code. > > > http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/vax/lang/c/AI-L370C-= TE_Guide_to_VAX_C_V2.3_Mar1987.pdf > > It did help that the code I was working with was pretty damn good. I lear= n > C porting KIC to VMS. > > > On 12 Mar 2024, at 7:44=E2=80=AFAM, Marc Rochkind = wrote: > > > > Since it came up in this thread, here's my review of Coherent in BYTE > Magazine (1985): > > > > https://www.mrochkind.com/mrochkind/docs/Byte-Pick-Coherent-Theos.pdf > > > > Marc > > > > On Mon, Mar 11, 2024 at 11:13=E2=80=AFAM Paul Ruizendaal wrote: > > On Thu, Mar 7, 2024, 4:14=E2=80=AFPM Tom Lyon wro= te: > > > > > For no good reason, I've been wondering about the early history of C > > > compilers that were not derived from Ritchie, Johnson, and Snyder at > Bell. > > > Especially for x86. Anyone have tales? > > > Were any of those compilers ever used to port UNIX? > > > > An unusual one would be the =E2=80=9Crevenue bomb=E2=80=9D compiler tha= t Charles Simonyi > and Richard Brodie did at Microsoft in 1981. > > > > This compiler was intended to provided a uniform environment for the > menagerie of 8 and 16-bit computers of the era. It compiled to a byte cod= e > which executed through a small interpreter. This by itself was hardly new > of course, but it had some unique features. It generated code in overlays= , > so that it could run a code base larger than 64KB (but it defined only on= e > data segment). It also defined a small set of =E2=80=9Csystem=E2=80=9D co= mmands, that > allowed for uniform I/O. I still have the implementation spec for that > interpreter somewhere. > > > > This compiler was used for the first versions of Multiplan and Word, an= d > my understanding is that the byte code engine was later re-used in Visual > Basic. I think the compiler also had a Xenix port, maybe it even was Xeni= x > native (and at this time, Xenix would still essentially have been V7). > > > > I am not sure to what extent this compiler was independent of the Bell > compilers. It could well be that it was based on PCC, Microsoft was a Uni= x > licensee after all and at the time busy doing ports. On the other hand, > Charles Simonyi would certainly have been capable of creating his own fro= m > scratch. I do know that this compiler preceded Lattice C, the latter of > which was distributed by Microsoft as Microsoft C 1.0. > > > > Maybe others know more about this Simonyi/Brodie compiler? > > > > Paul > > > > Notes: > > http://www.memecentral.com/mylife.htm > > > https://web.archive.org/web/20080905231519/http://www.computerworld.com/s= oftwaretopics/software/appdev/story/0%2C10801%2C76413%2C00.html > > http://seefigure1.com/images/xenix/xenix-timeline.jpg > > > > > > -- > > My new email address is mrochkind@gmail.com > > Peter Yardley > peter.martin.yardley@gmail.com > > --000000000000164d2f06136bc490 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One of the neatest compilers I worked with was Eric Bieder= man's romcc.

"romcc is a C compiler which produ= ces binaries which do not rely on RAM, but
instead only use CPU register= s."

We used romcc for 15 years or so. It = was critical to getting DRAM and Hypertransport topology working on the=C2= =A0Opteron. Remember: at power-on/reset, RAM is dead, dead, dead, and getti= ng it going on newer systems is (literally) billions of instructions. So, n= o ram. The only "ram" romcc had were the general purpose register= s. Later, eric added support for the=C2=A0SIMD registers, and "memory&= quot; grew a few hundred bytes. No memory, no stack: 100% inlining. romcc k= new how to use puddle arithmetic and all the other tricks. It was amazing.<= /div>

It is a full ANSI C compiler (as of 2006 ANSI C) i= n 25KLOC=C2=A0code, in one file:=C2=A0https://github.com/wt/coreboot/blob/ma= ster/util/romcc/romcc.c

The story of its creat= ion, as told to me by the Linux=C2=A0NetworX CTO ca 2004: Eric worked at Li= nux NetworX at the time, and they were shipping LinuxBIOS-based systems. Ev= eryone working with Opteron was suffering with assembly. Eric vanished for = 30 days, and on the 31st day returned from the mountain (or his apartment I= guess) with romcc, and It Was Good. Really good. The code we wrote for Opt= eron Hypertransport was far better than AMDs; they even admitted it to us l= ater.=C2=A0 We could even run with empty Socket 0; they could not.=C2=A0

Last I checked, it still builds and 100 or so regres= sion tests work just fine.



On Mon, Mar 1= 1, 2024 at 3:28=E2=80=AFPM Peter Yardley <peter.martin.yardley@gmail.com> wrote:
=
I used the DEC VMS C comp= iler extensively while I was at NSWIT. I ported a lot of Berkley (I think) = C code to VMS. Some of their VLSI design suite, KIC etc. There weren=E2=80= =99t a lot of changes to make, the compiler and library was pretty K&R = from what I remember. The usual small header issues applied. VMS IO is a bi= t different from UNIX IO=C2=A0 but they had a mode (stream I think) that me= ant minimal changes to UNIX code.

http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/vax/lang/c/AI-L= 370C-TE_Guide_to_VAX_C_V2.3_Mar1987.pdf

It did help that the code I was working with was pretty damn good. I learn = C porting KIC to VMS.

> On 12 Mar 2024, at 7:44=E2=80=AFAM, Marc Rochkind <mrochkind@gmail.com> wrote:=
>
> Since it came up in this thread, here's my review of Coherent in B= YTE Magazine (1985):
>
> https://www.mrochkind.com/= mrochkind/docs/Byte-Pick-Coherent-Theos.pdf
>
> Marc
>
> On Mon, Mar 11, 2024 at 11:13=E2=80=AFAM Paul Ruizendaal <pnr@planet.nl> wrote: > On Thu, Mar 7, 2024, 4:14=E2=80=AFPM Tom Lyon <pugs78 at gmail.com> w= rote:
>
> > For no good reason, I've been wondering about the early histo= ry of C
> > compilers that were not derived from Ritchie, Johnson, and Snyder= at Bell.
> > Especially for x86.=C2=A0 Anyone have tales?
> > Were any of those compilers ever used to port UNIX?
>
> An unusual one would be the =E2=80=9Crevenue bomb=E2=80=9D compiler th= at Charles Simonyi and Richard Brodie did at Microsoft in 1981.
>
> This compiler was intended to provided a uniform environment for the m= enagerie of 8 and 16-bit computers of the era. It compiled to a byte code w= hich executed through a small interpreter. This by itself was hardly new of= course, but it had some unique features. It generated code in overlays, so= that it could run a code base larger than 64KB (but it defined only one da= ta segment). It also defined a small set of =E2=80=9Csystem=E2=80=9D comman= ds, that allowed for uniform I/O. I still have the implementation spec for = that interpreter somewhere.
>
> This compiler was used for the first versions of Multiplan and Word, a= nd my understanding is that the byte code engine was later re-used in Visua= l Basic. I think the compiler also had a Xenix port, maybe it even was Xeni= x native (and at this time, Xenix would still essentially have been V7). >
> I am not sure to what extent this compiler was independent of the Bell= compilers. It could well be that it was based on PCC, Microsoft was a Unix= licensee after all and at the time busy doing ports. On the other hand, Ch= arles Simonyi would certainly have been capable of creating his own from sc= ratch. I do know that this compiler preceded Lattice C, the latter of which= was distributed by Microsoft as Microsoft C 1.0.
>
> Maybe others know more about this Simonyi/Brodie compiler?
>
> Paul
>
> Notes:
> http://www.memecentral.com/mylife.htm
> https://web.archive.org/web/200809= 05231519/http://www.computerworld.com/softwaretopics/software/appdev/story/= 0%2C10801%2C76413%2C00.html
> http://seefigure1.com/images/xenix/xenix-= timeline.jpg
>
>
> --
> My new email address is mrochkind@gmail.com

Peter Yardley
peter.m= artin.yardley@gmail.com

--000000000000164d2f06136bc490--