From owner-hpff-doc Fri Jan 3 14:16:47 1997 Received: (from daemon@localhost) by cs.rice.edu (8.8.4/8.7.1) id OAA29408 for hpff-doc-out; Fri, 3 Jan 1997 14:16:47 -0600 (CST) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by cs.rice.edu (8.8.4/8.7.1) with ESMTP id OAA29328 for ; Fri, 3 Jan 1997 14:15:19 -0600 (CST) Received: from cst.ljo.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id OAA26183; Fri, 3 Jan 1997 14:55:04 -0500 (EST) Received: by cst.ljo.dec.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BBF986.4F4115E0@cst.ljo.dec.com>; Fri, 3 Jan 1997 14:56:33 -0500 Message-ID: From: David Loveman To: "'hpff-doc@cs.rice.edu'" Cc: David Loveman Subject: hpff-doc: revision to extrinsics.tex Date: Fri, 3 Jan 1997 14:57:21 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-hpff-doc Precedence: bulk --------------------------------------------------------------------------- hpff-doc@cs.rice.edu is a mailing list for HPF 2.0 language specification authors and editors. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- % File: extrinsics.tex % Contents: Extrinsics chapter for HPF 2.0 document % Revision history: % May-10-96 Created by Charles Koelbel, Rice University (from HPF 1.2 % document) % Aug-15-96 Draft stage new chapter (David Loveman) in interim stage (mez) % Sep-09-96 Next draft of chapter by David Loveman, Digital. % Oct-04-96 Revised draft of chapter by David Loveman, Digital. % Dec-10-96 Revised at HPFF meeting, Rice University, by David Loveman, Digital % Jan-03-96 Fixed small typos, added language="F77", clarified constraint % for external-name, restructured "Access to ..." section, % by David Loveman, Digital \chapter{Extrinsic Program Units} \label{ch-extrinsics} The HPF global model of computation extends (and restricts) Fortran to provide programmers with the Fortran model of computation implementable efficiently on a wide class of hardware architectures with, in general, multiple processors, multiple memories with non-uniform access characteristics, and multiple interconnections. This model of computation presents a single logical thread of control, including Fortran's data parallel features such as array syntax and the \texttt{FORALL} statement, and data visibility defined by the scoping rules of Fortran. In particular, this model does not require the use of low-level features such as threads libraries and explicit message passing to exploit such architectures. Programmers expect their HPF compilers to generate efficient code by using HPF's features to assist in mapping data and computation to the given hardware architecture. This chapter defines the \textit{extrinsic} mechanism by which HPF program units may use non-HPF program units that don't use the HPF global model. It describes how to write an explicit interface for a non-HPF procedure and defines the caller's assumptions about handling distributed and replicated data at the interface. This allows the programmer to use non-HPF language facilities, for example, 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. Such an interface can also be used to interface HPF to other languages, such as C. \section{Overview} An HPF program may need to call a procedure implemented in a different programming model or in a different programming language. A procedure's \emph{programming model} might provide: \begin{itemize} \item a single logical thread-of-control where \emph{one} copy of the procedure is conceptually executing and there is a single locus of control within the program text; this model is called \emph{global} when the underlying target hardware has (potentially) multiple processors or memories and is called \emph{serial} when the underlying target hardware is treated as a uniprocessor (or a single node in a multiprocessor), \item multiple threads-of-control, one per processor, each thread executing the same procedure; this model is called \emph{local} or, more generally, SPMD (Single Program, Multiple Data), or \item some other model, not discussed here, such as multiple threads-of-control, perhaps with dynamic assignment of loop iterations to processors or explicit dynamic process forking, where there is, at least initially upon invocation, \emph{one} copy of the procedure that is conceptually executing but that may spawn multiple loci of control, possibly changing in number over time, within the program text. \end{itemize} A \emph{programming language} provides a specific syntax (language features), semantics (meanings), and pragmatics (purposes). Examples of programming languages include Fortran (an ANSI and ISO standard---the most recent revision is expected to be approved by 1997), HPF (a specification of extensions and restrictions to Fortran), Fortran 77 (a previous ANSI and ISO standard), C, C++, Java, Visual Basic, and COBOL. A program unit's language and model, when taken together, constitute its \emph{extrinsic kind}. This \emph{extrinsic kind} may be specified explicitly by an \textit{extrinsic-prefix} or implicitly by the selection of a compiler and its invocation with a particular set of compiler options. Thus, one might view the compiler as providing a \emph{host scoping unit} as defined by Fortran. For example, a program unit compiled by an HPF compiler will be of extrinsic kind \texttt{HPF}. Alternatively, its extrinsic kind may be specified explicitly by an \textit{extrinsic-prefix} such as \texttt{EXTRINSIC(HPF)} or \texttt{EXTRINSIC(LANGUAGE="HPF", MODEL="GLOBAL")}. \section{Declaration of Extrinsic Program Units} \subsection{Function and Subroutine Statements} An \textit{extrinsic-prefix} may appear in a \textit{function-stmt} or \textit{subroutine-stmt} (as defined in the Fortran standard) in the same place that the keywords \texttt{RECURSIVE}, \texttt{PURE}, and \texttt{ELEMENTAL} may appear. This is specified by an extension of rule R1219 for \textit{prefix-spec} in the Fortran standard. Rules R1217 for \textit{function-stmt}, R1218 for \textit{prefix}, and R1222 for \textit{subroutine-stmt} are not changed, but are restated here for reference. \BNF function-stmt \IS [ prefix ] FUNCTION function-name ( [ dummy-arg-name-list ] ) [ RESULT ( result-name ) ] subroutine-stmt \IS [ prefix ] SUBROUTINE subroutine-name [ ( [ dummy-arg-list ] ) ] prefix \IS prefix-spec [ prefix-spec ] ... prefix-spec \IS type-spec \OR RECURSIVE \OR PURE \OR ELEMENTAL \OR extrinsic-prefix \FNB \begin{constraints} \item Within any HPF \textit{external-subprogram}, every \textit{internal-subprogram} must be of the same extrinsic kind as its host and any \textit{internal-subprogram} whose extrinsic kind is not given explicitly is assumed to be of that extrinsic kind. \end{constraints} The definition of \emph{characteristics of a procedure} as given in F95:12.2 is extended to include the procedure's extrinsic kind. \subsection{Program, Module, and Block Data Statements} An \textit{extrinsic-prefix} may also appear at the beginning of a \textit{program-stmt}, \textit{module-stmt}, or \textit{block-data-stmt}. The following syntax definition extends the Fortran 95 syntax rules R1102 for \textit{program-stmt}, R1105 for \textit{module-stmt}, and R1111 for \textit{block-data-stmt}. \BNF program-stmt \IS [ extrinsic-prefix ] PROGRAM program-name module-stmt \IS [ extrinsic-prefix ] MODULE module-name block-data-stmt \IS [ extrinsic-prefix ] BLOCK DATA [ block-data-name ] \FNB \begin{constraints} \item Every \textit{module-subprogram} of any HPF \textit{module} must be of the same extrinsic kind as its host, and any \textit{module-subprogram} whose extrinsic kind is not given explicitly is assumed to be of that extrinsic kind. \item Every \textit{internal-subprogram} of any HPF \textit{main-program} or \textit{module-subprogram} must be of the same extrinsic kind as its host, and any \textit{internal-subprogram} whose extrinsic kind is not given explicitly is assumed to be of that extrinsic kind. \end{constraints} \subsection{The Extrinsic Prefix} \BNF extrinsic-prefix \IS EXTRINSIC ( extrinsic-spec ) extrinsic-spec \IS extrinsic-spec-arg-list \OR extrinsic-kind-keyword extrinsic-spec-arg \IS language \OR model \OR external-name language \IS [ LANGUAGE = ] scalar-char-initialization-expr model \IS [ MODEL = ] scalar-char-initialization-expr external-name \IS [ EXTERNAL_NAME = ] scalar-char-initialization-expr \FNB \begin{constraints} \item In an \textit{extrinsic-spec-arg-list}, at least one of \textit{language}, \textit{model}, or \textit{external-name} must be specified and none may be specified more than once. \item If \textit{language} is specified without \texttt{LANGUAGE=}, \textit{language} must be the first item in the \textit{extrinsic-spec-arg-list}. If \textit{model} is specified without \texttt{MODEL=}, \textit{language} without \texttt{LANGUAGE=} must be the first item and \textit{model} must be the second item in the \textit{extrinsic-spec-arg-list}. If \textit{external-name} is specified without \texttt{EXTERNAL_NAME=}, \textit{language} without \texttt{LANGUAGE=} must be the first item and \textit{model} without \texttt{MODEL=} must be the second item in the \textit{extrinsic-spec-arg-list}. \item The forms with \texttt{LANGUAGE=}, \texttt{MODEL=}, and \texttt{EXTERNAL_NAME=} may appear in any order except as prohibited above. Note that these rules for \textit{extrinsic-spec-arg-list} are as if \texttt{EXTRINSIC} were a procedure with an explicit interface with a \textit{dummy-arg-list} of \texttt{LANGUAGE, MODEL, EXTERNAL_NAME}, each of which was \texttt{OPTIONAL}. \item In \textit{language}, values of \textit{scalar-char-initialization-expr} may be: \begin{itemize} \item \texttt{"HPF"}, referring to the HPF language; if a \textit{model} is not explicitly specified, the \textit{model} is implied to be \texttt{"GLOBAL"}; \item \texttt{"FORTRAN"}, referring to the ANSI/ISO standard Fortran language; if a \textit{model} is not explicitly specified, the \textit{model} is implied to be \texttt{"SERIAL"}; \item \texttt{"F77"}, referring to the former ANSI/ISO standard FORTRAN 77 language; if a \textit{model} is not explicitly specified, the \textit{model} is implied to be \texttt{"SERIAL"}; \item \texttt{"C"}, referring to the ANSI standard C programming language; if a \textit{model} is not explicitly specified, the \textit{model} is implied to be \texttt{"SERIAL"}; or \item an implementation-dependent value with an implementation-dependent implied \textit{model}. \end{itemize} Note that, for most implementations, \texttt{"C"} will only be allowed for \textit{function-stmt}s and \textit{subroutine-stmt}s occurring in an \textit{interface-body}. \item If language is not specified it is the same as that of the host scoping unit. \item In \textit{model}, values of \textit{scalar-char-initialization-expr} may be: \begin{itemize} \item \texttt{"GLOBAL"}, referring to the global model, \item \texttt{"LOCAL"}, referring to the local model, \item \texttt{"SERIAL"}, referring to the serial model, or \item an implementation-dependent value. \end{itemize} \item If \textit{model} is not specified or implied by the specification of a language, it is the same as that of the host scoping unit. \item All \textit{language}s and \textit{model}s whose names begin with the three letters \texttt{HPF} are reserved for present or future definition by this specification and its successors. \item In \textit{external-name}, the value of \textit{scalar-char-initialization-expr} is a character string whose use is determined by the extrinsic kind. For example, an extrinsic kind may use the \textit{external-name} to specify the name by which the procedure would be known if it were referenced by a C procedure. In such an implementation, a user would expect the compiler to perform any transformations of that name that the C compiler would perform. If \textit{external-name} is not specified, its value is implementation-dependent. \end{constraints} \BNF extrinsic-kind-keyword \IS HPF \OR HPF_LOCAL \OR HPF_SERIAL \FNB \begin{constraints} \item \texttt{EXTRINSIC(HPF)} is equivalent to \texttt{EXTRINSIC("HPF", "GLOBAL")}. In the absence of an \textit{extrinsic-prefix} an HPF compiler interprets a compilation unit as if it were of extrinsic kind \texttt{HPF}. Thus, for an HPF compiler, specifying \texttt{EXTRINSIC(HPF)} or \texttt{EXTRINSIC("HPF", "GLOBAL")} is redundant. Such explicit specification may, however, be required for use with a compiler that supports multiple extrinsic kinds. \item \texttt{EXTRINSIC(HPF_LOCAL)} is equivalent to \texttt{EXTRINSIC("HPF", "LOCAL")}. A \linebreak \textit{main-program} whose extrinsic kind is \texttt{HPF_LOCAL} behaves as if it were a subroutine of extrinsic kind \texttt{HPF_LOCAL} that is called with no arguments from a main program of extrinsic kind \texttt{HPF} whose executable part consists solely of that call. \item \texttt{EXTRINSIC(HPF_SERIAL)} is equivalent to \texttt{EXTRINSIC("HPF", "SERIAL")}. A \textit{main-program} whose extrinsic kind is \texttt{HPF_SERIAL} behaves as if it were a subroutine of extrinsic kind \texttt{HPF_SERIAL} that is called with no arguments from a main program of extrinsic kind \texttt{HPF} whose executable part consists solely of that call. \item All \textit{extrinsic-kind-keyword}s whose names begin with the three letters \texttt{HPF} are reserved for present or future definition by this specification and its successors. \end{constraints} \begin{implementors} Other \textit{language}s or \textit{model}s may be defined and provided by compiler vendors. Although not part of this HPF specification, they are expected to conform to the rules and spirit of HPF extrinsic kinds. An implementation may place certain restrictions on the programmer; moreover, each extrinsic kind 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 \texttt{INTENT(OUT)}, then all copies must have been updated consistently by the time of subprogram return. \end{implementors} \section{Calling HPF Extrinsic Subprograms} A call to an extrinsic procedure behaves, as observed by a calling program coded in HPF, exactly as if the subprogram were coded in HPF. If a function or subroutine called from a program unit of an HPF extrinsic kind does not have an explicit interface visible in the caller, it is assumed to have the same extrinsic kind as the caller. In order to call a subprogram of an extrinsic kind other than that of the caller, that subprogram must have an explicit interface visible in the caller, and the subprogram is expected to behave, as observed by the caller, roughly as if it had been written as code of the same extrinsic kind as the caller. Some of the responsibility for meeting this requirement may rest on the compiler and some on the programmer. This interface defines the ``HPF view'' of the extrinsic procedure. A called procedure that is written in a model or language other than HPF, whether or not it uses the local procedure execution model, should be declared \texttt{EXTRINSIC} within an HPF program that calls it. The \texttt{EXTRINSIC} prefix declares what sort of interface should be used when calling indicated subprograms. If there is no extrinsic specification, then the users must assume full responsibility for correctness of the implementation-dependent interface. A \textit{function-stmt} or \textit{subroutine-stmt} that appears within an \textit{interface-block} within a program unit of an HPF extrinsic kind may have an extrinsic prefix mentioning any extrinsic kind supported by the language implementation. If no \textit{extrinsic-prefix} appears in such a \textit{function-stmt} or \textit{subroutine-stmt}, then it is assumed to be of the same HPF extrinsic kind as the program unit in which the interface block appears. The procedure characteristics defined by an \textit{interface-body} must be consistent with the procedure's definition. The definition and rules for a procedure with an extrinsic interface lies outside the scope of HPF. However, explicit interfaces to such procedures must conform to HPF. Note that any particular HPF implementation is free to support any selection of extrinsic kinds, or none at all except for \texttt{HPF} itself, which clearly must be supported by an HPF implementation. \subsection{Access to Types, Procedures, and Data} \label{ext-access} In general, program units of a given extrinsic kind may use names of types, procedures, or data of another program unit of the same extrinsic kind, subject to the scoping rules of Fortran. Use of names of types, procedures, or data of another program unit of a different extrinsic kind are subject to additional restrictions summarized in Table \ref{access-table} and described below. Note that, if a module X of one HPF extrinsic kind is used by a program unit Y of another HPF extrinsic kind, then only names of items in X that Y is entitled to use or invoke may be use associated; that is, either X must make private all items that Y is not entitled to use, or the \texttt{USE} statement in Y must have an \texttt{ONLY} option that lists only names of items it is entitled to use. \begin{table} \def\QQ#1#2#3{\hbox to 5em{\textbf{#1}\quad\textbf{#2}\quad\textbf{#3}\hfill}} \begin{center} \begin{tabular}{|l|r|c|c|c|} \hline \multicolumn{2}{|c|}{} &\multicolumn{3}{c|}{\emph{Extrinsic kind of the used module}}\\\cline{3-5} \multicolumn{2}{|c|}{} &\texttt{HPF} &\texttt{HPF_SERIAL}&\texttt{HPF_LOCAL}\\\hline \emph{Extrinsic kind} &\texttt{HPF} & \QQ{T}{P}{D} & \QQ{T}{P}{ } & \QQ{T}{P}{ } \\ \cline{2-5} \emph{of the using} &\texttt{HPF_SERIAL}& \QQ{T}{ }{ } & \QQ{T}{P}{D} & \QQ{T}{ }{ } \\ \cline{2-5} \emph{program unit} &\texttt{HPF_LOCAL} & \QQ{T}{ }{ } & \QQ{T}{ }{ } & \QQ{T}{P}{D} \\\hline \multicolumn{5}{l} {}\\ \multicolumn{5}{l} {\textbf{T} = derived type definitions} \\ \multicolumn{5}{l} {\textbf{P} = procedures and procedure interfaces} \\ \multicolumn{5}{l} {\textbf{D} = data objects} \end{tabular} \end{center} \caption{Entities that a using program unit is entitled to access from a module, according to the HPF extrinsic kind of each. \label{access-table}} \end{table} \subsubsection{Types} Derived type definitions without explicitly mapped components may be thought of as ``extrinsic kind neutral''; a program unit of any HPF extrinsic kind may use derived type definitions from a module of any HPF extrinsic kind. Note that an Approved Extension permits the mapping of components of derived types. \subsubsection{Procedures} An HPF global program or procedure may call other HPF procedures that are global, local, or serial. An HPF local program or procedure may call only other HPF local procedures and not HPF global or serial procedures. An HPF serial program or procedure may call only other HPF serial procedures and not HPF global or local procedures. \subsubsection{Data} A named \texttt{COMMON} block in any program unit of an HPF kind will be associated with the \texttt{COMMON} block, if any, of that same name in every other program unit of that same extrinsic kind; similarly for unnamed \texttt{COMMON}. (Such \texttt{COMMON} storage behaves like other declared data objects within program units of that extrinsic kind; in particular, for \texttt{HPF_LOCAL} code there will be one copy of the \texttt{COMMON} block on each processor.) It is not permitted for any given \texttt{COMMON} block name to be used in program units of different HPF kinds within a single program; similarly, it is not permitted for unnamed \texttt{COMMON} to be used in program units of different HPF kinds within a single program. %A particular restriction is placed on HPF local procedures to be called %from an HPF procedure or global program: array dummy arguments and %array components of dummy arguments of a derived type must be declared %as assumed-shape, both in the definition of the subprogram itself and %in any interface blocks in other program units. \subsection{The Effect of a Call} A call to an extrinsic procedure must be semantically equivalent to a call of an ordinary HPF procedure that does not remap its arguments. Thus a call to an extrinsic procedure must behave \textit{as if} the following actions occur. The HPF technical term \textit{as if} means that the described actions should appear to a user as if they occurred, in the order specified; an implementation may carry out any actions in any order that provide the correct user-visible effects. \begin{enumerate} \item All actions of the caller preceding the subprogram invocation should be completed before any action of the subprogram is executed; and all actions of the subprogram should be completed before any action of the caller following the subprogram invocation is executed. \item Each actual argument is remapped, if necessary, according to the directives (explicit or implicit) in the declared interface for the extrinsic procedure. Thus, HPF mapping directives appearing in the interface are binding---the compiler must obey these directives in calling local extrinsic procedures. As in the case of non-extrinsic subprograms, actual arguments may be mapped in any way; if necessary, they are copied automatically to correctly mapped temporaries before invocation of---and copied back to the actual arguments after return from---the extrinsic procedure. Scalar dummy arguments and scalar function results behave as if they are replicated on each processor. These mappings may, optionally, be explicit in the interface, but any other explicit mapping is not HPF conforming. \item \texttt{IN}, \texttt{OUT}, and \texttt{INOUT} intent restrictions should be observed. \item No HPF variable is modified unless it could be modified by an HPF procedure with the same explicit interface. Note that even though \texttt{HPF_LOCAL} and \texttt{HPF_SERIAL} routines are not permitted to access and modify HPF global data, other kinds of extrinsic routines may do so to the extent that an HPF procedure could. \item When a procedure returns and the caller resumes execution, all objects accessible to the caller after the call are mapped exactly as they were before the call. In particular, the original distribution of arguments is restored, if necessary. \item Exactly the same set of processors is visible to the HPF environment before and after the subprogram call. \end{enumerate} \begin{implementors} \item To ensure that all actions that logically precede the call are completed, multiple processors may need to be synchronized before the call is made. \item If a variable accessible to the called routine has a replicated representation, then all copies may need to be updated prior to the call to contain the correct current value according to the sequential semantics of the source program. \item Replicated variables, if updated in the procedure, must be updated consistently. More precisely, if a variable accessible to a procedure has a replicated representation and is updated by (one or more copies of) the procedure, then all copies of the replicated variable must have identical values when the last processor returns from the local procedure. An implementation might check, before returning from the local subprogram, to make sure that replicated variables have been updated consistently by the subprogram. Note, however, that there is no requirement for an implementation to do so; it is merely an implementation tradeoff between speed and, for instance, debuggability. Note that, as with a global HPF subprogram, actual arguments may be copied or remapped in any way, so long as the effect is undone on return from the subprogram. \item To ensure that all actions of the procedure logically complete before execution in the caller is resumed, multiple processors may need to be synchronized after the call. \end{implementors} \section{Examples of Extrinsic Procedures} Consider: \CODE PROGRAM DUMPLING INTERFACE EXTRINSIC("HPF","LOCAL") SUBROUTINE GNOCCHI(P, L, X) INTERFACE SUBROUTINE P(Q) REAL Q END SUBROUTINE P EXTRINSIC("COBOL","LOCAL") SUBROUTINE L(R) REAL R(:,:) END SUBROUTINE L END INTERFACE REAL X(:) END SUBROUTINE GNOCCHI EXTRINSIC("HPF","LOCAL") SUBROUTINE POTSTICKER(Q) REAL Q END SUBROUTINE POTSTICKER EXTRINSIC("COBOL","LOCAL") SUBROUTINE LEBERKNOEDEL(R) REAL R(:,:) END SUBROUTINE LEBERKNOEDEL END INTERFACE ... CALL GNOCCHI(POTSTICKER, LEBERKNOEDEL, (/ 1.2, 3.4, 5.6 /) ) ... END PROGRAM DUMPLING \EDOC The main program, \texttt{DUMPLING}, when compiled by an HPF compiler, is implicitly of extrinsic kind \texttt{HPF}. Interfaces are declared to three external subroutines \texttt{GNOCCHI}, \texttt{POTSTICKER}, and \texttt{LEBERKNOEDEL}. The first two are of extrinsic kind \texttt{HPF_LOCAL} and the third is of an extrinsic kind specified by the language \texttt{COBOL} and the local model. Now, \texttt{GNOCCHI} accepts two dummy procedure arguments and so interfaces must be declared for those. Because no \textit{extrinsic-prefix} is given for dummy argument \texttt{P}, its extrinsic kind is that of its host scoping unit, the declaration of subroutine \texttt{GNOCCHI}, which has extrinsic kind \texttt{HPF_LOCAL}. The declaration of the corresponding actual argument \texttt{POTSTICKER} needs to have an explicit \textit{extrinsic-prefix} because its host scoping unit is program \texttt{DUMPLING}, of extrinsic kind \texttt{HPF}. Here are some more examples. In the first example, note that the declaration of the explicit size of \texttt{BAGEL} as 100 refers to its \textit{global} size and not its local size: \CODE INTERFACE EXTRINSIC("HPF","LOCAL") FUNCTION BAGEL(X) REAL BAGEL(100) REAL X(:) !HPF$ DISTRIBUTE (CYCLIC) :: BAGEL, X END FUNCTION END INTERFACE \EDOC In the next example, note that the \texttt{ALIGN} statement asserts that \texttt{X}, \texttt{Y}, and \texttt{Z} all have the same shape: \CODE INTERFACE OPERATOR (+) EXTRINSIC("C","LOCAL") FUNCTION LATKES(X, Y) RESULT(Z) REAL, DIMENSION(:,:), INTENT(IN) :: X REAL, DIMENSION(:,:), INTENT(IN) :: Y REAL, DIMENSION(SIZE(X,1), SIZE(X,2)) :: Z !HPF$ ALIGN WITH X :: Y, Z !HPF$ DISTRIBUTE (BLOCK, BLOCK) X END FUNCTION END INTERFACE \EDOC In the interface block in this final example, 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: \CODE INTERFACE KNISH FUNCTION RKNISH(X) !normal HPF interface REAL X(:), RKNISH END RKNISH EXTRINSIC("SISAL") FUNCTION CKNISH(X) !extrinsic interface COMPLEX X(:), CKNISH END CKNISH END INTERFACE \EDOC --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-doc-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-doc Fri Jan 3 16:10:42 1997 Received: (from daemon@localhost) by cs.rice.edu (8.8.4/8.7.1) id QAA02105 for hpff-doc-out; Fri, 3 Jan 1997 16:10:42 -0600 (CST) Received: from [128.42.5.162] (pasyn-36.rice.edu [128.42.5.164]) by cs.rice.edu (8.8.4/8.7.1) with ESMTP id QAA02072; Fri, 3 Jan 1997 16:09:20 -0600 (CST) X-Sender: chk@titan.cs.rice.edu Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 3 Jan 1997 15:54:50 -0600 To: David Loveman From: Chuck Koelbel Subject: Re: hpff-doc: revision to extrinsics.tex Cc: "'hpff-doc@cs.rice.edu'" , David Loveman Sender: owner-hpff-doc Precedence: bulk --------------------------------------------------------------------------- hpff-doc@cs.rice.edu is a mailing list for HPF 2.0 language specification authors and editors. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- The new extrinsics.tex is now (being) installed in "the usual place" as document version 2.0.nu. BTW, anybody have a recommendation for version numbers when we run out of Greek letters? Chuck ************************************************************ Chuck Koelbel Research Scientist Center for Research on Parallel Computation Rice University "History is made at night. Character is what you are in the dark." ************************************************************ --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-doc-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-doc Mon Jan 6 09:00:38 1997 Received: (from daemon@localhost) by cs.rice.edu (8.8.4/8.7.1) id JAA22626 for hpff-doc-out; Mon, 6 Jan 1997 09:00:38 -0600 (CST) Received: from dns.whnet.edu.cn (dns.whnet.edu.cn [202.112.20.131]) by cs.rice.edu (8.8.4/8.7.1) with SMTP id IAA22602 for ; Mon, 6 Jan 1997 08:59:24 -0600 (CST) Received: from ns ([202.197.16.1]) by dns.whnet.edu.cn (5.x/SMI-SVR4) id AA15153; Mon, 6 Jan 1997 20:36:27 +0800 Received: from ns.csit.edu.cn by ns (4.1/SMI-4.1) id AA16347; Mon, 6 Jan 97 20:38:24 CST Date: Mon, 6 Jan 1997 20:38:19 +0800 (CST) From: "Mr. Zhibin Wu" To: hpff-doc@cs.rice.edu Subject: hpff-doc: want hpf2.0 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hpff-doc Precedence: bulk --------------------------------------------------------------------------- hpff-doc@cs.rice.edu is a mailing list for HPF 2.0 language specification authors and editors. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Dear sir: I am a chinese student.My main working is to design some directives as data partition,control parallel,redistibute and communication to suit for the hypernode SPP architecture.I am less farmiliar to those thing.from the WEB I know the HPF V2.0,but I can't transmit it(ftp or from your homepage),could you give the specification to me through the E-MAIL. thank you! --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-doc-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-doc Wed Jan 8 18:47:39 1997 Received: (from daemon@localhost) by cs.rice.edu (8.8.4/8.7.1) id SAA05884 for hpff-doc-out; Wed, 8 Jan 1997 18:47:39 -0600 (CST) Received: from [128.42.2.190] (morpheus.cs.rice.edu [128.42.2.190]) by cs.rice.edu (8.8.4/8.7.1) with ESMTP id SAA05874 for ; Wed, 8 Jan 1997 18:47:35 -0600 (CST) X-Sender: chk@titan.cs.rice.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 8 Jan 1997 18:46:02 -0600 To: hpff-doc From: Chuck Koelbel Subject: hpff-doc: HPF 2.0.chi draft Sender: owner-hpff-doc Precedence: bulk --------------------------------------------------------------------------- hpff-doc@cs.rice.edu is a mailing list for HPF 2.0 language specification authors and editors. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- We are nearing convergence on the HPF 2.0 spec. I'll let Guy explain what happened in the latest (major) update: >Date: Wed, 8 Jan 1997 17:09:10 -0500 >From: gls@livia.East.Sun.COM (Guy Steele - Sun Microsystems Labs) >To: chk@rice.edu >Subject: HPF 2.0 draft >Cc: Guy.Steele@East.Sun.COM >X-Sun-Charset: US-ASCII >Status: O > >Okay, Chuck, here is what I have done with the draft. > >I have done the BNF thing. It would be a good idea if someone >with access to the Fortran 95 spec (I don't have a copy) would >double-check all the \Fortranrule declarations in file >overview.tex and make sure that the Fortran rule numbers >are all correct. > >I have taken care of making all typewriter-font single quotes >be vertical. Within \CODE...\EDOC and \ICODE...\EDOC, this >happens automatically. It turns out that there is a technical >difficulty with doing this in running text (and especially headings), >so it is necessary to use a macro \vquote. Thus what used to >look in the TeX source code like > > \texttt{'BLOCK'} > >now reads as > > \texttt{{\vquote}BLOCK{\vquote}} > >Ugly, but effective, and there really weren't too many of them. > >FYI, in TeX error messages about underfull and overfull boxes, the >vertical single-quote character will be shown as ^^M. > >I also searched all the files for double quote characters and converted >them to either {\vquote} (in typewriter font) or to '' (otherwise). > >I did some rewording of sentence and other minor things to try to eliminate >overfull and underfull boxes. I did not get them all, and did not have time >to sweep the entire document for this, but I did about two-thirds of them. > >I am in Paris next week for ACM POPL. I'll take a copy of the draft with >me for airplane reading. I'll be in my office tomorrow and Friday if there >are any problems with these TeX files. > >My next message to you will contain the tar, gzip, uuencode form of the files. > >--Guy > HPF version 2.0.chi can be found in (you guessed it!): ftp://titan.cs.rice.edu/public/HPFF/work-in-progress Many TeX files are there, plus a tar'ed, gzip'ed archive. I will plan on checking the F95 BNF this weekend, if nobody publically beats me to it. We are still on-schedule for: Jan 14 Comments back to chapter editors Jan 21 Final edited chapters back to Chuck Jan 28 Final document announced on the net Thanks to Guy for the BNF work (completed despite a nasty flu, we hear)! Chuck ************************************************************ Chuck Koelbel Research Scientist Center for Research on Parallel Computation Rice University "What kind of a man is Capt. Renault?" "A man like any other man, only more so." ************************************************************ --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-doc-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-doc Thu Jan 30 23:24:24 1997 Received: (from daemon@localhost) by cs.rice.edu (8.8.5/8.7.1) id XAA29284 for hpff-doc-out; Thu, 30 Jan 1997 23:24:24 -0600 (CST) Received: from [128.42.5.148] (pasyn-20.rice.edu [128.42.5.148]) by cs.rice.edu (8.8.5/8.7.1) with ESMTP id XAA29276; Thu, 30 Jan 1997 23:24:16 -0600 (CST) Date: Thu, 30 Jan 1997 23:24:16 -0600 (CST) X-Sender: chk@titan.cs.rice.edu (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: hpff-doc, hpff-core From: Chuck Koelbel Subject: hpff-doc: HPF Language Specification, version 2.0.omega Sender: owner-hpff-doc Precedence: bulk --------------------------------------------------------------------------- hpff-doc@cs.rice.edu is a mailing list for HPF 2.0 language specification authors and editors. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- By the time you read this messge, HPF version 2.0.omega will be available at ftp://titan.cs.rice.edu/public/HPFF/work-in-progress/work-in-progress.tar.gz ftp://titan.cs.rice.edu/public/HPFF/work-in-progress/hpf-report.dvi ftp://titan.cs.rice.edu/public/HPFF/work-in-progress/hpf-report.ps I plan to move this to the official draft directory (ftp://titan.cs.rice.edu/public/HPFF/draft) around 8:00pm tonight unless there are serious problems. I do not intend to make *any* changes in that move, except to revise the version number to 2.0. If you find any problems with this draft (can't download it, your version of LaTeX crashes when processing it, ...) PLEASE tell me as soon as possible. In particular, I'd like to know before close of business today (Friday) so there's some chance to correct it before announcing it to the world. Thanks to everybody who has made this document possible (if you aren't sure whether you're in this group, check the acknowledgments :-) Chuck ********************************************************************** Charles Koelbel CRPC, MS 132 Center for Research on Parallel Computation Rice University Rice University 6100 Main Street chk@cs.rice.edu Houston, TX 77005 ********************************************************************** --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-doc-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe ---------------------------------------------------------------------------