LS FORTRAN 3.0, Pt 2
Volume Number: 8
Issue Number: 2
Column Tag: Jörg's Folder
Language Systems FORTRAN 3.0
By Jörg Langowski, MacTutor Regular Contributing Author
[Due to a bug that showed itself in Quark XPress 3.1, portions of this article
were not printed properly in the April/May issue. The relevant portions are reprinted
here. Just goes to show, to err is human, but to really foul things up takes a computer.
- Ed.]
Language Systems FORTRAN 3.0
FORTRAN 2.1 was already very robust, generated good, fast code, and all in all,
allowed programs that ran on mainframes to be ported very quickly to the Macintosh.
Also, subroutines could be assigned to menu items, and the runtime system would handle
the menu selections automatically for you, files could be OPENed using the standard file
dialogs, and many more goodies.
A Multi-dialect FORTRAN
When I opened the 3.0b2 version of the LS FORTRAN (LSF) compiler, amazingly
enough I discovered that one could still make substantial improvements to this
development system. First of all, Language Systems proved that one can actually make
several existing FORTRAN dialects live happily together in one system. Although I have
only VAX programs to test here, I believe their claim that Cray, Microsoft, Data
General, and of course standard ANSI 77 FORTRAN programs mostly compile without
modifications and produce the expected results. There is a whole section of the manual
(20 pages, to be precise) devoted to describing the compatibility with other systems,
and the changes that may still be necessary for porting the programs. The manual - or
rather Karen Rall, who wrote it - “thinks for you”; the Mac user who has never before
transferred a FORTRAN program from a mainframe will even get instructions about
file-transfer protocols, Macintosh file attributes and VAX record types. There are -vax
and -cray compiler switches for porting programs from those respective machines.
Even the VAX pre-connected filenames SYS$INPUT, SYS$OUTPUT, SYS$PRINT and
SYS$ERROR are supported. Also, all Microsoft compiler directives are recognized and
respected, if possible
But porting programs is not the whole story. You’ll want to develop new
programs, test out those bugs, and for that part LSF now adds new debugging options. Of
course, the trace and dump options always existed which would trace subroutine entry
and exit, and allow to dump variable values to the output screen. Now there is the new
-debug compiler switch with four levels: debug=1 adds code that displays the file name
and source line number where a runtime error occurred; and when you press the caps
lock key during execution, a window pops up where the source line numbers that are
being executed flash by. At debug=2, in addition, the heap is checked at the end of each
subroutine, and at level 3, after each line of source code.
Of course, you can generate symbol tables for use with SADE, to have source code
level debugging.
Toolbox Calling Conventions
The Mac toolbox interface has been improved even further. Now, when you
declare functions as PEXTERNAL or CEXTERNAL, character constants passed as
arguments are automatically converted to the Pascal (length byte followed by text) or C
format (zero-terminated string). The names of PEXTERNAL routines are always passed
to the linker in upper case, regardless of the case sensitivity of the FORTRAN compiler
chosen (ignore case or case-sensitive), and CEXTERNAL names are always passed in
case-sensitive format. These are the formats that the linker expects for C and Pascal.
You can declare variables GLOBAL, which means they are application globals referenced
from A5; again, to match the Pascal and C naming conventions, you can use the PGLOBAL
and CGLOBAL declarations.
System 7
As promised, the new LS FORTRAN supports AppleEvents. The runtime library
includes code that automatically recognizes the four required AppleEvents, ‘oapp’,
‘odoc’, ‘pdoc’, and ‘quit’ (see this column in V7#11). If you compile a FORTRAN
program with the background processing option, it will react when another program
sends it an AppleEvent. As an example, I have listed two programs provided on the LSF
disks: the main program opens a second application, sends it some data via an
intermediate file, and the second application transfers the processed data back to the
main program and quits.
The inclusion of AppleEvents in LSF opens up a whole range of perspectives: for
instance, one could imagine a ‘compute server’, a Quadra for example, sitting
somewhere on the network with a math library, comprising lots of tiny applications,
and programs on other Macintoshes that use this library. Or a way of distributed
processing on the network, where a CPU-intensive program can ‘steal’ time from other
machines when they are not being used. The routine F_OpenDocWaiting() is used to
synchronize such parallel processes; it will continue only when the program has
received an ‘odoc’ event. A very rudimentary but effective way of parallel processing.
Although (up to now) only the four required AppleEvents are recognized
automatically by the FORTRAN runtime library, you can send any event you like, as
shown in the third example. HyperCard 2.1 understands the event ‘dosc’ which will
make it execute a HyperTalk script contained in the event’s data. The program sets up
such a script and sends it to HyperCard; if you don’t have HyperCard opened, it will
issue an error message. When you have HyperCard running and start the program,
you’ll hear one beep and see the card window disappear and reappear. Very impressive.
The edition manager of System 7 is also supported in a way; you can publish a
FORTRAN- created file by executing CLOSE(UNIT=iunit, STATUS=’PUBLISH’).
‘Subscribing’ to such a ‘published’ document from another program that supports the
edition manager means that changes made by the publisher to the document are
automatically reflected in the version of the document opened by the other program
(I’ll give an introduction to the Edition manager in a later column, haven’t fully
under-stood it myself yet).
The last System 7 feature that has been included into LSF 3.0 is alias support. If
you open an alias to a file from within a FORTRAN program, the original file will be
accessed, just as you would expect.
New Compiler Options
The compiler includes support for generating 68040-specific code, and the
optimizer has been improved. As far as I could tell from some limited comparisons
(comparing the assembly output generated for the Linpack and Matmult benchmarks,
see V7#1), the code generated for the 68040 looks extremely similar to the 68030
code, except for some floating point FMOVE instructions, which are different. I’ll check
whether there is a large speed difference on a 68040 between code compiled with the
-mc68030 and the -mc68040 options as soon as I have access to a Quadra.
The quality of the code has improved from version 2.1. The Linpack and matrix
multiplication benchmarks (V7#1) now run at the same speed as the Absoft
MacFortranII compiled versions, although the Whetstone benchmark is still 20%
slower. Note, however, that Absoft is much slower if you insist on full Pascal calling
conventions, which is standard in LSF.
The most striking difference between the code created by the LSF and the Absoft
compiler occurred when I ran a program called “Paranoia” which tests the accuracy
and consistency of math operations. While LSF at opt=3 passed all the tests with no
problems reported, Absoft’s code (with the basic optimizations) reported a lot of
errors and got stuck halfway through. I include the two compiled versions on the source
code disk so you can see for yourself.
At this moment, LSF seems to be superior to Absoft FORTRAN in almost all
aspects, from the quality of the code to the Macintosh environment, to System 7
support; there may still be a slight disadvantage for integer-computation intensive
programs (not for floating point). The new Absoft FORTRAN should be out by now, so
we’ll soon see what that brings. From the information they gave in their ad, e specially
the 68040 support looks very interesting; however, the AppleEvents support is unique
to LSF.
Other Features
There are many other improvements made in LSF 3.0 that you notice browsing
through the manual, most often printed in boldface text because they are nonstandard
extensions. The chapter about optimization was missing from my beta manual; it would
have been interesting to see what they actually changed to get the better performance,
but I’ll have to wait for the final version. There is a long appendix on how to use
HyperCard as a front end to FORTRAN applications, which should be e specially
interesting under System 7, where both HyperCard and FORTRAN programs can pass
AppleEvents to each other. Of course, you can still write XCMDs in FORTRAN, as was
always possible. Also, 4th Dimension external commands are supported. All in all,
there is almost no reason anymore why seasoned FORTRAN programmers should learn
Pascal or C (although I do like C++).
For more information, contact:
Language Systems Corporation
441 Carlisle Drive, Herndon, VA 22070-4802
800-2-LANGSYS or 703-478-0181, 703-689-9593 (fax)
AppleLink: LANGSYS, America Online: LANGSYS
Retail Price: $595 w/MPW, $495 w/o MPW
FORTRAN Upgrades: $100, MPW Upgrades: $50