D. ADAPTOR Problems and Restrictions

This section summarizes all restrictions of the current version of ADAPTOR.

D..1 Front End Problems

The front end of ADAPTOR still has some problems for building correct lexical tokens. In the following all known problems are listed by an example that will not work in the current release.

• ADAPTOR cannot deal with Holerith constants (except in FORMAT statements, but there might also be problems in certain situations).

        DATA PGNAME/8HPAMCRASH/         ! synax error      
    450 FORMAT(1H ,20(1H!),16H FEHLERAUSGANG (,I2,1H),16(1H!))
  

• Do not use array variables with a name that has some other meaning in Fortran. In this case, the array variable should be renamed.

        INTEGER DATA (100)
        DATA = 10
        DATA (50) = 3    ! this makes problems
  

• Blanks are significant for the front-end. Do not use blanks within names, numbers and relational operators.

        C O M M O N / / A
        A = 21 000 000.d0
        IF (0. EQ. A) ...
  

• no PAUSE statement,

• no alternate returns.

D..2 KIND Parameters

ADAPTOR supports only one representation method for data of type integer which corresponds to type default integer. The type specifier for this integer type is the keyword INTEGER. Any kind type parameter for integer constants and integer intrinsics must be constants that evaluate to the default integer size (which is usually 4).

In the same way, ADAPTOR only supports one representation for data of type logical.The type specifier for this logical type is the keyword LOGICAL.

For the character type, ADAPTOR supports only one representation method that uses one byte.

For the real type, ADAPTOR supports two representation methods, one for the default real size and one for the double precision size. The type specifiers for these two real types are REAL and DOUBLE PRECISION. Quad precision is not supported yet.

      integer(kind=N) K   ! okay if N evaluates to default_integer_size
      logical(kind=N) L   ! okay if N evaluates to default_integer_size
      real(kind=N) R      ! N must evaluate to default_real_size
                          ! or to 2 * default_real_size
      complex(kind=N) C   ! N must evaluate to default_real_size
                          ! or to 2 * default_real_size

The kind-param can be used in int-literal-constant and real-literal-constant. It is not supported for a logical-literal-constant and for a char-literal-constant.

      K = 1234_N
      R = 1.2_C
      L = .TRUE._4   ! not supported yet

A symbolic name for a data type can be followed by a data type length specifier of the form *s, where s is one of the acceptable lengths for the data type being declared.

       real*4      X    ! same as real(kind=4)
       real*8      DX   ! same as real(kind=8)
       integer*4   I    ! same as integer(kind=4)
       logical*4   L    ! same as logical(kind=4)
       complex*16  Z    ! same as complex(kind=8)

Note: ADAPTOR does not support quad precision for real types and does not support INTEGER*2, INTEGER*1 or LOGICAL*1. The restrictions for the representation are mainly due to the fact that the HPF runtime system only supports these representations.

D..3 Problems with Dynamic Arrays

When translating array operations to serial DO loops ADAPTOR needs information about the bounds of the array dimensions. Therefore it takes the expressions of the ALLOCATE statement or of the array declaration.

      subroutine S (N)
      real, dimension (N) :: A
      real, dimension (:), allocatable :: B
      allocate (B(N))
      ...
c     A(2:) = B(:N-1) will be translated to 
      do I = 2, N
         A(I) = B(I-1)
      end do
      deallocate (B)

Therefore the variables within the index expressions must not be redefined during the lifetime of the corresponding array.

      allocate (B(N))
      N = N + 1          ! might cause serious problems
      B(:) = B(:) + 1
      deallocate (B)

D..4 Restrictions for COMMON Blocks

ADAPTOR supports the mapping of arrays in COMMON blocks. Sequence and storage association is no longer guaranteed for these arrays and for common blocks containing mapped arrays.

• COMMON blocks with mapped data should be defined in all procedures with the same mapping and layout directives for the data. ADAPTOR checks it at compile time but cannot deal with it in case of separate compilation.
• COMMON blocks with mapped data should also be defined in the main program even if it is not used there. ADAPTOR allocates mapped data for COMMON blocks only in the main program, in all other routines it will only attach to the mapped data.

      program MAIN
      real, dimension (100,100) :: A, B
!hpf$ distribute (block,block)
      common /DATA/ A, B        ! data will be allocated in MAIN
      ...
      end program MAIN

D..5 Restrictions for the SAVE Attribute

