Subject: hpff: May 96 HPFF minutes

From: owner-hpff
Date: Tue, 18 Jun 1996 16:39:22 -0500 (CDT)

High Performance Fortran Forum Meeting
May 1-3,  Arlington, Texas
Record of Action:  Mary Zosel
Sender: owner-hpff
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.
---------------------------------------------------------------------------

Executive Summary
There were 22 people from 18 institutions present at the May 
96 HPFF meeting.

The group processed the first or second reading of a number 
of language proposals.  Following summarizes the status.
Details of the proposals are included in the full minutes below.

Proposals passing second reading:
Remove Global_LB/UB  (15-0-0)
Sort_UP/Down in library  [in 2.0] (16-0-0)
Modifications to inquiry routines (13-0-4)
Extrinsic Policy (14-0-2)
On Processors - no interprocedural calls  (14-0-2)

Proposals still in progress of second reading:
New inquiry routines.
Task Regions passed (12-0-4), but pending write-up.

Proposals passing in first reading: 
Base language is Fortran (instead of F90). (21-0-1)
On Processors - interprocedural interface (15-0-6)
Amend C interface to be more common with ISO proposal 
	(18 - 2 - 1)
Definition of F77_LOCAL interface (11 - 2 - 4)
---

Other items of note:
There are three new companies on the announced product list: 
Thinking Machines, Transtech, and CDAC.  Also Tera has been 
added to the "interested" category.  
The plan for producing the draft HPF 2.0 document was made.
The next HPFF meeting is scheduled San Francisco July 10-12. 
The final HPFF meeting is September 18-20 (again San 
Francisco), with the expectation that there will be a 
public comment period between July and September.

End of Executive Summary
____________________________

Detailed Record of Action
Wednesday afternoon  May 1, 96 - HPFF Subgroup Meetings.

The HPFF Meeting convened Thursday AM, May 2 chaired by Ken 
Kennedy of Rice University. Introductions and review of 
voting rules took place.  We are still operating under the 
rule that formal readings require a 2/3 vote with abstentions 
counting as no.

The status of proposals expected for processing at the 
meeting was reviewed:

PROPOSAL STATUS
			1st	2nd
group C                          
	on		Jan	May			ck	
	task		Mar	May	
	inq updates	Jan	May			rs

group D                              
	dark corners of ptr  Mar.	May

group E                                
	
	SPMD-HPF-ext.   Mar	May/June
	am/lfm	Rules for extrinsics Mar	May
	No GLOBAL_LB/UB Mar 	May		mz 
	Sort functions	Mar	May		cm
	F77_LOCAL       May	June		cm

DONE - 
	(C) async		ext		lm
	(C) gen transpose	ext 		rs
	(D) reduce - simple	2		rs
	(D) reduce - simple amended	2	rs
	(D) derived typ		ext		gls
	(D) derived type amended ext
	(D) shadow width	ext		co
	(D) irreg map		ext		?
	(D)dist ranges				hz
	(D) seq. nonmap		2		cm	
	(D) subsets		ext		pm
	(E)name/etc.			
	(E) kernel		chapter		am
	(E) interop		ext		am
	(E) local_global func	?		cm	
	(E) explicit interf	2		~

For the first technical item, Mary Zosel presented the 
second reading of the proposal to  remove GLOBAL_LB/UB  
from HPF 1.2 (and HPF 2.0).  The original motivation for 
these functions is gone, and the 
definition in the document is resulting in cci's.  
The proposal passed 2nd reading 15-0-0.

Carol Munroe presented the second reading of Sort_UP/Down 
which allow the possibility of sorting in one step.  The existing 
library has grade-up/down which require two steps.  There was 
some discussion about whether these should be subroutines to allow 
sort in place, but it was decided that functions are ok, and it is 
possible for the compiler to recognize  A= SORT(A) as a special case.  
The proposal passed with an institutional vote  of 16-0-0.

Piyush Mehrotra presented another discussion o f  Dark Corners of 
Pointers - A long running Day Time Soap Opera also known by the 
name  "As the Stomach Turns".

The current proposal for mapping of pointer is that:

