From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 18297 invoked from network); 3 May 2020 20:27:35 -0000 Received-SPF: pass (minnie.tuhs.org: domain of minnie.tuhs.org designates 45.79.103.53 as permitted sender) receiver=inbox.vuxu.org; client-ip=45.79.103.53 envelope-from= Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 3 May 2020 20:27:35 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id A5DCA9CA17; Mon, 4 May 2020 06:27:32 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 6A76E9CA0C; Mon, 4 May 2020 06:27:01 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=ccc.com header.i=@ccc.com header.b="X5JI/drZ"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 170619CA0C; Mon, 4 May 2020 06:26:58 +1000 (AEST) Received: from mail-qv1-f50.google.com (mail-qv1-f50.google.com [209.85.219.50]) by minnie.tuhs.org (Postfix) with ESMTPS id 6C1879CA0B for ; Mon, 4 May 2020 06:26:57 +1000 (AEST) Received: by mail-qv1-f50.google.com with SMTP id h6so7387482qvz.8 for ; Sun, 03 May 2020 13:26:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VG85/5T165Cut1nH3F6ExkSI0YjGKnunw1jAoMw4QQs=; b=X5JI/drZiuUn4X1BAdNyCY3e2jSXIw0hPbMeP6JwIewFK9p++qMv8wK8RGTlxIlchH vFfa94XiHz2woBTSEGLx8UmQSo7Xb7YihpqUUvO0/MynqyR7AApKnsC3EYXSQCNk6ujQ v13KQ1inc7KSO8oZ7DGbLilFg26wiriWnEBKs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VG85/5T165Cut1nH3F6ExkSI0YjGKnunw1jAoMw4QQs=; b=W3le3aVpXg0nIoG1Ka5+ohKGwY0Dcq4pKGR608mTsMzi1b/u25vGWxG75nZq/y2oIS hsDzrrD8q3OfY8skLoFmsXmnjWGN5ZxatkRmrrWY3Ji7at35er79/u8/7ZUSbhFSok2x nTXhzflXKaAqJPulPci2W+VKOYiA0/pNmdR/rVztwU+8i1MG33S6EXGnw1hlkLckH35W cWAYndwp+D0xOJCIe/sEzOGrAGAgrCaE3faetKz/OVkosCculhYFlPe9q1daTxJrQPQw D6/+L1aU9bYk7oE/PkasGbJSmmGuRyV7BLUxV9GxuYhhG1Y/lfCRRQN893q30ZFrDR/0 ga4w== X-Gm-Message-State: AGi0PuZZE5YnjFbg/Siy8Gw5P2puA6LSKA3BGauR31sIvihAd0HOkgiE wQhjATpkCqnMb2lpraXh8oTN7KSGMy4he5fCkTYhcUOTMDZ2qA== X-Google-Smtp-Source: APiQypKC01NEsk7GFdLFNDRvbZg4HxDFN7v7gFbraIDPY7FDFSJVm+/N9l52gL9MgEDHpRNgl8pqfhg0mHpifcIO49E= X-Received: by 2002:a0c:cdc9:: with SMTP id a9mr13496950qvn.243.1588537616289; Sun, 03 May 2020 13:26:56 -0700 (PDT) MIME-Version: 1.0 References: <2F4C604D-F01C-4A82-948A-7E77093B48A1@planet.nl> <21F16C75-62AB-422A-A43F-981407E11434@planet.nl> In-Reply-To: From: Clem Cole Date: Sun, 3 May 2020 16:26:30 -0400 Message-ID: To: Henry Bent Content-Type: multipart/alternative; boundary="00000000000054f6a805a4c43cc1" Subject: Re: [TUHS] SDB debugger X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list , Paul Ruizendaal Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --00000000000054f6a805a4c43cc1 Content-Type: text/plain; charset="UTF-8" On Sun, May 3, 2020 at 1:13 PM Henry Bent wrote: > This raises a question I've always had - what was the relationship between > DEC's compilers on MIPS/Alpha and the work the MIPS folks did? Early > versions of OSF/1 on both platforms have tools that are very, very similar > to the MIPS compiler suite - ugen, uopt, two-pass assembler, etc. - and > I've always been curious what the heritage was there. > I can answer that ;-) You need to understand/remember that the first OS that ran on Alpha was a port of the Ultrix/MIPS base. We debugged the hardware with Ultrix (not VMS). The key is that DEC had full rights to all the MIPS tools. So a quick redo of the MIPS/3000 backend was made to emit Alpha since GEM was not really ready yet and Ultrix was way more portable than VMS was. There was a big fight about if Ultrix/Alpha should ship or not, which as we know never happened as Tru64 was to be the new OS base (particularly since DC had taken Mica to Microsoft which became NT etc..). In practice, one of the big problems was that Tru64 was OSF/1 really in name and command system only. The Tru64 team kept rewriting large kernel subsystems under the rules of "this code is not 64-bit clean", or "it's immature, I need to rewrite I can't understand it", "We need better SCSI support," "the TTY driver sucks," *etc*. ... The idea of 'perfection' was very high on people's minds. As I have always said, every one of those choices could be argued as the correct one technically and in the small, but when you integrate against the whole, Tru64 was 3 years late (and DEC had not revenue because other than a little bit of business in system refresh, few people wanted to buy new Vaxen or MIPS boxes -- they went to Sun). So it was actually a bad idea. They should have shipped OSF/1-Alpha as is and then tweaked it to become Tru64 over time. Or they could have shipped the early OSF/1 for Alpha and MIPS together as a stepping stone - the later did actually Shipp under a special license to a few research sites but was never productive. I don't think the former ever left the building. Anyway back to compilers, Tru64 had a 'good enough' compiler based on the MIPS code base to get us all going, but GEM's primary target was VMS since one of the important features of GEM was the VAX->Alpha transpiler technology. VMS was still heavily written in VAX Assembler at the time. Plus, It actually was a little hairy because GEM had a new C/C++ front-end. So TLE's high order bit was VMS for the Alphas. GEM for Tru64 was about 18 months later. This was also a mixed blessing -- one thing was GEM caught a huge number of 64-bit-ism (God Bless Judy Ward's error detection code). Most large ISV's were having big issues with 32-bit dirty code and in particular the ILP32 assumption (all 64-bit UNIX's use the LP64 model). At that point, there were absolutely no tools in the market to help people move to the new 64-bit world. So until the GEM compiler showed up, ISVs were pretty slow in getting their code cleaned. The funny part of all that work is that DEC basically paid the big ISVs (read Oracle et al) to make their code work on later generations of MIP, SUN, and INTEL*64. I know of a number of ISV's that discovered after the Tru64/Alpha port, their bug rate dropped and a whole ton of bugs in the basic codebase had been eliminated. As an aside, to do this day, if I am given an old piece of C or C++ that I want to run on a modern system (like I was a couple of weeks ago to read some old tapes), I fire up my Alpha and feed the sources to Judy'd front-end and listen very carefully to her warnings -- if the GEM Tru64 compiler can accept it without warnings, I have never had a case where the code did not 'just work' when I recompiled for my Mac when I brought it back. --00000000000054f6a805a4c43cc1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, May 3, 2020 at 1:13 = PM Henry Bent <henry.r.bent@gm= ail.com> wrote:
This raises a question I've al= ways had - what was the relationship between DEC's compilers on MIPS/Al= pha and the work the MIPS folks did?=C2=A0 Early versions of OSF/1 on both = platforms have tools that are very, very similar to the MIPS compiler suite= - ugen, uopt, two-pass assembler, etc. - and I've always been curious = what the heritage was there.
I can answer = that ;-)

