VMS Help
FORTRAN, Statements, Directive Statements
*Conan The Librarian (sorry for the slow response - running on an old VAX)
|
|
CDEC$ ALIAS name, external-name
CDEC$ ASSERT (e)
CDEC$ END OPTIONS (see CDEC$ OPTIONS)
CDEC$ IDENT string
CDEC$ INIT_DEP_FWD
CDEC$ NOVECTOR
CDEC$ OPTIONS /qual...
CDEC$ PSECT /common-name/ attr [,attr,...]
CDEC$ SUBTITLE string
CDEC$ TITLE string
CPAR$ CONTEXT_SHARED var_name[,...,var_name]
CPAR$ CONTEXT_SHARED_ALL
CPAR$ DO_PARALLEL [distribution-size]
CPAR$ LOCKON lock-variable
CPAR$ LOCKOFF lock-variable
CPAR$ PRIVATE name[,...,name]
CPAR$ PRIVATE_ALL
CPAR$ SHARED common_name[,...,common_name]
CPAR$ SHARED_ALL
You can use directives in a Fortran source program to influence
certain aspects of the compilation process.
Directives are prefixed, starting in column 1, with a 5-character
identifier and a space (or tab). Directives prefixed with CDEC$
are enabled in all Fortran compilation units, regardless of the
qualifiers used on the FORTRAN command line.
Directives may also be prefixed with a first character of ! (!DEC$
or !PAR$) in any column of a source line as long as only whitespace
(blanks or tabs) precedes the directive prefix.
Directives prefixed with CPAR$ are enabled only in Fortran
compilation units involved in parallel processing (that is, when
the /PARALLEL qualifier is specified on the FORTRAN command line).
If the /PARALLEL qualifier is not specified, parallel-processing
directives (CPAR$ directives) are interpreted as comment lines.
A directive statement cannot be continued across multiple lines in
a source program, and any blanks appearing after column 6 are
insignificant.
Continuation lines cannot appear in directive statements.
If a blank common block is used in a compiler directive, it must be
specified as two slashes (/ /).
CDEC$ ALIAS name, external-name
The ALIAS directive lets you specify an alternate external name to
be used when referring to external objects such as subroutines and
functions. This can be useful when compiling applications written
for other platforms which have different naming conventions.
The external-name may be an identifier or a quoted character constant.
If a quoted character constant is specified, it is used as-is; the
string is not changed to upper case nor are blanks removed. Names
which are not acceptable to the OpenVMS linker will cause link-time
errors.
The ALIAS directive affects only the external name used for references
to the specified internal name.
CDEC$ ASSERT (log-exp)
or in statement form:
ASSERT (log-exp)
log-exp Is a logical expression.
The ASSERT directive (also available in statement form) provides
the compiler with information to improve optimization (particularly
if vectorization or automatic decomposition for parallel processing
is being performed). The directive can also be used to provide a
form of error checking in user applications.
The ASSERT directive tells the compiler that "log-exp" evaluates as
.TRUE. at the location in the program unit where the ASSERT
appears.
If the compiler option /CHECK=ASSERTIONS (or
OPTIONS/CHECK=ASSERTIONS) is in effect, the compiler adds run-time
code to verify the asserted expression; if the expression evaluates
as .FALSE., a run-time error is signaled.
The following is an example of how to use the CDEC$ ASSERT
directive for error checking (the program is compiled using the
compiler option /CHECK=ASSERTIONS:
CDEC$ ASSERT (ICOUNT .NE. 0)
IVAL = IVAL / ICOUNT ! Avoid zero-divide exception
CDEC$ IDENT string
The IDENT directive lets you specify a string that can be used to
identify 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 string that you specify
can consist of a group of up to 31 printable characters delimited
by apostrophes.
Only the first IDENT directive is effective -- the compiler ignores
any additional IDENT directives in a program unit.
CDEC$ INIT_DEP_FWD
The INIT_DEP_FWD (INITialize DEPendences ForWarD) directive
specifies that the compiler is to begin its dependence analysis by
assuming all dependences occur in the same forward direction as
their appearance in the normal scalar execution order. This
contrasts with the normal compiler behavior, which is for the
dependence analysis to make no initial assumptions about the
direction of a dependence.
The INIT_DEP_FWD directive must precede the DO statement for each
DO loop. No source code lines, other than the following, can be
placed between the INIT_DEP_FWD directive statement and the DO
statement: an optional CPAR$ DO_PARALLEL directive, a CDEC$
NOVECTOR directive, placeholder lines, comment lines, or blank
lines.
CDEC$ NOVECTOR
The CDEC$ NOVECTOR directive tells the compiler not to vectorize
the DO loop following the directive. This is useful in cases where
the vectorized form would not perform as well as the scalar form.
This directive is only available on VAX processors.
The NOVECTOR directive must precede the DO statement for each DO
loop to which you want the directive to apply. No source code
lines, other than the following can be placed between the NOVECTOR
directive statement and the DO statement: an optional CPAR$
DO_PARALLEL directive, a CDEC$ INIT_DEP_FWD directive, placeholder
lines, comment lines, or blank lines.
|
6 - OPTIONS and ENDOPTIONS
|
CDEC$ OPTIONS
The OPTIONS directive controls whether the Compaq Fortran compiler
naturally aligns fields in records and data items in common blocks
for performance reasons, or whether the compiler packs those fields
and data items together on arbitrary byte boundaries. The OPTIONS
directive takes the following form:
CDEC$ OPTIONS /[NO]ALIGN[=p] /[NO]WARNINGS=[NO]ALIGNMENT
.
.
.
CDEC$ END OPTIONS
p Is a specifier with one of the following forms:
[class =] rule
(class = rule,...)
ALL
NONE
class Is one of the following keywords:
COMMONS (for common blocks)
RECORDS (for records)
STRUCTURES (a synonym for RECORDS)
rule Is one of the following keywords:
PACKED - Packs fields in records or data
items in common blocks on arbitrary
byte boundaries.
NATURAL - Naturally aligns fields in records
and data items in common blocks on
up to 64-bit boundaries (inconsistent
with the FORTRAN-77 standard).
If you specify NATURAL, the compiler will
naturally align all data in a common
block, including REAL*8, and
all COMPLEX data.
STANDARD - Naturally aligns data items in common
blocks on up to 32-bit boundaries (con-
sistent with the FORTRAN-77 standard).
Note that this keyword only applies to
common blocks; therefore, you can specify
/ALIGN=COMMONS=STANDARD, but you cannot
specify /ALIGN=STANDARD.
ALL Is the same as /ALIGN, /ALIGN=NATURAL, and
/ALIGN=(RECORDS=NATURAL,COMMONS=NATURAL).
NONE Is the same as /NOALIGN, /ALIGN=PACKED, and
/ALIGN=(RECORDS=PACKED,COMMONS=PACKED)
CDEC$ OPTIONS (and accompanying CDEC$ END OPTIONS) directives must
come after OPTIONS, SUBROUTINE, FUNCTION, and BLOCK DATA statements
(if any) in the program unit, and before statement functions or the
executable part of the program unit.
For performance reasons, Compaq Fortran always aligns local data items
on natural boundaries. However, EQUIVALENCE, COMMON, RECORD, and
STRUCTURE data declaration statements can force misaligned data.
You can use the OPTIONS directive to control the alignment of
fields associated with COMMON and RECORD statements. By default,
you do not receive compiler messages when misaligned data is
encountered.
To request aligned data in a record structure, specify
/ALIGN=RECORDS=NATURAL, or consider placing source data declarations
for the record so that the data is naturally aligned.
NOTE
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 /ALIGN
compiler option) minimizes misaligned data.
To request aligned, data in common blocks, specify
/ALIGN=COMMONS=STANDARD (for data items up to 32 bits in length) or
/ALIGN=COMMONS=NATURAL (for data items up to 64 bits in length), or
place source data declarations within the common block in
descending size order, so that each data field is naturally
aligned.
The OPTIONS directive supersedes the /ALIGN compiler option.
OPTIONS directives must be balanced and can be nested up to 100
levels, for example:
CDEC$ OPTIONS /ALIGN=PACKED ! Group A
declarations
CDEC$ OPTIONS /ALIGN=RECO=NATU ! Group B
more declarations
CDEC$ END OPTIONS ! End of Group B
still more declarations
CDEC$ END OPTIONS ! End of Group A
Note that common blocks within Group B will be PACKED. The CDEC$
OPTION specification for Group B only applies to RECORDS, so
COMMONS retains the previous setting (in this case, from the Group
A specification).
For more information on alignment and data sizes, see your user
manual.
The /WARNINGS qualifier may be specified to control whether or not
alignment warnings are given for STRUCTURE and COMMON declarations
within the scope of this CDEC$ OPTIONS directive. Warnings are given
only if /WARNINGS=ALIGNMENT was also specified on the command line;
use the directive qualifier to disable alignment warnings for selected
declarations.
For COMMON blocks, all declarations and directives naming the COMMON
block must have the same setting for /WARNINGS=ALIGNMENT. For example:
CDEC$ OPTIONS /WARN=ALIGNMENT
COMMON /CMN/ X
CDEC$ END OPTIONS
CDEC$ OPTIONS /WARN=NOALIGNMENT
SAVE /CMN/
CDEC$ END OPTIONS
will result in a warning message from the compiler. The initial state
is taken from the value of /WARNINGS=ALIGNMENT on the command line.
CDEC$ PSECT /common-name/ attr [,attr,...]
The PSECT directive lets you modify several attributes of a common
block.
You specify the name of a common block, preceded and followed by a
slash, and one of the following attributes:
LCL Local scope.
GBL Global scope.
[NO]WRT Writability or no-writability.
[NO]SHR Shareability or no-shareability.
[NO]MULTILANGUAGE Length padded to multiple of alignment or not
ALIGN=val Alignment for the common block.
Val must be a constant (0 through 9).
Refer to the "OpenVMS Linker Reference Manual" for detailed information
about default attributes of common blocks.
CDEC$ TITLE string
CDEC$ SUBTITLE string
The TITLE directive lets you specify a string and place it in the
title field of a listing header. Similarly, SUBTITLE lets you
place a specified string in the subtitle field of a listing header.
The string that you specify can consist of up to 31 printable
characters and must be delimited by apostrophes.
In addition to the compiler-directive syntax rules, the TITLE and
SUBTITLE directives have the following specific rules:
o To enable TITLE and SUBTITLE directives, you must specify the
/LIST compiler option.
o When TITLE or SUBTITLE appears on a page of a listing file, the
specified string appears in the listing header of the following
page.
o If two or more of either directive appear on a page, the last
directive is the one in effect for the following page.
o If either directive does not specify a string, no change occurs
in the listing file header.
CPAR$ CONTEXT_SHARED var_name[,...,var_name]
CPAR$ CONTEXT_SHARED_ALL
CONTEXT_SHARED directives can be interspersed with declaration
statements within program units in a parallel-processing
application program. Variables (scalars, arrays, and records)
specified on a CONTEXT_SHARED directive reside in a shared memory
location throughout any one invocation of a subprogram (subroutine
or function), including any parallel loops contained within the
subprogram.
However, if a subprogram has several concurrent invocations
(because it is called from within a parallel loop), each invocation
will use different memory for these variables. This context
adjustment is handled automatically by the compiler and is not a
programming consideration.
By default, all variables in a routine compiled with the /PARALLEL
qualifier are context-shared.
Commas are required between variable names specified on a
CONTEXT_SHARED directive.
The CONTEXT_SHARED_ALL directive forces all symbols that are
declared within a routine to default to CONTEXT_SHARED. This
directive affects only default behavior. Individual symbols can
still be declared PRIVATE.
See your user manual for information about when to use directives
to resolve certain types of data dependence problems.
CPAR$ DO_PARALLEL [distribution-size]
The DO_PARALLEL compiler directive statement identifies an indexed
DO loop that is to be executed in parallel.
The DO_PARALLEL directive must precede the DO statement for each
parallel DO loop. No source code lines, other than the following
can be placed between the DO_PARALLEL directive statement and the
DO statement: a CDEC$ INIT_DEP_FWD directive, a CDEC$ NOVECTOR
directive, placeholder lines, comment lines, or blank lines.
You can specify how the DO loop iterations are to be divided up
among the processors executing the parallel DO loop. For example,
if a parallel DO loop has 100 iterations and you specify a
distribution size of 25, iterations will be distributed to each
processor for execution in sets of 25. When a process completes
one set of iterations, it then begins processing the next
unprocessed set. If the number that you specify for distribution
size does not divide evenly into the number of iterations, any
remaining iterations are run in the last process.
The expression that you use to specify the distribution size must
be capable of being evaluated as a positive, nonzero integer. If
necessary, it is converted to an integer. For example, 5.2 is
acceptable and is converted to 5. The number 0.2 is not
acceptable, however, because it is converted to 0.
CPAR$ LOCKON lock-variable
CPAR$ LOCKOFF lock-variable
The LOCKON and LOCKOFF compiler directive statements can be used
within a parallel DO loop to prevent multiple processes from
executing selected statements in parallel. These directives force
the multiple processes executing a parallel DO loop to execute
selected statements serially. This can be useful when a statement
(or set of statements) creates an unacceptable data dependence
problem that cannot be resolved by other means.
The lock variable can be a variable or a dummy argument. It must
have a data type of LOGICAL*4 and must have a status of shared
(SHARED directive). The lock is in effect when the lock variable
has a value of .TRUE. and unlocked when the lock variable has a
value of .FALSE.
The LOCKON and LOCKOFF directives perform the following operations:
LOCKON Waits, if necessary, for the lock variable to become
.FALSE., then sets it to .TRUE. (that is, locks the
lock), and then proceeds.
LOCKOFF Sets the lock variable to .FALSE. (that is, unlocks
the lock).
These directives use the VAX interlocked instructions to guarantee
proper synchronization on a multiprocessor. Do not use any other
statements to modify the lock variable while another process may be
executing a LOCKON or LOCKOFF directive.
See your user manual for examples of how locks are used in parallel
DO loops.
CPAR$ PRIVATE name[,...,name]
CPAR$ PRIVATE_ALL
PRIVATE directives can be interspersed with declaration statements
within program units in a parallel-processing application program.
The PRIVATE[_ALL] directive specifies those variables (scalars,
arrays, and records) and common blocks that must have unique memory
locations within each of the processes executing a parallel DO
loop.
PRIVATE_ALL causes all variables and common blocks declared in a
routine to default to private -- unless they are explicitly
declared as shared (for common blocks) or context-shared (for
variables). PRIVATE_ALL does not disallow the use of the SHARED
and CONTEXT_SHARED directives; it merely establishes the default
behavior for data sharing as PRIVATE, overriding the default
behavior (SHARED_ALL and CONTEXT_SHARED) established by the
/PARALLEL qualifier.
Commas are required between the names that you specify on PRIVATE
directives. In addition, common block names must be enclosed by
slashes (for example, /name/ or, for blank common, / /).
See your user manual for information about when to use directives
to resolve certain types of data dependence problems.
CPAR$ SHARED common_name[,...,common_name]
CPAR$ SHARED_ALL
SHARED directives can be interspersed with declaration statements
within program units in a parallel-processing application program.
The SHARED[_ALL] directive identifies those variables (scalar,
array, and record variables) and common blocks that are to be
shared among all the processes executing the compilation unit -- in
both parallel and nonparallel (serial) execution contexts.
SHARED_ALL does not disallow the use of the PRIVATE directive; it
merely reinforces the default behavior for data sharing established
by /PARALLEL. The default behavior associated with the /PARALLEL
qualifier is to give a status of shared to all common blocks
declared in a given compilation unit.
Note that any given common block should have the same status
(shared or private) in all subprograms in the parallel application.
The common block names must be enclosed by slashes (for example,
/name/ or, for blank common, / /). Commas are required between
names.
See your user manual for information about when to use directives
to resolve certain types of data dependence problems.
[legal]
[privacy]
[GNU]
[policy]
[netiquette]
[sponsors]
[FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.