The Status of FORTRAN

By Chuck Bouldin, Washington, DC

Status of FORTRAN on the Macintosh

Until recently there has been a noticeable shortage of Fortran compilers for the Macintosh (translation: there has only been one Fortran compiler). This situation has changed enough that it is worthwhile to look over the available compilers and see what each has to offer. With the advent of the Mac II and Apple’s new emphasis on “Desktop Engineering” there is now enough interest and cpu horsepower to transform the Mac into a serious “platform” for scientific and engineering applications. Finally, the Mac II is being treated by Apple and others as a serious low-cost alternative to more expensive workstations, so the availability of industrial strength Fortran compilers is an obvious requirement.

What’s Available

At this writing, there are three Macintosh Fortran compiler vendors; Absoft, with a 68000 Fortran for the Mac+ and SE and a 68020 version for the Mac II and Mac’s with accelerator cards. DCM has a Fortran with both 68000 and 68020 code generation, so it is suitable for both Mac+ and SE, as well as the Mac II. A third vendor, Language Systems, has just released a Fortran compiler that runs under MPW. Absoft is also in beta-test with a new Fortran ( Risc Architecture Technology, or “RAT”) that runs under Apple Unix and with MPW. The RAT compiler augments, but does not replace the existing MacFortran compiler, as it requires a 68020 and 68881. All of this products include inline hardware floating point code generation, a crucial factor for fast floating point calculations.

A Variety of Approaches

The compilers available (or soon available) for the Mac show a variety of different approaches to providing an “environment” for Fortran on the Mac. Each approach carries with it some inherent strengths and weaknesses. I want to go over these carefully before getting into comparisons of code size, execution speed, etc, since it is these differences in approach, not things like compile speed or code size that are frequently the limitation in the overall productivity of a programmer. There are inevitably subjective decisions in comparing these approaches, and I will make some. However, I will also try to be clear about why I make those decisions so that you can decide which of these products is most suited to your needs.

DCM Fortran

This is the only true “integrated” environment in the bunch. With this product you have an environment in which you can edit, compile, link, symbolically debug and run programs. The editor is about on a par with the MDS “Edit”, but isn’t nearly as high powered as, for example, Qued/M. The environment can be run under Multi-Finder, so if you want to use tools such as other editors or text utilities you can make them work reasonably well with this compiler. As with Absoft Fortran, this compiler allows both code and data to be larger than 32K in size. There are a number of extensions to ANSI Fortran, mostly improved flow control with SELECT CASE and other constructs.

The classic dilemma of an integrated environment is that if you don’t like the setup as the vendor provides it, then it is usually difficult to modify. I find this environment marginally acceptable, as the editor seems under-powered compared to stand-alone alternatives and there are also minor problems with the Mac interface. For example, during compiles the cursor is not consistently maintained with the watch icon, so the user has no visual feedback that anything is happening. Worse, the edit windows do not have zoom boxes. Finally, this compiler has the ultimate “dumb” linker. A link simply appends the 155K runtime package to your compiled code. So the minimum size for any program is about 156K! You don’t have to link in the runtime library, as it can be auto-linked at execution, but the size of this runtime package will be a real detriment to anyone seeking to write applications to distribute.

Absoft MacFortran

This compiler is now in beta-test in the 2.4 version. This is much improved over the 2.3 release, with a number of bug fixes and a much better Mac interface. The compiler can now be configured so that your choice of text editor, as well as the Fortran linker, Debugger, Scriptbuilder, etc, can be “sub-launched” from the compiler. This does a lot to speed up transfers between the pieces of the programming environment, and also allows the programmer flexibility in choosing those pieces, such as specifying your favorite text editor. A script-builder utility similar to the MPW Commando is now provided to tame the atrocious command line interface which was the only way to run the Linker in the 2.3 version. In addition, Scriptbuilder can be used to construct a list of files for doing multiple compilations without operator intervention. The runtime library and user pre-compiled subroutines can be automatically linked at execution, so during development it is almost never necessary to use the linker. As with DCM Fortran, linking the runtime library to your code just copies in the entire library, but in this case you only have to carry around 12K for the runtime package. There are extensions to ANSI Fortran that are similar to those in DCM Fortran. Also in common with DCM, Absoft Fortran has no restrictions on code or data sizes, other than available memory.

This compiler has developed a bad reputation for bugginess. The 2.4 beta release fixes a number of these, and Absoft has taken steps to improve feedback from users by establishing a dial-in bulletin board that users can access to obtain information, fixes and to report bugs. Along with the clean up of bugs and improvement in the Mac interface in the 2.4 version, this compiler appears to be much improved. The compiler does not correctly support the Fortran ENTRY statement, but as far as I know, this is the only deviation from the ANSI standard for Fortran.

Language Systems Fortran

