MIPSpro Fortran 90 supports multiprocessing with user-inserted parallel directives. These directives follow the recently adopted PCF (Parallel Computing Forum) X3H5 guidelines. (See “Using PCF Directives”.)

MIPSpro POWER Fortran 90 is an extended version of MIPSpro Fortran 90 that supports the same language and directives, but adds automatic optimization for multiprocessing. This compiler analyzes a serial program for potential parallelization and when possible, generates an executable that can utilize multiple processors when executed in a Silicon Graphics, Inc. computer that has multiple CPUs in sufficient numbers.

The following nonstandard syntax features are accepted by the compiler in order to make it simpler to port programs from Fortran 77.

None of these extensions adds functionality to the language; they only make it easier to port existing programs that depend on Fortran 77 extensions. Because they are nonportable, you should avoid using them when writing new code.

(This topic amplifies topic 1.7 in the Fortran 90 Handbook.)

No standard or intrinsic modules are shipped with MIPSpro Fortran 90. One module has been proposed as a standard to ISO (ISO/IEC 1539-2:1994(E)). It is a module that implements varying-length strings of characters. The Fortran 90 source of an exemplary implementation of this module is available on the World Wide Web. See the sources mentioned under “Internet Resources for Fortran 90 Users”.

(This topic amplifies topics 2.9, 3.1, 4.1, 4.3, and 13.3 in the Fortran 90 Handbook.)

MIPSpro Fortran 90 supports the following data types:

Except for COMPLEX, the supported kind-parameters (1, 2, 4, 8 and 16) represent the size of a scalar value in bytes and the default alignment of one scalar item in memory. For COMPLEX, the kind-parameter represents the size and alignment of each of the components of the number. (This can be slightly confusing when migrating from Fortran 77. In Fortran 77, a complex number composed of two REAL*8 numbers is a COMPLEX*16 variable. But in Fortran 90, a complex number composed of two REAL(8) numbers is a COMPLEX(8) variable.).

CHARACTER(80,1) MSG
MSG = 1_"Enter File Name"

(This topic amplifies topic 3.5 in the Fortran 90 Handbook.)

The Fortran 90 INCLUDE statement causes a specified file to be read by the compiler. When the argument of INCLUDE specifies an absolute path—that is, if it begins with a slash or a dot—the specified file is included.

INCLUDE "../hdrs/header1"

When the argument of INCLUDE specifies only a filename or a relative pathname, the compiler searches for the specified file in directories specified by the -I option and in standard locations for included files (see “Specifying Compiler Input Files”).

INCLUDE "hdrs/header1"

There is a limit of 98 on the depth of nesting included files. That is, the compiler supports a total of 99 source files concurrently open: the original source file and up to 98 included files.

(This topic amplifies topics 5.2, 5.3, and 12.5.3 in the Fortran 90 Handbook.)

Fortran 90 supports arrays whose actual shape is not known until run time. Assumed-shape arrays are dummy arguments whose shape is not declared in the procedure—they take the shape of the actual parameter passed. Deferred-shape arrays are array variables with the POINTER or ALLOCATABLE attribute—their shapes are specified when memory is allocated for them.

When a program accesses an element of an assumed-shape or deferred-shape array, the access is not direct, but indirect through a descriptor block in memory. As a result, two to four times as many machine instructions are needed to retrieve an element from one of these arrays than from an array of declared size.

In addition, there is no interface for passing an assumed-shape or deferred-shape array as an argument to a function written in C (as discussed in “Unsupported Array Parameters”).

(This topic amplifies topic 5.6.4 in the Fortran 90 Handbook.)

The SAVE attribute is implemented in different ways for different types of variables. This topic describes the one implementation of the compiler. However, this information is subject to change in future implementations. It would be unwise to write code that depended directly on this information.

Procedure Local Variables

Variables declared local to any procedure are allocated as part of the procedure's stack frame. They are released when the procedure returns.

---

Note: This means that in the current implementation, any function can be called recursively. However, Silicon Graphics can change the implementation of local variables in a future implementation. Always specify RECURSIVE with a function that you intend to be recursive.

---

A local variable with the SAVE attribute is not allocated in the procedure stack frame, but rather in a block storage segment. This means that there is only one fixed instance of the variable for the procedure. It retains its most recent value from one call of the procedure to another, or from one level of a recursive function to the next.

If different procedures have local variables with the same name and the SAVE attribute, each procedure has a unique block-storage allocation for its variable.

(This topic amplifies topic 5.7.2 in the Fortran 90 Handbook.)

MIPSpro Fortran 90 does not provide any intrinsic functions or subroutines other than the ones standardized in Fortran 90. For information on porting a Fortran 77 program that relies on nonstandard intrinsics, see “Differences in Intrinsic Functions”.

MIPSpro Fortran 90 does provide a large number of library functions for access to IRIX kernel functions (see “Support for IRIX Kernel Functions”). These are not “intrinsic” since their names are not recognized automatically by the compiler.

(This topic amplifies topic 6.5.1 in the Fortran 90 Handbook.)

The status returned from ALLOCATE or DEALLOCATE is 0 when the operation is performed, and 1 when it fails.

When the operation fails owing to a logical error such as deallocating a variable that has not been allocated, no other information is available. When an failure is due to a system condition such as a lack of memory, the system error number is recorded. You can retrieve the system error number with the ierrno() function, or display an error message on unit 0 using perror() (see the perror(3f) reference page).

ALLOCATE (AV(SZ),STAT=STAT)
IF (0 /= STAT) THEN
   IF (0 /= IERRNO()) THEN
      CALL PERROR("Allocating vector")
   ELSE
      WRITE (6,*)"Unknown error allocating vector"
   END IF