Pointers with sequential attribute may
 - point to targets with sequential attribute only.
 - allocate sequential object only.

Pointer with no explicit mapping may
  - point to targets with no explicit mapping.
  - require consistency particularly across procedure boundaries.

Rob asks if something declared DYNAMIC falls here - Piyush/Carl 
say no.

Pointers with static declarations may
   - point to non-dynamic objects with "conforming" mapping.
   - allocate object with specified declaration.

Pointers with dynamic attribute:
  - point only to targets with dynamic attribute.
  - can redistribute using the pointer if
       	 - point to the whole object
       	 - object is allocated through a pointer
       	 - all other pointers lose association.
    - range can be used  to restrict what it points to.
   - allocation as usual.

NEW:  Pointers can have a transcriptive distribution.
        distribute  * :: p(:)
                 - this pointer can be used to point to ANY mapping.
                 - range can be used to restrict target distribution.
                 - (note that)  cannot be used for redistribution.
                 - allocation - compiler's choice.

Rob continued discussion - pointing out that DYNAMIC is 
orthogonal to mapping.  Rob proposed an amendment so that   
dynamic points only to dynamic and non-dynamic points only to 
non-dynamic (static).  The subcommittee will fix the proposal to 
reflect this  and come back.  Carol Munroe observed that pointers 
without dynamic cannot be passed to routines where the arg has dynamic. 

=====
Back tracking --- Rob moved that SORT be part of the 2.0 standard 
instead of approved extensions:  Seconded. The chair interprets as 
only 1 vote needed and the proposal passed by an institutional vote 
of 16-0-0.

Next the vendor slide was reviewed. There are three new companies 
on the announced product list.  It now reads:  

Announced Product
Applied Parallel Research, CDAC, Digital, Fujitsu, 
Hitachi, IBM, Intel, Meiko, Motorola, 
NA Software, NEC, Pacific Sierra Research, 
The Portland Group, Inc., Thinking Machines, Transtech

Announced Effort
ACE, Lahey, NAG, nCube

Interested
Edinburgh Portable Compilers, HP,  
Silicon Graphics/Cray Research,  Sun, Tera

Note the tendency of companies that stay in the interested category, 
also are tending to merge.  It's a dangerous place to stay.  :-)

========

Rob Schreiber presented   Inquiry updates:  mods to 
HPF_ALIGNMENT, HPF_TEMPLATE, HPF_DISTRIBUTION
   - Removes reference to aggregate covers.
    - may these be called for Sequential objects?  Now not for 
assumed_size dummy args -  these things do have a mapping ... but 
they cause problems because these routines are libraries (instead of 
intrinsics) and it is non-trivial to call the library with both kinds of 
arguments.  Straw vote about forbidding sequential in all inquiry functions: 
18 - 0 - 4

There are now new outputs to HPF_DISTRIBUTION:

PLB - processor lower bound
PUB - processor upper bound
PSTRIDE - processor stride
LOW_SHADOW
HIGH_SHADOW

Example
REAL A(10,10)
!HPF$ TEMPLATE T(40,20)
!HPF$ ALIGN A(I,:) WITH T(3*I+1, 2:20:2)
!HPF$ DISTRIBUTE T(BLOCK, BLOCK)  ONTO PROCS (4:1:-1, :)
    PLB = [4,1]
    PUB =  [1,2]
    PSTRIDE [-1:1]

Two New Inquiry Functions are proposed:

Map_Array (Array,Dim)
Number_Mapped(Array,Dim)

     Dimension A(2)
!HPF$ Template T(4,8)
!HPF$ Align a(I) with T(2*I, 5)
!HPF$ Processors procs(2,2)
!HPF$  Distribute T(Indirect ((/1,2,2,1/)), GEN_BLOCK ((/3,5/))) 
ONTO PROCS
      MAP_ARRAY (A,DIM=1) is [1,2,2,1]
      MAP_ARRAY (A, DIM=2) is [ 1,1,1,2,2,2,2,2]
Henry points out that this is a result that can get changed by a comment.

