Language Systems FORTRAN 3.0

By Jörg Langowski, MacTutor Regular Contributing Author; Neil Ticktin, Editor, MacTutor Magazine

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, especially 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 especially 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 like C++ :->).

Next time, some C++ again.

Listing 1
c
cMAIN
c
cPart of an AppleEvents example in the 
cFORTRAN manual.
c
cInvokes program Transform and passes it an 
carray for processing.
c
cCompile this demo with -bkg=4.
c
 PROGRAM MAIN
 REAL*4 Pressure(50)
 INTEGER*4NumPts/50/
 INTEGER*2ERROR,F_SendEvent
 LOGICAL*4F_OpenDocWaiting
 EXTERNAL F_SendEvent,F_OpenDocWaiting
 
 ! initialize an array
 DO J = 1,NumPts
 Pressure(J) = J
 END DO
 
 ! open TRANSFORM
 ERROR = F_SendEvent(‘oapp’,’TRANSFORM’,’’)
 IF (ERROR <> 0) CALL AlertBox(‘AppleEvent Error reported!’)
 
 ! send the data as binary file
 OPEN(10,FILE=’Main.Data’,form=’unformatted’)
 WRITE(10) NumPts,Pressure
 CLOSE(10)
 ERROR = F_SendEvent(‘odoc’,’TRANSFORM’,’Main.Data’)
 IF (ERROR <> 0) 
 1 CALL AlertBox(‘AppleEvent Error reported!’)
 
 ! wait for the data to return
 DO WHILE (.TRUE.)
 IF (F_OpenDocWaiting()) LEAVE
 END DO

 ! close TRANSFORM
 ERROR = F_SendEvent(‘quit’,’TRANSFORM’,’’)
 IF (ERROR <> 0) 
 1 CALL AlertBox(‘AppleEvent Error reported!’)
 
 ! print the data
 OPEN(10,FILE=*,form=’unformatted’)
 READ(10) NumPts,Pressure
 CLOSE(10,status=’delete’)
 WRITE(*,100) (Pressure(i),i=1,NumPts)
100FORMAT(5(x,f10.4)/)
 END

c
cTRANSFORM
c
cPart of an AppleEvents example in the FORTRAN manual.
c
cIs called by MAIN, processes an array and returns it.
c
cCompile this demo with -bkg=4.
c
 PROGRAM TRANSFORM ! a utility program to be
 REAL*4 DataSet(500) ! called by many other processes
 INTEGER*4NumPts
 INTEGER*2ERROR,F_SendEvent
 LOGICAL*4F_OpenDocWaiting
 EXTERNAL F_SendEvent,F_OpenDocWaiting

 ! loop until quit event comes
 DO WHILE (.TRUE.)
 IF (F_OpenDocWaiting()) THEN
 
 ! read in data
 OPEN(10,FILE=*,form=’unformatted’)
 READ(10) NumPts,(DataSet(J),J=1,NumPts)
 CLOSE(10,status=’delete’)
 
 ! transform it
 DO J = 1,NumPts
 DataSet(J) = DataSet(J) * 2.0
 END DO
 
 ! send the data back
 OPEN(10,FILE=’Transform.out’,form=’unformatted’)
 WRITE(10) NumPts,(DataSet(J),J=1,NumPts)
 CLOSE(10)
 ERROR =
 1  F_SendEvent(‘odoc’,’*sender’,’Transform.out’)
 IF (ERROR <> 0) 
 1 CALL AlertBox(‘AppleEvent Error reported!’)
 ELSE
 ! do nothing
 END IF
 END DO
 END

c
cSendScript
c
cSends a script to HyperCard 2.1 via the ‘dosc’ event.
c
cHyperCard v2.1 must be currently executing
c befor running this demo.
c
cCompile this demo with -bkg=4.
c
 program SendScript

 integer*2 err, F_SendScript
 external F_SendScript
 character*20  ch(3)
 character*5ch5
 
 ch(1) = ‘beep’
 ch(2) = ‘hide card window’
 ch(3) = ‘show card window’

 err = F_SendScript(‘HyperCard’,ch,3)
 
 if (err <> 0) then
 write(ch5,’(i5)’) err
 call alertbox
 1 (‘Error ‘//ch5//’ occurred during SendScript.’)
 write(*,*) 
 1 ‘Error ‘//ch5//’ occurred during SendScript.’
 end if
 end