Subject: hpff-core: HPFF May96 Active CCI

From: owner-hpff-core
Date: Mon, 29 Apr 1996 14:23:57 -0500 (CDT)

Following are the active CCI items for the May HPFF meeting.
For your reference - this long text file is ordered by group
and contains the following:
Sender: owner-hpff-core
Precedence: bulk

---------------------------------------------------------------------------
[email-masked] is a mailing list for announcements related to High
Performance Fortran.  Instructions for adding or deleting yourself
from this list appear at the bottom of this message.
---------------------------------------------------------------------------
One CCI #58 for Group C - new
One CCI #56 for either Group C or D - new
Five CCI's for group D
	(11,39,47 ptr group), 49, 50 {both maybe done}
Six CCI's for group E
	(45/46 pair) (51,54,55 group), 57 new

--------
CCI #58	use of independent and new	
Group C	
Helmers	[email-masked]	
submitted: 3/28/96	
status: new	

question:
Is this a legal use of INDEPENDENT & NEW ???

REAL x, y(n)

!HPF$ INDEPENDENT, NEW(i)
DO i = 1, n
   x = x + y(i)            ! Clumsy way to calculate: x=SUM(y)
END DO

Jens Helmers,
[email-masked]
---
discussion:
Answer from Henry
Hi Jens,
     This is not a legal use of INDEPENDENT, unless n <= 1.  When the
 INDEPENDENT directive appears before a DO, it asserts to the compiler that
 (among other things) two iterations of the DO will not assign to the same 
atomic object.  Here, the assignment to x violates that condition, unless n is 
less than or equal to 1.

     A proposal that will appear in the HPF 2.0 document will permit some DO 
loops which perform intrinsic reduction operations to be marked as 
INDEPENDENT, like so:

  REAL x, y(n)

  x = 0.0
  !HPF$ INDEPENDENT, NEW(i), REDUCTION(x)
  DO i = 1, n
     x = x + y(i)
  END DO

Thanks,

Henry
__________________________________________________

CC I #56	Interpretation of HPF_TEMPLATE library routine	
Group C or D	
Whaley	[email-masked]	
submitted: 3/20/96	
status: new	

question:
Hi,

I'm looking at "High Performance Fortran Language Specification", 
May 3, 1993 Version 1.0.

Under the description of HPF_TEMPLATE, is the following wording:

... HPF_TEMPLATE returns information concerning the variable from the 
template's point of view (assuming the alignment is to a template rather than
 an array) ...

My understanding of this routine is that it can give information about any 
ALIGNEE, even those not ultimately aligned to an !HPF$ TEMPLATE.  
Rather, I interpret this to reference to be to the more general definition of 
template, "an index space".  Can you tell me if this is correct?  
If so, it might be helpful to disambiguate the above sentence . . .

Thanks,
Clint
__________________________________________________

CCI #11	pointer with sequence	
Group D	
updated: 8/14/95
Henry Zongaro	[email-masked]	
submitted: 02/16/95	
status: in progress	Note - this one was marked resolved and then 
revived to be discussed together with 39 and 47 ...
 Current proposal (with strawvotes) follows this question.

question:
Hello,
     Things have been quiet here lately, so I thought I'd send a few questions
that I've been hoarding.  All page and line references are relative to the
1.0 HPF Language Spec.
     I'd like to hear other people's opinions on these, especially the 2nd and
3rd items.
1) The response to CCI item 6.3 indicated that variables with the POINTER
   attribute must be distributed or aligned.  A related question - can they be
   given the SEQUENCE attribute?  Or can a pointer be associated with both
   sequential and nonsequential targets?

=====================================
PROPOSAL FROM THE MARCH 96 MEETING - ADDRESSING THIS CCI AND #39 and #47
11, 39, 47 - pointers.
HPF 1.1. has contradictory statements about pointers.
Proposal:     1st reading .... 
 - Retain text in section 3.6 page 38 line 33 which states that pointers may 
appear as an alignee or a distributee - takes effect on allocation
 -delete constraints 3 page 27 line 5 - distribute cannot have pointer attribute
(also page 186 line 48)
- Add text: If a pointer (target) is explicitly mapped and is associated with a 
target using a pointer assignment, the mapping of the target object must
MATCH the declared mapping of the pointer.  (Where MATCH needs to be 
defined.)
     Override -   then this applies only on allocation
If a pointer is declared to be DYNAMIC, it can point to any non-sequential 
object.  The RANGE directive can be used to restrict the mappings of the target 
object or the allocated array. 

A pointer declared sequential using the SEQUENCE attribute can point to 
sequential objects only.

 A pointer which is not explicitly mapped or declared sequential can point to a target which is not explicitly mapped or declared sequential.

Discussion of DYNAMIC - is this an appropriate overloading of DYNAMIC?  
Can a dynamic pointer point to a static objects? PM  - saying this is illegal is
too restrictive --- but user might think that because pointer is dynamic it can 
be redistributed ... but other text should restrict this.

example  
A(100), B(100)
!HPF$ distribute (cyclic):: A,B
pointer, dynamic :: p(;)
   p => A
   p=> B

Straw poll on this for a first reading - clearly not ready for second reading
  19 - 0 - 0.

========
previous discussions ...
from July meeting - subgroup proposal:
conforming dimensions of the pointer object and target either must be 
(unmapped or both be identcally distributed) or both must be sequential.

The issue is ... does the pointer exist as an instance by itself, or is it just 
assocated with its bound arg. There is a case of pointers to sections of arrays,
 so just knowing that a pointer goes a block distributed thing, one can't talk 
about pointers to section.Andy Meltzer recalls that was related to the fact that
allocatable objects don't have their distribution until after they are assigned.
A straw poll was taken with  special understanding that a substantial vote for 
"abstain" would mean reconsider.  The vote was   7-3-10, so this CCI item is 
returned to committee for further clarification of the issue.

=========
from September meeting minutes:

CCI 11  Pointers cannot be mapped.  Can they be associated with both 
sequential and non sequential targets?   Subgroup recommends that pointers 
cannot point to sequential variables. Full group didn't think this was right and
asked the subgroup to try again.
=====
new proposal at Nov meeting:

  (a) Pointers with the HPF SEQUENCE attribute may point only to targets with 
the SEQENCE attribute.
  (b) POINTERS without the SEQUENCE attribute may point only to targets 
without the SEQUENCE attribute. 

When a pointer is invoked you know ahead whether it is sequence or not ...
institutional vote ... 22  - 0 - 0
======
-page 38 section 3.6 implies pointer can be mapped.  This should specifically 
say that the pointer is not distributed, the pointee is.

- pointers cannot be mapped

End of 3.6  "for the relationship of pointers and sequence attricutes 
[ refernce to the next sentece]

Add section 7.3  "Pointers and Sequence Association" - put rules (a) and (b) 
in the text ...

==========
This was revisited at the March meeting --- see #39 and #47. 
 A proposal is in progress addressing all three of these cci's.

__________________________________________________

CCI #39	Mapping Pointer Restrictions	
Group D	
updated: 4/27/96

Larry Meadows	[email-masked]	
submitted: 11/21/95	
status: in progress - being discussed with #11 and #47 - 
see #11 for current proposals ..
---

question:
I've noticed an inconsistency in the 1.1 document wrt F90 pointers. You'll
recall CCI 6.3, from last year; this resulted in additional constraints
to the 1.1 document, that alignees and distributees could not have the
POINTER target (p. 27, line 5, and p. 32, line 5). However, later in the
same chapter, there is some text (p. 38, line 33):

A variable with the POINTER or ALLOCATABLE attribute may appear as an alignee
in an ALIGN directive or as a distributee in a DISTRIBUTE directive.

This is clearly a contradiction.

This is also somewhat related to CCI #11 (what is the SEQUENCE attribute
when associated with a pointer).

I'm assuming the following, in HPF 1.1:

1) Mapping statements can't apply to pointers. Note, therefore, that allocated
   pointers cannot be explicitly mapped.

2) Pointers can point to any object, regardless of their mapping attributes.

For HPF 2.0, there was some restriction on pointers that I've forgotten.
It really seems that a restriction similar to the following would be in
the spirit of Kernel HPF:

        Mapping statements can be applied to pointers. These statements
        assert that any object with which the pointer is associated will
        have the described. Pointers with mapping statements may point
        only to whole arrays, not to subarrays.

        Pointers without mapping statements may point only to objects without
        explicit mappings, and may point to subarrays of those objects.

lfm
-------
ed note:   this has both a cci item for group D and kernel input for group E... 
but is primarily a group D item.

SEE #11 FOR CONTINUED DISCUSSION OF THIS ONE --- 11 and 39
 and 47 are being discussed together.	
__________________________________________________

CCI #47	distribute/pointer contradiction	
Group D	
updated: 4/27/96
Singleton	[email-masked]	
submitted: 2/2/96	
status: in progress - being discussed with #11 and #39 - see #11 for 
current proposal
----
question:
Is there a contradiction within the HPF 1.1 Language Specification
document with regards to distributed pointer arrays?

In section 3.3, page 27, line 5 (repeated in appendix C, page 186,
line 48), it is stated that a distributee in a DISTRIBUTE directive
may NOT have the POINTER attribute. However section 3.6, page 38, line
24, makes the contrary statement. The rest of section 3.6 clearly
suggests that pointer arrays are supposed to be distributable.

The negative statements where not in HPF Version 1.0.

Can you clarify please?

Thanks,
David Singleton

-----------
follow-up question after Henry's first reply ...

Thanks for your prompt reply Henry.

It is reasonable that a pointer array has the distribution of its
associated target. However this does not cover the case when the
pointer array is allocated instead of pointer assigned to an existing
array. If pointers are removed from section 3.6 then the only
conclusion is that pointer arrays cannot be allocated as distributed
arrays. Is this correct?

If true, this seems highly and unnecessarily restrictive. If
allocatable and automatic arrays can be distributed, why not
dynamically allocated pointer arrays? The big advantage of allocated
pointer arrays is that they can be placed in the global namespace via
COMMON or modules. The Fortran90 and HPF constraints on nonsequential
COMMON blocks should be sufficient to include distributed pointer
arrays.

Not allowing pointer arrays as distributees or alignees also
eliminates the possibility of REDISTRIBUTING or REALIGNING them after
allocation as well.

Even without having pointer arrays, CMFortran successfully encompassed
dynamic allocation of distributed arrays albeit by actually giving the
user access to array descriptors. Fortran90 pointer arrays should only
simplify the user interface to such dynamic allocation.

I would be very interested to understand the HPFF stance on allocated
distributed pointer arrays - it doesn't appear to be addressed in HPF2
documents. If you can point me at any other relevant online
documents, I'd be wery appreciative.

Thanks for your help and time,

discussion:
NOTE THIS IS BEING ADDRESSED TOGETHER WITH #11 and #39
SEE TEXT IN #11 for the discussion from the March Meeting	
Answer from Henry
Hi David,
> Is there a contradiction within the HPF 1.1 Language Specification
...
> suggests that pointer arrays are supposed to be distributable.
     Yes, there is a contradiction in the HPF 1.1 document.  The response to an
interpretation question posed was that pointers cannot appear as distributees
in a DISTRIBUTE directive.  Instead, a pointer acquires the mapping of its
associated target, if any.
     The instance you cite in section 3.6 was missed in the HPF 1.1 document,
