Random Generator
| Volume Number: | | 1
|
| Issue Number: | | 10
|
| Column Tag: | | Fortran's World
|
"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.]
[One problem with the toolbox definitions is that in the toolbx.par file included in version 2.0, many of the trap calls are unimplemented with a comment saying "...for future implementation...". We have already mentioned the fact that RAM based packages and access to the quickdraw globals is missing in this version. We have requested a copy of version 2.1 to see if the toolbox is more fully implemented, as we expect. We will report on version 2.1 in the next issue including a review of the toolbx.par file to see how many trap calls are implemented. -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.
True double-clickable applications, fully compiled to 68000 machine code. This is the only available true compiler for the Macintosh outside of the C compilers. As of this writing no other language on the Mac can be compiled to 68000 object code except C. Can the assembly source code be assembled with the MDS system and linker into an application? The answer is YES!
I ran the assembly source code through the MDS assembler and it worked! The only change was the ".START" label had to be changed to "START" and declared external for the (not so smart) MDS linker. The resultant object code file can be linked by the MDS linker to resource files, custom icons, you name it. The output of the MDS linker is an application, but one that will attempt to open the Fortran run time module. When you double clik on it, the Fortran file in question is opened (so it must be available) and the program executes. I then tried to take this MDS Linker output (a code resource file) and link it to the Fortran run time module using the Fortran linker. For some reason, this failed. The Fortran linker would not recognize the program file. In summary, you can compile a Fortran source program to assembler source code or object code; you can link the object code to create a stand alone application or you can assemble the assembly source code with the MDS system and link it with files created under the MDS system but the resulting application will require the Fortran run time module to be present on the disk. There probably is a way to get the Fortran linker to link MDS applications to the run time module, but that will take more investigation. -Ed.]
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
