"Random Generator shows off MacFortran"

By Mark McBride, Assit. Professor of Economics, Miami University, Oxford, Ohio

Having used the Macintosh for over a year in my routine daily work of word processing and telecommunicating and for some minimal programming in Pascal and assembly, I decided it was time to consider expanding the activities I do on the Mac. Being an economist, most of my computer work focuses on complex statistical analysis on the mainframe computers using SAS, SPSS, and Shazam, as well as custom Fortran programs. Therefore, I began investigating ways to convert the custom mainframe Fortran programs to the Mac.

This column will cover three topics of interest to Mac users wanting to program in Fortran or convert Fortran porgrams from other machines. First, tutorials on how to implement Mac features from within Fortran programs. Second, strategies for converting Fortran programs to the Mac. And third, combining the first two, creating custom Mac versions of your mainframe programs which take maximum advantage of the Mac's user interface with the least amount of conversion effort.

Which Fortran?

In beginning my quest, I laid down four criteria for the conversion of Fortran programs to the Mac. First, I should be able to easily import the source code from the mainframe via the modem. Second, I should be able to compile and run the existing code on the Mac with a minimum of conversion problems. Third, I should be able to redesign parts of the code to have Mac-like features, as I deemed necessary. And finally, I should be able to create self-contained applications.

MacFortran by Absoft

In evaluating Fortran systems to meet these criteria, I discovered that only MacFortran by Absoft appeared to meet all four criteria. The Absoft system (version 2.0a; version 2.1 is due for release this month) consists of Apple's Edit program (a general purpose text editor used in the MDS and Consulair C systems), a Fortran 77 compiler, a linker, an interactive debugger, and a library manager. Only the linker appears to have some deficiencies (more on that below). MacFortran compiles into 68000 machine code. The compiler has many options, including an option for compiling Fortran 66 source code. Probably one of the most interesting features of the compiler is the ability to generate 68000 assembly source code which can be used with an assembler to fine tune the code. (This is also useful for studying how compilers produce native code.) MacFortran's desirable language features include structured programming constructs: if then else, block if, case, etc. The interactive debugger is almost as easy to use and as powerful as the debugger in MacPascal. This makes debugging relatively easy in MacFortran. While the documentation is thin in places, the system is fairly easy to get up and running and access to the toolbox is well documented. (Version 2.1 has an extra 100 pages of toolbox docs included.)

Fig. 1 Screen output of this month's Fortran program

Using MacFortran

