|
HP OpenVMS Systems Documentation |
|
HP Fortran for OpenVMS
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Previous | Contents | Index |
An elemental intrinsic procedure has scalar dummy arguments that can be called with scalar or array actual arguments. If actual arguments are array-valued, they must have the same shape. There are many elemental intrinsic functions, but only one elemental intrinsic subroutine (MVBITS).
If the actual arguments are scalar, the result is scalar. If the actual arguments are array-valued, the scalar-valued procedure is applied element-by-element to the actual argument, resulting in an array that has the same shape as the actual argument.
The values of the elements of the resulting array are the same as if the scalar-valued procedure had been applied separately to the corresponding elements of each argument.
For example, if A and B are arrays of shape (5,6), MAX(A, 0.0, B) is an array expression of shape (5,6) whose elements have the value MAX(A (i, j), 0.0, B (i, j)), where i = 1, 2,..., 5, and j = 1, 2,..., 6.
A reference to an elemental intrinsic procedure is an elemental reference if one or more actual arguments are arrays and all array arguments have the same shape.
To facilitate references to non-Fortran procedures, HP Fortran provides built-in functions %DESCR, %REF, and %VAL to pass actual arguments; and %LOC, which computes the internal address of a storage item.
When a procedure is called, Fortran (by default) passes the address of the actual argument, and its length if it is of type character. To call non-Fortran procedures, you may need to pass the actual arguments in a form different from that used by Fortran.
The built-in functions %DESCR, %REF, and %VAL let you change the form of an actual argument. You must specify these functions in the actual argument list of a CALL statement or function reference. You cannot use them in any other context.
These functions specify how to pass an actual argument (for example, a) to a non-Fortran procedure, as follows:
| Function | Effect |
| %VAL ( a) | Passes argument a as an n-bit 1 immediate value. If a is integer (or logical) and shorter than n bits, it is sign-extended to an n-bit value. For complex data types, %VAL passes two n-bit arguments. |
| %REF ( a) | Passes argument a by reference. |
| %DESCR ( a) | Passes argument a by descriptor. |
Table 8-1 lists the HP Fortran defaults for argument passing, and the allowed uses of %DESCR, %REF, and %VAL.
| Allowed Functions | ||||
|---|---|---|---|---|
| Actual Argument Data Type |
Default | %VAL | %REF | %DESCR |
| Expressions: | ||||
| Logical | REF | Yes | Yes | Yes |
| Integer | REF | Yes | Yes | Yes |
| REAL(4) | REF | Yes | Yes | Yes |
| REAL(8) | REF | Yes | Yes | Yes |
| REAL(16) | REF | No | Yes | Yes |
| COMPLEX(4) | REF | Yes | Yes | Yes |
| COMPLEX(8) | REF | Yes | Yes | Yes |
| COMPLEX(16) | REF | No | Yes | Yes |
| Character | DESCR | No | Yes | Yes |
| Hollerith | REF | No | No | No |
| Aggregate 1 | REF | No | Yes | No |
| Derived | REF | No | Yes | No |
| Array Name: | ||||
| Numeric | REF | No | Yes | Yes |
| Character | DESCR | No | Yes | Yes |
| Aggregate 1 | REF | No | Yes | No |
| Derived | REF | No | Yes | No |
| Procedure Name: | ||||
| Numeric | REF | No | Yes | Yes |
| Character | DESCR | No | Yes | Yes |
The %VAL, %REF, and %DESCR functions override related cDEC$ ATTRIBUTE settings.
On how to use the %VAL, %REF, and %DESCR functions, see the
HP Fortran for OpenVMS User Manual.
The built-in function %LOC computes the internal address of a storage
item. It takes the following form:
The %LOC function produces an integer value that represents the
location of the given argument. The value is INTEGER(8). You can use
this integer value as an item in an arithmetic expression.
The LOC intrinsic function serves the same purpose as the %LOC built-in
function.
8.8.9.2 %LOC Function
arg
Is the name of an actual argument. It must be a variable, an
expression, or the name of a procedure. (It must not be the name of an
internal procedure or statement function.)
Every procedure has an interface, which consists of the name and characteristics of a procedure, the name and characteristics of each dummy argument, and the generic identifier (if any) by which the procedure can be referenced. The characteristics of a procedure are fixed, but the remainder of the interface can change in different scoping units.
If these properties are all known within the scope of the calling program, the procedure interface is explicit; otherwise it is implicit (deduced from its reference and declaration). The following table shows which procedures have implicit or explicit interfaces:
| Kind of Procedure | Interface |
|---|---|
| External procedure | Implicit 1 |
| Module Procedure | Explicit |
| Internal Procedure | Explicit |
| Intrinsic Procedure | Explicit |
| Dummy Procedure | Implicit 1 |
| Statement function | Implicit |
The interface of a recursive subroutine or function is explicit within the subprogram that defines it.
An explicit interface can appear in a procedure's definition, in an interface block, or both. (Internal procedures must not appear in an interface block.)
The following sections describe when explicit interfaces are required,
how to define explicit interfaces, and how to define generic names,
operators, and assignment.
8.9.1 Determining When Procedures Require Explicit Interfaces
A procedure must have an explicit interface in the following cases:
Interface blocks define explicit interfaces for external or dummy procedures. They can also be used to define a generic name for procedures, a new operator for functions, and a new form of assignment for subroutines.
An interface block takes the following form:
|
generic-spec
Is one of the following:
- A generic name
- OPERATOR (op)
Defines a generic operator (op). It can be a defined unary, defined binary, or extended intrinsic operator.- ASSIGNMENT (=)
Defines generic assignment.interface-body
Is one or more function or subroutine subprograms. A function must end with END FUNCTION and a subroutine must end with END SUBROUTINE.The subprogram must not contain a statement function or a DATA, ENTRY, or FORMAT statement; an entry name can be used as a procedure name.
The subprogram can contain a USE statement.
name-list
Is the name of one or more module procedures that are accessible in the host. The MODULE PROCEDURE statement is only allowed if the interface block specifies a generic-spec and has a host that is a module (or accesses a module by use association).The characteristics of module procedures are not given in interface blocks, but are assumed from the module subprogram definitions.
Interface blocks can appear in the specification part of the program unit that invokes the external or dummy procedure.
A generic-spec can only appear in the END INTERFACE statement (a Fortran 95 feature) if one appears in the INTERFACE statement; they must be identical.
The characteristics specified for the external or dummy procedure must be consistent with those specified in the procedure's definition.
An interface block must not appear in a block data program unit.
An interface block comprises its own scoping unit, and does not inherit anything from its host through host association.
A procedure must not have more than one explicit interface in a given scoping unit.
A interface block containing generic-spec specifies a generic interface for the following procedures:
To make an interface block available to multiple program units (through a USE statement), place the interface block in a module.
The following rules apply to interface blocks containing pure procedures:
The following example shows a simple procedure interface block with no generic specification:
SUBROUTINE SUB_B (B, FB)
REAL B
...
INTERFACE
FUNCTION FB (GN)
REAL FB, GN
END FUNCTION
END INTERFACE
|
An interface block can be used to specify a generic name to reference all of the procedures within the interface block.
The initial line for such an interface block takes the following form:
|
generic-name
Is the generic name. It can be the same as any of the procedure names in the interface block, or the same as any accessible generic name (including a generic intrinsic name).
This kind of interface block can be used to extend or redefine a generic intrinsic procedure.
The procedures that are given the generic name must be the same kind of subprogram: all must be functions, or all must be subroutines.
Any procedure reference involving a generic procedure name must be resolvable to one specific procedure; it must be unambiguous. For more information, see Section 15.3.
The following is an example of a procedure interface block defining a generic name:
INTERFACE GROUP_SUBS
SUBROUTINE INTEGER_SUB (A, B)
INTEGER, INTENT(INOUT) :: A, B
END SUBROUTINE INTEGER_SUB
SUBROUTINE REAL_SUB (A, B)
REAL, INTENT(INOUT) :: A, B
END SUBROUTINE REAL_SUB
SUBROUTINE COMPLEX_SUB (A, B)
COMPLEX, INTENT(INOUT) :: A, B
END SUBROUTINE COMPLEX_SUB
END INTERFACE
|
The three subroutines can be referenced by their individual specific names or by the group name GROUP_SUBS.
The following example shows a reference to INTEGER_SUB:
INTEGER V1, V2 CALL GROUP_SUBS (V1, V2) |
On interface blocks, see Section 8.9.2.
8.9.4 Defining Generic Operators
An interface block can be used to define a generic operator. The only procedures allowed in the interface block are functions that can be referenced as defined operations.
The initial line for such an interface block takes the following form:
|
op
Is one of the following:
- A defined unary operator (one argument)
- A defined binary operator (two arguments)
- An extended intrinsic operator (number of arguments must be consistent with the intrinsic uses of that operator)
The functions within the interface block must have one or two nonoptional arguments with intent IN, and the function result must not be of type character with assumed length. A defined operation is treated as a reference to the function.
The following shows the form (and an example) of a defined unary and defined binary operation:
| Operation | Form | Example |
|---|---|---|
| Defined Unary | .defined-operator. operand 1 | .MINUS. C |
| Defined Binary | operand 2 .defined-operator. operand 3 | B .MINUS. C |
For intrinsic operator symbols, the generic properties include the intrinsic operations they represent. Both forms of each relational operator have the same interpretation, so extending one form (such as >=) defines both forms (>= and .GE.).
The following is an example of a procedure interface block defining a new operator:
INTERFACE OPERATOR(.BAR.)
FUNCTION BAR(A_1)
INTEGER, INTENT(IN) :: A_1
INTEGER :: BAR
END FUNCTION BAR
END INTERFACE
|
The following example shows a way to reference function BAR by using the new operator:
INTEGER B I = 4 + (.BAR. B) |
The following is an example of a procedure interface block with a defined operator extending an existing operator:
INTERFACE OPERATOR(+)
FUNCTION LGFUNC (A, B)
LOGICAL, INTENT(IN) :: A(:), B(SIZE(A))
LOGICAL :: LGFUNC(SIZE(A))
END FUNCTION LGFUNC
END INTERFACE
|
The following example shows two equivalent ways to reference function LGFUNC:
LOGICAL, DIMENSION(1:10) :: C, D, E N = 10 E = LGFUNC(C(1:N), D(1:N)) E = C(1:N) + D(1:N) |
| Previous | Next | Contents | Index |