This is a Fortran that runs under MPW. This brings with it all the power and tools of MPW, such as cross-linking with C and Pascal, support for MacApp and (Someday! Are you listening, Apple?) the common symbolic debugger that will work with all these tools. This is definitely a power environment for serious Fortran development work, but it also implies that you carry around the baggage of MPW whether you want it or not. In practice, you actually need to learn very little about MPW to get started. Once script files to compile and link your programs are developed, the MPW environment for Fortran is reasonably “Mac-like”. There is a Commando interface for the compiler, so it is easy to get started. Language systems also provides calls to Mac Toolbox routines as inline constructs rather than through a “pointer” subroutine, as in DCM and Absoft Fortran. Finally, this is the only compiler that supports Structures and Records, so that complicated data constructs are handled by the compiler, rather than arduously mapped onto arrays by the programmer. This is an important consideration for accessing the Mac Toolbox since this always requires data structures, some of which are complex. This compiler supports 68020 and 68881 code generation. Because of Apple’s decisions the MPW compiler is stuck with the 32K segment limit on code, although they allow data to exceed 32K in size.

Absoft RAT Compiler

This is a new Fortran that runs under MPW. The interesting thing about this compiler, which is still in early beta testing, is that the compiler does some optimizations that are usually associated with RISC (reduced instruction set chip) microprocessors. The compiler requires both a 68020 and 68881. The compiler treats the register pool of both processors as one set of registers, and the contents of these registers are allocated dynamically with a score-boarding technique. What this means is best illustrated by an example. A compiler will ordinarily choose, automatically or under programmer control (as with the Register keyword in C), certain variables that are kept in cpu registers. This optimization is done on a module-wide basis. That is, registers allocations are constant over the execution of a subroutine. This is fine until you run out of registers. For example, if a compiler has three registers left to allocate when it compiles a code structure of three nested DO loops, then the loop counters may be put into registers. However, if the compiler now encounters another set of triply-nested DO loops farther along in the same subroutine, it is usually impossible for those counter variables to go into registers. The departure that the RAT compiler takes is that registers contents are optimized on a line-by-line rather than subroutine-wide basis. In the above example, the first three loop counter variables could go into registers and then be flushed out and replaced with the next set of three loop counters. This register score-boarding method should help most in code that is large and complicated, with lots of variables, which where a traditional compiler will run out of registers variables to statically allocate.

As in Language Systems Fortran there is a Commando interface for the compiler and calls to Mac Toolbox routines are inline calls. However, there are no Structure or Record data types, so one must still use array declarations and equivalence statements to pass arguments to Toolbox routines. Also, the RAT compiler will not be available until Apple releases MPW 3.0, as Absoft is waiting for Apple to provide a fix for the 32K data segment limit, rather than coding around Apple’s mistake as Language Systems was forced into.

Benchmarks

With Fortran, there are a number of quasi-standard benchmarks that have been run on almost all machines. These are not Mac specific, so they do not test the ability of the compilers to provide support for the Macintosh environment, but they do have the advantage that they have been run on many other machines, allowing broader comparisons to be made. I chose to evaluate these compilers with the three most common tests: the Sieve of Eratosthenes, the “Whetstone”, and the double-precision Linpack. These tests emphasize, respectively, integer operations and addressing of small arrays (Sieve), floating point operations and transcendental function evaluation (Whetstone) and solution of linear equations, double-precision floating point arithmetic and addressing of large arrays (Linpack). In addition I kept track of compile times and code sizes of these three programs.

All compilers were run with options set to maximize compile and execution speed. All compilations were done with INTEGER*4 as the default storage class, and I took no pains to tweak options to change code size. All tests were run on a Mac+ with a Novy systems 16 mhz 68020/68881 upgrade board with 4 megs of 1 wait-state memory, a 512K disc cache and a MacBottom 45 hard disc with 26 msec seek time. In computation speed, this system is roughly the same speed as a Mac II. The results are tabulated below. Each position in the table contains, from top to bottom, the results for DCM Fortran 3.0 , Absoft MacFortran 2.4 , Language Systems Fortran 1.1, and Absoft RAT Fortran “pre-beta”. All sizes are in kilo-bytes and all execution times, except Whetstone, are in seconds. Whetstone results are traditionally reported in units of “whetstones per second”. For this benchmark only, a larger number means faster execution. Finally, for Whetstone and Linpack, I included speeds for a VAX 11/780, so you can see how well this desktop computer is doing against a large mainframe!

Results of Generic Fortran Tests

These test results need to be interpreted with some care. For example, an important distinction in the Compile and Link time results is that DCM Fortran and MacFortran do an automatic link-at-runtime, which is the time reported in the table, while RAT and Lang. Sys. both use the MPW linker, so they always require an explicit hard link. This is one example of the compromises that one makes by running under MPW rather than your own integrated environment.