DIMENSION A(2,40)
     !HPF$ template t(4,8,4,16)
     !HPF$ align a(I,*) with T(2*I, 5,*,*)
     !HPF$ PROCESSORS PROCS (2,2,3)
     !HPF$ distribute T ( Indirect ((/2,2,1,2/)), &
             BLOCK ((/3,5/)), *, BLOCK) ONTO PROCS

  NUMBER_MAPPED (A, DIM = 1) is [1,3]
  NUMBER_MAPPED (A, DIM = 2) is [3,5]
  NUMBER_MAPPED (A, DIM = 3) is [6,6,4]

There is a full write-up for the item.

These are second readings.

Vote on mods to the align, template, distribution functions with the 
first two items changes to HPF 2.0 and the new outputs part of the 
extended language:  
13 - 0 - 3

Questions clarifying local library - they exist, but they refer to the 
global routines.

Now on the new inquiry functions,  MAP_ARRAY and 
NUMBER_MAPPED (for gen-block and indirect),   Henry proposed 
an amendment to make these subroutines. After discussion, Carol 
seconded the amendment and proposed an improvement:   call 
map_array (array, dim, result)  where  result needs to be at LEAST as 
big as the max size the of the returned value and does not require 
that the caller know exactly how big it is.   Rob agreed to call this a 
friendly amendment.

Jerry wonders if a different keyword should be used ... e.g. 
PROCSDIM ... to be consistent it should be PROCESSORS_DIM.  
What about names for the results?  Could also possibly be just one 
subroutine with two possible results.

Final result to vote on later.

BREAK

Mary presented the proposal for Extrinsic Policy

HPFF will have a policy of formally recognizing certain extrinsic 
interface definitions, where the interface, and its addition to the HPF 
document is considered to be a service to the HPF community. 
Examples are language bindings to HPF or library packages. 

To be considered for HPFF recognition, a proposed extrinsic must  
demonstrate the following things.  It should be noted, however, that 
meeting these criteria 
does not guarantee acceptance of a proposed interface by HPFF.

	    conformance to HPF rules for calling extrinsics  (reference)
	    significant new functionality
	    existing practice such as users, implementations, etc.
	    institutional backing with evidence of ongoing support
	    coherent documentation
	    non-proprietary interface definition
	    copyright goes to HPFF for interface, with permission to use 
(royalty free)

If accepted by HPFF, then:
	    HPFF will recognize the interface and reference it in 
documentation, but 
HPFF does not assume responsibility for the extrinsic or its interface.
	    The sponsor of the extrinsic must continue to conform to the 
HPF interface rules for extrinsics.  The interface HPFF approves must not 
change without HPFF approval.
	    The sponsor must assume responsibility for any CCI 
requests  concerning the extrinsic.

A list of recognized extrinsic interfaces will be included in HPF 
documentation, with the following guidelines:

	    There should be a single page introduction to the extrinsic 
which contains:
	        the name of the extrinsic
	        a brief abstract of functionality
	        a brief and informal description of the interface
	        information about platform and system availability
	        reference and contacts for formal documentation, 
		continued responsibility, and additional information 
		(e.g. compiler  availability).
	    There should be about two pages with short examples of usage.
	     A short paper with the formal definition of the interface 
and an informal description of the functionality of the extrinsic.

To submit an extrinsic interface to HPFF for consideration, 
the sponsor prepares a proposal that includes:
	a statement of what significant new functionality is provided
	a description of existing practice
	a statement institutional backing with evidence of ongoing support
	a copy of the coherent documentation
	a copy of the text (described above) that would be included 
in the HPFF  documentation
	a statement justifying the claim that the interface follows 
HPF  conventions for calling extrinsics.

If approved the sponsor then submits:
	   a formal statement for HPFF records that the interface 
definition is non-proprietary and that  the copyright of the interface 
belongs HPFF.
	   the formal contact for CCI and continued maintenance of interface 
	   a copy of the interface documentation formatted for HPFF 
use, including a copy in the current document and web mark-up languages.
----

There was discussion about what is the continuing process for 
submitting new things - this proposal presumes that the process continues.

It was decided that this should be in the document as the 
introduction to the appendix containing any interfaces.