but will be fixed in HPF 1.2.
Thanks,  Henry
-----
followup reponse from Henry after second question
   Hi David,
   > It is reasonable that a pointer array has the distribution of its
  ...
   > conclusion is that pointer arrays cannot be allocated as distributed
   > arrays. Is this correct?

   That's correct; a pointer appearing in an ALLOCATE statement would get some
 compiler default distribution (probably replication).

   > If true, this seems highly and unnecessarily restrictive. If
   .....
   > eliminates the possibility of REDISTRIBUTING or REALIGNING them after
   > allocation as well.
   The original interpretation request that prompted this restriction asked
   whether the following was a valid program - could a pointer be given one
   mapping and made to point at something with a different mapping.
              program p
                integer, pointer :: ptr(:)
                integer, target :: targ(100)
       !hpf$    processors proc(number_of_processors())
       !hpf$    distribute targ(cyclic) onto proc
       !hpf$    distribute ptr(block) onto proc
                ptr => targ
              end program p
HPFF decided that it would be best to avoid such problems by prohibiting the
pointer from having an explicit mapping, and having it acquire the mapping of
its target.  This (perhaps inadvertently - I'm not sure) had the effect of
preventing the user from explicitly mapping pointers when they become
associated through the ALLOCATE statement.
   > Even without having pointer arrays, CMFortran successfully encompassed
  .........
   > documents, I'd be wery appreciative.
 This issue was raised by Larry Meadows for HPF 2.0, but I'm not sure off-hand
   how it was dealt with at the last HPFF meeting.  Does anyone recall whether
   this aspect of the problem came up for discussion?
 Thanks,  Henry

---- and additional comment from Carol  ---- 
I only recall that this came up at the vendors subgroup, where we proposed
that DISTRIBUTE and ALIGN be reallowed for POINTER and 
ALLOCATABLE variables for precisely this reason. The idea, as I 
understood it, was to let POINTER arrays be mapped, but only 
(in the absence of DYNAMIC) allow them to point to similarly mapped 
variables. (I don't think we talked about the question of pointing at array 
sections of similarly mapped variables.) I'm not sure what the last official 
HPFF vote on pointers was, although I believe it implied that nondynamic
 pointer arrays should only point to
things with the same mapping, which seems to me most compatible with their
having a mapping themselves, not with their having no mapping.

SEE #11 FOR CONTINUED DISCUSSION
__________________________________________________

CCI #49	distribution with array border elements	
Group D	
Rosing	[email-masked]	
submitted: 2/7/96	
status: new	(NOTE - I MUST HAVE MISSED RECORDING ACTION ON 
THIS ONE - IS IT OK AS ANSWERED OR DOES IT REQUIRE FURTHER 
ATTENTION?)

question:
I'm trying to figure out how to distribute two types of arrays to
minimize communication, the first has border elements and the second
doesn't. The first array is declared B(-2:nx+2, -2:ny+2, -2:nz+2) and
the second is declared A(nx,ny,nz). Array A should be distributed by
blocks in one or more dimensions and array B should be distributed
such that B(i,j,k) is on the same node as A(i,j,k) for 0<i<=nx,
0<j<=ny, and 0<k<=nz. The border elements should be on the nodes where
the neighboring non-border elements are.

The align directive doesn't appear to work because the lengths of the
dimensions are not the same (page 34, line 42, version 1.1 of the
manual). I can't afford to put extra elements around A for several
reasons; A is really a 5D array and the extra storage would be large
(there are also lots of A's), for reasons of load balancing I
don't want the border elements included in how the block sizes are
computed and placed, and I don't want to rewrite all of the array
operations on the A arrays to not operate on any new borders.

This seems like a typical problem and I'm fairly sure it was discussed
at one time.

matt
([email-masked])

	initial reply from Mary
Matt ... I'm going to forward this to the hpff-interpret mailing
list.  In a quick reading of your message - it looks to me like you
need the "generalized block" feature that has been accepted as
a feature in the latest round of HPFF meetings  (but is likely  to be in
the set of features that has an uncertain future wrt implementation).
Someone else can comment if I've misread the question or if it needs
generalized block plus something additional.
   -mary-

---
follow-up from Chuck

In short, Mary's answer was correct.  To do precisely what you want, you
need the generalized block mapping.  Current thinking is that this will be
part of the "approved extended features" of HPF 2.0.  That means the syntax
and semantics will be defined, but vendors are likely to concentrate on the
core (aka kernel) features of the language first.

BTW, You can use ALIGN as follows:
        !HPF$ ALIGN A(i,j,k) WITH B(i,j,k)
Or
        !HPF$ ALIGN A(:,:,:) WITH B(1:nx,1:ny,1:nz)
The rule is basically that the array sections in ALIGN must conform, but
the align-target (B) doens't have to specify the whole array.  However,
this ALIGNment doesn't solve your problem with not counting boundary
elements in the block sizes.

                                                Chuck
__________________________________________________

CCI #50	implicit remapping	
Group D	
updated: 4/27/96
	
Zongaro	[email-masked]	
submitted: 2/8/96	
status: in progress  (is this done except for exact words?)
	     
question:
The much-beloved section 3.10 of the HPF Language Spec. states (in part)
on page 54 that
      The rules on the interaction of the REALIGN and REDISTRIBUTE directives
      with a subprogram argument interface are:
      1. . . . .
      2. If an array or any section thereof is accessible by two or more paths,
         it is not HPF-conforming to remap it through any of those paths. . . .
         In general, in any situation where assignment to a variable would be
         nonconforming by reason of aliasing, remapping of that variable by an
         explicit REALIGN or REDISTRIBUTE directive is also forbidden.
     These rules deal explicitly with REALIGN and REDISTRIBUTE, but not with
some other situations in which aliasing might occur.  For example, is the
following a conforming program?  Here 'a' is remapped on becoming associated
with 'x'.  Can an element of 'a' then be referenced in sub?  If I had a call
to HPF_DISTRIBUTION passing 'a', what would be the AXIS_TYPE?
      program p
        integer :: a(100) = 1
!hpf$   distribute a(block)
        call sub(a)
      contains
        subroutine sub(x)
          integer x(100)
!hpf$     distribute x*(cyclic)
          i = a(1)
        end subroutine sub
      end program p
How about the following?  'a' is remapped when it becomes associated with 'x' -
can 'a' then be passed to sub2, which would require remapping as well?  Given
that REALIGN and REDISTRIBUTE are prohibited, my guess is that this 
would be prohibited as well.
      program p
        integer :: a(100) = 1
!hpf$   distribute a(block)
        call sub(a)
      contains
        subroutine sub(x)
          integer x(100)
!hpf$     distribute x*(cyclic)
          call sub2(a)
        end subroutine sub
        subroutine sub2(y)
          integer y(100)
!hpf$     distribute y*(*)
        end subroutine sub2
      end program p
How about this one?  Here, the same actual argument is associated with two
different dummy arguments, each of which requires a different mapping from the actual.
      program p
        integer :: a(10, 10) = 1
!hpf$   distribute a(block, block)
        call sub(a, a)
      contains
        subroutine sub(x, y)
          integer x(10, 10), y(10, 10)
!hpf$     distribute x*(cyclic, block)
!hpf$     distribute y*(block, cyclic)
          print *, x, y
        end subroutine sub
      end program p
If the mapping of 'x' had been the same as that of 'a', would the third 
examplethen be conforming?
Thanks,  Henry	

discussion:  FROM MARCH 96 Meeting:  CCI 50:  Legal F90!
program p
   integer a(100), b(10,10)
!HPF$ DISTRIBUTE a(block), b((block,block)
    call sub1 (a,b,b)
contains
   subroutine sub1(x1,x2,x3)
   integer x1(100), x2(10,10), x3(10,10)
!HPF$ DISTRIBUTE x1 *(cyclic)
!HPF$ DISTRIBUTE x2 *(block,cyclic)
!HPF$ DISTRIBUTE x3 *(cyclic,block)
    print *, x2, x3
  .....  = a(i)
   call sub2(a)
  end
subroutine sub2 (x)
   integer x(100)
!HPF$ DISTRIBUTE x *(*)
  end sub2
end 
Not HPF conforming.
page 46 line 17
  - actual arg will be remapped to conform to the interface
 page 54 line 14
  - if array accessible through 2 or more paths cannot be remapped.
Proposal:  (to make the above example legal)
   Change text page 46 line 17 to delete reference to remapping of
 actual arguments;    [need better words]
... and a remapping of the actual argument is necessary, the call should 
proceed as if the data was copied to a temporary variable mapped 
to match the mapping of the dummy argument.
     Rational (to be added): sometime actual is accessible through 
say host association, so cannot remap actual.
===== 
Discussion - is a better solution just to say it illegal. 
Ken - points out that the places to worry are where a program 
is legal in F90 and one changes to HPF it is illegal - with no fix ... 
doesn't apply here.
straw poll on fix (vs saying illegal) - aliasing     0 - 14 - 6
====
second part of the same problem (aliasing involving pointers)
program p
   integer, pointer :: a(;)
!HPF$ DISTRIBUTE a(block)
    allocate a(100)
    call sub(a)  
contains 
    subroutine sub(x)
       integer, pointer :: x(:)
!HPF$ DISTRIBUTE x  *(cyclic)
        x(i) = ...
        a(i)   = ... 
     end sub
  end p
problem:  legal F90 => a and x point to same data with different distribution:
Proposal: 
add restriction [better words]  to the pointer proposal discussed earlier
   The mapping of a dummy argument with a pointer attribute has to match the 
mapping of the actual argument if the latter is accessible inside the procedure 
through another path.  strawpoll :  18 - 0 - 3
	
__________________________________________________

CCI #45	extrinsic clarifications	
Group E	
Hennecke	[email-masked]	
submitted: 1/23/96	
status: in progress	(note most of these good comments/corrections
                                    - ran out of time in March to complete list)

question:
Hello,
some questions and comments on EXTRINSIC are added below. I assembled 
them when additions to more suitable places and (b) significantly shortened to 
only those aspects that do not depend on possible restrictions for
<extrinsic-kind-keyword>s other than HPF. All such material should be 
collected in the annexes (A and B for the HPF_* keywords) to separate the 
general EXTRINSIC functionality from the specific implementations of the two 
interfaces defined within the HPF language.
Regards,
Michael Hennecke      http://www.uni-karlsruhe.de/~Michael.Hennecke/
 ----------------------------------------------------------------------
  University of Karlsruhe         RFC822: [email-masked]
  Computing Center (G20.21 R210)           BITNET: [email-masked]
  Zirkel 2  *  P.O. Box 69 80                 Phone: +49 721  608-4862
  D-76128  Karlsruhe                               Fax: +49 721  32550
 =======================
HPF v1.1, section 6
143:14+  change "subprograms" to "procedures"
         SISAL and C extrinsics are not subprograms.

143:14+  Is a FORTRAN_LOCAL subprogram an HPF subprogram?

143:16.5 "It defines the means for handling distributed and replicated
          data at the interface."

        I do not see these definitions in section 6, which only imposes general 
restrictions on the callee in 6.3. IMHO,this is not in the scope of this section
which only defines the caller's (declaration) part. Everything else is processor-
dependent, except for the HPF_LOCAL and HPF_SERIAL specifications 
which are also not in section 6 but in annex A and B.

144:6.8  "should be declared EXTRINSIC ..."
         Is this a requirement or a recommendation?
         (Since HPF supports EXTERNAL, it probably cannot be a requirement.)
         If it is a recommendation, perhaps add more explanatory material
         like "Because HPF has to communicate some information about the
         distribution/alignment of procedure arguments, a user's assumptions
         about implementation details are more likely to fail as in sequential
         languages."

144:11   "6.2  Definition and Invocation ..."
         Change "Definition" to "Declaration". Except for the requirement
         that EXTRINSIC(HPF) is redundant and may appear in the definition
         of an HPF subprogram, this section is about declaring interfaces
         to EXTRINSIC procedures, not defining them.

144:26   Change "\bnf{extrinsic-kind}" to "\bnf{extrinsic-kind-keyword}"
         (alternatively, delete \bnf markup.)

144:29   Add a reference to annex B for HPF_SERIAL specifications:
         "The keyword HPF_SERIAL is intended for use in calling uniprocessor
          routines described in Annex B."

144:41.6 change "subprogram" to "procedure" (see 143:14+)

144:42.7 change "subprograms" to "procedures" (see 143:14+)

145:1+   The examples given implicitly require the C_LOCAL and SISAL
         languages to be able to pass arrays by descriptor because
         assumed shape arrays are passed to them.
         On 146+:43+, COBOL_LOCAL also recieves assued-shape arrays.
         This should be avoided. However: all argument passing becomes
         tricky if the EXTRINSIC is not Fortran...
	question continued:

145:9+   The OPERATOR(+) interface is not standard-conforming:
         add INTENT(IN) for X and Y.

145:32.8 "The intent is ... "
         Context lost... This should be a general requirement on EXTRINSIC,
         here it appears after the discussion of a generic interface example.

145:33.7 change "has been" to "had been"

146:2    "... mut have an explicit interface"
         Question 1: shoudn't this be "EXTRINSIC interface"? A mere interface
                     block does not help, except for the default case.
         Question 2: Shouldn't this requirement be less strict? To my
                     understanding, the only case where such an interface is
                     always required is when the procedure arguments are
                     distributed HPF arrays (or the Fortran standard requires
                     one).

146:11   Move this stuff up to then beginning of 6.2.

146:28   "main-program"
         Change from \tt to \bnf markup

146:41   "... as the host scoping unit" (and the following example)
         There is no such thing: host association is restricted to internal
         and module subprograms, and derived type definitions (14.6.1.3).
         An interface block always has its own scope, it cannot access anything
         from outside by host association. Introducing such mechanisms
         in HPF seems to be very confusing.

147:38   change " ahs " to " has "

=====continued in #46  =======================
CCI #46	extrinsic clarifications	
Group E	
Hennecke	[email-masked]	
submitted 1/23/96	

status: in progress	 NOTE THIS IS A CONTINUATION OF #45 
with the Annex part split into a separate item.

HPF v1.1, annex A

162:8    Change "accessible to an extrinsic procedure (arrays passed as
         arguments)" to "passed as actual arguments to an extrinsic procedure",
         because there are more arrays accessible than array arguments: COMMON
         and MODULE objects.

164:4.5  "distributed HPF array"
         Does this include replicated arrays? If not, list them in the same
         lines as scalars.

165:3+   change \tt to \bnf markup three times

165:6    change "the the" to "the"

166:8.5  change "type" to "type and type parameters"

178:30   change "type" to "type and type parameters"		
__________________________________________________

CCI #51	array sections and HPF_LOCAL	
Group E	
updated: 4/27/96
Zongaro	[email-masked]	
submitted 2/13/96	
status: in progress	being discussed with #54 and #55 - see #55 for proposal

question:
Hello,
     I thought I had sent this question a few weeks ago, but I couldn't find
any record of having done that - my apologies if this is a duplicate.

     Consider the following program.

         program prog
           interface
             extrinsic(hpf_local) subroutine sub(dummy)
               integer :: dummy(:, :)
   !hpf$       inherit dummy
             end subroutine sub
           end interface
           integer actual(4, 4)
   !hpf$   processors p(2, 2)
   !hpf$   distribute actual(block, block) onto p

           call sub(actual(1:2, 1:2))
         end program prog

         extrinsic(hpf_local) subroutine sub(dummy)
           use hpf_local_library
           integer :: dummy(:, :)

           print *, 'proc = ', my_processor(),                                &
        &           'lbound = ', lbound(dummy),                               &
        &           'ubound = ', ubound(dummy)
         end subroutine sub

Assuming that elements of p correspond to physical processors as follows
             p(1,1)     0
             p(2,1)     1
             p(1,2)     2
             p(2,2)     3
which of the following correctly describes the output from the four instances
of the HPF_LOCAL subroutine?

a)     proc = 0 lbound = 1 1 ubound = 2 2
       proc = 1 lbound = 1 1 ubound = 0 2
       proc = 2 lbound = 1 1 ubound = 2 0
       proc = 3 lbound = 1 1 ubound = 0 0

b)     proc = 0 lbound = 1 1 ubound = 2 2
       proc = 1 lbound = 1 1 ubound = 0 0
       proc = 2 lbound = 1 1 ubound = 0 0
       proc = 3 lbound = 1 1 ubound = 0 0