MacFortran requires two drives to use it effectively. I keep Edit, the compiler, the debugger, and the MacFortran overlay files on the internal drive along with a stripped down Mac system file and an Imagewriter file. This leaves about 35k of free space. I have removed the MacFortran overlay file -- f77003.fc-- from my work disk. This overlay file is necessary only if you are going to generate assembly source code during compiles. In the external drive, I keep commonly used subroutine code files, source files, the linker, and the library manager. The external disk does not contain any Mac system files. This arrangement seems to provide a workable environment for developing programs. (Don't you agree the Mac should have had the 800K drives it was designed for? -Ed)

Converting a Fortran Program

For a first attempt at converting programs, I choose a relatively simple Fortran source code: an economic simulation of a small third world country (Fredonia) developed by a colleague. The Fredonia simulation is about 1500 lines of code which is essentially a large DO LOOP over straight line code. Only 3 short subroutines exist within the source code. MacTerminal provided easy downloading of the code from the HP 3000 minicomputer via text capture. The Edit program read the MacTerminal file, allowing me to remove all the extraneous information from the download.

Before compiling the source code, I checked the file I/O conventions used in the source code against those available under MacFortran. MacFortran handles the file I/O specifications of Fortran 77. However, there are a few items worth noting. First, while writing output to the printer via unit 6 is possible, data input with read statements using unit 5 are not available in MacFortran. Second, the file unit identifier * is connected to the I/O devices defined by units 5 and 6. The * unit identifier can be redirected to the keyboard for reads and the screen for writes with a compiler option. Third, the file unit identifier 9 is connected to the keyboard for reads and the screen for writes. Fourth, other files read from or written to need to have their OPEN statements checked against the syntax that MacFortran uses for open statements. If the mainframe program used JCL statements to assign file I/O, then the ported program will need OPEN statements added to establish the file preconnections. A final word of caution concerns writing to the printer via unit 6. MacFortran will spool your output to a temporary file. This temporary file will be sent to the printer when your program ends by a subroutine called spool. To avoid out of memory errors at runtime (error=64), include the following subroutine in your source:

subroutine dum
integer*2 ary(1000)
common ary
return
end

This forces MacFortran to reserve enough memory to load the spool subroutine.

The Fredonia source file compiled with only one error on the first pass. This error was caused by the absence of a Fortran subprogram specific to the HP 3000 which generates random numbers. The ensuing search for a random number generator allowed me to explore some of the intricacies of the MacFortran system.

Implementing Random Numbers

A search of the MacFortran manual revealed that access to the toolbox included the random number toolbox routine which is part of Quickdraw (see Inside Mac for a description of random). The toolbox random routine can be seeded in a system global variable, RndSeed, in order to generate different random sequences. When Quickdraw is initialized, Rndseed is set to zero.

Given that the location of RndSeed is known via an offset to a pointer contained in register A5, direct access to the seed location from Fortran was not possible. This is because the present system does not support access to the quickdraw globals. However, Absoft states version 2.1 includes access to system global variables, as well as RAM based packages, which are not currently supported. I decided to write a short assembly language routine to seed the random number generator.

This turns out to be more difficult than it sounds. Apparently MacFortran also uses the A5 register internally, forcing Absoft to relocate the Mac pointer contained in A5 that assembly programmers have learned to love. Absoft states that the Mac pointer is located at -4(A0), but I still haven't gotten the assembly based seeding to work yet. This is not to be critical of Absoft, who have been extremely patient and helpful in answering the duffer questions of a neophyte assembly programmer. I decided to wait on version 2.1 to access globals directly from Fortran. Others who want to call external assembly language subprograms would be well advised to contact Absoft to find the best solution for their particular needs, and in particular, making sure they have version 2.1. I will report a general solution as soon as I figure/ find it out.

The next solution tried was to implement a random number generator in Fortran. The routine I selected is given in Rand.for shown in listing 2. This random number function returns a real value between zero and one. The random sequence can be reseeded on any call or a fixed sequence can be maintained for program debugging purposes.

Examination of the random number function source code reveals two interesting features. One is the use of the Save statement. A subprogram in MacFortran does not save local variable values between succesive calls of the program. The random number generator needs to retain local variable values between calls and does so with the Save statement.

ToolBox Support

Second, I use the Macintosh toolbox traps TickCount and BitXor. MacFortran uses a general purpose subprogram called toolbx to handle toolbox traps. Toobx is defined as integer*4 and can be used as either a subroutine call or as a function call. MacFortran keeps track of which is being done based upon which toolbox routine is called.

To make a toolbox call in MacFortran the program defines and assigns values to the necessary variables of information to be passed or received. This information is passed along with the name of the toolbox routine by a call to the toolbx subprogram (Note: this is very similiar to the inLine procedure in MacPascal). Absoft has provided include files that handle the toolbox name and parameter declarations. Absoft has also provided example source code files and good documentation on accessing the toolbox from Fortran.

[The way this toolbox calling is implemented is non-standard. A source file called toolbx.par contains a list of trap names equated to integers from 0 to 500 or so. The trap name is set equal to this integer index in your program by either including this file of definitions, or using the parameter statement to assign the integer value to the trap name. Apparently the subroutine toolbx.sub uses the integer value as an index into it's own table of glue routines, where it obtains the real trap address and executes the toolbox call. The source code to toolbx.sub is not provided. Since there is no obvious connection between the integer values in the file toolbx.par and the trap address, and since the trap names are not in any kind of order, it is a bit difficult to wade through the 500 assignments looking for the trap call your interested in. The trap names are standard so by including the parameter file you don't have to bother trying to figure out how Absoft happened to assign those integer values to each trap name! -Ed.]

Using the Rand function

Listing 1 provides the source file Random Test.for which checks the accuracy and speed in using the Tausworthe random number generator. This program does not create or use any special Mac features, such as windows or menus. The program uses the default tty like environment Absoft has set up. This environment is useful when first porting over a Fortran program to ensure that the compiled code is behaving the same on the Mac as it did the mainframe. We'll talk next time about creating Mac user interface features in Fortran.

Upon successful compilation, you can immediately run your new codefile by double clicking the Random Test apl file on the desktop. This will cause the MacFortran run time library (f77.rl) to be dynamically linked in, as well as the external subprogram toolbx.sub the first time it is called. This approach of dynamic runtime linking can be useful if you have a set of commonly used subroutines.

Linking to Stand alone

One of the stated goals at the start of the article was the ability to link the resulting code into a single stand alone clickable application. This can be done with the MacFortran linker. To link the example program double click the linker and execute the following linker commands in response to the > prompt:

>f Random Test
>f toolbx
>l f77.rl
>o Random Program
> (carriage return)

Be sure that the files Random Test apl, toolbx.sub, and f77.rl are all on the same disk and that the commands are executed in the above order. The primary restriction is that the runtime library should always be the last file linked. This will generate an approximately 22k application file (2k from Random Test apl, 3k from toolbx.sub, and 17k from f77.rl, the fortran run time support module required of any stand alone program).

While linking a stand alone file in this sample program was easy enough, that is not always the case with the MacFortran linker. The linker can get lost sometimes and report no unresolved references, even when some still exist. Notably, this situation seems to arise when there is a call to an external function which references a function which is external or internal in the calling subprogram's parameter list. For example, the following call would not be handled properly:

KU2=toolbx(BITXOR,KU1,toolbx(BITAND, LU1*N2TCM,KC))

This is not a problem at run time for unlinked external subprograms because the runtime program will dynamically search the disk to resolve any unresolved reference. The problem arises only with programs linked with the linker. This problem is being corrected by Absoft in the soon to be released version 2.1 which will contain a completely rewritten linker. A short term strategy, which may or may not work, is to link to the compiled code to the external procedures, then relink that code again to the external procedures, and then link the run time library. Anther notable change in version 2.1 is that the toolbx.sub file will shrink from approximately 3k to 500 bytes and the runtime library will stay about the same size.

Gripes with the lack of Mac Like Features

The following several paragraphs were added by the editor based on his efforts to compile and link the Random number program presented in this article.

[The present linker as well as the other Absoft routines unfortunately show that this product is a port over job from another computer. The Mac interface is poorly implemented. The dialog boxes are rather simplistic and unprofessional in appearance. The 'about' dialog box looks at first glance like an error message! The protection scheme is also implemented in a rather shoddy manner. Instead of a simple statement asking you to insert the master disk for verification, the dialog box makes you clik a button to eject the disk, insert the master, then click another button to say "OK, I've inserted it!", and finally insert the system disk back in the drive after the master is ejected. A very tedious procedure considering you have to do it everytime you boot up. They could have at least ejected the disks for you and detected the disk insertion event rather than making you do all the work. The quality of the buttons in the dialog boxes also look like a rush job to quickly get the Mac interface up and running. The linker is especially bad in that it doesn't even have a menu bar! Strictly keyboard commands! There is really no excuse for that at this late date in the Mac life cycle. The compiler also operates in a funny way, again showing haste in implementation. To compile a file, you first select the file from the file menu, then open it, (nothing appears to happen at this point) then go to the compile menu to compile whatever it was you opened way back when. Again, this is very round about. The expected behavior is to simply invoke the compile command, get a standard file dialog box and click on the file to be compiled, and be off and running. This is the way it should work, but doesn't in version 2.0. We will report if this user interface is cleaned up in 2.1.

No Error Messages

My final gripe is cryptic error messages. If the disk fills up, you get a XX error code and a disk full of locked intermediate files you can't get rid of without shuting down and rebooting everything or running another application to release the "in use" lock. More meaningful error messages, or better still, alert boxes allowing some remedy would be nice. And the fact that the files created by the compiler are all locked as "in use" after the compiler gave up has got to be a bug. On the positive side, the compiler does have a transfer menu that lists the MDS editor or MacWrite. Nice. However, they neglected to adjust the companion transfer menu in Edit so the transfer is only one way. Edit doesn't know about the fortran compiler; it simply shows the Apple assembler as grayed out. I tried compiling the assembly source code output to see what would happen and I found out. The compiler doesn't have an escape button to eject from a compiler gone mad condition. So I had to wait while the compiler choked its way through the assembler file, flashing countless error messages at me. A simple cmd-period escape would be nice.

Assembly Source or Object Code

Something to be aware of is when you select the assembler source code compiler option, no object code is generated! Apparently you either get the object code or the assembly source, but not both together. This caught me by surprise. I couldn't figure out why I wasen't getting any output from the compiler. The output of the compiler (when you don't select asm source option) is a 3K code resource file placed on the desktop with a standard application icon. This is decieving however. This file is not a true application since it can't run by itself. The Absoft system dynamically links this file to the run time support package when you click on it. If that package is not available you get a beep and a quick trip to the Finder. To get an honest-to-gosh application, also under the standard icon, you have to invoke the linker and execute the link commands as shown previously. Then you get a 23K file that can go anywhere.

Testing the Rand function

Running the Random Test apl reveals two interesting features about the performance of the random number routine and MacFortran. The test program runs 1000 trials of sample size 60 on random numbers between 1 and 6. The average number of outcomes for a particular value in a sample of 60 rolls should be 10. Every time I have run this test, the average number over 1000 trials has been within 1 or 2 percent of 10 for each value between 1 and 6. This is a crude indication of a fairly reliable random number generator. The second feature to note is the length of time to execute the 60,000 executions of rand and assign the outcomes to the counting bins: 106 seconds for the unlinked program and 92 seconds for a fully linked version. Conversations with Absoft revealed that the first two loops in a nest are handled with registers in the compiled code. This helps explain the speed of the program, which is very good. [Those of you frustrated with BASIC should take note! -Ed.]

Well, I hope this gives you an initial idea about porting Fortran programs to the Mac. In future columns we will explore adding menus and windows to your programs, standard file procedures, and other Mac software technology. Until then, if you have any suggestions or tips on Fortran on the Mac, please pass the information along.

Fig. 2  Sample line of Fortran in assembly source code format from the compiler 
output
;       KU1=toolbx(BITXOR,KU1,LU1/N2TM)

        MOVEM.L  D5/D6/D7/A0/A2/A3/A4/A5,-(A7)
        SUBQ.W   #6,A7
        MOVEQ    #89,D0
        MOVE.L   D0,-(A5)
        MOVE.L   A5,-(A7)
        PEA      8(A3)
        MOVE.L   8(A3),D0
        MOVE.L   24(A3),D1
        JSR      68(A4)
        MOVE.L   D0,-(A5)
        MOVE.L   A5,-(A7)
        MOVEQ    #3,D0
        MOVE.L   #2137475944,D1
        JSR      4(A4)
        ADDA.W   #18,A7
        MOVEM.L  (A7)+,D5/D6/D7/A0/A2/A3/A4/A5
        MOVE.L   D0,8(A3)

*  
*  A MacFortran program implementing a random function
*  and doing a rudimentry test of its properties.  The
*  program uses toolbx calls for bit operators and 
*  tickcount, but does not use toolbx for custom menus
*  or windows.
*
*  Mark E. McBride
*  211 N. University
*  Oxford, OH  45056
*  (513) 523-1438
*  July 1, 1985
*
      PROGRAM Testrandom
*
*  Declarations
*
      Integer*4 Y,Tick1,Tick2
      Integer*4 toolbx,TICKCOUNT    ! toolbox variable    
      Integer*4 A(1001,6)
      PARAMETER (TICKCOUNT=362)     ! toolbox trap 
*
*     PROGRAM STARTS HERE
*
      Y=Rand(0)       ! Seed the random number generator
*
* Initilize array, MacFortran will not initialize for you
*
      DO 500 I=1,1001
      DO 500 J=1,6
 500  A(I,J)=0
*
*  Get a system tick count using the toolbox routine
*
      Tick1=toolbx(TICKCOUNT)       
      write(9,*) ' System tick count at start is ',Tick1
      write(9,*) ' more coming...'
      write(9,*)
*
*  Do one thousand trials each of sample size 60
*
      DO 1000 I=1,1000
      DO 1000 J=1,60
      Y=int(Rand(1)*6+1)
1000  A(I,Y)=A(I,Y)+1
*
*  Get a second system tick count
*
      Tick2=toolbx(TICKCOUNT)
*
*  Calculate total number of responses for each value
*
      DO 1500 I=1,1000
      DO 1500 J=1,6
1500  A(1001,J)=A(1001,J)+A(I,J)
*
* Write out results to MacFortran generated output window
*
      Write(9,*)' The average # of responses in sample
     + of size 60 after 1000 trials is'
      Write(9,*)
      DO 2500 J=1,6       ! write average response rate
2500  Write(9,101) J,float(A(1001,J))/1000   
 101  Format(/1x,' For die value ',I2,' the average  
     + number of responses was ',f8.5)
      write(9,*)
      write(9,*) ' System tickcount at end is ',Tick2
      write(9,*)
      write(9,*) ' Sampling took ',float((Tick2-Tick1)/60),
     +' seconds'
      write(9,*)
      PAUSE 'Press Return to quit'     ! hold the screen
      STOP
      END
*
*  Include the code for the random number generator
*
      include Rand.for
*
*  end of source code
*

        FUNCTION Rand(IX)
*
*  This random number generator is a variation on Tausworthe 
*  generator described in "Solution of Statistical Distribution 
*  Problems" by H. O. Hartley in Statistical Methods for Digitial 
*  Computers Vol III, edited by Enslein, Ralston, and Wilf 
*  (John Wiley & Sons 1977). The only modification of consequence
*  is the ability to reseed the generator with the system 
*  tickcount.
*
*  The function returns a real value between 0 and 1.
*  Rand(0) will reseed the random sequence using system tickcount.
*  Rand(1) will use previous calls values as seeds for next number
*  in the sequence.  Always using Rand(1) will generate a specific
*  random sequence based upon starting values internal to 
*  the function.
*
      Real*4 Factor,KU1,KU2

      Integer*4 Toolbx,BITXOR,TICKCOUNT     !  toolbox definitions
      Integer*4 KU3,LU1,KC,N2TM,N2TCM

      Equivalence (KU2,KU3),(KU1,LU1)

      PARAMETER (BITXOR=89)                 !  toolbox definition
      PARAMETER (TICKCOUNT=362)             !  toolbox definition

*  Note that the parameter statement assigns a value to 
*  the indicated constant label. In this case, it is the index 
*  into a table of trap addresses contained in TOOLBX.SUB which
*  converts the call to a trap call. A list of these assignments
*  is given in the file TOOLBOX.PAR.

*  You must explicitly tell MacFortran to save the values of
*  local variables across successive calls of the subroutine.

      SAVE
      Data Factor/0.4656613e-9/
      Data N2TCM/z'00040000'/
      Data KU1,KC,N2TM/z'40000003',z'7fffffff',z'00002000'/

*     KU1    enters with U(I) uniform random variable
*     KU2    leaves with U(I+1) uniform random variable
*     KCU1   complement of KU1
*     KCU2   complement of KU2
*     KC     complementing constant
*     LXXX   logical equvalences of above KXXX
*     N2TM   2**M where M is shifting factor
*     N2TCM  2**P-M where P is word size
*     Factor float value of 2**P
*     XOR    is the exclusive or operator

      if (IX=0) KU1=toolbx(TICKCOUNT)
      KU1=toolbx(BITXOR,KU1,LU1/N2TM)
      KU2=toolbx(BITXOR,KU1,(LU1*N2TCM).and.KC)
      Rand=FLOAT(KU3)*Factor
      KU1=KU2
      RETURN
      END