Question - should be generalized for interfaces like libraries: 
--- 13 - 0 - 3
Vote on the Policy ... Second READING - 14 - 0 - 2.

Some discussion of status of our F90_LOCAL  - should it become one 
of these?  How about the proposed F77_LOCAL?

There was additional discussion about our base language document  
- F95 or F90?

Carl raised a different point  - should we really say F90_LOCAL?  
Shouldn't it just be Fortran_LOCAL? 

Jerry points out that X3J3 will probably vote the recommendation 
that the F77 archival standard be withdrawn.

Ken points out that this may make our action clear ... we should just 
say that our base language is Fortran.

StrawPoll --- We should be based on the "current" Fortran standard.   
(Implication is that we change F90_LOCAL to Fortran_LOCAL.)
     21 - 0 - 1
This was declared to be a first reading of this subject. 

BREAK FOR LUNCH  - to return at 1:10.

Chuck Koelbel presented the 2nd Reading - ON Proposal.
In first reading, this was for approved extensions only.

On  gives more control to the user and recommends where
operations should be executed.  Resident asserts that data need not 
move to processors outside the "on" set.

!HPF$  ON HOME (a(i))
    a(i+1) = b(i) + a(i)
----
do i=1,n
    !HPF$  ON HOME (a(indx(i))) BEGIN
            a(indx(i)) = b(i)
            v(i) = c(indx(i))
     !HPF$  END ON
end do
---
Do k - 1,10
    !HPF$  ON HOME (X(:,k) )
           DO j = 1,100
                !HPF$  ON HOME (X(j,k))
                    y(j+1,k+1) - x(j,k) + x(j+1, k) + x(j,k+1)
            end do
end do

--------

examples with calls

consider
!HPF$  ON HOME (a(1:2))
call foo(a)
---
subroutine foo(x)
!HPF$  ENVIRONMENT :: ON HOME (x(1))
x(2) = ...

key rules:
	- foo must have explicit interface in caller
	- foo's interface must include declarative ON
	- foo's ON set must be a subset of caller's ON set
	- DISTRIBUTE and ALIGN in foo:
		locals and dummies: mapped to foo's ON set
		Globals: may be mapped anywhere
		ALLOCATABLES: mapped to ON set of ALLOCATE

Discussion  - particularly about the assumptions about unmapped 
dummies. This was referred back to subgroup to work out more details.
---

Chuck next presented the proposal for RESIDENT.

!HPF$  ON HOME (X(k)), RESIDENT (X(indx(k))
x(k) = x(indx(k)) + y(indx(k))

!HPF$  ALIGN x(i) WITH  y(i)
DO i=1,n
    !HPF$  ON HOME (indx1(i)) BEGIN
          !HPF$  RESIDENT( x(n1)) BEGIN
               n1 =  indx(i)
               n2 = indx2(i)
               tmp = y(n1) - y(n2)
               x(n1) = x(n1) + tmp
               x(n2) = x(n2) - tmp
         !HPF$  END RESIDENT
    !HPF$  END ON
END DO

Inter procedural  Issues:  
	Does the compiler know which processors should execute FOO?
		 Yes from the declarative ON.
	Can the compiler allocate data?  Yes, local data in FOO must 
be mapped on executing processors. ALLOCATE must map to 
executing processors. Previously allocated data (globals, 
ALLOCATABLES) were local when memory was allocated. 
Remapping must map from executing processors to executing 
processors
	Can the compiler access data?  As well as it ever could.

Should dummies be resident by construction? - straw proposal 
14 - 0 - 7

Jaspal Subhlok presented the current  TASK REGIONS proposal:

!HPF$  begin task regions
     do  I - 1,n     ! a task regions is an assertion 
			(disclosure about code in region)
!HPF$    ON HOME (P91:4))    ! code directed to executed ON a 
			processors subset can only access RESIDENT data
    call colffts(a1)
!HPF$  endon
     a2  =  a1   ! No two ON blocks executing on 
		non-identical processor subsets can have conflicting I/O
!HPF$   ON home (p(5,8)
    call rowffts(s2))
!HPF$    endon
    enddo
