5. FORTRAN Programming Notes

5.1 General Comments

Note that a LAS program written in FORTRAN is not transportable in the true sense. The FORTRAN source program must be run through a C preprocessor (LAS support tool faim). The C preprocessor determines which system the program is being compiled on and generates a new source file with the appropriate FORTRAN code for that system. The LAS support tool fpp will expand the environment variables in the include statement to the full path name.

Every support service subroutine must be callable by standard FORTRAN-77 code. That means that the subroutine name must contain six characters or less, letters and numerals only, with the first character as a letter. All values must be passed by reference.

The sequential processing scenario seems the best way to handle BIL (band interleaved by line) tapes, while the random scenario is better for BSQ (band sequential) processing.

For the sequential processing scenario, if the eopens() and egroup() calls are in a separate subroutine than the call to estep(), then the argument fdesc (file descriptor) must be saved at the end of the subroutine containing the eopens() and egroup() calls; this ensures that the value is available for estep() to reference later on. Therefore, to use the image I/O routines, FORTRAN code requires a common block:

    /imgio/ -- common block may be named anything.
               This block should contain the file 
               descriptor array, the group 
               descriptor, and the offset arrays.

These must be stored in a common block because the image I/O routines require the addresses to be static throughout the application program. Note that the common block may be omitted if the program uses the SAVE command instead, which makes the variables static.

5.2 Exceptions to the FORTRAN Coding Standards

LAS programs written in FORTRAN follow the coding standards listed in the FORTRAN Coding Standards section with the following exceptions.

For stylistic reasons and readability, all source text is in lower case except for symbolic constants (parameters) which should be in upper case. If necessary, programs could be converted to all upper case using a program like tr on UNIX.
For readability, blank lines are used in source code. Also, a "C" is used in column 1 of comment lines rather than an asterisk. A program could easily be written to strip the blank lines and change the "C" in column 1 to an asterisk.
LAS programs do not strictly adhere to the standard that subroutines should be ordered alphanumerically within a program module or that common declarations should be ordered alphanumerically. However, this practice is recommended.
In order to process all the required image data types, nonstandard data types are used. A typical LAS application program uses byte (character*1 for UNIX), integer*2, integer*4, and real*4 data types.
Since most LAS programs must handle 8bit images and UNIX does not support the nonstandard byte data type, the data type character*1 is used for byte data on UNIX systems. When processing is performed, the ichar and char functions are used. However, since the values returned by these functions are processor dependent, we have written a C version which returns the same value on each UNIX system.
The equivalence statement is sometimes used to assign two different data types to the same location in memory. For example, rather than having four separate buffers for storage of image lines (one for each data type), only one buffer is used.

5.3 Method of Processing BYTE Data

UNIX does not support the nonstandard byte data type while VMS does. To get by this limitation, the data type character*1 is used for all byte data processing on UNIX systems. VMS still uses the byte type. Since this implies implementing algorithms slightly differently, code which is run on both UNIX and VMS machines is written in the same file using C preprocessor directives to provide conditional selection at compile time. Thus, the source for a program which uses byte data might look like this.

Example:


    #ifdef sun
          external ichar
    #endif

     integer*4 ichar

    #ifdef unix
        character*1 buffb(BSIZE)
    #else
        byte    buffb(BSIZE)
    #endif    common /thebuf/buffb
     common /imgio/ fdesc,gdesc,offset
          .
          .
          .

for number of samples in a line do:


    #ifdef unix
        buffb(out) = char(ichar(buffb(in1)) + ichar(buffb(in2)))
    #else 
        buffb(out) = buffb(in1) + buffb(in2)
    #endif

5.4 Include Files

Programmers writing modules to run in conjunction with the LAS system need to use a variety of include files. Each major service generally requires that a programmer include a specific file. TAE also requires an include file. These files typically define several symbolic parameters. Whatever the contents or purpose of the include files, they are all accessed in the same way on the LAS system. All LAS include files are stored in the directory whose specification is the value of the environment variable LASINCLUDE.

FORTRAN include files used by an LAS application end in ".mfi". Because there is not a conditional include mechanism available for standard FORTRAN, a work around had to be developed. A FORTRAN program should contain the statement:

    #include "las.mfi"

This is not, of course, a FORTRAN statement but a C preprocessor statement. When the C preprocessor is run on a FORTRAN program which contains this line, the line will be replaced with a valid FORTRAN include statement for the appropriate system. Thus, on UNIX systems, the previously noted line will become:

    include '$LASINCLUDE/worgen.fin'
    include '$LASINCLUDE/imageio.fin'
    . . .

Unfortunately, the UNIX FORTRAN compiler cannot use the value of shell variables, so for UNIX systems the source has to be preprocessed a second time through fpp to expand all shell variables. Thus, on UNIX systems if the shell variable LASINCLUDE has the value:

    "/sg2/csb/software/build/las/include"

then the original include statement will finally become:

    include '/sg2/csb/software/build/las/include/worgen.fin'
    include '/sg2/csb/software/build/las/include/imageio.fin'
    . . .

Faim is a tool which has been written on UNIX which runs the C preprocessor and produces the correct code for any supported system. Thus, to write a FORTRAN program, the programmer should create the FORTRAN source code, run it through faim on a UNIX system specifying the target system, copy that output to the target system, and then compile and link this preprocessed source file. The actual files finally included for FORTRAN programs end in the suffix .FIN. Even though these files can be used in include statements, there should never be a need to do so. Programmers should always use the C preprocessor statement and then preprocess the file. Although this may appear to be clumsy, it is necessary to allow one source file to be used to generate source for all systems. It is a first step to making FORTRAN more portable. Besides allowing for different file specification syntax, it also allows UNIX shell variables to be expanded.

The individual include files and their contents are listed in the Include File section of this guide.