October 2, 1978 was a typical New England fall day. I walked into the entrance of what had once been a Caldor department store in Tewksbury, Massachusetts. This converted shopping center was the just-opened software development outpost of Digital Equipment Corporation, or DEC, and it was my first day of my new job there to be a developer on the VAX-11/VMS Run-Time Library. I announced myself to the security guard in the lobby and waited for my hiring manager to come out and escort me in. And waited. And waited. It turned out that they were waiting for another new hire who knew people there and had just walked in! Eventually I was rescued and brought inside.
Tacked up on a wall was a line-printer banner proclaiming "WELCOME TO ANDOVER STREET". You see, most of the people there had been previously working in DEC's home town of Maynard where buildings other than "The Mill" were named after the street they were on, such as "Parker Street". The idea was to make people feel that they were just on another Maynard street instead of some 20 miles to the north. This was the new home of the teams developing the VMS operating system, which had just delivered version 1.0 in August, as well as the "Technical Languages" group responsible for Fortran and the VMS debugger. The Run-Time Library (RTL) team was actually part of "Commercial Languages", based in a site DEC built in the woods of Merrimack, New Hampshire; however, as I was being assigned to work on Fortran my cubicle was in Tewksbury with that team. Initially I was told to work out of Merrimack for six weeks to meet the rest of the RTL team, so I spent some time there. (In later years, DEC closed the Merrimack site and it's now the local headquarters for Fidelity Investments.)
Since the RTL was a component of VMS and not sold separately the way the compilers were, I was a de-facto member of the VMS development group, and I got to know many members of that team quite well, including Dick Hustvedt (see also my tribute to Dick), Andy Goldstein, and, yes, Dave Cutler. My earliest assignments were to patch bugs in the RTL using assembler-style patching and my first patches went into VMS 1.01. For Fortran, I added the remaining FORTRAN 77 features to the RTL including NAMELIST and "OPEN on a connected unit", (one of my least favorite features of the language), as well as VMS-specific features such as indexed file support. I was also working on the language-independent library support (an amazing VMS feature I have not found in any other operating system), and got involved with the addition of extended-range floating point to the VAX architecture. A memorable event was a trip to the Smithsonian Astrophysical Observatory's facilities in Cambridge, MA, where the a VAX-11/780 was being modified (with technicians adding wires to the backplane with a wirewrap tool!) to support the new instructions.
In July of 1980 I moved, along with the VMS team, to DEC's shiny new Software Engineering site in Nashua, New Hampshire - the compiler teams would follow in September. A second building was added in 1982 and I moved there, where I would stay for another 28 years! (See Thirty Years of Zonker Kookies.) I designed and implemented the entirety of the Run-Time Library for the all-new VAX Pascal V2 (V1 had come from the University of Washington), and then in 1983 I was asked to lead a new project to bring Ada to Cutler's new Real Time and Embedded OS VAXELN. I spent five years on the Ada team, also working on the VMS run-time support for Ada and had the delightful experience of hand-carrying a magtape of VAX Ada to Versailles, France, where the Ada language's creator Jean Ichbiah had his company Alsys. I stayed with Alsys for a week while they tried out the new compiler (and I enjoyed delicious French meals!)
In 1988, after five years on Ada, I was looking for a change. I had an open offer to work for the VAXELN team in Maynard, (Cutler was no longer involved), but I really wanted to stay in Nashua and the VAX Fortran compiler team was glad to have me. For a while I was part of a sizable team working on the VAX compiler, but a side project was underway to build a Fortran 90 compiler based on a "front-end" we acquired from another company along with DEC's new "GEM" code generator. The two projects existed side-by-side for a while, and after a couple of years I was the whole of the VAX Fortran project, adding features such as recursion and pointers, while also starting to work on the DEC Fortran 90 compiler, specializing in its VMS features. (I once lamented that this was the third compiler for which I had added support for the DEC Source Code Analyzer, but each time I learned how to do it better!)
The 1990s were a tumultuous time for DEC. The new 64-bit Alpha processor was a technical hit, but that didn't lead to huge sales success for DEC (or DIGITAL as senior management wanted it to be known after they replaced founder Ken Olsen with Bob Palmer.) Soon, a never-ending round of layoffs shrank the company and darkened the mood of the employees remaining. Still, DEC Fortran was a bright spot and was highly regarded in the industry. We branched out a bit to create a Fortran product that ran on Windows NT on Alpha systems and this got us in the good graces of Microsoft, which was not terribly interested in their current PowerStation Fortran product. When we asked Microsoft about licensing Visual Studio for the Windows NT Alpha product, they offered instead to have us replace PowerStation with our own product. In 1997, DIGITAL Visual Fortran (DVF) for Windows (x86 and Alpha) was born, and nothing would be the same again.
With DVF, we were in an entirely new and unfamiliar market and we needed to learn and invent new processes, from packaging (the engineering team stuffed boxes!) to sales (retail?!) and support. There was initial roughness, with PowerStation fans holding our feet to the fire, but we ended up doing a very good job and quickly became a very popular option on Windows. The combination of our large feature set with robust Fortran 95 support, plus the excellent optimization of the GEM code generator was hard to beat. But DEC was still on a downward slide, and in 1999 Compaq bought the company in what many considered an ill-advised move. For us, very little changed other than renaming the products from DEC to Compaq, so there was now Compaq Visual Fortran (CVF) and a new color scheme to the boxes.
One weekend in June 2001, we got strange emails and phone calls from our supervisor, William Youngs. On Monday, we were told, everybody at the Nashua site would be told to report to the cafeteria for an important announcement - but not us. The Fortran team, along with selected other compiler developers, were told to go to the auditorium instead. We had no idea what this was about. What we learned there was that Compaq was selling off much of its Alpha-related development teams, including the Fortran team, to Intel. Intel! The company behind Itanium that had yet to ship. The arch-rival of AMD which had approached us earlier and asked that we enhance CVF for their processors (which we did, adding prefetch support.) Intel, whose Fortran compiler was routinely beaten in benchmarks by CVF. And so on August 16, 2001, we left Compaq and joined Intel, though we didn't actually move anywhere. Instead, our section of the Nashua site was walled off and we shared the rest of the building with Compaq. (And then just a couple of months later, HP bought Compaq. So, no, I never worked for HP.) Our immediate task was to combine our Fortran "front end" with Intel's code generator and optimizer replacing GEM. The Intel division manager who brought us in suggested it would take six months; three years later we shipped the first combined version, Intel Fortran 8.0.
Initially, I continued the compiler work I was doing and ramped up support of our Windows customers. As was typical at DEC, I wore many hats: developer, support, licensing, packaging, training and "evangelism" (to use a term that had become popular), but at Intel these functions tended to be handled by separate teams. After about six months, Intel managers Joe Wolf and Jon Khazam dropped in to my cube and asked if I'd consider joining Joe's compiler support team based in Hillsboro, Oregon. I wouldn't have to move and would just be focusing entirely on support, training and "evangelism", leaving development behind. After consideration and a visit to Hillsboro, I agreed and joined the compiler support team. I still sat in with the Fortran compiler developers but didn't completely abandon development; over the years I found ways to contribute to features such as Fortran 2015 C Interoperability, Fortran 2003 array reallocation and Windows API declarations.
Over the years we took what was now Intel Fortran to greater heights, building on the best technology from both companies, adding Linux and MacOS to the platforms, being on the leading edge of support for new Fortran standards, adding 64-bit support (again!) and enabling the new Intel Xeon Phi coprocessor line. Back at DEC we had started a user forum for Visual Fortran users and this was brought over to Intel, where at the time there were a bunch of mostly-abandoned forums for various processors. The Fortran forum user base was so large we split it into two and as other Intel software tools added their own forums what became Intel Developer Zone grew into a major attraction for users. Even today, the volume of the Fortran forums dwarfs that of every other forum at IDZ.
I joined the Fortran standards committee in 2008, just in time to help with some last-minute changes to Fortran 2008 (published in 2010.) For a while I would go to meetings only when Stan Whitlock, our primary representative, couldn't make it, but I then volunteered to become "International Representative" and started attending every meeting. This has been a fascinating development for me and I've been able to contribute to the of design new language features and help explain the standard to both developers and users through my "Doctor Fortran" blog. (For some background on that see The Real Doctors of Fortran.) We've now got almost all of Fortran 2008 implemented and are looking forward to Fortran 2015.
We stayed in the Nashua site until November 2010, when we moved to the renovated floor of an office building in Merrimack, New Hampshire, that had once had Fidelity offices in it! At the end of 2016, however, Intel is moving us again to its site in Hudson, Massachusetts. Yes, that's the old DEC site where Alpha processors were once manufactured. Intel continued to run the "fab" there for many years, but that side of it is now closed. There is however a lot of nice office space and some benefits that we don't have in Merrimack such as a cafeteria!
So why this trip down memory lane? It's because I've decided that, at the end of 2016, I'm going to retire, after more than 38 years in the Fortran business. It was a difficult decision - I love the work I do and the people I work with - both inside and outside Intel - but I had been thinking about this for a while and it just felt like the right thing to do. I want to emphasize that Intel very much wanted me to stay, but I'm comfortable with my choice.
Though I spent a lot of text above on my DEC days, Intel has been very good to me and I've gotten to know many talented people here. I like to tell the story of how, shortly after I joined Intel I was sent to observe a survey group of Boston software developers. The moderator announced that they were going to discuss "Intel software", at which point one guy exclaimed, "Intel? They don't make software!" How times have changed! Intel software, not just the compilers, is now highly regarded and widely used. Fortran is a big part of Intel's software success, and they know it. The compiler team here has been growing in recent years, and is still hiring! While I'm leaving, Intel's compiler support team is strong,with many talented and dedicated engineers around the world. If you're one of our customers, you will be in good hands.
When I was mentally composing this piece, I wanted to write about what was the biggest change I had seen over 38 years. At first I thought about software complexity; how in the past it was common for a single developer to be responsible for an entire product or large component but that's extremely rare today. But one day I looked around me at a Fortran team meeting and I realized that almost half the developers in the room were women - remarkable! In 1978, women were very rare in software engineering. Females were not entirely absent - I remember working with Nancy Kronenberg, Kathy Morse, Ruth Goldenberg and Audrey Reith on VAX and VMS - but it was then mostly a sea of white males.
Today, technology companies are being pushed to hire and retain more senior women and "underrepresented minorities". Intel has made major commitments in this regard and I see a lot of forward motion. Perhaps it is true that Intel as a whole has a lot of catching up to do here, but the Intel Fortran team has always had a sizable number of women developers and, with recent hires of several bright, young women, going into 2017 the team will be more than half female! It's not just Fortran - all around me I see women in leading technical roles, and I'm delighted.
So, what does the future hold for me? I will be taking a break from everything Fortran, but I won't stay away for long and eventually will be back in the user forum under my personal account. I will, very reluctantly, have to give up my active participation in Fortran standards, but maybe I'll find another way to contribute there. I'd like to continue to write Doctor Fortran posts. I'll certainly miss the great people I work with, not only here in New Hampshire but at Intel sites around the globe, many of whom I've had the pleasure of meeting in person over the years. Other than that, I really don't know. Travel more, maybe get more involved in the local community, maybe find some consulting work to keep my mind active.
It's been fun - really it has. I'm especially grateful for the fifteen additional career years I almost certainly would not have had if Intel had not "rescued" me and my colleagues back in 2001. Time to see what's next.
For more complete information about compiler optimizations, see our Optimization Notice.