You need to underst= and/remember that the first OS that ran on Alpha was a port of the Ultrix/M= IPS base.=C2=A0 We debugged the hardware with Ultrix (not VMS).=C2=A0 =C2= =A0The key is that DEC had full rights to all the MIPS tools.=C2=A0 =C2=A0S= o a quick redo of the MIPS/3000 backend was made to emit Alpha since GEM wa= s not really ready yet and Ultrix was way more portable than VMS was.

There was a big fight about if Ultrix/Alpha should= ship or not, which as we know never happened=C2=A0as Tru64 was to be the n= ew OS base (particularly since DC had taken Mica to Microsoft which became = NT etc..).=C2=A0 In practice, one of the big=C2=A0problems was that Tru64 w= as OSF/1 really in name and command system only.=C2=A0 =C2=A0The Tru64 team= kept rewriting large kernel subsystems under the rules of "this code = is not 64-bit clean", or "it's immature, I need to rewrite I = can't understand it", "We need better SCSI support," &qu= ot;the TTY driver sucks," etc. ...

The ide= a of 'perfection' was very high on people's minds.=C2=A0 =C2=A0= As I have always said, every one of those choices could be argued as the co= rrect one technically and in the small, but when you integrate against the = whole, Tru64 was 3 years late (and DEC had not revenue because other than a= little bit of business in system refresh, few people wanted to buy new Vax= en or MIPS boxes -- they went to Sun).=C2=A0 So it was actually a bad idea.= =C2=A0 They should have shipped OSF/1-Alpha as is and then tweaked it to be= come Tru64 over time.=C2=A0 Or they could have shipped the early OSF/1 for = Alpha and MIPS together as a stepping stone - the later did actually Shipp = under a special license to a few research sites but was never productive.= =C2=A0 I don't think the former ever left the building.

Anyway back to compilers, Tru64 had a 'good enough' compiler = based on the MIPS code base to get us all going, but GEM's primary targ= et was VMS since one of the important features of GEM was the VAX->Alpha= transpiler technology.=C2=A0 =C2=A0VMS was still heavily written in VAX As= sembler at the time.=C2=A0 Plus, It actually was a little hairy because GEM= had a new C/C++ front-end.=C2=A0 =C2=A0So TLE's high order bit was VMS= for the Alphas.=C2=A0 =C2=A0GEM for Tru64 was about 18 months later.=C2=A0=

This was also a mixed blessing -- one thing was GEM c= aught a huge number of 64-bit-ism (God Bless Judy Ward's error detectio= n code).=C2=A0 =C2=A0Most large ISV's=C2=A0were having big issues with = 32-bit dirty code and in particular the ILP32 assumption (all 64-bit UNIX&#= 39;s use the LP64 model).=C2=A0 At that point, there were absolutely no too= ls in the market to help people move to the new 64-bit world.=C2=A0 So unti= l the GEM compiler showed up, ISVs were pretty slow in getting their code c= leaned.=C2=A0 The funny part of all that work is that DEC basically paid th= e big ISVs (read Oracle et al) to make their code work on later generations= of MIP, SUN, and INTEL*64.=C2=A0 =C2=A0I know of a number of ISV's tha= t discovered after the Tru64/Alpha port, their bug rate dropped and a whole= ton of bugs in the basic codebase had been eliminated.=C2=A0 As an aside, = to do this day, if I am given an old piece of C or C++ that I want to run o= n a modern system (like I was a couple of weeks ago to read some old tapes)= , I fire up my Alpha and feed the sources to Judy'd front-end and liste= n very carefully to her warnings -- if the GEM Tru64 compiler can accept it= without warnings, I have never had a case where the code did not 'just= work' when I recompiled for my Mac when I brought it back.
=
--00000000000054f6a805a4c43cc1--