Only slightly less known is Knuth's series of books The Art of Computer Programming (TAOCP). Planned as a seven-volume set, the first three volumes were published in the 1970s and were considered "required reading" by most everyone studying computer science. In college, I was especially taken with Knuth's use of an invented computer architecture called MIX, as it was a mixture of several well-known (at the time) architectures, and like some other college students of the era, I wrote an extended MIX interpreter, (mine was in IBM System\370 Assembler in two boxes of punch cards), that I oh-so-cleverly called XIM.

My XIM implemented not only the standard MIX instruction set, but also added all of the architectural extensions Knuth described in the volumes, such as floating point and I/O. In the mid-70s, I wrote Knuth a letter describing XIM and asking, as an aside, when we might expect to see volume 4 published. I received a thoughtful and courteous reply, saying, essentially, not to hold my breath! Sadly, my only copy of XIM perished in an apartment fire.

Knuth since has rewritten and revised TAOCP volumes 1-3 multiple times, trying to keep it relevant for the times. (Algorithms for efficient sorting of data stored on magnetic tapes are probably not as useful as they once were.) What I missed, though, was the start, in 2005, of the publication of parts of TAOCP Volume 4! Still a work in progress, Knuth has published "Fascicles", sets of chapters from the book. Fascicles 1-4 are out, and Fascicle 0 has just been released.

What? Oh, yeah. The interview. Knuth has been an advocate of what he calls Literate Programming, which if I understand it correctly, has one write programs that are designed to be read by humans so that they can understand what the program is supposed to do. I'm all in favor of this, as a long time advocate of writing understandable code and letting the compiler handle the optimization.

Knuth also expressed disdain for "unit tests", saying "lots of time is wasted on activities that I simply never need to perform or even think about. Nothing needs to be 'mocked up.'" He also takes CPU manufacturers to task for moving to multicore:

... it looks more or less like the hardware designers have run out of ideas, and that they’re trying to pass the blame for the future demise of Moore’s Law to the software writers by giving us machines that work faster only on a few key benchmarks! I won’t be surprised at all if the whole multithreading idea turns out to be a flop, worse than the [Itanium] approach that was supposed to be so terrific—until it turned out that the wished-for compilers were basically impossible to write.
...
I know that important applications for parallelism exist—rendering graphics, breaking codes, scanning images, simulating physical and biological processes, etc. But all these applications require dedicated code and special-purpose techniques, which will need to be changed substantially every few years.

Well, some at Intel would take issue with that! It is certainly true that multithreading requires a different way of approaching algorithms, and there's a lot of progress in making threading easier, but there's lots more work to do.

Knuth has also revised the 1960s-era MIX, creating MMIX, a more modern 64-bit architecture.

Finally, I note that Knuth still plans to complete the seven-volume set of TAOCP. I'll look forward to that!

I greatly admired Dick for his brilliance, his keen sense of what it meant to design things right, and for his wicked sense of humor. Dick was famous for his elaborate pranks, including the SD730 Fixed Head Solar Horologue, a sundial with a photocell that detected noon, connected by a parallel port to the VAX-11/730 which lacked a time-of-day clock. This also inspired Dick's choice of microfortnights as the unit for the VMS SYSGEN parameter TIMEPROMPTWAIT.

As a young software engineer at DEC in the late 70s and early 80s, I looked up to Dick as a shining example of what I aspired to be. Dick believed in architecture, designing and thinking things through before building, and he was great at getting cooperation and extra effort out of the VMS team. I like to think that a little of him rubbed off on me.

Tragically, Dick suffered severe brain injury in 1984 when his car was struck in an auto accident. I visited him a couple of times afterward, at the home he shared with his wife (and DEC engineer) Audrey Reith. His son Marc wrote a memorial post which provides some more information about Dick and his life.

Rest in peace, Dick. And farewell. I'm privileged to have known you.

One certainly can write clear and understandable code in Fortran, and many do. I see a lot of code from different people cross my desk each day, and I've learned to recognize certain "idioms" in Fortran code which are there to help make the code easier to understand. Meaningful variable names, use of mixed-case and free-format source, etc. Sometimes, though, a helpful coding practice can bite you. Here's one I ran across the other day...