END IF

The MIPSpro Fortran 90 Handbook notes that the Fortran 90 standard permits the processor to skip the evaluation of parts of an array constructor under certain conditions. It is true that, in certain limited cases, MIPSpro Fortran 90 does omit evaluation of zero-sized array constructor elements. However, the rules for when this is done are complex and subject to change. Furthermore, the standard does not specify the order in which expressions and sub-expressions within a constructor are evaluated.

In general, you should assume that any expression within an array constructor will be evaluated. You should never write code that relies on the compiler not evaluating a constructor expression, or on its evaluating the constructor in any particular order.

(This topic amplifies topic 9.2.2 in the Fortran 90 Handbook.)

The values left in an IOSTAT variable following input are as follows:

(This topic amplifies topic 9.5.5 in the Fortran 90 Handbook.)

When a file is opened for sequential output and no specific RECL= argument is given, there is no maximum record length. The length of each record is determined by the data written to it.

The value of the RECL= specifier is interpreted as a count of bytes for formatted I/O and for sequential unformatted I/O. The value returned by INQUIRE(IOLENGTH) is always in terms of bytes.

In the single case of unformatted direct I/O, RECL= is interpreted as a count of 32-bit words (this behavior is for compatibility with some heritage Fortran 77 programs). You can change this behavior, forcing RECL= to be interpreted as a byte count in every case, by specifying the -bytereclen driver option (see “Specifying Source File Format”).

(This topic amplifies topic 10.9.4 in the Fortran 90 Handbook.)

The treatment of the Sign edit code "S" is processor dependent. MIPSpro Fortran 90 does not display a positive sign for "S" editing.

(This topic amplifies topic 11.2.1 in the Fortran 90 Handbook.)

Although according to the Fortran 90 standard a main program has no provision for receiving arguments, the main program is invoked from the IRIX command line, and it can access the command-line arguments using the getarg() library function (see the getarg(3) reference page). That function may not be available in systems from other vendors.

(This topic amplifies topic 2.1 and 11.6.6 in the Fortran 90 Handbook.)

MIPSpro Fortran 90 implements the MODULE statement automatically. When the compiler front-end encounters a MODULE statement, it checks the syntax of the contents of the module that follow.

When the syntax is valid, the compiler writes a .kmo file in the current directory. This is a small, printable file containing a summary of the accessible identifiers declared in the module. The name of the file is the name given in the MODULE statement, in uppercase letters.

When the compiler encounters a USE statement, it searches for a modname.kmo file (see “Specifying Compiler Input Files” for the search path). The contents of the file establish the names provided in that module.

As a result of these rules, a MODULE must be compiled before any USE statement for the module can be compiled.

The object code contained in a MODULE is generated when the MODULE is compiled. Procedures defined within the MODULE are named modname$procname_ in the object file; that is, the names are qualified by the module name. In other respects, these procedures generate code no different from that of other procedures in the same object file. The object code of a MODULE is stored and linked just like any other unit of object code. Compiled modules are not stored in any special location or format. (For hints on converting a MODULE to a DSO, see “Creating Dynamic Shared Objects”.)

To prepare and distribute a functional package based on a MODULE,

Using this approach, you do not have to distribute the source code of the module, only the summary .kmo file. The binding between accessible names in the module and the code that uses them is established at link time (or at load time for a DSO). As a result, you can distribute updated object files and the client programs do not have to be recompiled—as long as the names and data types of the accessible names are not changed.

(This topic amplifies topic 12.1.3 in the Fortran 90 Handbook.)

The current release of MIPSpro Fortran 90 allocates procedure local variables on the process stack (see “Treatment of the SAVE Attribute”). However, this is not a defined programming interface. You should always use the keyword RECURSIVE for any function that can be called recursively.

(This topic amplifies topic 12.3.4 in the Fortran 90 Handbook.)

The Fortran 90 Handbook indicates (section 12.3.4, rule 2) that there is ambiguity in the language standard regarding the use of array arguments to intrinsic functions (within the context of a statement function). MIPSpro Fortran 90 does not permit the use of array arguments to intrinsics within a statement function.

(This topic amplifies topic A.83 in the Fortran 90 Handbook.)

The pseudorandom number generator used to implement the RANDOM_NUMBER function was originally described in “Toward a Universal Random Number Generator” by George Marsaglia and Arif Zaman (Florida State University Report: FSU-SCRI-87-50 (1987)). It was later modified by F. James and published in “A Review of Pseudo-Random Number Generators.” It is thought to be the best available random generator. It passes all tests for random number generators and has a period of 2¹⁴⁴.

The algorithm is a combination of a Fibonacci sequence (with lags of 97 and 33, and operation “subtraction plus one, modulo one”) and an arithmetic sequence using subtraction.

The RANDOM_SEED function takes two seed integers,

A change in either ij or kl produces a new sequence of length approximately 10³⁰. For example, if several groups are working on parts of the same calculation, each group could be assigned its own ij seed number, leaving it with 30,081 choices for kl.

To test the random generator, use the code shown in Example 2-2.

integer seed(2)
   real first20k(20000), next6(6)
   seed(1) = 1802
   seed(2) = 9373
   call random_seed(put=seed(1:2))
   call random_number(harvest=first20k)
   call random_number(harvest=next6)
   do j=1,6
      write (6,"(F10.1)") (4096*4096*next6(j))
   end do
end

The output from this test should be the following numbers:

 6533892.0
14220222.0
 7275067.0
 6172232.0
 8354498.0
10633180.0