The SAVE attribute cannot be set for arrays that have no longer SEQUENCE association (mapped arrays). It is only allowed for replicated data (distributed memory machines) including scalar variables.

The problems with the SAVE attribute are very similar to the problems with mapped data in COMMON blocks. ADAPTOR needs dynamic memory allocation for these arrays and cannot verify at runtime whether memory has already been allocated or not.

D..6 Restrictions for Processor Arrays and Distributions

The ADAPTOR runtime system only supports processor arrays with up to 4 dimensions. Processor arrays with more dimensions are not accepted.

!hpf$ processors, dimension (2,2,2,2)   :: P1     ! okay
!hpf$ processors, dimension (2,2,2,2,2) :: P2     ! ERROR

Arrays or templates can have up to 7 dimensions like in Fortran. If more than 4 dimensions are distributed, ADAPTOR only takes the last 4 distributed dimensions and gives a warning.

      real, dimension (N1,N2,N3,N4,N5)            :: A
!hpf$ distribute (block,block,block,block,cyclic) :: A
      ! distribution will be replaced with
!hpf$ distribute (*,block,block,block,cyclic) :: A

Please note that ADAPTOR supports also a flag to restrict the number of distributed dimensions (-d <n>).

D..7 Restrictions for Alignment

Currently, ADAPTOR has the following restrictions for the alignment:

• ADAPTOR must know the values for a linear embedding at compile time.

        real A(M), B(N)
  !hpf$ align A(I) with B(C*I+D)   !  C, D must be known at compile time
  

• Alignment with : is not allowed for sources or targets that have the ALLOCATABLE or the POINTER attribute.

        real, dimension (:), allocatable :: A, B
  !hpf$ align A(:) with B(:)                         ! not allowed
  !hpf$ align A with B                               ! the same as before
  !hpf$ align A(I) with B(I-lbound(B,1)+lbound(A,1)) ! unknown bounds
  

  In previous versions of ADAPTOR, this kind of alignment was implicitly translated in the following way:

  !hpf$ align A(:) with B(:)    ! was implicitly translated
  !hpf$ align A(I) with B(I)    ! only correct if A and B have same lower bound
  

• Alignment with a stride is only supported to a serial dimension or to a block distributed dimension.

        real, dimension (N,N) :: A
        real, dimension (M,M) :: B
  !hpf$ distribute A(block,cyclic(3))
  !hpf$ align B (I,J) with A(I,J)        ! okay
  !hpf$ align B (I,J) with A(2*I,J)      ! okay
  !hpf$ align B (I,J) with A(I,2*J)      ! not allowed
  

Note: Scalar variables can now be aligned with other data. This allows to specify ownership for scalars even if all processors might allocate memory for the scalar variables.

      real A, B(N)
!hpf$ align A with B(5)   ! no alignment for scalar variables

D..8 Restrictions for Layout

Shared layout for arrays is supported in such a way that all active processors share the data of the array. Sharing of data along a single dimension is not supported yet.

D..9 Restrictions for Redistributions

ADAPTOR supports the REDISTRIBUTE statement and REALIGN statement. This has been proven to be very convenient for some applications, especially when the distribution is computed during the initialization.

But it assumes that every access to a distributed array has only one reaching distribution, and this is the last syntactical DISTRIBUTE or REDISTRIBUTE statement.

D..10 Restrictions for the ON Directive

The ON HOME directive can restrict the execution to a single processor in one dimension, but not to a subset of processors.

      real, dimension (N) :: A
!hpf$ distribute (block)  :: A
      ...
!hpf$ on home (A(1))
         <statement>       ! will be executed on the first processor
!hpf$ on home (A(1:4))
         <statement>       ! will be executed on all processors

D..11 Random Numbers

The intrinsic routine RANDOM_DATA returns random numbers. In case of distributed arrays, this is a parallel random number generator. The penalty is that the routine delivers different random numbers when executed on different number of processors. Only when the program is executed on the same number of processors, it delivers the same results.

D..12 Unsupported Intrinsics and Library Routines

The array sort functions GRADE_DOWN, GRADE_UP, SORT_DOWN and SORT_UP of the HPF library are not supported.

D..13 Mapping of Pointer and Derived Data Types

ADAPTOR supports mapping of pointers and components of derived data types. Nevertheless, there might be still a lot of problems that have not all been fixed yet.