In other words, should sub behave as if dummy is divided up like this

            -------------------------------------
           | dummy(1:2, 1:2)  |  dummy(1:2, 1:0) |
a)          -------------------------------------
           | dummy(1:0, 1:2)  |  dummy(1:0, 1:0) |
            -------------------------------------
or this?
            -------------------------------------
           | dummy(1:2, 1:2)  |  dummy(1:0, 1:0) |
b)          -------------------------------------
           | dummy(1:0, 1:0)  |  dummy(1:0, 1:0) |
            -------------------------------------
Thanks, Henry
	Rob replies ...
Henry,
Good question about lbound and ubound for dummies
of extrinsic local routines!    I favor iterpretation (a)

            -------------------------------------
           | dummy(1:2, 1:2)  |  dummy(1:2, 1:0) |
a)          -------------------------------------
           | dummy(1:0, 1:2)  |  dummy(1:0, 1:0) |
            -------------------------------------
All HPF distributions onto multidimensional processors arrangements are
cartesian products of one-dimensional distributions; this interpretation
is consistent with that rule.
Rob
----- 
comment from David Watson 
[email-masked]
---
Can I add support for interpretation a) i.e.
            -------------------------------------
           | dummy(1:2, 1:2)  |  dummy(1:2, 1:0) |
            -------------------------------------
           | dummy(1:0, 1:2)  |  dummy(1:0, 1:0) |
            -------------------------------------
