|
HP OpenVMS Systems Documentation |
|
HP Fortran for OpenVMS
|
| Previous | Contents | Index |
The DEFINE directive creates a symbolic variable whose existence or value can be tested during conditional compilation. The UNDEFINE directive removes a defined symbol.
The DEFINE and UNDEFINE directives take the following forms: 1
|
c
Is one of the following: C (or c), !, or * (see Section 14.1).name
Is the name of the variable.val
Is an INTEGER(4) value assigned to name.
DEFINE and UNDEFINE create and remove variables for use with the IF (or IF DEFINED) directive. Symbols defined with the DEFINE directive are local to the directive. They cannot be declared in the Fortran program.
Because Fortran programs cannot access the named variables, the names can duplicate Fortran keywords, intrinsic functions, or user-defined names without conflict.
To test whether a symbol has been defined, use the IF DEFINED (name) directive You can assign an integer value to a defined symbol. To test the assigned value of name, use the IF directive. IF test expressions can contain most logical and arithmetic operators.
Attempting to undefine a symbol that has not been defined produces a compiler warning.
The DEFINE and UNDEFINE directives can appear anywhere in a program, enabling and disabling symbol definitions.
Consider the following:
!DEC$ DEFINE testflag
!DEC$ IF DEFINED (testflag)
WRITE (*,*) 'Compiling first line'
!DEC$ ELSE
WRITE (*,*) 'Compiling second line'
!DEC$ ENDIF
!DEC$ UNDEFINE testflag
|
1 The following forms are also allowed: !MS$DEFINE name[=val] and !MS$UNDEFINE name. |
The FIXEDFORMLINESIZE directive sets the line length for fixed-form
source code. The directive takes the following form: 1
You can set FIXEDFORMLINESIZE to 72 (the default), 80, or 132
characters. The FIXEDFORMLINESIZE setting remains in effect until the
end of the file, or until it is reset.
The FIXEDFORMLINESIZE directive sets the source-code line length in
include files, but not in USE modules, which are compiled separately.
If an include file resets the line length, the change does not affect
the host file.
This directive has no effect on free-form source code.
Consider the following:
14.6 FIXEDFORMLINESIZE Directive
c
Is one of the following: C (or c), !, or * (see Section 14.1).
CDEC$ NOFREEFORM
CDEC$ FIXEDFORMLINESIZE:132
WRITE(*,*) 'Sentence that goes beyond the 72nd column without continuation.'
1 The following form is also allowed: !MS$FIXEDFORMLINESIZE:{72|80|132}. |
The FREEFORM directive specifies that source code is in free-form
format. The NOFREEFORM directive specifies that source code is in
fixed-form format.
These directives take the following forms: 1
When the FREEFORM or NOFREEFORM directives are used, they remain in
effect for the remainder of the file, or until the opposite directive
is used. When in effect, they apply to include files, but do not affect
USE modules, which are compiled separately.
14.7 FREEFORM and NOFREEFORM Directives
c
Is one of the following: C (or c), !, or * (see Section 14.1).
1 The following forms are also allowed: !MS$FREEFORM and !MS$NOFREEFORM. |
The IDENT directive specifies a string that identifies an object
module. The compiler places the string in the identification field of
an object module when it generates the module for each source program
unit. The IDENT directive takes the following form:
Only the first IDENT directive is effective; the compiler ignores any
additional IDENT directives in a program unit or module.
14.8 IDENT Directive
c
Is one of the following: C (or c), !, or * (see Section 14.1).
string
Is a character constant containing up to 31 printable characters.
On syntax rules for all general directives, see Section 14.1.
The IF and IF DEFINED directives specify a conditional compilation
construct. IF tests whether a logical expression is .TRUE. or .FALSE..
IF DEFINED tests whether a symbol has been defined.
The directive-initiated construct takes the following form: 1
The IF and IF DEFINED directive constructs end with an ENDIF directive
and can contain one or more ELSEIF directives and at most one ELSE
directive. If the logical condition within a directive evaluates to
.TRUE. at compilation, and all preceding conditions in the IF construct
evaluate to .FALSE., then the statements contained in the directive
block are compiled.
A name can be defined with a DEFINE directive, and can
optionally be assigned an integer value. If the symbol has been
defined, with or without being assigned a value, IF DEFINED (name)
evaluates to .TRUE.; otherwise, it evaluates to .FALSE..
If the logical condition in the IF or IF DEFINED directive is .TRUE.,
statements within the IF or IF DEFINED block are compiled. If the
condition is .FALSE., control transfers to the next ELSEIF or ELSE
directive, if any.
If the logical expression in an ELSEIF directive is .TRUE., statements
within the ELSEIF block are compiled. If the expression is .FALSE.,
control transfers to the next ELSEIF or ELSE directive, if any.
If control reaches an ELSE directive because all previous logical
conditions in the IF construct evaluated to .FALSE., the statements in
an ELSE block are compiled unconditionally.
You can use any Fortran logical or relational operator or symbol in the
logical expression of the directive, including: .LT., <, .GT., >,
.EQ., ==, .LE., <=, .GE., >=, .NE., /=, .EQV., .NEQV., .NOT.,
.AND., .OR., and .XOR.. The logical expression can be as complex as you
like, but the whole directive must fit on one line.
Consider the following:
14.9 IF and IF DEFINED Directives
c
Is one of the following: C (or c), !, or * (see Section 14.1).
expr
Is a logical expression that evaluates to .TRUE. or .FALSE..
name
Is the name of a symbol to be tested for definition.
block
Are executable statements that are compiled (or not) depending on the
value of logical expressions in the IF directive construct.
! When the following code is compiled and run,
! the output depends on whether one of the expressions
! tests .TRUE., or all test .FALSE.
!DEC$ DEFINE flag=3
!DEC$ IF (flag .LT. 2)
WRITE (*,*) "This is compiled if flag less than 2."
!DEC$ ELSEIF (flag >= 8)
WRITE (*,*) "Or this compiled if flag greater than &
or equal to 8."
!DEC$ ELSE
WRITE (*,*) "Or this compiled if all preceding &
conditions .FALSE."
!DEC$ ENDIF
END
1 Each directive in the construct can begin with !MS$ instead of cDEC$ |
The INTEGER directive specifies the default integer kind. This
directive takes the following form: 1
The INTEGER directive specifies a size of 1 (KIND=1), 2 (KIND=2), 4
(KIND=4), or 8 (KIND=8) bytes for default integer numbers.
When the INTEGER directive is effect, all default integer variables are
of the kind specified in the directive. Only numbers specified or
implied as INTEGER without KIND are affected.
The INTEGER directive can only appear at the top of a program unit. A
program unit is a main program, an external subroutine or function, a
module or a block data program unit. The directive cannot appear
between program units, or at the beginning of internal subprograms. It
does not affect modules invoked with the USE statement in the program
unit that contains it.
The default logical kind is the same as the default integer kind. So,
when you change the default integer kind you also change the default
logical kind.
Consider the following:
14.10 INTEGER Directive
c
Is one of the following: C (or c), !, or * (see Section 14.1).
INTEGER i ! a 4-byte integer
WRITE(*,*) KIND(i)
CALL INTEGER2( )
WRITE(*,*) KIND(i) ! still a 4-byte integer
! not affected by setting in subroutine
END
SUBROUTINE INTEGER2( )
!DEC$ INTEGER:2
INTEGER j ! a 2-byte integer
WRITE(*,*) KIND(j)
END SUBROUTINE
1 The following form is also allowed: !MS$INTEGER:{2|4|8}. |
The IVDEP directive assists the compiler's dependence analysis. It can
only be applied to iterative DO loops. This directive can also be
specified as INIT_DEP_FWD (INITialize DEPendences ForWarD).
The IVDEP directive takes the following form:
The IVDEP directive is an assertion to the compiler's optimizer about
the order of memory references inside a DO loop.
The IVDEP directive tells the compiler to begin dependence analysis by
assuming all dependences occur in the same forward direction as their
appearance in the normal scalar execution order. This contrasts with
normal compiler behavior, which is for the dependence analysis to make
no initial assumptions about the direction of a dependence.
The IVDEP directive must precede the DO statement for each DO loop it
affects. No source code lines, other than the following, can be placed
between the IVDEP directive statement and the DO statement:
The IVDEP directive is applied to a DO loop in which the user knows
that dependences are in lexical order. For example, if two memory
references in the loop touch the same memory location and one of them
modifies the memory location, then the first reference to touch the
location has to be the one that appears earlier lexically in the
program source code. This assumes that the right-hand side of an
assignment statement is "earlier" than the left-hand side.
The IVDEP directive informs the compiler that the program would behave
correctly if the statements were executed in certain orders other than
the sequential execution order, such as executing the first statement
or block to completion for all iterations, then the next statement or
block for all iterations, and so forth. The optimizer can use this
information, along with whatever else it can prove about the
dependences, to choose other execution orders.
In the following example, the IVDEP directive provides more information
about the dependences within the loop, which may enable loop
transformations to occur:
In this case, the scalar execution order follows:
IVDEP directs the compiler to initially assume that when steps 1 and 5
access a common memory location, step 1 always accesses the location
first because step 1 occurs earlier in the execution sequence. This
approach lets the compiler reorder instructions, as long as it chooses
an instruction schedule that maintains the relative order of the array
references.
14.11 IVDEP Directive
c
Is one of the following: C (or c), !, or * (see Section 14.1).
!DEC$ IVDEP
DO I=1, N
A(INDARR(I)) = A(INDARR(I)) + B(I)
END DO
On syntax rules for all general directives, see Section 14.1.
The MESSAGE directive specifies a character string to be sent to the
standard output device during the first compiler pass; this aids
debugging.
This directive takes the following form: 1
Consider the following:
14.12 MESSAGE Directive
c
Is one of the following: C (or c), !, or * (see Section 14.1).
string
Is a character constant specifying a message.
!DEC$ MESSAGE:'Compiling Sound Speed Equations'
On syntax rules for all general directives, see Section 14.1.
1 The following form is also allowed: !MS$MESSAGE:string. |
The OBJCOMMENT directive specifies a library search path in an object
file. This directive takes the following form: 1
The linker searches for the library named by the OBJCOMMENT directive
as if you named it on the command line, that is, before default library
searches. You can place multiple library search directives in the same
source file. Each search directive appears in the object file in the
order it is encountered in the source file.
If the OBJCOMMENT directive appears in the scope of a module, any
program unit that uses the module also contains the directive, just as
if the OBJCOMMENT directive appeared in the source file using the
module.
If you want to have the OBJCOMMENT directive in a module, but do not
want it in the program units that use the module, place the directive
outside the module that is used.
Consider the following:
14.13 OBJCOMMENT Directive
c
Is one of the following: C (or c), !, or * (see Section 14.1).
library
Is a character constant specifying the name and, if necessary, the path
of the library that the linker is to search.
! MOD1.F90
MODULE a
!DEC$ OBJCOMMENT LIB: "opengl32.lib"
END MODULE a
! MOD2.F90
!DEC$ OBJCOMMENT LIB: "graftools.lib"
MODULE b
!
END MODULE b
! USER.F90
PROGRAM go
USE a ! library search contained in MODULE a
! included here
USE b ! library search not included
END
On syntax rules for all general directives, see Section 14.1.
1 The following form is also allowed: !MS$OBJCOMMENT LIB:library. |
The OPTIONS directive affects data alignment and warnings about data
alignment. It takes the following form:
The OPTIONS (and accompanying END OPTIONS) directives must come after
OPTIONS, SUBROUTINE, FUNCTION, and BLOCK DATA statements (if any) in
the program unit, and before the executable part of the program unit.
The OPTIONS directive supersedes the compiler option that sets
alignment and the compiler option that sets warnings about alignment.
For performance reasons, HP Fortran aligns local data items on
natural boundaries. However, EQUIVALENCE, COMMON, RECORD, and STRUCTURE
data declaration statements can force misaligned data. If
/WARN=NOALIGNMENT is specified, warnings will not be issued if
misaligned data is encountered.
14.14 OPTIONS Directive
c
Is one of the following: C (or c), !, or * (see Section 14.1).
option
Is one (or both) of the following:
Controls whether warnings are issued by the
compiler for data that is not naturally aligned. By default, you
receive compiler messages when misaligned data is encountered
(/WARN=ALIGNMENT).
Controls alignment of fields in record
structures and data items in common blocks. The fields and data items
can be naturally aligned (for performance reasons) or they can be
packed together on arbitrary byte boundaries.
p
Is a specifier with one of the following forms:
class
Is one of the following keywords:
rule
Is one of the following keywords:
Packs fields in records or data items in common blocks
on arbitrary byte boundaries.
Naturally aligns fields in records and data items in
common blocks on up to 64-bit boundaries (inconsistent with the Fortran
95/90 standard).
This keyword causes the compiler to naturally
align all data in a common block, including INTEGER(8), REAL(8), and
all COMPLEX data.
Naturally aligns data items in common blocks on up to
32-bit boundaries (consistent with the Fortran 95/90 standard).
This keyword only applies to common blocks; so, you can specify
/ALIGN=COMMONS=STANDARD, but you cannot specify
/ALIGN=STANDARD.
ALL
Is the same as specifying /ALIGN, /ALIGN=NATURAL, and
/ALIGN=(RECORDS=NATURAL,COMMONS=NATURAL).
NONE
Is the same as specifying /NOALIGN, /ALIGN=PACKED, and
/ALIGN=(RECORDS=PACKED,COMMONS=PACKED).
Misaligned data significantly increases the time it takes to execute a program. As the number of misaligned fields encountered increases, so does the time needed to complete program execution. Specifying cDEC$ OPTIONS/ALIGN (or the compiler option that sets alignment) minimizes misaligned data. |
If you want aligned data in common blocks, do one of the following:
If you want packed, unaligned data in a record structure, do one of the following:
An OPTIONS directive must be accompanied by an END OPTIONS directive; the directives can be nested up to 100 levels. For example:
CDEC$ OPTIONS /ALIGN=PACKED ! Start of Group A declarations CDEC$ OPTIONS /ALIGN=RECO=NATU ! Start of nested Group B more declarations CDEC$ END OPTIONS ! End of Group B still more declarations CDEC$ END OPTIONS ! End of Group A |
The CDEC$ OPTIONS specification for Group B only applies to RECORDS; common blocks within Group B will be PACKED. This is because COMMONS retains the previous setting (in this case, from the Group A specification).
| Previous | Next | Contents | Index |