Subject: Re: mapping of pointers

From: Rob Schreiber <[email-masked]>
Date: Wed, 6 May 92 08:45:51 PDT

Dear Mike,

I think you missed something:

The allocated data in the application at hand is global.   Allocatable
arrays may not be placed in common blocks, pointers may.

One may use modules, true.   
(Modules may or may ot be in the "minimal subset".)
But a second aspect of the application of 
David Serafini is the use of a dynamically determined NUMBER
of dynamic arrays.   To do this, he allocates an array of pointers,
the size of which is determined at runtime.   Then he allocates storage
for each of the allocated pointers.   If every one of his allocated
arrays had to have its own name, this would be difficult to do.

Rob

---

From: [email-masked] (Joel Williamson)
Date: Wed, 6 May 92 13:50:08 CDT

[email-masked] writes:
> 
> 	      DO K = 1, 4
> 	CHPF$ REALIGN A(K)%B(I,J) WITH D((2**(4-K))*I,(2**(4-K))*J)
> 	      END DO
> 
>     which seems to capture what we want.  This won't work because any
>     variable names appearing on the "left-hand side" of an ALIGN/REALIGN
>     directive are deemed to introduce a new scope for that name, valid for
>     the rest of the directive.  So the K in the directive actually has
>     nothing to do with the loop index K.  This too would have to be changed
>     in order to solve our problem.
> 

What the heck, Fortran has already solved this one:

 CHPF$ (REALIGN A(K)%B(I,J) WITH D((2**(4-K))*I,(2**(4-K))*J), K = 1, 4)

Joel

---

From: [email-masked]
Date: Wed, 06 May 92 14:24:16 -0400

> Date: Wed, 6 May 92 08:45:51 PDT
> From: Rob Schreiber <[email-masked]>
> To: [email-masked]
> Subject: Re:  mapping of pointers
> Cc: halstead, [email-masked], [email-masked]
> 
> Dear Mike,
> 

This last point is certainly true.  But I wonder a bit about how you actually
construct this object, and how it would relate to the ALIGN/REALIGN syntax
that HPF is likely to have:

 1. Just creating an array of pointers is moderately challenging.  Section
    6.2.2 of the Fortran 90 standard states that "An array element ... never
    has the POINTER attribute."  So you can't just declare an array of pointers
    the way you might in a C program.  Presumably you have to define a
    one-element derived type that contains the pointer, and make an array of
    those objects.

 2. Now, how do you specify a [re]mapping for the targets of the pointers
    (as opposed to the "top-level" array of derived-type entities)?  In the
    January HPF proposal from Digital, we tried to be clear that you could
    only specify alignments for top-level arrays, so in particular any
    derived-type entity, no matter whether it included an array, could only
    be aligned with a single decomposition point.  Otherwise you may end
    up having to deal with alignment directives such as

	CHPF$ ALIGN A(I,J)%B(K,L) WITH D(K,J,L)

    or if you try to rule such things out, then you have to devise a set of
    rules that excludes the cases you don't want to think about but includes
    the things that people want to do.  I haven't seen any HPF proposals
    floating through the Internet that would allow this, though I suppose
    some people who would actually like to be able to do this may not have
    thought explicitly about this issue before now.

 3. But in order to handle David Serafini's wishes, we may even have to
    go beyond this capability, to allow a set of directives something like,

	CHPF$ REALIGN A(1)%B(I,J) WITH D(8*I,8*J)
	CHPF$ REALIGN A(2)%B(I,J) WITH D(4*I,4*J)
	CHPF$ REALIGN A(3)%B(I,J) WITH D(2*I,2*J)
	CHPF$ REALIGN A(4)%B(I,J) WITH D(I,J)

    or the equivalent executed inside of a loop.  This differs from previous
    proposals for the ALIGN directive in that the same "top-level" name A
    (or "A%B" if you prefer) is mentioned several times in REALIGN directives
    that don't cancel each other because parameters appear in the "left-hand
    side" of the REALIGN directive that make each directive apply to a
    different _part_ of the object!  This is a major step beyond what I
    believe to be the current proposals for mapping directives, but if we
    don't take this step, David Serafini's examples won't work as an argument
    for being able to align pointers.

    Now that I think of it, there's another problem with the scenario of
    writing a loop (which I assume is what one would like to do) to handle
    the above realignments.  Suppose we write the loop

	      DO K = 1, 4

This message has probably gotten too long already.  The main point is, while
the idea of using REALIGN directives in this way on arrays of pointers is
clever, it goes quite a bit beyond what is currently being proposed, in many
more ways than just by involving dynamic realignment of pointers.  If we want
to support this idiom, a lot of things will need to be reconsidered.   -Bert

---

From: David B. Serafini <[email-masked]>
Date: Fri, 8 May 92 10:15:52 PDT

Date: Wed, 06 May 92 14:24:16 -0400
   From: [email-masked]
   X-Mts: smtp

This is basically the method Mike Metcalfe describes in his notes on F90.
His example (for those without the notes)
	TYPE row			!declare type
		REAL, POINTER :: r(:)
	END TYPE
	TYPE(row) :: s(n),t(n)		!declare arrays
	do  i=1,n
		ALLOCATE( t(i)%r(1:i) )	!Allocate row i of length i
	enddo
	s(i)%r => t(i)%r	!equivalent to array assignment `s = t'

And the ALIGN implied-DO loop syntax suggested by Joel Williamson
([email-masked]) seems reasonable and sufficient to me to handle this
case.  In the multi-block algorithm I gave originally as example, alignment
between blocks will either be irrelevant (if the cost of exchanging boundary
data between blocks is small) or very difficult (if the blocks are different
sizes, and the goal is to align at least some of the boundaries to reduce this
cost).  I don't see why realignment of pointers will be more difficult to
implement that alignment of static arrays - you just have to copy the algorithm
the compiler uses for static arrays into the run-time library.  Making it cheap
enough to be worth using is a different problem, though.  Maybe I'm missing 
something important here.

-David