Section Extrinsic Procedures 1 1 1 1 1 1 1 1 0 1 This chapter defines the mechanism by which HPF programs may call non-hpf subprograms as extrinsic procedures. It provides the information needed to write an explicit interface for a non-hpf procedure. It defines the means for handling distributed and replicated data at the interface. This allows the programmer to use non-fortran language facilities, perhaps to descend to a lower level of abstraction to handle problems that are not efficiently addressed by HPF, to hand-tune critical kernels, or to call optimized libraries. This interface can also be used to interface HPF to other languages, such as C. Advice to implementors. Annex A describes a suggested approach to supporting the coding of single-processor "node" code in single-processor Fortran 0 or in a singleprocessor subset of HPF; the idea is that only data that is mapped to a given physical processor is accessible to it. This allows the programming of MIMD multiprocessor machines in a single-program multiple-data (SPMD) style. (End of advice to implementors.) o.1 Overview 1 It may be desirable for an HPF program to call a procedure written in a language other than HPF. Such a procedure might be written in any of a number of languages: A single-thread-of-control language not unlike HPF, where one copy of the procedure is conceptually executing and there is a single locus of control within the program text. A multiple-thread-of-control language, perhaps with dynamic assignment of loop iter- o ations to processors or explicit dynamic process forking, where again there is, at least 1 initially (upon invocation) one copy of the procedure that is conceptually executing but which may spawn multiple loci of control, possibly changing in number over time, within the program text. Any programming language targeted to a single processor, with the understanding that many copies of the procedure will be executed, one on each processor; this is frequently referred to as SPMD (Single Program, Multiple Data) style. We refer to a procedure written in this fashion as a local procedure.
SECTION. EXTRINSIC PROCEDURES A local procedure might be written in Fortran, Fortran 0, C, Ada, or Pascal, for example. A particularly interesting possibility is that a local procedure might be written in HPF! Not all HPF facilities may be used in writing local code, because some facilities address the question of executing on multiple processors and local code by definition runs on a single processor. See Annex A. A called procedure that is written in a language other than HPF, whether or not it uses the local procedure execution model should be declared EXTRINSIC within an HPF 1 program that calls it. The EXTRINSIC prefix declares what sort of interface should be used when calling indicated subprograms.. Definition and Invocation of Extrinsic Procedures An explicit interface must be provided for each extrinsic procedure entry in the scope where 1 it is called, using an interface block. This interface defines the "HPF view" of the extrinsic 1 procedure. 1 1 H01 extrinsic-prefix is EXTRINSIC ( extrinsic-kind-keyword ) H0 extrinsic-kind-keyword is HPF or HPF _LOCAL An extrinsic-prefix may appear in a subroutine-stmt or function-stmt (as defined in the Fortran 0 standard) in the same place that the keyword RECURSIVE might appear. See Section. for the extended forms of the grammar rules for function-stmt and subroutinestmt covering this case. The extrinsic-kind-keyword indicates the kind of extrinsic interface to be used. (It may be helpful to think of this name as being to the subprogram calling interface what a KIND parameter is for a numeric type. However, an extrinsic-kind is not integer-valued; it is merely a keyword.) HPF defines two such keywords: HPF and HPF LOCAL. The keyword HPF LOCAL is intended for use in calling routines coded in the "local HPF" style described in Annex A. The keyword HPF refers to the interface normally used for calling ordinary HPF routines. Thus writing EXTRINSIC (HPF) in an HPF program has exactly the same effect as not using an EXTRINSIC specifier at all. Rationale. HPF defines the extrinsic-kind-keyword HPF primarily to set an example for other programming languages that might adopt this style of interface specification. For example, in an extended Fortran 0 compiler it would not be redundant to specify EXTRINSIC(HPF), though it might be redundant to specify EXTRINSIC(F0). In a C compiler it would not be redundant to specify extrinsic (hpf). (End of rationale.) A subprogram with an extrinsic interface lies outside the scope of HPF. However, explicit interfaces to such subprograms must conform to HPF. Note that any particular HPF implementation is free to support any selection of extrinsic kind keywords, or none at all except for HPF itself. Examples: 1 1 1 1 0 1 0 1 0 1
.. DEFINITION AND INVOCATION OF EXTRINSIC PROCEDURES 1 1 1 1 1 1 1 INTERFACE EXTRINSIC(HPF_LOCAL) FUNCTION BAGEL(X) REAL X(:) REAL BAGEL(0) DISTRIBUTE (CYCLIC) END FUNCTION X, BAGEL INTERFACE OPERATOR (+) EXTRINSIC(C_LOCAL) FUNCTION LATKES(X, Y) REAL, DIMENSION(:,:) ::X REAL, DIMENSION(SIZE(X,1), SIZE(X,)).. Y, Z ALIGN WITH X:: Y, Z DISTRIBUTE (BLOCK, BLOCK) X END FUNCTION INTERFACE KNISH RESULT(Z) 1 0 1 FUNCTION RKNISH(X) REAL X(:), RKNISH END RKNISH EXTRINSIC(SISAL) FUNCTION CKNISH(X) COMPLEX X(:), CKNISH END CKNISH!normal HPF interface!extrinsic interface 0 1 0 1 In the last interface block, two external procedures, one of them extrinsic and one not, are associated with the same generic procedure name, which returns a scalar of the same type as its array argument. The intent is that a call to an extrinsic subprogram behaves, as observed by a calling program coded in HPF, exactly as if the subprogram has been coded in HPF. Advice to implementors. This is an obligation placed on the implementation of the interface and perhaps on the programmer when coding an extrinsic routine. However, it is also desirable to grant a certain freedom of implementation strategy so long as the obligation is satisfied. To this end an implementation may place certain restrictions on the programmer; moreover, each extrinsic-kind-keyword may call for a different set of restrictions. For example, an implementation on a parallel processor may find it convenient to replicate scalar arguments so as to provide a copy on every processor. This is permitted so long as this process is invisible to the caller. One way to achieve this is to place a restriction on the programmer: on return from the subprogram, all the copies of this scalar argument must have the same value. This implies that if the dummy argument has INTENT(OUT), then all copies must have been updated consistently by the time of subprogram return. (End of advice to implementors.)
1 SECTION. EXTRINSIC PROCEDURES. Requirements on the Called Extrinsic Procedure HPF requires a called extrinsic procedure to satisfy the following behavioral requirements: 1. The overall implementation must behave as if all actions of the caller preceding the subprogram invocation are completed before any action of the subprogram is executed; and as if all actions of the subprogram are completed before any action of the caller following the subprogram invocation is executed.. IN/OUT intent restrictions declared in the interface for the extrinsic subroutine must be obeyed.. Replicated variables, if updated, must be updated consistently. More precisely, if 1 a variable accessible to a local subprogram has a replicated representation and is 1 updated by (one or more copies of) the local subroutine, then all copies of the repli- 1 cated data must have identical values when the last processor returns from the local 1 procedure. 1. No HPF variable is modified unless it could be modified by an HPF procedure with the same explicit interface.. When a subprogram returns and the caller resumes execution, all objects accessible to the caller after the call are mapped exactly as they were before the call. Advice to implementors. Note that, as with a non-extrinsic (that is, ordinary HPF) subprogram, actual arguments may be copied or remapped in any way, so long as the effect is undone on return from the subprogram. (End of advice to implementors.). Exactly the same set of processors are visible to the HPF environment before and after the subprogram call. The call to an extrinsic procedure that fulfills these rules is semantically equivalent to the execution of an ordinary HPF procedure. Annex A has examples of the use of local subprograms through extrinsic interfaces. 1 1 1 0 1 0 1 0 1
Industrial Engineering Multimedia The Scientific World Journal Volume 01 Volume 01 Applied Computational Intelligence and Soft Computing International Distributed Sensor Networks Volume 01 Volume 01 Volume 01 Fuzzy Systems Modelling & Simulation in Engineering Volume 01 Volume 01 Submit your manuscripts at Computer Networks and Communications Artificial Intelligence Volume 01 International Biomedical Imaging Volume 01 Artificial Neural Systems International Computer Engineering Computer Games Technology Volume 01 Software Engineering Volume 01 Volume 01 Volume 01 Volume 01 International Reconfigurable Computing Robotics Computational Intelligence and Neuroscience Human-Computer Interaction Volume 01 Volume 01 Electrical and Computer Engineering Volume 01 Volume 01 Volume 01