If we consider a function or subroutine delivering a result sized according
to an incoming argument this interpretation is necessary for correct behaviour.
The following (exceedingly artificial) code illustrates the necessity

         program prog
           interface
             extrinsic(hpf_local) function funres(dummy)
               integer :: dummy(:, :)
               integer :: funres(size(dummy,1))
   !hpf$       inherit dummy
   !hpf$       align with dummy(:,*) :: funres
             end subroutine funres
           end interface
           integer actual(4, 4)
           integer junk(4)
   !hpf$   processors p(2, 2)
   !hpf$   distribute actual(block, block) onto p
   !hpf$   align junk(:) with actual(:,*)

           junk(1:2) = funres(actual(1:2,1:2))
         end program prog

         extrinsic(hpf_local) function funres(dummy)
               integer :: dummy(:, :)
               integer :: funres(size(dummy,1))
   !hpf$       inherit dummy
   !hpf$       align with dummy(:,*) :: funres
               funres = 0
               dummy  = 0
         end subroutine funres

under interpretation b) processor 2 (assuming the numbering in the original
example) would return a size zero array into a size 2 array.
Cheers,
   Dave
#51, 54 and 55 being discussed together - see #55 for proposal.

__________________________________________________

CCI #54	local inquiry about globals	
Group E	
updated: 4/27/96
Offner	[email-masked]	
submitted:3/7/96	
status: in progress	being discussed with #51 and #55 - see #55 for proposal

