
\section{The HPF subprogram interface}

     In a language like HPF, which handles explicitly distributed data,
the subprogram interface is more or less bound to be troublesome.  The
underlying reason for this is clear---each distributed array is bundled
with a complex set of mapping parameters, and structures such
as templates.  Getting all this information across the procedure interface in a
flexible but efficient way is by no means straightforward.

     The present definition of the HPF procedure interface leaves
something to be desired.  In some respects it seems over-complex, in
others, less flexible than one might hope.  In this document we try to
concentrate on a useful subset of the defined interface, omitting some
of its more awkward features.

\subsection{\label{prescriptive}Prescriptive mapping of dummy arguments}

     Conceptually the simplest approach to mapping of data in
subprograms is for it to be completely decoupled from mapping in the
calling program.  The subprogram contains mapping directives for
its local data and dummy arguments, following the syntax introduced in
the last section.  If a dummy argument has one mapping, and the
corresponding actual has another, the compiler arranges (by means at
it's own discretion) to remap the incoming data to agree with
subprogram's expectation (and remap any outgoing results back to the
callers expectation on exit from the subprogram).

     This is called {\em prescriptive} mapping of the dummy arguments,
because the mapping directives ``prescribe'' that data will be
remapped.
\begin{verbatim}
  PROGRAM MAIN
    PROCESSORS Q (2, 2)

    TEMPLATE U (4, 4)
    DISTRIBUTE U (CYCLIC, CYCLIC) ONTO Q

    COMPLEX M (4, 4)
    ALIGN M (I, J) WITH U (I)

    CALL HERM (M)
  ENDPROGRAM

  SUBROUTINE HERM (A)
    PROCESSORS P (4, 1)

    COMPLEX A (4, 4)
    DISTRIBUTE A (BLOCK, BLOCK) ONTO P

    FORALL (I = 1 : 4, J = 1 : 4)
      A (I, J) = CONJG (A (J, I))
    ENDFORALL
  ENDSUBROUTINE
\end{verbatim}
The actual and dummy argument of \verb$HERM$ have the same shape and
type, so the call is certainly valid Fortran.  They have completely
different mappings (different processor arrangements, and \verb$CYCLIC$
versus \verb$BLOCK$).  The compiler transparently sorts this out,
preserving the normal Fortran meaning of the program.  (Incidentally,
the mapping in the subprogram is an illustration of the use of an
implicit template.)

     The disadvantage to prescriptive mapping of dummies is the
obvious one: there is a large run-time overhead in remapping the arguments.
Although this penalty may be acceptable for large subroutines,
such as those in a separately-compiled numerical library, it
often will not be acceptable for lightweight procedures in
the users program.

\subsection{\label{conformance}Identification of processor arrangements,
templates, and mappings}

     As a preliminary to discussion of parameter-passing methods which
leave mapping of the arguments unchanged, we need to consider what it
means for two mappings in different program units to be ``the same''.
Fortran doesn't allow processor arrangements or templates to be passed
as procedure arguments or included in common blocks, so there is a logical
problem here---since mappings are defined by reference to processors
and templates.  In an HPF implementation based on full Fortran 90, this
problem can be solved by putting processor arrangement or template
declarations in a module, then importing this module into calling and
called program units.  Unfortunately, many early implementations of HPF
probably won't incorporate the whole of Fortran 90, and modules
may well be amongst the omitted features.

     In practise, HPF adopts a model of ``structural equivalence''
between these objects.  Two processor arrangements represent the
same set of processors if and only if they have the same shape.
We will say that two such processor arrangements are {\em identifiable}
(with the caveat that this is not standard HPF terminology).

     Likewise, we will say that two templates are identifiable
if they have the same shape (they are conforming), and they
have distribution directives with identical distribution formats,
targetting identifiable processor arrangements.

     Finally we have to say what it means for the mapping of two arrays
to be ``identifiable''.  This is more complicated\footnote{We will give
a slightly stricter definition of identifiable mappings than the one
implicit in the HPF definition.  Some mappings with non-identifiable
templates are regarded as being ``the same'' in the HPF definition.  As
admitted above, this discussion only covers a subset of HPF.}.  The
mappings of two arrays are identifiable if they have the same shape,
and they have identical alignments to identifiable templates.  This is
fairly informal---to be more formal one would have to give precise rules
for resolving indirection in alignment (when arrays are aligned to
arrays), and for saying when ultimate alignments are identical.  This
is reasonably straightforward, and would make boring reading.

     The rule in the last section is applicable to named array
