Storage and Sequence Association

the distribution of sequence and storage associated objects are now not part of the new HPF standard, HPF 2.0.

• sequence association does not work on distributed memory systems,
• storage association and retyping of memory does not mix well with distributed objects.

Things to avoid,

• distributing arrays in COMMON,
• distributing EQUIVALENCE d arrays,
• assumed-size arrays.

One of the hardest tasks of the HPFF was to try to marry FORTRAN 77 style sequence and storage association with the HPF concept of distributed objects. Many of the largest and most computationally intensive research programs that would benefit the most from conversion to HPF will contain at least some sequence or storage association. High Performance Fortran compilers are bound to implement Chapter 7 of the HPF Specification; this will be very important to anybody who wishes to run legacy codes.

Due to the separate compilation nature of FORTRAN 77, it was (and indeed still is) possible to perform many dirty tricks with arrays when used as procedure arguments. For example, in FORTRAN 77 programs it was possible, and common, to use assumed-size arrays to change the shape of an array across a procedure boundary:

       PROGRAM MAIN
       REAL A(10,10)
        ...
       CALL SUBBO(A)

       SUBROUTINE SUBBO(X)
       REAL X(*)
        ...

As a FORTRAN 77 compiler cannot not necessarily see SUBBO when compiling MAIN, it had to rely on the fact that the whole of the actual argument A is stored as a contiguous block in memory. The assumption that memory is linear is of course not the case for a distributed object on a distributed memory machine. Given that Fortran program units can be separately compiled, it can be seen that supporting legacy FORTRAN 77 codes could prove to be a taxing problem.

There are other problems too, especially in the area of storage association, EQUIVALENCE and COMMON blocks. EQUIVALENCE can be used to change the type and variable name that a particular area of memory is referred through; COMMON blocks provide a mechanism to access global data. A COMMON block reserves a contiguous area of memory which is accessed through the specified names. Each instance of a common block can be different which means that the partitioning of the memory specified by the block can vary from routine to routine. For example, the following COMMON block could appear in different procedures in a separately compiled Fortran program:

       COMMON /BLEURGH/ X(10,10),Y(2,22),I(100)
        ...
       COMMON /BLEURGH/ Z(12,12),J(10,10)
        ...
       COMMON /BLEURGH/ I(44),J(100),X(2,50)

If any of the arrays in the COMMON blocks are to be distributed then a HPF compiler will have a problem! It is highly likely that, without prior warning, the arrays from these COMMON blocks would be distributed using the default mapping. This mapping is typically * (replication) or BLOCK distribution.

The HPFF have defined some additions to Fortran 90 to try to lever sequence and storage association back into the arena. It is possible to categorise two distinct situations, one where objects used in sequence and storage associations can be used as distributed objects and the second where they cannot. In general, if a COMMON block is used in the same way on every occurrence then it is possible to distribute its elements. (After the abovementioned COMMON block problem was recognised it was considered good programming style to place each COMMON block in an INCLUDE file and to attach this file whenever access to the COMMON block was desired. This would ensure that every use was forced to be the same.)

There is a SEQUENCE directive which can be applied either in general or to a named entity (variable name or COMMON block). This will mean that the named entities are stored sequentially and it will also allow COMMON blocks such as BLEURGH to be used safely in HPF programs. The SEQUENCE directive must be applied to every instance of BLEURGH.

!HPF$ SEQUENCE :: /BLEURGH/

The HPFF have introduced the concept of covers and aggregates. In Fortran it is possible to use a COMMON or EQUIVALENCE statement to string together groups of variables by overlapping storage, a very simple example would be:

     REAL A(2), B(2), C(2)
     EQUIVALENCE (A(2),B(1))
     EQUIVALENCE (B(2),C(1))

here A and C are linked by B so must follow each other in memory. This group of overlapping variables is called an aggregate variable group. We can define a cover for this group in a further EQUIVALENCE statement:

     REAL COVER(4)
     EQUIVALENCE(COVER(1),A(1))

The aggregate variable group are part of a single storage sequence (aliased as COVER) of size 4. Neither A, B or C can be mapped but COVER, as long as it is one dimensional, can be.

Some variables are automatically sequential (ie they implicitly have the SEQUENCE attribute). A variable is sequential if it is an assumed size array, if it appears in a sequential common block, is a member of an aggregate variable group, if it is a derived type with the SEQUENCE attribute or is given the HPF SEQUENCE attribute. A sequential variable can be storage or sequence associated ; nonsequential variables cannot.

A sequential variable cannot be mapped unless it is a scalar or a rank one array that is an aggregate cover. This means that an assumed sized array cannot be distributed as it can never be an aggregate cover.

Recent developments at the HPFF have indicated that due to the complexity and non-usefulness of the mapping of sequential variables, it looks likely that the next version of HPF, HPF2, will not allow such mappings.

Return to corresponding overview page