!HPF$  end task regions
             
----
Execution MODEL / IMPLEMENTATION
Same code is generated as without task region, except:
   - non executing processors skip ON blocks completely
   - synchronizations / barriers inside an ON block are restricted to 
the subset

Task Parallelism Issues
   nesting TASK REGIONS and Ons is allowed
   exits from task regions are allowed, but may inhibit parallelism 
	(exit from an ON is of course illegal)
   Implementation should replicate computations involving replicated variables
	(This is a good idea in general in HPF)
  Async message passing can exploit more task parallelism than 
synchronous in barrier-based models.

example
TASK REGION
     while (true)
         on HOME (p1)
               done1 = read(a1)
               if (!done1)  fft1(a1)
          end on
       done = done1   !potential barrier
       if (done) exit
        a2 =a1
        on home (p2)
            fft2(a2)
         end on
              a3 = a2
        on home (p3)
             fft3(a3)
        end on
  end while
end task region

The difference from what Chuck presented at the last meeting is on 
I/O. This has a tighter restriction.

Vote with the understanding that if documentese doesn't appear 
tomorrow - it is resinded ... 
2nd reading ... 12 - 0 - 4  (as an approved extension)

BREAK FOR SUBGROUP MEETINGS

FRIDAY MORNING
Mary presented the document plan
In the interest of time - we will abandon the idea of producing a 1.2 
document, but we will use the text prepared for this document as the 
basis for generating our new 2.0 document.  The time schedule for 
producing the 2.0 document follows. 
May 3:  Chuck sends out a file with the 1.2 base files (minus the library)
May 3:  Chuck initializes an HPFF_DOC email list with instructions 
	for how to subscribe.  
Before May 10: Raw text pasted together in the order of the chapters 
given below is due to Chuck.  This text may or maynot be in latex. 
Chuck will merge and distribute a "raw" document as our
starting point.

May 13-May 22 - Chapter writers produce latex in roughly hpf-ese 
for each chapter.

Before May 22:  Latex with in roughly HPF-ese for each chapter is 
due to Chuck. Things like cross-references will be missing.

May 23 - Chuck will post the first "latex" draft of the document. 

May 24-June 7  back-up readers, volunteer readers, sweepers go over 
text and send in comments to hpff_doc.   Each comment should 
reference the chapter in the subject line.

June 7-June 21 Chapter editors iterate to improve and incorporate 
comments.  Comments can also continue - but may not make it into 
the revised text.

By June 21 - Send updates to Chuck.

June 24 -   Chuck reposts document.  An "alpha" version of the 
document also sent to wider audience to request early help in fixing  
problems in the document before it goes for formal public comment.