variables, with explicit alignment directives.  It is also possible to
define the alignment of, and thus identify mappings between, ``regular
sections'' (array sections built without using vector subscripts).
This is a useful facility, whose fairly obvious details we omit here.

\subsection{Descriptive and transcriptive mappings}

     A ``descriptive'' mapping of a dummy argument is one which {\em
asserts} that an argument has a particular mapping, without implying
any action to remap the argument on call of the procedure.  In one
respect, this is a very natural policy for argument mapping---it
directly parallels the treatment of other argument attributes.  In
Fortran we don't expect that if the type of an actual is different from
the type of a dummy, the types will be coerced to agree on entry and
coerced back on exit.  Instead we accept that if actual and dummy types
disagree, the program is probably erroneous.

     A descriptive mapping is flagged by the appearance of asterisks at
appropriate points in the directives involved.  A variant of the
example in section \ref{prescriptive}, with descriptive alignment to an
explict template (\verb$MAIN$ is unchanged from the previous version):
\begin{verbatim}
  SUBROUTINE HERM (A)
    PROCESSORS P (2, 2)

    TEMPLATE T (4, 4)
    DISTRIBUTE T (CYCLIC, CYCLIC) ONTO P

    COMPLEX A (4, 4)
    ALIGN A (I, J) WITH *U (I)

    FORALL (I = 1 : 4, J = 1 : 4)
      A (I, J) = CONJG (A (J, I))
    ENDFORALL
  ENDSUBROUTINE
\end{verbatim}
The processor arrangements \verb$P$ and \verb$Q$ are identifiable;
hence the templates \verb$T$ and \verb$U$ are identifiable; hence the
mapping of the actual argument \verb$M$ is identifiable with the
mapping of the dummy \verb$A$.  The asterisk preceding the alignment
target means that this directive is descriptive.  If the mapping
of the dummy {\em hadn't} agreed with the the mapping of the actual,
the program would have been erroneous.

     Another variant, with descriptive distribution of an implicit template
\begin{verbatim}
  SUBROUTINE HERM (A)
    PROCESSORS P (2, 2)

    COMPLEX A (4, 4)
    DISTRIBUTE A *(CYCLIC, CYCLIC) ONTO *P

    FORALL (I = 1 : 4, J = 1 : 4)
      A (I, J) = CONJG (A (J, I))
    ENDFORALL
  ENDSUBROUTINE
\end{verbatim}
There are two asterisks here, one for the distribution format clause, and
one for the target processor arrangement clause (the reason for
the separate treatment will become clear below).

     The implicit template has the same shape as, a target processor
arrangement identifiable with, and a distribution format identical to,
the template of the actual argument.  So the two templates are
identifiable.

     A variant of descriptive mappings allows clauses in the
mapping directives to be ``wild-carded''.  In this case, there
is an asterisk but no explicit distribution format or target
processor arrangement.  The distribution directives in
the previous example are could be changed to one of
\begin{verbatim}
  DISTRIBUTE A * ONTO *P

  DISTRIBUTE A *(CYCLIC, CYCLIC) ONTO *

  DISTRIBUTE A * ONTO *
\end{verbatim}
The first case asserts that the target of the distribution is
\verb$P$ but says nothing about the distribution format.
The second says that the distribution format is cyclic, but
leaves the processor arrangement unspecified.  The last
provides no information about either\footnote{Incidentally, it is
also allowable for a \verb$DISTRIBUTE$ directive to have, say, a
descriptive distribution format clause but a prescriptive target
processor arrangement clause, or vice versa.  The value of this facility
is slightly unclear.}.

     When a directive contains these ``wild-card'' clauses (which are
called ``transcriptive'' in the standard), the idea is that the mapping
of the actual will be unchanged on entry to the subprogram, and the
subprogram must be compiled to accept {\em any} legal variant of the
wild-carded attribute.

     There is no simple analogue of these transcriptive directives in
the explicit template case.  Instead there is a special attribute called
\verb$INHERIT$, which provides some of the functionality one might
expect there.  Its exact meaning is subject to interpretation, and this is not
a suitable forum for speculation.

