LS FORTRAN 2.0
Volume Number: 6
Issue Number: 3
Column Tag: Jörg's Folder
Language Systems FORTRAN 2.0 
By Jörg Langowski, MacTutor Editorial Board
“Language Systems FORTRAN 2.0”
A new version of the Languages Systems FORTRAN for MPW has just arrived
here. Version 2.0 has been improved a lot compared to the previous version - not that
version 1.2.1 wasn’t already a very good product. I’d like to give a short overview and
some code examples in this month’s column, so that you can appreciate the ease with
which Fortran application can now be created on the Mac, or ported from a mainframe
to the Mac.
But first of all, a figure that might be very important for many of you Fortran
users: the new compiler runs the Whetstone benchmark at 1072 K whetstones/sec
(Language Systems FORTRAN 2.0, opt=3, MacIIx) instead of the 425 K whetstones/sec
that the version 1 compiler produced. The optimizer now actually works, and
depending on the type of the code there can be very significant speed differences from
one optimization level to the other. The matrix multiplication benchmark that I
described in the V5#8 column, now runs in 2.66 seconds (opt=3, MacIIx) instead of
6.52 seconds (145% faster), if you don’t take the constant index expression out of the
loop; or in 2.55 instead of 4.65 seconds (82% faster), if the common subexpression
elimination is done by hand on the source code. Thus - at least for these cases - LS
Fortran produces code that is now even faster that MPW Pascal’s code, and
significantly faster than the same Fortran code on a MicroVAX II.
Built-in Mac interface to FTN programs
The Macintosh interface to Fortran programs has been extensively improved and
simplified. It has always been possible to create a typical Macintosh application around
a central event loop with mouse down, update and activate handlers etc. entirely in
Fortran, and there is a Multi finder-compatible sample Fortran application on the
Examples disk. But this is not what the typical Fortran user would have in mind when
porting a functioning application from a mainframe to the Mac. Rather, one would like
to conserve most of the existing Fortran code and add to it the ease of use of the
Macintosh, without having to write a whole new user interface around it.
With the new LS Fortran, such an operation is extremely easy, as long as your
program is well-written, i.e., sufficiently modular. There are enough examples of
GOTO-clobbered spaghetti code with 25-page long subroutines that I wouldn’t wish my
worst enemy having to adapt to a new machine, but as long as you can cut up your code
into distinct routines that each fulfil a defined task and then return to a main program,
porting the program to the Macintosh becomes child’s play.
To achieve this, Language Systems have expanded on a feature of their system:
namely, that a LS Fortran program does not immediately exit to the Finder after the
END statement, but returns into a run time system that lets you edit, save or print the
output window. The new compiler version allows the user to add new menus and menu
items to the menu bar that is drawn after exit from the main program. Each of the
menu items can be assigned a pointer to a subroutine that will be executed when the
menu is selected. Control returns to the Fortran run time system when the subroutine
finishes; there, a new menu selection may be made, either from the default Fortran
File, Edit, and Fonts menus, or from any added user menus.
Furthermore, a routine has been added that gives the Fortran program access to
the menu items in the Fortran run time menu bar. For instance, to quit to the Finder
immediately at the end of a program - instead of keeping the editable output window
and the menus available - all you need to do is
CALL DoMenu(‘File’,’Quit’)
at the end of your main program.
The example - a simple graphics display program
Using the new menu features, the Fortran program will be structured in such a
way that the main program only does data, window, etc. initialization and sets up the
user menus, while the actual work is done by subroutines that are invoked through
menu selections. Listing 1 gives an example of such a program, a simple facility to
read a file with consecutive lines of x/y coordinate pairs and to plot the corresponding
graph in various ways in a graphics window.
Furthermore, one of the subroutines (Listing 2) is written in Pascal and
illustrates the possibility of passing parameters either through the procedure’s
parameter list or through accessing Fortran’s COMMON data directly.
You’ll notice that two new Fortran compiler directives appear at the beginning of
the program. The compiler directive !!G Toolbox.finc is used to load a precompiled
‘global include’ file that contains toolbox variable, structure and parameter
definitions. This speeds up recompiling a program considerably if you use lots of
toolbox definitions. Global include files can be created to the needs of each individual
program, including only those definitions used in the code; or one can simply create
one file that contains all the definitions. In the latter case, compiling takes only
slightly longer.
Just as the directive !!M Inlines.f was used in version 1.2.1 to make the trap
definitions known to the compiler, we can now use !!MP Inlines.f to simplify the
calling mechanism. In the latter case, all trap routines are automatically declared as
PEXTERNAL, which means that parameter will be passed by value rather than by
reference (the Fortran default). This allows you to write
call SetRect (%ref(myRect),
1 int2(20),int2(40),int2(500),int2(235))
rather than
C 1
call SetRect (myRect,
1 %val(int2(20)),%val(int2(40)),
2 %val(int2(500)),%val(int2(235)))
as you would have to do when call-by-reference is the default. Since toolbox calls
receive a great number of their parameters by value, this saves a lot of writing and
makes the program much more readable. Of course, the old directive !!M Inlines.f is
still available. You may now also declare any other subroutine PEXTERNAL, and
further CALLs to that routine will use Pascal calling conventions.
Fortran subroutines may also be declared to receive some of their arguments by
value; you write, in the subroutine definition,
C 2
SUBROUTINE XX(A,B,%VAL(I)),
and the routine will expect the value of I on the stack, not its address. This can be
important for writing certain filter procedures that are called by toolbox routines.
The Main Program
The main program will first move the Fortran output window to the bottom of the
(Mac+) screen, then set up the user menu with its items and their corresponding
subroutines. Routines which are not defined in the same source file must of course be
declared EXTERNAL (or PEXTERNAL or CEXTERNAL). OutWindowClear, which erases
the Fortran output window, is such a case.
After the calls to AddMenuItem, we type a blank line (type *) to have at least one
reference to the window output routines in the main program, and thus create the
output window. Thereafter, a graphics output window is created.
We must call DoMenu at least once before the main program exits if we want to
modify some of the user menu items, for instance set a check mark. Since the menu bar
is not created before the main program exits or DoMenu is called, any calls to
CheckItem, SetItem, etc. won’t have an effect before.
One line - commented out in the example - calls a routine that was undocumented
in the version of the manual that I received (thanks, Claudia Vaughan from Language
Systems, for the information!): SetIdleProc receives a pointer to a routine that will be
called regularly from the Fortran run time system’s main event loop. Here, that
routine would just beep once (that’s why I commented it out in the final version).
SetIdleProc could be used to do background calculations or refresh graphics windows,
since the present system does not allow to associate update routines with windows,
unless the complete event loop is rewritten in Fortran.
File access through the SF dialog
The routine that reads in the data, readData, shows a non-standard extension that
LS has made to the Fortran OPEN statement:
C 3
open(unit, file=*, status=’OLD’)
will display the standard file dialog for opening a file and assign the selected file to the
Fortran unit number;
C 4
open(unit, file=*, status=’NEW’)
of course, will display the ‘Save File’ dialog and have the user input the file name. The
actual file name, if needed, can be obtained through the Fortran INQUIRE statement. By
default, files are of type ‘TEXT’, creator ‘MPS ‘; this can be changed through the
keywords CREATOR and FILETYPE in the Open statement. The latter keyword also
changes the files displayed in the ‘Open File’ dialog.
Many other keywords have been added to the Open statement, some of which have
no effect at all, but ensure compatibility with other Fortran dialects (e.g. VAX) that
use them.
Cross-language calling and COMMON access
Most of the remaining routines which display the data, play around with the