ASSERT

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

IDENT

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.

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.

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.

PSECT

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. ALIGN=val Alignment for the common block. Val must be a constant (0 through 9).

Refer to the "VAX Linker Reference ManuaL" for detailed information about default attributes of common blocks.

TITLE_and_SUBTITLE

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.

CONTEXT_SHARED

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.

DO_PARALLEL

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.

LOCKON_and_LOCKOFF

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.

PRIVATE

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.

SHARED

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.