[TUHS] SDB debugger

[Clem Cole]

On Sun, May 3, 2020 at 1:13 PM Henry Bent <henry.r.bent at gmail.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200503/7cbb4c31/attachment.htm>