Subject: hpff-doc: revision to extrinsics.tex

From: David Loveman <[email-masked]>
Date: Fri, 3 Jan 1997 14:57:21 -0500

---------------------------------------------------------------------------
[email-masked] 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 [email-masked].
Leave the subject line blank, and in the body put the line
(un)subscribe <email-address>
---------------------------------------------------------------------------

---

From: Chuck Koelbel <[email-masked]>
Date: Fri, 3 Jan 1997 15:54:50 -0600

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."
************************************************************