LS FORTRAN 2.1, Forth
Volume Number: 6
Issue Number: 10
Column Tag: Jörg's Folder
LS FORTRAN 2.1; Forth News 
By Jörg Langowski, MacTutor Editorial Board
Note: Source code files accompanying article are located on MacTech CD-ROM orsource code disks.
After our excursions into the world of MacApp and C++ (which will be
continued), this month will get us back to FORTRAN and Forth - somewhat closer to the
ground, some may say. Language Systems just sent me their latest update of FORTRAN
for MPW, and I’d like to show you some of its new features.
FORTRAN background processing
One of the main improvements is automatic background execution. Assume you
are porting a program from a mainframe to the Macintosh. FORTRAN programs on big
machines are often written to compute some output, given some input, in a rather
‘linear’ style, that is, user interaction occurs only at some predefined points in the
program. As an avid reader of this magazine you will know by now that Macintosh
programming (and, for that matter, programming of other graphical user interfaces
such as XWindows or MS Windows) is done differently; the program should only do
small pieces of its operation at a time, and check for user events (mouse down, key
down, etc.) as often as possible. This is done by making the program cycle through a
main ‘event loop’, and do time-intensive tasks only at times when there are no such
events to be handled.
The average data treatment, curve fitting, numerical simulation, etc. program
that has been running on a VAX or some other machine will not be structured with a
graphical user interface in mind. It will also be several thousand lines long, have gone
through the hands of three generations of programmers, and, politely speaking, not
adequately documented. However, it works, so how can we port it to the Macintosh with
the least hassle, but please make it run in the background so that the work gets done
while one is preparing the paper which was due three days ago (as I’m doing right now
with this column, while a Fortran program is actually running in the background)?
One must find a mechanism by which the computation is broken up into little
pieces, after which the program can return control to the operating system. As some of
you might recall, a while ago I presented such a mechanism: at each point where you
want the program to return control, insert a call to WaitNextEvent with an event mask
that checks only for update and suspend/resume events. As long as WaitNextEvent
receives only null events at those control points, the program will continue to do its
work, advancing from WaitNextEvent to WaitNextEvent, whether it is in the
foreground or in the background. When the mouse is clicked, the usual task switching
will occur.
Of course, one must be careful about placing the WaitNextEvent calls; spaced too
far apart, foreground execution of other applications will be ‘chunky’ when the
program is turning in the background, and too many calls can slow down the Fortran
program considerably.
Language Systems, in its Fortran 2.1, has integrated a ‘be-nice’ routine,
F_DoBackground, into their libraries. A call to this routine causes events to be
checked, and if necessary, control will be transferred to another process.
It would still be a lot of work to include calls to this routine into an existing
Fortran program; therefore the 2.1 compiler adds a new option, -bkg=n, to its
command line switches. If you use this switch with n greater than 0, you tell the
compiler to add calls to F_DoBackground to your code automatically. The value of n
controls the frequency at which calls to the backgrounding routine are made:
n=0: the default (and the way the old compiler worked): background processing is
possible only during input/output to the console window.
n=1: F_DoBackground is called during file operations or console I/O.
n=2: F_DoBackground is called at each entry to a subroutine or function.
n=3: F_DoBackground is called before each labeled statement.
n=4: F_DoBackground is called inside each DO loop.
There are more possibilities to influence the frequency of F_DoBackground calls.
Another library routine, F_SetBackInterval(ticks) will tell the system not to do a
background call unless the specified number of ticks have elapsed, if otherwise your
program would slow down unnecessarily. If you have some critical code that has to run
uninterrupted, you can also insert a compiler switch into your source code that turns
off the automatic insertion of background calls, and later turn it back on again.
Referenced by (2):