One of the big strengths of modern Fortran is its wealth of array-oriented features. Few languages offer the whole-array and array slice operations that Fortran does, and often you can do an array operation without a traditional DO loop. For example, you can add two arrays with:

A = B + C

You can even have functions that return arrays (explicit interface required!), which freaks out some who grew up on FORTRAN 77 or even FORTRAN IV. Some programmers, though, like to remind readers that an array is an array, so they'll write code that looks like this:

A(:) = func(B(:), C(:))

with the (:) alerting the reader that the variable is an array (sort of like the Dave Barry joke that an apostrophe serves to warn you that the letter "s" is coming up in grocery store signs.) In Fortran syntax, (:) indicates an array section that starts at the first element and ends at the last element - the whole array, in other words.

Whenever I see this usage, I cringe, because I know that the compiler has to work extra hard to recognize that the programmer really meant "the whole array" and not a piece of it. In the past, unnecessary use of (:) would often prevent optimizations. Nowadays this is less often the case, thanks to hard work by the compiler developers, but sometimes it still happens. Still, most of the time, the (:) is "harmless" in that it does not change the overall meaning of the program, since an array section is "definable" (can be stored into), as long as you don't use a vector subscript such as A([1,3,5,7]).

In the recent case, the customer had written something like:

A(:) = func(B)

where A was an ALLOCATABLE array and function "func" returned an array. In Fortran 90 and 95, the language required that A already be allocated and have the same shape (dimensions) as the function return value.

Fortran 2003, however, added a new twist. In F2003, if the allocatable array on the left of the assignment is not currently allocated with a shape matching the right-side, it is automatically deallocated (if needed) and then allocated with the correct shape. This can make code a lot cleaner as you don't have to worry about knowing the shape in advance.

The downside, though, is that the checking required to support this is a lot of extra code, and applications where it is known that the array is already allocated to the correct shape don't need this check which would just slow them down. This is why Intel Fortran does not support this F2003 feature by default - you have to ask for it with the option /assume:realloc_lhs, or for Linux and Mac users, -assume realloc_lhs. ("lhs" here means "left hand side".)

The programmer who wrote the above code had in fact used this feature and depended on it, with array A starting out unallocated. He was therefore surprised to find that his program, when it got to the above assignment, complained that array bounds were violated!

It turned out that it was the use of the "helpful" (:) that caused the problem. This changed the meaning of the left-hand-side from an "allocatable variable" to an array section, and as such, it did not qualify for automatic reallocation. Consider, for example, if the code had read:

A(2:5) = func(B)

you could not reallocate some elements of an array section!

The solution in this case was to remove the superfluous (:), in which case the program ran as expected. On my advice, the customer also removed unnecessary (:) in other places as they could impede optimization.

So, Doctor Fortran's advice if you put (:) on your arrays? Don't do that!

Got any other examples of Fortran coding practices that can hurt you?

For computer geeks of a certain age, such as yours truly, it was an opportunity to relive the glorious past when Dennis Jerz announced that an early 1977 version of Will Crowther's Adventure game source code had been discovered. Adventure was one of the first puzzle-exploration games and it not only captured the imagination of computer users worldwide when it became more widespread in 1978, but it inspired many future games such as the popular Zork and even many of today's graphics-heavy computer games. Not bad for a text-only game written in Fortran. Right, Fortran.

A HOLLOW VOICE SAYS 'PLUGH'

Crowther's game was inspired by Mammoth Caves, a real-life cave system in Kentucky. In the game, you explore the cave and give one or two word commands to move or perform actions. As you go, you collect items that may or may not be useful in other parts of the game, and often there is a sequence you need to follow in order to complete a task. Don Woods expanded the game and the version most well known was released in 1978.

I first encountered Adventure soon after I joined the VAX Fortran compiler project in 1978, as it had been released on a DECUS (Digital Equipment Computer Users Society) library tape and made its way into the compiler's test system, where a script had it play a perfect game. (Factoid: Another game in the VAX Fortran test system was a program that played Scrabble against a human opponent. When the VAX-11/730, a low-cost model, was being tested in 1980, we were puzzled to find that the 730 played a different game than the previous 750 and 780 models did. It turned out that the program had a 30-second limit to its search for the optimal play, and the 730 was enough slower that it exceeded this on certain plays, leading it to choose a different word.)