question:
We have run into some problems with the hpf local inquiry intrinsics
(e.g., GLOBAL_TO_LOCAL, GLOBAL_UBOUND, etc.).  These intrinsics 
are
described as returning information about the
        "actual HPF global array argument associated with an
        HPF_LOCAL dummy array argument".
The problems we see are these:
1.  The actual argument might be an array expression.  This wouldn't
be a problem for things like array bounds information -- I think
Fortran already has a consistent way of defining such things in such
cases (e.g. for assumed-shape arrays).  But what about the MAPPING of
the actual?  Expressions have no mappings, but these intrinsics can be
used to extract global mapping information.
2.  The actual argument might be remapped by the compiler in the
course of processing the subroutine call.  (This would commonly happen
if the dummy argument had a different mapping.)  The user really is
then interested in the "remapped actual".
3.  This could also happen if the compiler (for whatever reasons of its
own) decides to use a different mapping than that specified by the
programmer.  Compilers today are not going to do that, but in the
future one could imagine an optimizing compiler with that kind of
capability.  The user certainly wants information about the real
object, not about whatever appears syntactically specified.
4.  Finally, there is an additional problem:  There are mappings that
can be specified in more than one way.  A compiler will typically not
store the source of the mapping directives -- it will pick some
internal representation for the mapping.  When it reports information
from this internal representation, it may look superficially different
to the programmer, even though it amounts to the same thing.
     Furthermore, the representation may depend on things like the number
of processors being compiled for.  To take an extreme case (one could
make up a more realistic case; but this exhibits the problem well
enough), suppose the compiler is told to compile an HPF program for
execution on 1 processor.  It is reasonable for the compiler to decide
internally that all mappings are serial, even if they were specified
as BLOCK in the source program.  Certainly there would be nothing
wrong with reporting a serial mapping, since it would describe
precisely the data layout; but it's not what either the actual or
dummy arguments were described as in the program source.
     The point is that there is really no need for the results of these
inquiry intrinsics to be tied syntactically to the actual argument.
All the user needs is the information necessary to write explicit
message-passing code.  The compiler should be able to use whatever
internal representation is consistent with what the user has written,
and to report information based on this internal representation.
I think that's what the user really wants, in any case.
      Here is the idea of what we would like to say:  Since the ONLY reason
that a user would ever want to call such a routine is to extract
information in order to perform explicit message-passing, we think
that the routines ought to be defined to return information about
        "the global object of which the dummy argument is a
        local section"
with the understanding that this "global object" is implementation-defined.
     The problem, of course, is that I don't know a standard
computer-language formal way to state this.
                        --Carl Offner   [email-masked]
--------
beginning of reply from Chuck
I'll try to get straight to the punch line.  Let me admit up front,
however, that I'm a little hazy on some aspects of EXTRINSIC.

>Here is the idea of what we would like to say:  Since the ONLY reason
...
>with the understanding that this "global object" is
>implementation-defined.
>
>The problem, of course, is that I don't know a standard
>computer-language formal way to state this.
I thought this is what the original language meant.  (Or was intended to
mean...)
    I think of it this way:
The EXTRINSIC callee gets  an area of memory (the dummy argument) and a
data descriptor (not directly visible) from the caller.
    GLOBAL_FOO and FOO_GLOBAL routines extract information otherwise
inaccessible from the descriptor.  [Suddenly I'm suspicious that these
routines should be intrinsics - else it's hard to explain where they get
their arguments...]
   The "actual HPF global array argument" is an array with (a copy of) that
descriptor and area of memory.  This may not correspond to any particular
syntactic element of the program.
     I would agree that the current wording isn't crystal clear (despite being
written by Guy Steele, if I remember right).  But then the whole idea of
EXTRINSIC procedures has always been kind of hard for me to grasp...
     Starting from that premise, let's see if any of these problems get clearer.
 At 08:24 03/08/96, Carl Offner wrote:
>The problems we see are these:
>
>1.  The actual argument might be an array expression.  This wouldn't
>...
>used to extract global mapping information.
The mental model seems to handle this OK in common cases- the caller has 
to build a descriptor, which may not correspond to any array variable or 
section thereof.  Indirection arrays break the model by making the
descriptor poorly defined.  But they also break INTENT(OUT) and 
assumed-shape dummies.
    HPF has rules for when descriptive mappings can be used for dummy 
arguments (i.e. when mappings are identical).  Cant we amend the standard 
so that GLOBAL_TO_LOCAL & friends are implementation-dependent 
when a descriptive mapping cannot be used?  A note to implementors 
might say "We suggest that the compiler create the simplest possible 
descriptor for the other cases - for example, align the result of an array 
expression with one of itsinputs."