June 27 -   If some serious problems are noted with the June 24 
version - fixes due by this time.  Draft to Theresa for printing by June 
28.  (This timing recognizes that between the US holiday the 
following week, and the Vienna workshop, very few people will be 
around, and Chuck will not be available to issue a revised document, 
and that a few days are required for duplications / shipping.

July 10-12 - Final
 Names of the primary writing team, and back-up readers for each 
section are limited.  These are people who commit to input by the 
dates given and Mary will contact directly to nag about their 
contributions.

For each chapter a primary writing team has been assigned, along 
with other names designated as readers.  It should be understood 
that anyone is welcome to read an comment on any section.  In 
addition, a "sweep team" has been named - for a group who will do 
a pass across the entire document - looking for more global issues 
that might have "slipped through cracks": did CCI's get in?  did all 
the proposals get in?  Did the appropriate material from 1.1 get 
included or removed? Is the division between 2.0 and Extended features correct?

DOCUMENT OUTLINE and NAMES

Section I   Introduction
Chapter 0:  Front, ack, etc
	writer: Mary
	reader: Chuck
Chapter 1: Overview - terms and concepts - new document/language 
structure, Fortran language base, F95 features, HPF 1.1 deletions, etc.
	writer: David and Carl
	reader:  Bob, Rob, Chuck, Jerry
Section II  HPF 2.0
Chapter 2: Mappings  - distribute, align, sequence, some of pointer.  
Material from most of v1.1 chapter 3 and some of chapter 7.
	writer: Piyush, Carl, GLS
	reader: Saday, Guy R.
Chapter 3: Mapping across Subprogram Interface. Material from v1.1 
chapters 3 and 7.
	writer/reader - same as chapter 2.
Chapter 4:  Independent and Reduce
	writer: Chuck
	reader: Rob and Jay
Chapter 5: HPF Library (plus sort-up and sort-down)
	writer: Rob
	reader: Carol
Chapter 6:  Extrinsics
	writer: David
	reader: Mary
Chapter 7: Portability and Efficiency Issues (forall examples)
	writer: Andy, Chuck
	reader: Larry, Carl, Henry, Guy R.

Section III Extended Features
Chapter 8: More mappings (and related subprogram interface issues){should 
this be two chapters as in Section II?}  GenBlock, indirect, range, 
shadow, subsets, derived type, more on pointers.
	writer:  Piyush, Carl
	reader: Saday, Guy R.
Chapter 9: ON, TASK, RESIDENT
	writer: Chuck, Jaspal
	reader: Jay
Chapter 10: New Library - generalized transpose, extended inquiries, 
new mappings.
	writer: Rob
	reader: Henry
Chapter 11: Async I/O
	writer: Larry
	reader: Alok
Chapter 12: HPF_LOCAL
	writer: David
	reader: Carl, Carol, Saday
Chapter 13: HPF_SERIAL
	writer: David
	reader: Carl, Carol, Saday
Chapter 14: PROVISIONAL TEXT - F77_LOCAL (don't really know 
where and if this goes yet).
	writer: Carol
	reader: ?
Chapter 15: C Interoperability
	writer: Henry and Andy
	reader: Scott, Jerry

Section IV  Appendixes
A - BNF  (GLS)
B - Extrinsic Extrinsics - (policy, mechanism, HPF_CRAFT)
	writer: Mary, Andy
	reader: Bob
C- Subset
	writer: Mary
	reader: Carol
Glossary and Bibliography later.  PLEASE - Chapter writers - note 
those features that should be defined in the glossary and put the 
appropriate latex on the key places they are used.

Sweep Team:   Piyush, Carol, Henry, Rob, Mary

Meeting date discussion
Move date to July 10-12
SF meetings will start about 10am  and end by  10am Friday
We should try for some external readers prior to this meeting.
----------

Chuck revisited ON proposal.
Simplifications:
Introduce the idea of "active processor set"
	the set of processors that are executing
	the processors in the dynamically nearest enclosing ON
Do not require declarative ON in called procedures
	instead the call (dynamically) inherits the active processor set 
of the caller
	the call is performed by the caller's ON clause processors
Clean up dark corners
	unmapped local variables - always stored on active processors
	other unmapped variables - cannot assert RESIDENT
	Processor subsets - need not be regular sections

Explicit Data Mapping
Intuition is still the same
PROCESSORS, ACTIVE:: 
P(ACTIVE_NUMBER_OF_PROCESSORS())
	allows references to the active processor set
	use P later in ONTO clauses, for example

DISTRIBUTE
	No ONTO: Compiler chooses processors from active set
	With ONTO:
	  locals must map to active processor set (semantic restriction)
	  ALLOCATE of mapped data put data onto ALLOCATE's active 
			processor set

ALIGN
	Relevant elements of align-target must be on active processor set

REDISTRIBUTE and REALIGN
	Active processors set must include old and new data homes

Rob points it should be number_of_active_processors  -  but this is a 
pretty long-winded identifier.

This replaces the use of number_of_ processors - in almost all cases, 
except for common.

Consider in two parts:

Non - interprocedural stuff - second reading   - including amendment 
for ON PROCESSORS ... 14 - 0 - 2

First reading interprocedural definition - 15 - 0 - 6
    (There will be something in the draft document.)
--------

The remaining inquiry functions were postponed until July meeting.

-------

TASK provisionally passed missing the text.

-------

POINTERS - 
first 2 points the same as presented yesterday:
	pointers with sequential attribute
	pointer with no explicit mapping
AND propose these go into 2.0

pointers with explicit mapping
	point to targets iff they have explicit conforming mapping
	allocate object of the specified mapping
pointers with transcriptive mapping
	pointer :: p(:)
	distribute * :: p

	point to targets with any explicit mappings
	range can be used to restrict
	on allocation - compiler chooses

In cases 3 and 4 if the pointer also has the dynamic attribute
	point to targets iff they have the dynamic attribute
	range can be used to restrict
	allocation with usual restrictions
	redistribution with restriction

First reading of conforming mapping:
   two objects have a conforming mapping iff the corresponding 
elements are assigned to the same abstract processor.

There was some discussion about what this means wrt partially 
specified distributions.
	straw poll - can conforming have under specification?  10 - 0 -  9
	straw poll - in favor of a definition along this line 16 - 0 - 4

Second reading of items  1 and 2 for pointer (into 2.0):  15 - 0 - 0

Second reading of items 3 and 4 for pointers,  to go into approved 
extensions: 13 - 0 - 2

Larry meadows moved that item 3 go into 2.0.  The vendors were 
consulted before voting - with a formal vote of 14-0-0.

Larry Meadows moved that that with the exception of dynamic and 
range that item  4 go into 2.0.    Again, after  vendor consultation the 
vote was 8 - 0 - 7, so the motion fails.
So pointers with transcriptive mappings goes in approved extensions.

BREAK

Henry Zongaro and Jerry Wagener: Report from C interoperability ....
Reviewed 2 proposals. 

EXAMPLE - 
char * coo (int *, char [], struct *s)   ptr to int, char array, and ptr to 
struct
     struct s { int P, double q[10]  };

There are deficiencies in both - e.g. **   double indirection

HPFF proposal:
module vogs

   type s
        integer :: p
       real :: o(10)
   end type

  interface
   extrinsic (c) function coo (A,B,C)  NAME ('Coo')
      character (*), map_to(char[]) :: c00
      integer, intent (out), map_to(int) :: A
      character (*), intent (inout), map_to(char[]):: B
      type (s), intent (in), map_to (int, double []):: C
    end function c00
  end interface

contains  
    subroutine Foo1(J.K)
        integer, intent (in) :: j
       type (s), intent (out) : k
      character (*)

PROGRAM Zxy
   use vogs
    integer ::x
     real :: y
   character (80) :: z
   type (s) ;:: ss
    real 

MODULE DEF_DATA_TYPES
   USE ISO_C_KINDS; USE IOS_C_STRINGS
    TYPE DT
       integer :: I; (KIND (...  )
     endtype DT

type, BIND (C) :: DT_C
     integer (C_INT_KI) :: I; REAL (C_DOUBLE_KR) :: ARR (10)
end type DT_C
END MODULE DEF_DATA_TYPES

PROGRAM P
   USE DEF_DATA_TYPES
   INTERFACE
   BIND (C, NAME = 'Coo') FUNCTION coo (I,C,s)
       USE DEF_DATA_TYPES
        TYPES (C_CHAR_STRING):: coo
    INTEGER (C_int_ki)

Amendment to existing proposal:
     change the c type names have kind type parameters in the map-to
     use intent out  to convey address-of
     extend map_to to structures

Finish the details of the amendment ... at the next meeting .... 18 - 2 - 1.
To be continued at the next meeting

Carol Munroe:
>From the subgroup that discussed the  Fortran issues.  The impact of 
a change of the base language on the document should be minimal.  
Basically, the rule numbers are ok.  It would be nice if we could have 
some appendix with formal definition of features we use - and we 
could shorten what we have in the document.  The name of 
F90_LOCAL should be changed to Fortran_LOCAL.

Carol then presented an F77_LOCAL proposal.  The motivation is to 
meet the needs of two groups of users: 
   group A - those wanting convenient interface to f77 library 
subroutines directly;
   group B those wishing to do low-level F77 programming plus 
message passing with local portions of globally distributed arrays 
with no remapping - in place, complete with complex layouts, 
shadow widths, etc.

Provision for array passing:
   group A  MAP_TO(F77_ARRAY)
       or PASS(F77_ARRAY)
   group B   MAP_TO (NO_CHANGE)
      or PASS (NO_CHANGE)
           PASS (DESCRIPTOR) - if descriptor handle is needed for local 
for local inquiry functions.

In the subgroup, several votes were taken:
	vote: minimalist version  with just F77 keyword - 3-2-1
	vote: should any F77_LOCAL interface provide an option to 
pass distributed arrays and  make the local portions contiguous 
(sequence associated)?    vote 6 - 0 - 0
  should any F77)Local interface allow a way to pass local portions 
distribution?

Subgroup recommends that we go for a recognized interface like 
HPF_CRAFT ...  4 - 1 - 1

First reading:  there should be a version of F77_local  - as   simple as 
possible. 11 - 2 - 4

-------

HPCN report - Ken gave two talks at HPCN.  There is good interest 
in Europe.  HPF is being tried on a variety of applications, and there 
was a general positive reaction to our extensions.  We should expect 
an active set of comments on what we are proposing.  There is a lot of 
interest in ON and irregular mappings.  Larry reported a surprising 
amount of interest (on the exhibit floor) from Eastern Europe, 
especially Poland.  

Guy Robinson reminded the group about the HPF meeting in Vienna 
in the first week of July.

===========================================
As of the end of the meeting, the proposal status is:

			1st	2nd
group E                                
	
SPMD-HPF-ext.		Mar	July		am/lfm
Base language Fortran (not F90) May	July
Amended C interface	May	July		hz/jw
F77_LOCAL ext interface May	July		cm

group D                              
dark corners of ptr  	Mar.	May

group C                          
on - interproc		May	July		ck	
task write-up		Mar	July
inq additions		Jan	July		rs

DONE - 
	(C) async		ext	lm
	(C) gen transpose	ext 	rs
	(C) inq updates	ext	rs
	(C) task regions	ext	js
	(C) on - {no calls}	ext	ck
	(D) reduc - simple	2	rs
	(D) reduc - simple amended	2	rs
	(D) derived typ		ext	gls
	(D) derived type amended ext
	(D) shadow width	ext	co
	(D) irreg map		ext	?
	(D) dist ranges		hz
	(D) seq. nonmap		2	cm
	(D) subsets		ext	pm
	(E) name/etc.	
	(E) kernel		chapter	am
	(E) interop		ext	am
	(E) local_global func	?	cm	
	(E) explicit interf	2	~
	(E)Elim. GLOBAL_LB/UB	1.2/2.0	mz
	New Sort functions	2.0	cm
	Rules for extrinsics	2	mz
-------------
The next HPFF meeting is scheduled San Francisco  July 10-12.  The 
final  HPFF meeting is September 18-20 (again San Francisco),  with 
the expectation that there will be a public comment period between 
July and September.

-------------------------------------------------------------
May Attendance:    
Robert Babb	u. of Denver  		[email-masked]
Siegfried Benkner Univ. of Vienna  	[email-masked]
Jay Boisseau	SDSC			[email-masked]
Bob Boland	LANL			[email-masked]
Alok Choudhary	Syracuse U.		[email-masked]
Ken Kennedy	Rice U./CRPC		[email-masked]
Charles Koelbel	Rice U. 		[email-masked]
David Loveman	Digital 		[email-masked]
Larry Meadows	The Portland Group 	[email-masked]
Piyush Mehrotra	ICASE			[email-masked]
Carol Munroe	Thinking Machines	 [email-masked]
Carl Offner	Digitalx		[email-masked]
Guy Robinson	University of Vienna 	[email-masked]
P. Sadayappan	Ohio State University	[email-masked]
Joel Saltz	U. of Maryland 		[email-masked]
Rob Schreiber	HP  			[email-masked]
Jaspal Subhlok	Carnegie Mellon		[email-masked]
Manuel Ujaldon	U. of Maryland 		[email-masked]
Arun Venkatachar Louisiana St. Univ.	[email-masked]
Jerry Wagener	U. of Oklahoma 	 [email-masked]
Henry Zongaro	IBM Canada		[email-masked]
Mary Zosel	LLNL			[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>
---------------------------------------------------------------------------