Like many others, I spent many hours exploring the game and drawing up a "map" of the various rooms with notes as to what commands were valid and what to do in each room. Many of the game's phrases and "magic words" became part of the programmer's vernacular in the following years.

I found it interesting to compare the "original" version of the code with the one I knew. For example, the original did have the set of eight connected rooms all of which described themselves as "You are in a maze of twisty little passages, all alike", but lacked the additional set of the newer version which were variously "You are in a twisty maze of little passages, all different", "You are in a maze of little twisty passages, all different", etc. (This inspired my usual description of Linux as "A maze of twisty little distros, all different.")

NOTHING HAPPENS

It was amusing to see the Slashdot crowd examine the Fortran code and try to make sense of constructs many had never before seen, such as computed GOTO and arithmetic IF, not to mention such oddities (and extensions) as comparing a REAL variable to a five-character string (Crowther developed the code on the 36-bit DEC PDP-10 which had 6-bit characters, uppercase only).

If you're interested in learning more, or want to play the game yourself, explore Rick Adams' Colossal Cave Adventure Page. For building with Intel Fortran, the "Adventure 6" version can be used. Turn off array bounds checking and note that the ADVSETUP program needs to be built and run once before running the game. Happy spelunking!

So it was with some amusement that I ran across an article on the Computerworld web site titled The top 10 dead (or dying) computer skills. Fortran was not on the list, though COBOL and C were. (I'll choose to ignore the possibility that the author wasn't even aware of Fortran...)

This sort of list always brings out emotions in people, and this one was no exception, looking at the comments. The inclusion of C on the list upset many, but the article's point was that if you know only C and not C++, you'll fall behind in the job market, and I think that is true.

My take on this is that one is served best by not focusing too narrowly on one particular technology, no matter what it is. In the case of programming languages, more is always better. You may not be actively using more than a couple of languages at a time, but being familiar with diverse languages can help expand your thinking and lead to better code. I think I've learned some two-dozen programming languages over my career. I could not write a valid program in many of them today, but I could probably read most (APL perhaps excepted).