>2.  The actual argument might be remapped by the compiler in the
>course of processing the subroutine call.  (This would commonly happen
>if the dummy argument had a different mapping.)  The user really is
>then interested in the "remapped actual".
   This is definitely unclear in the current language.

Using something along the lines of the mental model, we have to say "do the
remapping before constructing the descriptor".
>3.  This could also happen if the compiler (for whatever reasons of its
>....
>object, not about whatever appears syntactically specified.
     The same problem (theoretically) occurs in regular HPF code if the compiler
chooses its own distributions.  HPF_DISTRIBUTE may then return misleading
information.
      The onus is on the compiler to ensure that if it ignores user advice, then the 
results remain consistent.  In particular, GLOBAL_TO_LOCAL should produce 
an index that gets you to the expected element.  (In regular HPF, 
REDISTRIBUTE must move the right elements to the right places.)  Two 
mechanisms have been suggested for doing this:
1. Have the HPF library routines return the truth about what the compiler is 
doing.  This basically presumes run-time descriptors are queried (and updated).
2. Before any HPF library routine is called, remap the data back where the user 
said it should go, return the "expected" result, then remap data to where the 
compiler thinks it should be. As an optimization, the compiler can eliminate the
remappings as dead code.
     The first option is considered preferable.
    You seem to assume that the "actual" is the syntactic element -
 I think it is the runtime object.
    >4.  Finally, there is an additional problem:  There are mappings that
>can be specified in more than one way.  A compiler will typically not
>store the source of the mapping directives -- it will pick some
>internal representation for the mapping.  When it reports information
>from this internal representation, it may look superficially different
>to the programmer, even though it amounts to the same thing.
      You can say the same thing about HPF_DISTRIBUTE in regular HPF.
       My interpretation is that the HPF library inquiries can return any valid
representation of the mapping.  Since the representations correspond to 
equivalent mappings, this should not matter to the user.  (I suppose some users 
will try to reverse-engineer the optimizations on address arithmetic this way...
It will not matter to the *normal* user.)
       Is there something in the writeup that says "the mapping specified in the
syntax"?
>The point is that there is really no need for the results of these
>inquiry intrinsics to be tied syntactically to the actual argument.
      I agree that there is no need to tie them to the syntax.
Maybe it's just my warped point of view, but I don't think they are...
                                                Chuck
            about pt 1 above - Henry comments:
I think the HPF document already says enough.  If you check out Section 3.10, 
the second paragraph states that, "If there is no explicit interface, then
actual arguments that are whole arrays or array sections not involving vector 
subscripts may be remapped at the discretion of the language processor; the 
values of other expressions may be remapped in any manner at the discretion of the language processor."  This implies to me that even though the user cannot 
specify a mapping for an expression, the expression will nevertheless have a 
mapping.
              and about point 2 above Henry comments:
The second paragraph of 3.10 states that, "If there is an explicit interface 
for the 
called subprogram, . . . the actual argument will be remapped if necessary to 
conform to the directives in the explicit interface."  This describes remapping 
as affecting the actual argument - it doesn't speak in terms of an actual 
that the user specified vs. a remapped actual. 
There is only one actual, it is remapped 
on the call and becomes associated with a dummy argument; when the user 
inquires about the mapping of the associated actual, the information returned is
about the mapping the actual has while it's  associated with the dummy.
         #51, 54, and 55 being discussed together - see #55 for proposal

__________________________________________________

CCI #55	more global/local bound questions	
Group E	
updated: 4/27/96
Meadows	[email-masked]	
submitted: 3/08/96	status: in progress	

question:
Since we're on the topic of hpf_local:

! The question is, should this global_lbound return 1 or -104?  
     program xc06
      interface
        extrinsic (hpf_local) function vet(array2,results)
        integer vet
        integer, dimension (:,:,:,:,:,:,:)    :: array2
!HPF$ DISTRIBUTE(BLOCK,BLOCK,BLOCK,BLOCK,BLOCK,BLOCK,BLOCK)::array2
        integer,intent(out):: results
        end function
      end interface

      integer, dimension(-104:-100,2,0:1,-1:1,1:3,-1:0,1:2):: a2
      integer results
!HPF$ DISTRIBUTE(BLOCK,BLOCK,BLOCK,BLOCK,BLOCK,BLOCK,BLOCK)::a2
      integer ::a_res
      integer:: num_procs
      a_res=vet(a2,results)
      print *,results
      end
        
      extrinsic (hpf_local) function vet(array2,results)
      use hpf_library
      use hpf_local_library
      integer vet
      integer, dimension (:,:,:,:,:,:,:)    :: array2
      integer,intent(out):: results
      results=global_lbound(array2, 1)
      return
      end
------

	DISCUSSION FROM MARCH MEETING - #51,54, and this together  ...

      proposal:   first reading
      remove  global_ub/lb from HPF2  

     Motivation: global_shape etc. do the same thing.  Henry believes he asked 
for these functions and no longer needs them.  As a formal 1st reading, we will 
have time to reconsider.     Vote:   17 - 0 - 1

__________________________________________________

CCI #57	HPF_LOCAL and assumed size arrays	
Group E	

Whaley	[email-masked]
submitted: 3/22/96	
status: new

question:
Hi,
I am looking at the HTML version of the HPF language specification, version 
1.1.  It says:

>A dummy array argument of an EXTRINSIC(HPF_LOCAL) routine must 
have assumed
>shape, even when it is explicit shape in the interface. Note that, in general,
>the shape of a dummy array argument differs from the shape of the 
corresponding
>actual argument, unless there is a single executing processor. 

I think this statement is misleading. Is it true that all HPF_LOCAL routines are
constrained to accept only assumed shape arrays, or is it only HPF_LOCAL 
routines which are called from global HPF that have this restriction?

The reason I ask is that we have Fortran77 code which we are hoping to access 
from HPF.  The easiest route to do this is to have the HPF routine call an 
HPF_LOCAL routine with our arrays passed in as assumed shape.  Then, since 
HPF_LOCAL is a superset of Fortran77, we declare our Fortran77 routine as 
another HPF_LOCAL routine taking an assumed size array (required by Fortran77).

So, my question is: can HPF_LOCAL routines which will not be called from 
global HPF take assumed size arrays?  If so, I think a slight rewording of the 
standard might help make this apparent.

Thanks,
Clint
--------end of question - ---- beginning of discussion ---------
Mary comments:
Good point ... We already have wording here and there that
distinguishes the HPF_LOCAL routines that may be called from
global from the others ... it seems completely reasonable
to me that the assumed shape requirement would apply only
to those routines that cross that boundary.  
      Formally - your question will go on the list for the next meeting
(May 1-3).
   -mary-
-----------
Carl comments:
There is no constraint stopping an HPF_LOCAL routine from calling
a Fortran 77 routine, as far as I know.  In fact, a standard way
of calling such routines would be, as you suggest, to use the HPF_LOCAL
routine as a wrapper to set up the argument passing for the Fortran 77
or Fortran 90 routine it then calls.  Such a routine could be
declared, for example, as EXTRINSIC(F90_LOCAL).  (You have to declare
it as *something*; otherwise the default is that it is also considered
to be HPF_LOCAL.)
     Clearly there are some issues here that could be re-examined; but what
is there now is certainly workable.
                --Carl Offner   [email-masked]
---------
Clint replies:
Thanks for the response, but this is not at all what I am asking.  Probably my message was not very clear.  If the compiler supports F90_LOCAL, I don't need the intermediary step of HPF_LOCAL in the first place.  The whole point is that the compilers I have used are very selective in the extrinsics they support, and I'd like to be able to use HPF_LOCAL alone as a route to using an assumed size array.

It is clear that if F90_LOCAL is supported, my problem is solved.  However, if  
HPF_LOCAL is contrained to accept assumed shape arrays only when called 
from  global HPF, I will have a solution if either F90_LOCAL or HPF_LOCAL 
is  supported.

It seems to me that the assumed shape restriction was probably set in place to 
facilitate transfer from the global HPF to local, and thus it is not necessary 
when one HPF_LOCAL routine calls another.  Therefore, my question remains: 
can HPF_LOCAL routines which will not be called from global HPF take 
assumed size arrays?
Thanks, Clint	
------------------------
Back to Carl:
   Perhaps you misunderstood what I was trying to say.  You can take
your Fortran 77 routine and call it from an HPF_LOCAL as you
suggested.  There is nothing that currently prevents you from doing
that.  The only thing you have to be careful about is that you
have to explicitly declare it as NOT being HPF_LOCAL, since otherwise
that is the default.  I suggested EXTRINSIC(F90_LOCAL), which is
compatible with Fortran 77.  But anything else would do as well.
                --Carl Offner  [email-masked]

-------------------------
and back to Clint:
Yes, I understand your point.  It was one I examined before sending mail. 
My whole problem is that I do not want to have to count on there being any 
extrinsic besides HPF_LOCAL.  I see no reason to have the assumed shape 
restriction if one HPF_LOCAL routine calls another.  If this is the case, I can 
call a Fortran77 routine using HPF_LOCAL as the only extrinsic type.  To use 
the idea you are suggesting, the compiler must support two extrinsics, HPF_LOCAL and, for instance, F90_LOCAL or F77_LOCAL.

To give you an example, DEC's HPF compiler (at least the version I have) 
supports only HPF and HPF_LOCAL.  If the ruling is that HPF_LOCAL 
routines which are not called from global HPF can take assumed size arrays, I 
could get my code to work there without asking DEC to support more 
extrinsics.  I believe that IBM's xlhpf also does not support F90_LOCAL or 
F77_LOCAL at this time. That is why my question involved the ruling on 
passing assumed size arrays between HPF_LOCAL routines, rather than how 
to call a F77 routine from  HPF_LOCAL.
 Thanks,
Clint
----------------------
And - now a comment from Carol:

Clint raised an important point that has been bothering me as well. Not all
implementations of HPF_LOCAL necessarily have other types of EXTRINSIC
interface available, so HPF_LOCAL should be complete in itself, especially
since there exists a default assumption that a subprogram call from within
an HPF_LOCAL routine is calling another HPF_LOCAL routine.  I don't believe
there was an intent to block any use of explicit shape arrays locally,
whatever constraints might be put on dummies associated with globally
distributed arrays (even such a constraint has disadvantages). I do believe
that it should be possible to pass explicit-shape arrays from one HPF_LOCAL routine to another. I think the language specifications need to be altered to fix this problem.
--Carol Munroe   [email-masked]
   ----------------------------
And a couple more comments from Carl:
Well, I agree that there may be some room for language development
here.  But we will soon be supporting F90_LOCAL for the very reason
you need it; and the idea is that you can call it from an HPF_LOCAL
as you desire.  Calling an F90_LOCAL from a (global) HPF routine
would still not be possible with anything but assumed-shape dummy 
arguments (unless some further language enhancements are made
to support this kind of feature).  I don't think this is a big
feature for any compiler to implement -- the only real glitch
is that the default for a routine called from HPF_LOCAL is
stated to be HPF_LOCAL -- that's the only reason one even needs
another kind of intrinsic at all in this case.
                --Carl Offner  [email-masked]
-------------------------------------
I guess what has been motivating my replies is the feeling that
we are too late in this round of HPFF meetings to make any
changes in HPF_LOCAL like what Clint is suggesting.  Personally,
I don't have any objection to having HPF_LOCAL be able to accept
other than assumed-shape arguments when called from another HPF_LOCAL.

I just thought that in effect we have a mechanism for doing that,
with a very modest (really only a front-end) investment of work
for a compiler, and that we were unlikely to get anything else
immediately.  Again, though, I agree that there is room here
for some possible language change.

                --Carl Offner  [email-masked]

---------------------------------------------------------------------------
To (un)subscribe to this list, send mail to [email-masked].
Leave the subject line blank, and in the body put the line
(un)subscribe <email-address>
---------------------------------------------------------------------------