Introduction

 

This introduction gives an overview of the ways in which mapping directives interact with argument passing to subprograms. The language used here, however, is not definitive; the subsequent subsections of this Section contain the authoritative rules.

In addition to the data mapping features described in Section 3, HPF allows a number of options for describing the mapping of dummy arguments.

The mapping of each such dummy argument may be related to the mapping of its associated actual argument in the calling main program or procedure (the ``caller'') in several different ways. To allow for this, mapping directives applied to dummy arguments can have three different syntactic forms: prescriptive, descriptive, and transcriptive.

HPF provides these three forms to allow the programmer either to specify that the data is to be left in place, or to specify that during the execution of the call the data must be automatically remapped into a new and presumably more efficient mapping for the duration of the execution of the called subprogram.

The meaning of these forms is as follows:

prescriptive

The directive describes the mapping of the dummy argument. However, the actual argument need not have this mapping. If it does not, it is the responsibility of the compiler to generate code to remap the argument as specified, and to restore the original mapping on exit. This code may be generated either in the caller or in the called subprogram; the requirements for explicit interfaces in Section 4.6 insure that the necessary information will be available at compile time to perform the mapping in either place.

Prescriptive directives are syntactically identical to directives occurring elsewhere in the program. For instance, if A is a dummy argument,

!HPF$ DISTRIBUTE A (BLOCK, CYCLIC)

is a prescriptive directive.

descriptive

Descriptive syntax has exactly the same meaning as prescriptive syntax, except that in addition it amounts to a weak assertion by the programmer that the actual arguent requires no remapping.

The assertion is characterized as "weak" because if it is false, the program is still standard-conforming. In such a case, the compiler must generate the appropriate remapping.

If the compiler can prove that the assertion is false, or if the compiler cannot verify that it is true, it may issue a warning or informational diagnostic message.

Advice to users. The purpose of descriptive, as opposed to prescriptive, directives is simply to provide a possible way for the compiler to report information to the programmer that may be useful in program developement and debugging. Note that any diagnostic message that may be produced as a result of the use of descriptive directives is not a portable feature of this language. In particular, there are instances in which no remapping is needed but where this fact would be impossible or highly non-trivial for a compiler to ascertain. Different compilers may well emit messages in different circumstances; and there is no requirement that any such messages be emitted at all. (End of advice to users.)

Descriptive directives look like prescriptive directives, except that an asterisk precedes the description. For instance,

!HPF$ DISTRIBUTE A *(BLOCK, CYCLIC)

is a descriptive directive.

transcriptive

The mapping is unspecified. The called subprogram must accept the mapping of the argument as it is passed. Of course this means that (the implementation of) the caller must pass this mapping information at run-time.

Transcriptive directives are written with a single asterisk for distributions and processor arrangements; for instance

!HPF$ DISTRIBUTE A *
!HPF$ DISTRIBUTE B * ONTO *

are transcriptive directives. The INHERIT directive (see Section 4.4.2) is used to specify a transcriptive alignment.

Both distribution formats and processor arrangements can be specified prescriptively, descriptively, or transcriptively. Alignment is more complicated, because of the need to specify the template with which the dummy is aligned. This template may be unspecified (in this case of course there is no ALIGN directive), in which case it is the natural template of the dummy. (``Natural template'' is defined in Section 4.4.1 below.) Otherwise, one of the following disjoint possibilities must be true:

• The template is explicitly specified by a prescriptive ALIGN directive.
• The template is explicitly specified by a descriptive ALIGN directive.
• The template is inherited. This is specified by giving the dummy the INHERIT attribute (described in Section 4.4.2 below). This implicitly specifies the template to be a copy of the template with which the corresponding actual argument is ultimately aligned; further, the alignment of the dummy with that template is the same as that of the corresponding actual. This is, in effect, a transcriptive form of alignment.

This is restated more precisely in Section 4.4.1 below.

Advice to users.Although it is possible to write some combinations of mapping directives that are partially prescriptive and partially transcriptive, for instance, there is probably no virtue in doing so. The point of these directives is to enable the compiler to handle any necessary remapping correctly and efficiently. Now remapping can happen for one or more of the following reasons:

• to make the alignment of the actual and the dummy agree;
• to make the distribution of the actual and the dummy agree;
• to make the processor arrangement of the actual and the dummy agree.

For most machines, there is no real difference in the cost of remapping for any of these reasons. It is therefore a better practice (for readability, at least) to make a mapping either purely transcriptive, purely prescriptive, or purely descriptive.

While transcriptive mappings can be useful in writing libraries, they impose a run-time cost on the subprogram. They should therefore be avoided in normal user code. (End of advice to users.)