CURRENT NOTES NOVEMBER 1986 P R O S P E R O ' S P R O F O R T R A N - At Last, A Real Language - Reviewed by John Barnes I once promised myself that I would not replace my Atari 800 until I could get a computer with FORTRAN. The ST was hard to resist and became irresistible once I learned that there was at least one FORTRAN compiler for the machine. This article gives my impressions of the ProFortran package produced by Prospero software. Some other time I hope to use this space to tell why I love FORTRAN as a language. ProFortran, from Prospero Software is a product that claims to implement the entire FORTRAN-77 language as defined in ANSI Standard X3.9-1978. The compiler generates native code (i.e. machine-language rather than pseudo-code). There is however, no conversational mode, and all programs must be compiled and linked before they can be run. DOCUMENTATION. I regard ProFortran's documentation as good. The loose-leaf manual runs to around 200 pages in a sturdy binder. The sections are well organized and the instructions are clear. Some users may miss the usual patronizing "gee whiz" tutorial. I like to look in the index, find a clear, concise explanation, and try it. This manual is a reference manual. The explanations are precise, but terse. It is definitely NOT a textbook. If you already know FORTRAN you will be happy, as I was. If not, go to B. Dalton or Crown books and get yourself a book on FORTRAN, you will need it. If you are going to use the GEM hooks you will need additional documentation. The information provided by Prospero is nothing more than a list of calling sequences. No description, no nothing. I found a lot of useful-looking (but obtuse) information in the GEM Programmers' Reference from Abacus books. I have not yet had the courage to plunge into this. ST Applications magazine has a simple plotting application that looks pretty good and I hope to port something similar over from a super-mini soon. OPERATION. ProFortran comes on a single 360K disc. The disc is essentially filled up with a two-pass compiler, a linker, a program to install a "resident library", a library of modules to access GEM DOS in the ST, a librarian utility to allow the user to maintain his own collections of useful code modules, several miscellaneous object modules, a couple of programs for modifying configuration features, and several examples Nothing is protected and the user must build an operating disk (or directory on a hard disk) that suits his needs. The uswer also has the opportunity to customize the compiler by changing the default settings of certain "switches". There is no program editor. Any editor that produces a plain - ST 1 ST - CURRENT NOTES NOVEMBER 1986 vanilla ASCII text file will do. I use 1st-Word in the non-WP mode and Micro-Emacs depending on my mood. Since code development involves a number of cycles of editing, compiling, linking, and, finally (at long last), running, I often operate from Michtron's DOS Shell rather than the GEM desktop. I can then use .BAT files to save opening and closing windows and finding programs to click on. The .BAT files also serve to document the process of building programs up from complex assemblages of source modules. 1ST WORD, which is very nice for large-scale editing, is not comfortable in the DOS Shell environment and I usually use MicroEmacs on the final passes. I have never tried to compile to and from floppy disk, but I imagine it would be very tedious. For this reason I believe that this product will not appeal to users who have memory-starved ST's. I use a ramdisk on my ST to hold the various components of the FORTRAN package, and this does speed up editing, compiling, and linking. As soon as I can find a hard disk at a sensible price I will try that. In order to build a FORTRAN application program you must edit the source code, run the compiler to generate an object module in machine language, and link this module to some other boilerplate that the system requires in order to fire up the program up and hook into the ST's innards. The latter function is performed by a run-time library that must be installed before trying to run either the compiler or the application program. If you get the impression that this is not terribly convenient, you are right. Users who lust after GEM applications will find a library of functions and subroutines that can be linked to if needed. ProFortran includes a "library" facility that can be very handy in maintaining collections of modules (functions and/or subroutines) that are parts of a bigger package or that are generally useful. When linking to a library only those modules that are actually needed are extracted. Modules built in Pro Pascal can also be linked into a final program and instructions are giving for interfacing to modules written in assembly language. "Optimizing" compilers are supposed to be smart enough to minimize the number of steps needed to perform the program's work. I cannot say whether ProFortran does any optimizing. I suspect that the code that it generates is "threaded" rather than "inline". Compilation times do not seem to be unduly long (10 or 15 seconds using ramdisk). When the compiler has finished its work it gives the user a chance to view the screen before he must give a keystroke to continue. I wish this feature could be customized away or switched off because it interferes with batch operations. FUNCTIONALITY. Given that FORTRAN on the ST is somewhat awkward to - ST 2 ST - CURRENT NOTES NOVEMBER 1986 use the first reason for using it is to run a particular application for which source code has been obtained from elsewhere. So far every code that I have ported over in this way has worked. Minor editing changes have been needed because the original codes used extensions to the ANSI standard that ProFortran does not support. The compiler appears to generate correct code, which is the first criterion for functionality. My past experience in Atari software tells me that the other shoe will drop one of these days, so I will not give an unqualified endorsement of this product's ability to do its job. The use that the compiler makes of ST resources appears good, and there are several nice little features like the one that allows a running program to invoke a "daughter" program or to parse a command string. I would like an option to create standalone programs so that I can distribute them to friends who do not want or need the FORTRAN-77 language. The resident library notion prevents this although it does mean that not every piece of code has to have all of the boilerplate. SPEED. The second reason for using a compiler is speed. Code that does not need to be interpreted should run faster. Steve Eitelman's experience with various BASIC compilers shows that this is not always so, and I have compiled and run some of his benchmarks. The FORTRAN source codes for these will be available on a future AURA disk, but people who need them can contact me in the meantime. the only thing I could compare with was ST BASIC, but I found speed increases in all categories as the following table shows: Table 1 - Execution Times in Seconds ---------------------------------------- Benchmark ST BASIC ProFortran SIEVE 247.1 1.2 COSTEST 74.3 42.2 MANDLZM 131.8 14.8 STRINGS (CREATE) 67.2 3.2 (SORT) 257 3.8 (LIST) 172 38.1 ---------------------------------------- If anyone is seriously interested, they can drop me a line to obtain the sources for the above codes. The SIEVE, COSTEST, and STRINGS codes are from Steve Eitelman. MANDLZM is from Scientific American, August '85. ProFortran is obviously FAST, approaching speeds I would expect from a VAX. The speed gain for number crunching is not, however, as great as I would hope for. Benchmarks are often misleading because some benchmarks are well enough known that compilers can be set to recognize them and get really smart. FORTRAN is most renowned for applications that use a lot of floating point and a factor of 3 or 4 here would make the difference - ST 3 ST - CURRENT NOTES NOVEMBER 1986 between doing a calculation and forgetting about it. It is clear that ProFortran deserves serious consideration on the basis of speed. GEM DEMO. Just for grins I tried the GEM demo supplied by Prospero. It very quicly popped up a nice little window with a simple x-y plot in it. The source code cautions that a full-blown GEM application could run to a thousand or more lines of code. I am not ready for this yet, but I encourage anyone else to try. CONCLUSION. Given that FORTRAN is an outstanding language for solving all kinds of problems ( as distinguished from a language that teaches about computers), ProFortran should be able to hold its own against the various C's, Pascals, Modulas, etc. Pricing is under $100, which is certainly competitive. The implemenation provided here is complete enough that I am at a loss to make up a "wish list". ProFortran -- Try it, you might like it. - ST 4 ST - typing in longer programs any ASCII