The old adage, "When the only tool you have is a hammer, everything looks like a nail" applies to programming. There is not one single programming language that is best for all applications. Take the time to learn a few different languages, including scripting and object-oriented languages, and pick the one that is best suited to your application (keeping in mind issues such as who's going to maintain it, company policies and the like - just because you know Python that doesn't necessarily make it appropriate for your company's payroll application.)

I met Jean, briefly, back in 1984 when I was working on DEC's VAX Ada compiler project. In March of 1984 I had the delightful task of traveling to Versilles, France, to deliver to Ichbiah's company Alsys a magtape containing the first beta test version of VAX Ada. I spent a week with the Alsys team helping them shake out the compiler, which went on to be one of the most highly regarded implementations of the language. My main assignment from 1983 through 1988 was project leader for VAXELN Ada, a variant which ran on VAX systems under the real-time and embedded OS VAXELN, created by Dave Cutler just before he left DEC for Microsoft. In August 1988 I then joined the VAX Fortran compiler team.

Ada was an elegant and full-featured language with extremely expressive declaration features, multitasking, exception handling, a module facility with intelligent separate compilation and much more. The language gave the programmer the ability to tell the compiler what was allowed and not allowed to happen in the program and this enabled the compiler to do checking at a level rarely seen in other languages. I liked to say that if you could get an Ada program to compile, it would probably run correctly the first time. This, of course, was one of the things that the DoD wanted.

The DoD mandate that Ada must be used in defense contracts was both a blessing and a curse for Ada. A blessing in that it jumpstarted the widespread use of the language, but a curse in that many developers were dragged kicking and screaming into the world of Ada and non-defense programmers often avoided Ada specifically because of the DoD connection. After ten years, the screaming became loud enough that the DoD dropped the Ada mandate, and Ada use pretty much dropped out of sight. The orignal Ada 83 language was updated to Ada 88 and again in 1995, but DEC and most other vendors did not update their implementations.

What's the relevance of Ada to Fortran? Some of the major Fortran 90 features, such as modules and generics, are derived at least in part from Ada. Fortran's separate compilation model made it difficult to implement one of Ada's most elegant module features, IS SEPARATE, which permitted the implementation of a module procedure to be compiled separately from its declaration. The "submodules" proposal for Fortran 2008 finally brings that to the language.

So what's my second favorite language? SNOBOL.

This is the third Supercomputing conference I have attended, and I am astonished and surprised each year at the wide variety of exhibitors showing off hardware, software, services and projects, all in the "high performance computing" space. In what seems to be an amazing instance of Kismet, the booths of Intel and AMD, usually far apart on the show floor, are directly across from one another this year. But I digress...

What struck me, as I wandered the show floor, is that Fortran, a fifty-year-old language considered long-dead by many, has a customer base vibrant enough to support (at least) seven commercial vendors offering compilers on the same platforms, plus two (why two?) competing open source compiler projects! What other widely-adopted programming language can say the same? Some dinosaur, eh?

I'm currently reading Andy Grove: The Life and Times of an American, by Richard S. Tedlow. Grove, as many of you know, is one of the three founders of Intel and was CEO during Intel's most explosive growth in the 1990s. I didn't know too much about Grove, a Hungarian Jew who made his way to the US in the 1950s, but Tedlow tells the story well, other than the worshipful attitude of Tedlow towards Grove getting on my nerves at times.

So imagine my delight when I came across the following on page 86, as Tedlow is relating Grove's first few weeks working for Gordon Moore at Fairchild Semiconductor in 1963, sometimes quoting Grove:

Somewhere, during the course of his education, Grove had learned computer programming. This knowledge served him in good stead. He analyzed data on a batch-processing computer service that allowed him to create the "representation of that closed-form solution." [A problem Grove had been assigned to solve.] "[V]ery few people," said Grove, "knew how to program in Fortran in 1963 at a Silicon Valley commercial company."

See? Intel and Fortran go waaay back!

Also meeting this week is the Fortran standards committee. (They meet in sunny Las Vegas, but way off "the Strip".) I'll have to ask Stan Whitlock, our representative, what new things have been added to the next standard currently known as Fortran 2008. There's already a lot on the plate, and this is before a single full Fortran 2003 implementation exists. (F2003 is massive enough.) I'll talk about F2003 and F2008 in a later post.

(I've been warned that my blogs don't have enough arbitrary links - this should hold 'em for a while.)

Similarly, in Fortran (I'll bet you were wondering when I'd get to that), something can be so near yet seem so far away. A short time ago, I was writing a new module for Intel Visual Fortran to provide declarations for the Win32 Process Status API. This would contain declarations of types and constants as well as interface blocks for the API routines, some of which take arguments of the new type. The natural inclination is to write something like this:

MODULE psapi
TYPE sometype
some component
END TYPE sometype

INTERFACE
FUNCTION newroutine (arg)
INTEGER :: newroutine
TYPE (sometype) :: arg
END FUNCTION newroutine
END INTERFACE

END MODULE psapi

If you did and compiled it, you'd get an error that type sometype is undefined in the declaration of arg. "What? It's not undeclared, I can see it right above in the same module!" Well, yes and no. Yes, it's declared in the module and could be used anywhere in the module, except.. Except in interface blocks!

The problem is that interface blocks are a "window into the external routine" - they essentially duplicate the declarations you would see in the actual external routine, assuming that routine were written in Fortran. As such, they do not "host associate" any symbols from the enclosing scoping unit (the module in this case.)

In Fortran 90 and Fortran 95, the typical solution for this was to create a separate module, say, "psapi_types", containing all of the types and constants to be used, You'd then add a USE statement inside each function, just as you would have to in the hypothetical external routine written in Fortran. (If it were written in Fortran, the Doctor would slap your wrist with a wet punchcard and tell you to make the routine a module procedure, and then you wouldn't need to worry about this nonsense.) So you would end up with something like this:

MODULE psapi
USE psapi_types ! This is for the benefit of users of module psapi
INTERFACE
FUNCTION newroutine (arg)
USE psapi_types
INTEGER :: newroutine
TYPE (sometype) :: arg
...

Those of you who use Intel Visual Fortran know that in fact there's a giant module IFWINTY for this purpose, containing all of the types and constants for the other Win32 APIs. It's messy and inelegant, but that's what you have to do. Until now...

Fortran 2003 attempts to restore some elegance to this sorry situation, but to preserve compatibility with older sources, it couldn't just declare that interface blocks participate in host association. Instead, a new statement was created, IMPORT. IMPORT is allowed to appear in interface blocks only and it tells the compiler to import names visible in the host scope.

IMPORT is placed following any USE statements but before any IMPLICIT statements in an interface body (the FUNCTION or SUBROUTINE declaration). IMPORT can have an optional import-name-list, much like USE. Without one, all entities accessible in the host become visible inside the interface body. With a list, only the named entities are visible.

With IMPORT, my PSAPI module can look like the first example with the following change:

...
FUNCTION newroutine (arg)
IMPORT
INTEGER :: newroutine
TYPE(sometype) :: arg
...

I could, if I wanted to, use:

IMPORT :: sometype

to say that I wanted only that one name imported. Nice and neat and all in one module!

"But why are you telling me this?", you might ask, "That's a Fortran 2003 feature and Intel Fortran doesn't yet do all of Fortran 2003." True enough, but we keep adding more and more F2003 features to the compiler and IMPORT made it in back in August! So if you are keeping reasonbly current, you can now IMPORT to your heart's content and do away with the mess of a separate module for your types and constants.

If you want to know what other F2003 goodies are available to you, just check the Release Notes for each update. A full list of supported F2003 features is in each issue. Collect 'em all!

Stan Whitlock, now he IS the Intel Fortran project manager, as well as our Fortran standards committee representative. He joined the DEC FORTRAN-10 (for the PDP-10) engineering team in 1976. Stan later worked on Fortran for the DECsystem 20, VAX APL, and then rejoined the DEC Fortran team when the short-lived MIPS-based DECstation line was introduced. He's led the Fortran team ever since, through the years of Alpha, Digital Visual Fortran and now Intel Fortran. But wait, there's more...

Dave Eklund joined DEC in 1975 doing support for DEC FORTRAN-10, but support also meant bug fixing and eventually development. He stayed with the DEC 36-bit systems and then joined Stan on DEC Fortran, so he's been doing Fortran continuously for 31 years now.

And then there's Rich Grove. Rich started with DEC back in 1971 on PDP-11 Fortran. Rich was later the project leader for VAX-11 FORTRAN-IV-PLUS, to give it it's full name, and he interviewed me for the job I eventually landed on the VAX Fortran project. Rich later became the project leader for DEC's GEM code generator and optimizer, which powered the DEC compilers for MIPS, Alpha and IA-32 (with Digital Visual Fortran.). When Rich joined Intel, he was named an "Intel Fellow", an extremely senior position in the company, with the role of "Compiler Architect". While Rich doesn't work daily on Fortran, he sits just a couple of offices down from us and keeps Fortran in mind as he helps shape the future of Intel compilers. (Edit: Rich retired from Intel in 2007, after a long and illustrious career.  We had a wonderful dinner in honor of Rich, attended by many who had worked with him in the past.  Rich is now enjoying his grandchildren and still drops by from time to time to say hello.)

I should also mention Peter Karam, another Fortran compiler developer who has been with the project since he started in 1980. Peter tried being a manager for a while, but soon found that his heart was in development so that's where he returned and what he does today.

As you can see, there's a core of dedicated engineers who have guided a set of Fortran implementations for more than three and a half decades, starting with DEC, through the couple of years of Compaq, and now Intel. (We missed HP, which bought Compaq shortly after we joined Intel, which was a bit more than five years ago.) Of course, there's more to the project than just these folks, including many developers who have worked on compilers for 20 years or more (and some young whippersnappers, too.)

I once told a group of customers about our long Fortran heritage and that we were "a bunch of old farts". One of the group replied, "That's good - Fortran needs old farts."

P.S. Doctor Fortran now has his own URL. You can find the doctor at http://www.intel.com/software/drfortran I'll be posting more regularly in the future.