4.9 secs (VAX)

Figure 1. Test Results

On compile speed, it is a race between DCM and MacFortran. DCM is the fastest turnaround for very small code, but MacFortran starts to edge it out as code size grows. The RAT compiler is competitive on compile speed, but both it and Lang. Sys. suffer from link times under MPW.

The Absoft RAT compiler sweeps the field on execution speed, a reflection of the superior optimization features of this compiler. As predicted, the register scoreboarding technique has little effect on Sieve, where there are so few variables that static register allocation is virtually as good as dynamic optimization. On Linpack and Whetstone, the optimization in RAT makes a marked difference. Averaged over the three tests the other compilers are comparable in execution speed.

Code size is a complicated issue, as this is where differences in “philosophy” will show up most glaringly. MacFortran and RAT are the winners for small code size, partly because of the small runtime libraries. This is a minimalist approach, trading off small code size for little built in Mac support. For example, in MacFortran the runtime library only supports a non-scrollable, non-resizable “glass TTY” window and no support for desk accessories or other parts of the Mac environment. Language Systems and DCM provide more built in Mac features, which accounts for some of the code size. The Language Systems runtime support includes a scrollable text edit window with the usual File, Edit and Apple menus. If you want a reasonable built-in Mac interface, this looks to be a reasonable compromise.

Mac Programming Support

The test that I ran are generic Fortran code, so how do we evaluate the Fortran compilers on their ability to generate real Mac-style applications? Generally speaking, it is very difficult, and often inappropriate, to attempt a full-blown Mac interface in Fortran. The main difficulty is that all the toolbox routines expect Pascal or C type data structures, which are not supported in most Fortran compilers and are not part of the ANSI 77 standard for Fortran (although they are in the proposed 88 standard). Tools for adding a Mac interface are therefore an important consideration in choosing a Fortran compiler.

Fortran programmers have two main choices: (1) Use a Fortran that runs under MPW and program the interface code in C or Pascal, or with MacApp and link to your Fortran code, or (2) Use a programming aid called FaceIt. FaceIt is a set of stand-alone code resources that can be easily added to your Fortran code and makes it trivial to add Macintosh look and feel to your programs. FaceIt is presently available for MacFortran, and Language Systems Fortran, and should be available with RAT.

Conclusions

But first, a disclaimer. I have used the Absoft MacFortran for over 3 years, so I am very familiar with that product. In contrast, I have used an evaluation copy of DCM Fortran for a few weeks, have used the Language systems Fortran for about a month, and used RAT just enough to get the 3 benchmark programs run. I have tried to be objective, but it is almost inevitable for two things to happen: (1) I may tend to prefer MacFortran simply through familiarity. (2) I am much more familiar with bugs and flaws in MacFortran because of more accumulated usage with it.

With that settled, these are my conclusions. On a “by-the-numbers” basis, MacFortran and RAT are clear winners in the categories of stand-alone and MPW compilers. However, there is a lot more to overall productivity than the numbers in the table. Since I was trying to measure raw performance, the tests that I used are all “vanilla” Fortran and do not include any Mac features at all. In terms of runtime support of the Mac, MacFortran runs last, behind DCM and Language systems. If you want any Mac features, such as scrolling windows, DA support, etc, in MacFortran you do it all yourself. DCM and Language Systems are putting more code into the runtime package (hence the larger code sizes) to support the Mac environment. For applications that have a Fortran written Mac interface, the code sizes would probably be closer than the examples that I chose. However, as I indicated above, my approach is to avoid doing a Mac interface program in Fortran, and, instead, to use other tools which are better suited for that purpose.

The choice of stand-alone compiler, integrated environment or MPW also has important consequences. For instance, I found all of the compilers to be very responsive in terms of compile speed and context switching between programming tools. But, I am running on virtually the fastest Mac hardware available. On a floppy-based Mac+, the integrated environment of DCM could be much more important. In the other direction, running under MPW confers the benefits of use of Mac-App or cross-linking with C or Pascal. This is not an unmixed blessing, however, as it ties the fortunes of the compiler to decisions made by Apple. For example, the 32K segment limit for data has not yet been eliminated and there is still no symbolic debugger for compilers running under MPW.

The bottom line is that you must choose amongst these products on the basis of your needs. On systems that cannot support the overhead of MPW, or if just don’t like MPW, you may well be happier with MacFortran or DCM. If you have an existing Mac interface in C or a commitment to MPW, then Language Systems offers a means to integrate mainframe Fortran code into a Mac interface shell, with lots of MPW tools to help you.

I suspect that Fortran on the Mac is now going to see some of the improvements that we saw take place with C compilers once a competitive marketplace was established. We may even see programmers using a synergistic approach with several different Fortran compilers, just as some developers presently use Lightspeed C and MPW C at different times for different purposes.