Re: [TUHS] SDB debugger

On Sun, May 3, 2020 at 1:13 PM Henry Bent <henry.r.bent(a)gmail.com> wrote: 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.