Subject: hpff: January 96 HPFF Minutes

From: owner-hpff
Date: Mon, 26 Feb 1996 17:04:40 -0600 (CST)

---------------------------------------------------------------------------
[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.
---------------------------------------------------------------------------

High Performance Fortran Forum Meeting
January 9-12 Houston, Texas
Record of Action:  Mary Zosel

Executive Summary
There were 20 people from 17 institutions present.  Attendance was 
impacted by severe storms on the east coast that  delayed some and 
grounded others.

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:
Query of function results in local library (11-0-5)

Proposals still in progress of second reading:
Clarification/ simplification to intrinsic reduction proposal (previously 
passed).

Proposals passing in first reading: 
User-defined reduction (8-5-4)
Elimination of explicit mapping of sequential data (11-0-6)
SPMD_HPF extrinsic interface (11-0-7)
Processor sections as distribution targets (14-1-3)
Specification of distribution ranges (15-0-4)
ON proposal (15-4-1)

Proposals discussed in a preliminary review:
Possible disjoint processor subsets.
Out-of-core array specification (dropped 2-7-10).
Task/end Task  (8-2-8)
---

Other items of special note:  An update of the HPFF WWW pages is planned.  
A vendor group was chartered to address the issues of language split and 
what content and names should be from a marketing perspective.  Their 
initial recommendation, which will be considered in more detail at the next 
meeting, is that there be a subset language, a full language that includes 
HPF1.1 with minor exceptions plus a  few new features, and a set of 
approved extensions that include the other features discussed in the HPFF 2 
meetings.  This has not be formalized.

The next HPFF meeting is schedule for Arlington (Dallas area) March 13-15. 
There is also an HPF Workshop planned in conjunction with HPCN 96 in 
April and two additional HPFF meetings planned for May  1-3 (Arlington) 
and September 18-20 (San Francisco),  with the expectation that there will be 
a public comment period between May and September.

End of Executive Summary
____________________________

Detailed Record of Action
The meeting was called to order by Ken Kennedy Chair Tuesday Morning, 
Jan 9. Due to "Blizzard 96" a number of people planning to attend were 
stranded on the east coast.  Most eventually arrived, to give an attendance of 
20 people from  17 institutions.  Because of the staggered arrival, issues 
requiring voting were deferred until Wednesday.

		1st	2nd
group E                                
    	kernel	done		2	am
	interop	done		2000	am
	format	Jan	Mar	
	explicit interf	done		2	~
	SPMD-HPF	Jan	Mar	
	local_global func	Jan	Mar	

group D                              

	irreg map	done		2000	?
	dist exten	dead
	dist ranges	Jan	Mar
	seq. nonmap	Jan	Mar	
	subsets		Jan	
	derived type	done		2000	gls-
pper
	shadow width	done		2000	co
	OOC	Jan	Mar	

group C                          
	async	done		2000	lm
	on	Jan	Mar	
	reduc - simple	partly done		2	rs
	reduct	Jan	Mar	
	task	Jan	Mar	
	gen transpose	done		2	rs
	inq updates	?		~	rs
	whoami	needed

After a review of the status of proposals (above), the group broke into two 
subgroups - one to address the cci issues from group C, and the other to plan 
updates for the HPFF WWW page and work on the 1.2 document update.  

The group reconvened at 3:40 pm. with 4 additional people present.

WWW update
Ken will provide staff to work on a reorganization and update of the HPFF 
web pages. Two overall goals are to automate as much as possible, and give 
the people who generate the remaining information access so that they can 
do direct updates of the remaining pages.  Barbara Chapman will establish a 
site at Vienna where the main pages can be regularly forwarded, so that a 
European mirror site is also up to date.

There are  three major kinds of information on the pages:  implementation 
status, meeting/technical information, and information about related 
projects/efforts. These will each be handled separately.

Implementation status: The goal is to  get this information into a database - 
hopefully with automated updates, queries, and views.   New proposed 
views are what platforms a given software company supports, and which 
implementations are available on a given platform.   Software companies 
would have the responsibility of submitting a template to keep the 
information up to date about where a product runs.

For HPF2 information: - keep this up to date by the person responsible. 
Desired information includes meeting information (dates, announcements, 
minutes), proposals (list, status, text), and document drafts as they evolve - 
especially as they are ready for public comment.

For the related efforts: add new categories about education and workshops, 
and complete the automation.  Currently forms are submitted, but it is up to 
human interaction to update the pages.

We need to talk to Mississippi State about transition to the new pages and 
leaving a functional page at the original www address.

Editing - subgroup has text for many of the cci's and a goal is to have a draft 
1.2 document soon.

Rob Schreiber presented the CCI items from Group C
CCI 18 - X3 J3 has a resolution for a defined assignment in a forall. Propose 
we adopt the 
same solution.  Decision taken by WG5 was to prohibit variable on left-hand 
side of 
defined assignment from being referenced elsewhere.
Recommend we adopt the same:
Section 4.1.1, page 59, line 29, add the following paragraph:
"in a <forall-assignment-stmt>, a defined assignment subroutine must 
not reference any <variable> that becomes defined or <pointer-object> 
that becomes associated by the statement."

CCI 36 Can a call in independent cause an actual to remapped?
Resolution - no - it is almost forbidden in 1.1  Enlarge the prohibition 
against remapping a dummy adding - "This forbidden remapping 
includes remapping due to a subprogram invocation in which an 
actual argument that is a variable name or a regular array section 
is argument associated with a dummy argument that has a different 
mapping."
A similar sentence should go into the rational - CHK will do it.
    Some discussion about how this applies to the HPF library ... this is 
from page 85 of v1.1. third bullet ... 

CCI 37 - Locals of subprograms called in independent DO loop 
automatically - new?  Was resolved in 1.1. - no change needed.

CCI38  - Follow MINLOC example, use 1-based indices.   Make a document 
change to clarify required.  (does LB need to be added by user or library).  
In F90 you must added it yourself, but in GRADEUP, HPF does it the other 
way - library adds it for you.
    INTEGER A(5:10)
    CALL SUB(A) ...
    EXTRINSIC(HPF_LOCAL) SUBROUTINE SUB(D)
    USE HPF_LOCAL_LIBRARY
     INTEGER D(4:), L(1)
     CALL GLOBAL_TO_LOCAL (D, G_INDEX=(/5/), L_INDEX=L)
     END
Does 5 mean A(5) or 5th element of A???

Decision was to go with the 1-based, since it is in harmony with Fortran 
assumed-shape, and in some situations, it is not possible to get at LBOUND, 
(e.g., for ABSTRACT_TO_PHYSICAL). --- in the above it is A(9).  Henry 
will edit the source files for Rob.   Rob / Henry will check how many 
this applies to.   

CCI Item BB (new item)
PURE RECURSIVE FUNCTION LISTLEN (L) RESULT (R)
   TYPE LIST
       SEQUENCE
       TYPE (LIST), POINTER :: NEXT
       INTEGER :: VALUE
   END TYPE LIST
TYPE (LIST), POINTER ::L
IF (.NOT. ASSOCIATED(L)) THEN
   R=0
   RETURN
ENDIF
R=LISTLEN(L%NEXT)+1
END

Problem
p.76, lines 10-11 prohibits pointer dummy argument of pure function  from 
being associated with another pointer dummy argument on a  procedure 
reference.  This seems overly restrictive, so the proposal is that P.76 line 10-
11 change to:
  "· As an actual argument associated with a dummy argument of a pure  
subroutine with INTENT(OUT), INTENT(INOUT) or the POINTER 
attribute."  
And  include this example in the document.

There was a digression of discussing how this is different from F95 pure and 
also that  F95 has a different solution to CCI #3 (allocate in pure).

CCI new item (CC):
Need to clarify text in HPF_LOCAL to make it clear that each instance  of the 
HPF_LOCAL gets its own copy of HPF_LOCAL common blocks and  
HPF_LOCAL module data.  (That *was* the intent, wasn't it??)   Rob will do  
this.   Mary notes that SAVE is necessary. 

CCI #40 - NEW(I) for DO loop index 
Resolution legal - guarantees that I is not used (value is not referenced) 
following  the loop.

CCI 41 / 42 and were OK as answered.

CCI #29 EXTRINSIC in Independent
Resolution - no change. (Yes, you can do it).

Issues ready for discussion Wednesday were reviewed.
...........  

Wednesday AM - Meeting started at 9:00 with Ken as chair.  Two more 
people from the east coast storm area were present.

For the first agenda item Chuck Koelbel presented a possible HPF document 
outline.
David Loveman noted that the ack. section is missing(should still be there).  
In some discussion about where technical items would go:  INHERIT 
belongs in HPF 2. SEQUENCE  probably goes, in chapter 4 with how to cope 
in chapter 8.  Query about F95 intentions. There probably needs to be a new 
item in part I.  Also there is a new item to add on Parallel I/O

How to handle the syntax rules??? Put the complicated ones in Part II and 
handle the restrictions in the text???  Numbering is a problem.  Other 
considerations are reader understanding and also what kind of errors we 
expect HPF2.0 compilers to produce.

David has produced an MS word version of HPF 1.1. There was an  extended 
discussion about document formatting.  A subgroup will meet and discuss.  
Rob would prefer to stay with LATEX for the inquiry section. Ken said he 
would try to contact Adobe about licenses for FRAME.

-------
Jerry Wagener gave an update about F2000 Content and Process
ISO Technical Reports in preparation are:
	A. Floating-point - Exception Handling
	B. Interoperability with C
	C. Allocatable components, dummy arguments, function results
	D. Parameterized Derived Types (not yet approved by ISO as TR, but 
may be)
Specialized development bodies will develop the report (quickly) and X3J3 
will Review. then these will become a formal WG5/ISO Technical Report.   
This represents a new model for speeding up standardization.

Other F2000 Requirements - to be handled by X3J3:
1. Derived Type I/O
2. Condition Handling
3. Pointers to Procedures
4. Asynchronous I/O
5. Command-line Arguments
6. Specifying Default Precision
7. Object-oriented Fortran (still ill-defined concept)
8. Remove limitation on statement length
9. Private and Shared Data in Parallel Processes (how to handle things like 
exceptions that only happen on one processes) - ill-defined. This is a problem 
that needs to be fixed, but not sure what, and how to fix.  Ken pointed out 
that X3H5 did do careful work in this area.
10. Processor-dependent list
These will he handled by X3J3 ... then the ISO TR's will be integrated.

WG5 will take the approach of intrinsic functions for conditions handling, 
instead of the ENABLE proposals.

Ken asked how a TR subject gets created.  Jerry: go to WG5 meeting and 
convince them - WG5 then convinces ISO.  Ken wondered about the 
possibilities of getting some of HPFF document into the status of a published 
TR.  If we identified such subsets - we might work with some subgroup of 
X3J3.

To get at WG5 information, one can look at: 
http://www.etrc.ox.ac.uk/WG5.

==============
Next Rob Schreiber presented the reduction proposals
First, clarifications to  the simple reductions (we already had a 2nd reading):
(1) Intrinsics - all associative (math, not infinite precision); two not 
commutative: //(concatenate), and MATMUL.

(2) Use whole array, regular section, or single element in any reduction 
forces the whole array is a reduction variable
(example)
!hpf$ independent
Do
    !hpf$ reduce
    x(i) - x(i) + 1
    print *, x(2) ! bogus    all of x is a reduction variable
end do

This is a different way of saying the simple reduction. It makes the previous 
proposal a little simpler and makes it clear that the whole array is involved 
and puts it just in one place instead of a number of directives.

(3) External syntax
!hpf$ independent, reduction (x,y,z)
do i=1, ... n
 ....  ! x only allowed in reduction statements
enddo

Since this is a change (potential simplification) to previously passed item - 
procedure will be .... if accepted, second reading ... but request to have Rob 
present the full revised proposal.    15 - 0 - 3 strawpoll.

------
VERY SIMPLE extension for User-Defined Reduction  First reading
!hpf$ independent reduction (x, A=MY_ID(-))
do i-1,n
   x = x+1
   A = MY_OP (A,B)
   ... 
    A= MY_OP(C,A) ... only allowed if MP_OP is commutative

Propose a new keyword in the language that is used in the same place where 
PURE is ... COMMUTATIVE:
	PURE, COMMUTATIVE, TYPE(MY_TYPE) FUNCTION 
MY_OP(A,B)

Chuck argues that COMMUTATIVE should stay as a directive instead of 
first class keyword --- since it just gives information for another directive

Amendment - commutative should be directive rather than syntax ... 
strawpoll 8 - 2 - 8.
 
More discussion the larger issue of user-defined operators in reductions. 
Jaspal asks about if these functions (pure) are functional enough?  Others ask 
if this is too much - why should we have this even in HPF2000?  Has there 
been some experience. Yes - Jaspal has some, but PURE is too restrictive.   
Should there be a second reading of a reductions for user-defined reductions:    
8 - 5 - 4.   Ken requests a development of a second reading.

BREAK ...

Carol Munroe:    First Reading of a proposal to limit mapping sequential 
data.
Proposal:   A sequential array cannot be explicitly mapped. (i.e. remove 
exception for 1-D sequential aggregate covers.)

Reasons:
1. Make the language simpler for users.   (Eliminate painful definition of 
aggregate covers in 5.7.15 - 5.7.17.)
2. Simplify the compiler and the generated code.
3. The old rule may not help old codes anyway.
And no vendors have implemented it or even plan to do so.

Straw poll - 11 - 0 -6

-------------------

Andy  Meltzer - overview of SPMD straw proposal:
Introduction
SPMD_HPF is an extrinsic environment based upon HPF_LOCAL with all of 
the HPF 2.0 built on top.  SPMD_HPF is a multithreaded language like 
HPF_LOCAL.  It allows seamless use of low-level paradigms, such as 
message passing, get/put, and explicit sync.  All HPF 2.0 language and 
directives are features plus additional features for SPMD control and 
additional rules defining relationship between HPF_LOCAL and HPF2.0 
things have been added.

Why SPMD_HPF?
Not applicable to all platforms, but for platforms that can support it, allows 
greater flexibility and higher performance.  A multi-threaded model allows 
easier migration path for MP users, so HPF is no longer "all or nothing".  
Extrinsic environment allows well defined interface to standard HPF.  Many 
of these are currently successfully in use.

New in SPMD_HPF
Data defaults are those of HPF_LOCAL, called private.  The interaction 
between private and explicitly mapped data is defined. Parallel inquiry 
intrinsics added (IN_PARALLEL, IN_INDEPENDENT).  Serial regions are 
added (MASTER/END/MASTER).  Explicit sync primitives are added. 
Assorted other features are suggested that have been useful in CRI's Craft.

Data Mapping
No changes from HPF 2.0. All data distributions formats are available. Data 
defaults to private (the default behavior of HPF_LOCAL). If explicitly 
mapped, the array is shared - if not explicitly distributed, it is private on 
each processor.  Note that scalars are private  by default ... would have to 
make some explicit distribution to force the value  to be the same across the 
processors.

Input and Output
I/O behaves like HPF_LOCAL I/O.

Subprogram Interfaces
Subprogram interfaces behave exactly like HPF 2.0 for explicitly mapped 
data. Subprogram interfaces behave exactly like HPF_LOCAL for private 
data. The interaction between private and explicitly mapped data is defined 
in the written proposal.

The INDEPENDENT Directive
In one form, INDEPENDENT looks and behaves exactly like in HPF 2.0, 
except that private data is allowed to vary in value between processors.

Because we don't yet have any ON_HOME, the ON_HOME version of Craft 
is put in as a place holder.

 At this point there was a long discussion to clarify the model, the difference 
between this and HPF and HPF_LOCAL and  ???

Chuck posed this example:

DO I=1,5
    A(I) = 1  ! A private
    B(I) = 2  ! B distributed
END

Given 4 processors, and 20 elements for A and B, this will do 1-5 on each 
processor, hitting the first  5 elements of B multiple times.

A motion to kill the whole presentation died for lack of a second.

INDEPENDENT has an interesting difference .... do is more like a 
DO_PARALLEL in PCF ... when applied to a DO loop with or without 
independent.   In the model above - with INDEPENDENT - there is 
worksharing - someone does B(i) - without INDEPENDENT, there is no 
worksharing ... every processor does the B(i) - and then ships it to the owner 
of B(i) in the case of a distributed B.

Array Syntax
Array syntax with all private data acts like it does in HPF_LOCAL. Array 
Syntax with explicitly mapped data acts like it does in HPF 2.0.  All 
processors must co-operate. Mixing private and explicitly mapped at is 
defined, specific rules are give in the written document.  

Serial Regions
In a multi-threaded environment it is useful to start a single-threaded 
section, operating on one processor.  MASTER/END MASTER are used for 
this.

Synchronization Primitives - locks, critical section events, barriers are also 
defined.

Other user possibilities from Craft are:  no barrier - parallelism specification, 
resident,   assertions, geometry.

Ken: A way to think about this -  these extrinsic environments we are 
looking at are something like the TR from F2000.   There could be infinite 
extensions to the language, if we think about them as part of the language 
itself.   Here is a model a number of people are using:  we can either be 
concerned with a clean interface - or  as part of the language.

Straw poll about whether this should be proposed as a second reading for 
March:  11 - 0 - 7.

Break for lunch ....

1:40 reconvene
Larry Meadows (and Vince Shuster) Portland Group presented a proposal 
related to the naming of the language split - and the contents of the language 
split.  

The concept of a separate kernel HPF and enhanced HPF is valuable, but the 
HPF2000 and HPF 2.0 designations were arrived at without proper market 
considerations. Confusion and controversy exists.  HPF acceptance, HPF 
process credibility and HPF vendors will be affected by the designations. 
The HPF 2000 name does not foster a notion of it being commercially viable, 
but rather sounds like a good idea that will never be implemented.  A 
consideration:  should be code that is HPF 1.1 compliant that will not be HPF 
2.0 compliant?

Ken summarized the concerns:  HPF 2.0<HPF 1.1   and the implication is 
HPF2000 -> never.

Proposal:
A task force be created to redesignate these language. The task force should 
be composed of HPF compiler vendors and MP system vendors.
Charter:
	Determine designations that will advance HPF kernel acceptance 
and establish the enhanced HPF's commercial viability.
	Emphasize separate HPF Kernel as the choice for portability and 
performance.
	Address compliance issue for HPF1.1. programs that would not be 
HPF kernel compliant.
	Submit recommendations
-------
At this point there were several cheerful asides about possible names:
Cheerful aside about names:
	hpf_commercial vs hpf_academic
	hpf_real vs hpf_virtual
	hpf.com vs hpf.edu vs hpf.gov (for the users)

Serious point - before the break, we just had a very positive vote to take the 
explicit mapping of sequential variables out of the language.  What would 
this mean for HPF 2.0?

Question about who would make up this task force? Parallel vendors who 
have some HPF on their system?   The task force should report back like any 
of the subgroups do.  E.g. report the votes.  Proposal on the table by next 
time.

====================
The group adjourned for subgroup meetings, including a first meeting of the 
set of vendors about the Portland Group proposal.

Thursday Morning January 18
Carl Offner raised the issue of a technicality in the shadow width proposal 
that we have accepted.  Specification-expression should be constant-
specification-expression.  This modification was accepted.

Barbara Chapman presented the first reading of mapping to subsets of 
processors. The proposal is split in 2 parts:

(1)  - Processor sections as distribution targets:
Replace H311 by
dist-target is proc-name [(proc-section-subscript-list)]
                or * proc-name [(proc-section-subscript-list)]
                or *

proc section-subscript is subscript
                                        or subscript-triplet

constraint:  the number of items in the proc-section-subscript-list must equal 
the rank of proc-name.
constraint: the subobject referred to by proc-name [(proc-section-subscript-
list)] may not have size 0.
constraint: Each subscript should be an integer specification expression.

The subcommittee vote was 4-0-0.
The full committee (straw) vote   14 - 1 - 3.

Chuck asks if the constraint on the subscripts still applies to redistribute.

(2) Second part of the proposal -  We want to be able to have the possibility 
of having disjoint processor subsets - e.g. for a multi-grid distribution
   - we cannot define 2-d processor array so that disjoint sections of these 
shapes "fit in"
   - tasking also will require disjoint sections of available processors with 
high degree of flexibility.

This functionality can be provided by definition of subgroups and reshaping 
of processor arrays - for example:

   !hpf$ processors p1(20,20)
   !hpf$ subgroup psub of P1( 2:6, 3:15:2)
   !hpf$ subgroup psub1(50) of p1(6:100,1:10)

This gives a flexible means of obtaining, in particular, arbitrarily shaped 
disjoint subsets of processors.  But there appear to be several ways to do this;  
it isn't clear that this is the right way to go.

Subcommittee recommendation:  This needs yet more work - but isn't ready 
for a vote - even a first reading.  Chuck asks if the reshape intrinsic was 
considered.

========

Mapping intrinsics need to be reviewed with respect to subsets.

==============
The first reading of a proposal for distribution range specification was 
presented by Henry Zongaro.

Rationale:
For transcriptive distributions, DYNAMIC and pointers, compiler may have 
to
generate very inefficient code to ensure that it correctly handles all cases.  
Very often, a user will only need a small subset of the possibilities in a 
particular program.  In order to permit the compiler to generate more 
efficient code in such situations, the user can specify distribution ranges for 
such objects.

Two examples of possible syntax:
   subroutine sub(a)
   integer a(:,:,:,:)
!hpf$ inherit a
!hpf$ range a (block, * case(block,cyclic(), indirect),all)
    or
!hpf$ range a(block,*,block,*),(cyclic*cyclic,*)
   or 
   combine the two   e.g. pull in the case

Possibilities
   BLOCK - compatibility with  BLOCK,BLOCK() CYCLIC(), ALL
   BLOCK(n) - comp. with  BLOCK(), CYCLIC(), ALL
   CYCLIC - comp. with CYCLIC, CYCLIC(), ALL
   CYCLIC(n) comp with CYCLIC(),ALL
   * comp. with  ALL or *
   GEN_BLOCK- comp. with  GEN_BLOCK or ALL

There may be a need to work out some details about pointers being passed.
Carol asks about the case where just a part of an array  is passed - e.g.  A(2:n)

Joel --- When would this actually be used? Barbara and Carl both provide 
examples.
Straw poll about the overall proposal- 15 - 0 - 4
Some straw polls on the details:
	first syntax --- 6 - 4 - 9
	second syntax --- 11 - 0  - 7
	combination --- 4 - 6 - 9
There seems to be a preference for the second syntax.

============
Next Alok gave an over view of the Out-Of-Core proposal:

!hpf$ template temp(100,100)
!hpf$ distribute temp(block,block)
!hpf$ align with temp:: A,B
!hpf$ out-of-core: A(<unit no>) ... { user associates a metadata file by an open 
statement which opens the metadata file on unit number - if is old 
persistent}.
!hpf$ out-of-core:B     ... { compiler is free to choose a unit number and file 
name}.

Persistence of an array "specified" using the open statement by extending 
STATUS field
STATUS  = OLDPERSISTENT ! already exists
   = NEW PERSISTENT ! create and store
   = OLDSCRATCH ! already exists, no need to save
   = NEWSCRATCH ! create , delete after using

Other restrictions: 
   - unformatted only
   - direct access only
   - read write only

Metadata should:
 - contain names of files containing OOC, persistent array
 - processor arrangement that created persistent array distribution 
information 
 - data type (record ...)
 - organization of data within files(s)

This information should be accessible using inquiry functions.

Chuck asks if these can properly be considered directives, or should they be 
first class statement?  This was followed by various comments such as:  
"interesting, but too premature to talk about standardization", "might be a 
way to address new architecture directions", and questions about details of 
open, status, persistence options, etc.

Straw poll about interest in pursuing:    2 - 7 - 10
OOC will be dropped.

=============   

Carol presented the proposal to fix a local-global issue that stemmed from an 
earlier CCI.

Query functions for array-valued extrinsic HPF_LOCAL functions, 
specifically
the following HPF_LOCAL_LIBRRY procedures:
	GLOBAL_ALIGNMENT(ARRAY, ...)
	GLOBAL_DISTRIBUTION
	GLOBAL_TEMPLATE
	GLOBAL_LBOUND
	GLOBAL_UBOUND
	GLOBAL_SIZE
	GLOBAL_SHAPE(SOURCE)
	ABSTRACT_TO_PHYSICAL
	 PHYSICAL_TO_ABSTRACT
	LOCAL_TO_GLOBAL
	GLOBAL TO LOCAL
	LOCAL_BLKCNT
	LOCAL_LINDEX
	LOCAL_UINDEX(A

Currently, each of these procedures accepts an argument ARRAY (or 
SOURCE), as an INTENT (IN) argument that is a dummy array argument to 
the extrinsic function.

Proposal:  Modify the description of each ARRAY argument to read
"it must be either a dummy array that is associated with a global HPF actual 
array argument or the array-valued result of a HPF_LOCAL function called 
from HPF.

2nd reading vote --- 11 - 0 - 5.   This goes where ever rest of local library goes 
HPF2/HPF2000.

BREAK ----

SubGroup C proposal processing ....

Chuck - 1st reading mostly for HPF2000 features.

ON  Proposal
Motivation
Some programmers want more control:
	which processor executes the operation makes a big difference
	whether data is moved makes a big difference
ON HOME recommends where operations should be executed
	... similar to the way DISTRIBUTE recommends where data should be 
placed
RESIDENT asserts that data need not move
	similar to the way INDEPENDENT asserts that operations are parallel

Changes to proposal document since September:
	local is spelled RESIDENT
	ALL is spelled EVERY
	BLOCK is spelled BEGIN
	Declarative ON clause applies to the whole procedure
	2 Options - ON propagates through CALL, and it doesn't
	If ON propagates through CALL, the callee must also declare ON
Changes last night:
	Clarify RESIDENT meaning for reads and writes
	RESIDENT may be separate from ON
		asserts locality relative to the surrounding ON
	RESIDENT(X) means what RESIDENT (EVERY(X)) used to
	ON propagates through CALL (with declaration)
	Resident propagates through CALL (no declaration needed)
	Add a NEW clause to ON HOME (analogous to INDEPENDENT)
ON HOME Examples
!HPF$ ON HOME(a(i))
        a(i+1) = b(i) + a(i)
-----
DO i - 1,n
	!HPF$ ON HOME (A(index(i))) BEGIN
		a(index(i)) = b(i)
		b(i) = c(index(i))
	!hpf$ end ON
END DO
----
!HPF$ ON HOME(x(i,:)) BEGIN
DO j= 1,m
	!HPF$ ON HOME (x(i,j))
	x(i,j) = foo (y(j,i))
END DO
!HPF$ END ON
========
CALLS in ON HOME Blocks

Consider:
!HPF$ ON HOME (a(1))
CALL foo(a)
---
SUBROUTINE foo(x)
! ON must be a subset of the caller
!HPF$ ON HOME(x(1))
     x(2) = ...

The problems:

Does the compiler know which processors should execute FOO? Yes.
Can the compiler allocate and use local data?  Yes.
	Local data in FOO must be mapped on HOME (x(1)).
What about global data?  It's tough.
	Ignore ON  and  set up 2-way communication.
	Constraints on declarations need work.

Discussion - points out that may need some local processor arrangements 
declarations. Maybe relax the restriction that processor arrangements match 
the total processors - so that they match the current ON processor set.

---
RESIDENT Examples:
!HPF$ ON HOME(x(k)), RESIDENT (xindx(k))
      x(k) = x(indx(k)) + y(indx(k))
---
!HPF$ ON HOME(indx1(i)) BEGIN
	n1 = indx1(i)
	n2 = indx2(i)
	!HPF$ RESIDENT (x(n1), y(n1)) BEGIN
	   tmp = y(n1) - y(n2)
	   x(n1) = x(n1) + tmp
	   x(n2) = x(n2) - tmp
	!HPF$ END RESIDENT
!HPF$ END ON

Rob asks about if there should be some restrictions on the values of 
subscripts used in the RESIDENT clause?  Is it an assertion about the lexical 
expression - or about a specific value?
---
New and Old RESIDENT
!HPF$ ALIGN y(i) WITH x(i)
!HPF$ ON HOME (procs(1:2)), RESIDENT(x) ! "every element of x touched 
is local"
	x(i) = x(indx(i)) ! (i), x(indx1(i), x(indx1(i)) are local
	y(i) = y(indx2(i)) ! y(i) local, is y(indx2(i))?
!HPF$ END ON

! THE OLD WAY - obsolete
!HPF$ ON HOME (procs(1:2)), RESIDENT(x)  
	x(i) = x(indx1(i)) ! every element of x is local
	y(i) = y(indx2(i)) ! every element of Y is local
!HPF$ END ON

---
Interprocedural RESIDENT
!HPF$ ON HOME(procs(1:mp/2))   [, RESIDENT]
CALL foo(a,b)
---
SUBROUTINE foo(x,y)
!HPF$ ON HOME(procs(1:np/s))   [, RESIDENT}

Options:
	caller has RESIDENT, callee has RESIDENT
		Complete info, compiler has no problem
	caller has RESIDENT, callee doesn't have RESIDENT
		call can happen on half of processors, two-way comm will 
work
	caller doesn't have resident, callee has RESIDENT
		caller must compile for hard case, callee won't use half 
machine
	caller doesn't have RESIDENT, callee doesn't have RESIDENT
		Do it the hard way

At this point the subgroup C members had an extended subgroup discussion 
about the correspondence between ON/RESIDENT and explicit interface 
requirements.  In simple cases should calls require explicit interfaces?

----
On Directive in HPF 2.0

Restrict subscripts in HOME
	Only affine functions of DO loop indices.
	We also need variables that are invariant in the loop nest.
	HOME(x(i+1)) OK
	HOME(x(n-i+1)) OK
	HOME (x(indx(ii)) not OK
Are other restrictions needed?
	Calls not allowed?

Discussion of proposal as a whole - skipping details.
Carl:  problems of when functions enter into the picture - is this mostly for 
shared memory???  Otherwise, this is leading the user  in a misleading 
direction  that has performance impact.    What assumptions that subroutines 
execute on all processors vs a subset? Larry points out FORALL already 
assumes separate calls.     Discussion continues ... 
Straw poll on full proposal:  15  - 4 - 1
Should calls be precluded?  yes = no calls ... 2 - 9 - 9
Should explicit interface (with explicit ON) be required?  8 - 1 - 10
Should any of this be in HPF 2.0??? 3 - 7 - 11    (Subgroup won't put lot of 
priority)

Break at 12:15 for lunch

--------------

Rob presented the latest version of a TASK proposal.

Multiple HPF processes running in parallel each on a collection of processors 
- all in the same name-space.

Most profitable if and only if data can be mapped in a way that data items 
are distributed to subsets of processors.  Even the simple proposal about 
processor subsets before lunch facilitates some of this.
---
Recall 
ON_HOME (PROCS(LO:HI)), RESIDENT BEGIN 
 ...
END ON
 ... this implies
Every read in   ...    reads a variable with a copy on PROCS(LO:HI)
and 
Every write in the block writes a variable with no copies outside of 
PROCS(LO:HI)
---
Two new Intrinsics are proposed:
ON_NUMBER_OF_PROCESSORS()
ON_PROCESSORS_SHAPE()
They will inquire about the state of processors in the inner-most enclosing 
ON HOME.

--------
Strongly Parallel Tasks ... 
Proposal that doesn't require any additional mechanisms:

ON HOME(PROCS(1:10)), RESIDENT, BEGIN
   CALL F(A)
ENDON

ON HOME (PROCS(11:20)), RESIDENT, BEGIN
   CALL G(B)
ENDON

Note these two ON blocks are disjoint ...
	no dependence
	no 1-sided communication needed
	other procs skip the ON
	barriers not needed (except for dependence from prior code, 
subsequent code.)

Technical detail - there may be some additional issues related to I/O, etc.  so 
there may be a needed assertion that says   do it in parallel     so that the 
compiler would know for sure that there were no side-effects.   Or maybe 
that some outer hull is needed to group some things together

----
When RESIDENT is not available (SMP?) still need a way to assert 
independence:
so might want something like
TASK
	on_home(P1) f(A)
	on_home(P2) g(B)
	on_home(P1)
END TASK

Asserts that there is no dependence between two ON's in the regions if their 
HOMES are disjoint.

Allows parallel execution by
	procs skip ON if not part of HOME
	Barrier at start of each

--- 
NEW used for strong task parallel code:

ON_HOME(A), RESIDENT f(A)

ON_HOME(B), NEW(I), RESIDENT
   DO I=1,N 
     ....
   END DO

END ON

Same assertion as INDEPENDENT
ALLOWS privatization
RESIDENT(I) implied.

Straw poll   8 - 2 - 8  ... about developing more proposal for the TASK/END 
TASK
Should there be some new intrinsics?  Straw poll: 11 - 2- 5

---
SUBROUTINE SUB(x)
REAL x(:)
!HPF$ environment :: ON_HOME()
!HPF$ distribute x(block)
             ONTO ....       should there be something to say on the current ON 
set?
!HPF$ processors procs

Should the rules be changed to be able to talk about processor arrangements 
that are size and # of ON_HOME processors.    Currently, we have no way to 
talk about the inherited set of procs.  There are some difficulties that arise 
from not knowing the rank? Should they work on this?     Strawpoll:    7 - 2 - 
9

======================

Rob presented a proposal for how the library changes with generalized 
distributions.

HPF_DISTRIBUTION (A, ... PLB, PUB, PSTRIDE)
!hpf$ distribute A onto PROCS(1:10,4:12:2)
PLB = (/1,4/)
PUB = (/10,12/)
PSTRIDE - (/1,2/)

HPF_DISTRIBUTION (A,AXIS_TYPE)

Real a(10,10,10,10,10); INTEGER SIZES(4),  map(10)
!HPF$ DISTRIBUTE A(cyclic, block,*, BLOCK,*,BLOCK(SIZES), 
INDIRECT(map))

AXIS_TYPE = (/'cyclic',"block","collapsed","gen_block","indirect"/)

MAP = MAP_ARRAY (A, DIM= 5)
SIZES  = BLOCK_SIZES (A,DIM=4)

REAL A(10,10,10,10)
PROCESSORS P(4,3,2,2)
INTEGER sizes(2), MAP(10)
SIZES = (/3,7/)
MAP = (/1,1,1,1,1,1,1,1,1,2/)
!hpf$ distribute A(BLOCK, CYCLIC(3), *, BLOCK(SIZES), INDIRECT(MAP))

!HPF$ [BLOCK_SIZES  or NUMBER_MAPPED] (A,DIM)

if DIM = 1, RESULTS = (/3,3,3,1/)
   DIM = 2, RESULT  = (/4,3,3,1/)
   DIM = 3, RESULT = (/3,7/)
   DIM = 4, RESULT = (/9,1/)

Votes on generalizing distribution:    14 - 0 - 4
New inquiry functions about sizes:    12 - 0 - 6

==============
The report from the vendor subgroup at this point was  - no report - a lot of 
disagreement.  Joel Williamson proposes  that we call HPF2000 a JOD and 
freeze 2.0 where it is now.  Ken rules this out of order - that a group has been 
chartered to address the issue of naming of the language.

Break for subgroup meetings until 7pm plenary session. 
 
7 pm evening session

The vendor subgroup returned with a report of things that all of the vendors 
could agree about.  The proposal is that the language features be in three 
sections.  Note the names BIG and SMALL are just place holders.

#1 HPF JOD
HPF 2000 and most of the  new features.

#2 HPF BIG: (HPF 2.0, full HPF)
HPF 1.2, plus  Intrinsic Reductions (commutative only), explicit interface 
requirements
minus pointers?, aggregate covers, REALIGN, REDISTRIBUTE, DYNAMIC - 
with
different mechanism to handle ALIGN, DISTRIBUTE.

HPF SMALL: (HPF 2.0 kernel)
Has HPF 2.0 as defined last meeting , minus pointers.

Suggestion
Mention HPF and HPF www site regularly in
   comp.lang.fortran, comp.parallel, comp.system

----
Ken:  The terminology JOD has a history of implying that features haven't 
been thought out.  Find some other name.  

Sentiment that the name should not imply that it is a "language".   Some 
suggestion that JOD should be called  something more like Provisionally 
approved features.

Question by Ken:  with this approach, why not just publish the HPF1.2 
document - drop the "JOD" features entirely, and say we are done.  
Discussion:  (this was not the vendor intent).

The features in "full HPF" are things that all the vendors except CRI are 
committed to implementation.

Do we treat this as a first proposal, and vote on it the next time.

Chuck: What does this say about the proposed document outline?  Could 
make the kernel an appendix - or - maybe it would replace the subset 
chapters.

straw poll - 13 - 2 - 1   as a first reading - develop a full proposal for next 
meeting.

Another possibility is something in the appendix - that has the features - and 
are call endorsed extensions.

Can talk about a document outline tomorrow morning.

=========
Barbara:
At HPCN Europe 96  (Brussels, April 15-19 1996 )  an HPFF workshop is 
scheduled.
April 19 is workshop day.

SPONSORS(LOCAL) : PPPE (Barbara Chapman)  Prepare (Henk Sips)
Program Chair: Alok Choudhary
format:  full-day workshop (6 hours)

Suggested title:
High Performance Fortran: Status and Development

Suggested topics:
Compiler(Tools?), User Experience, Motivation for language 
Extensions/overview

Program   draft

Morning: current status
Introduction & Overview 30 - 60 minutes: Ken
Compilers 90 minutes:  - Larry+?
User Experience  60 minutes - European speaker, good experience, frustrated 
user - doesn't look like good possibility for US user.

Afternoon: Language Development
   Motivation and User Requirements 60 minutes - European speaker
   Overview of Extensions 30 minutes
   Panel Discussion 90 minutes

Who  planning to go?   Ken, Alok, Larry, Chuck, (Harvey Richardson), 
Barbara, Henk.
Maybe Jaspal??? or Paul on motivating applications.

Further discussion offline.   

Ken suggests maybe a pared down version of Chuck's tutorial Thursday 
evening.  Henk will see if this is possibility.  Ken would give a pitch for this 
in his talk on Thursday.

=============
Henry Zongaro gave a report about the status of WG5 Interoperability with 
C.

HPFF example
Interface
   Extrinsic(c) function f(A,B,C,D) External_NAME("MyCFunction")
   Integer, MAP_TO (short, LAYOUT-C_ARRAY) :: A(100,100)
   REAL, MAP_TO (float) :: B(100)
   REAL, MAP_TO (double) ::C
   INTEGER, MAP_TO(int) :: D
end Function F
End Interface

WG5/interop example from a pending proposal

Interface
   Bind(Name="MyCFunction", LANG=C) FUNCTION F(A,B,C,D)
   USE ISO_C
   INTEGER (C_shrt_ki):: A(100,100)
   REAL (c_flt_kr):: B(100)
   REAL (C_dbl_kr)::C
   INTEGER (c_int_ki) :: D
END FUNCTION F
END INTERFACE

TYPE DT
  CSTRUCT
  INTEGER (C_shrt_ki) ::A
  REAL (C_flt_ki):: B(100,100)
ENDTYPE DT

1) Extrinsic mechanism is useful, should be used
 - explicit interfaces are not required for BIND, which seems like a bad idea.
2) Name binding
   should remain part of EXTRINSIC statement
   unfortunately, doesn't  immediately do COMMON
   means LANG - isn't needed

N.B. for both proposals, lower case letters are required for conformance.

3) extern is a problem for both proposals
   COMMON could be implemented on some platforms in a way that cannot 
map to extern
   might invent a different mechanism

4) Two mechanisms for type mapping
   KIND mechanism
   MAP_TO attribute

Weaknesses:
KIND	MAP_TO
- character	- new machinery
- array transposition	- doesn't handle structure
- can't handle types	
   that are not representable	
- new machinery for structures
 - pointers	- pointers
 - typedefs	- typedefs

difference - HPFF type doesn't require that the Fortran side have, for 
example, a
specific type that maps to SHORT, while the WG5 draft would require a 
specific type

Ken:  Suppose I'm a Fortran programmer who needs to call C.  With the 
KIND approach, I can take the new C kinds ... and use them through out the 
program ... or I can copy to a c-type when it is time to use them and then 
copy back ... this is not a user-friendly approach.  The MAP_TO approach 
does this automatically.

Should we work on a revised proposal to combine ideas at the March 
meeting.  Andy and Henry to prepare proposal.

-------------
Meeting:   March 13-15  May 1-3 are the current dates for meetings.
If we produce a document for comments in May.  Could process in Sept.

If everything is done in May we might have a June 15 document out to 
public on the net..  Deadline Friday Sept. 13 - meet  18-20 September.   
Public comment mid-June to mid September.   

The September meeting will be in the San Francisco area.   Rob will locate a 
place.

========================
Excerpt from Andy Meltzer's LPF report:   (We've done most of the work 
already)

LPF III...I
No LPF committee member need to return early due to bad weather - no one 
wants them ack - no one wants HPF members back either but they are 
pushier.

Any vendor who wants may claim full LPF compliance - We're still waiting.

LPF has demonstrated a successful implementation:
	The hotel elevator at the Windham Greenspoint

New Proposal first reading:
!LPF$ ADDRESS
   details will be filled in if it passes first reading

Note the meeting adjourned after a late evening meeting Thursday to all 
some east coast people to catch earlier flights home on Friday because of 
another pending heavy snow storm.

Small group discussions on Friday am talked about document outlines and 
updates.

========================================================
Draft Jan Attendance:    
Barbara Chapman	University of Vienna 	[email-masked]
Alok Choudhary	Syracuse U.		[email-masked]
Steve Fink	UCSD			[email-masked]
Ken Kennedy	Rice U./CRPC		[email-masked]
Charles Koelbel	Rice U.			[email-masked]
David Loveman	Digitali	[email-masked]
Larry Meadow	The Portland Group	[email-masked]
Andy Meltzer	Cray Research		[email-masked]
Carol Munroe	Thinking Machines	[email-masked]
Carl Offner	Digital		 [email-masked]
J. Ramanujam	Louisiana St. Univ.	[email-masked]
P. Sadayappan	Ohio State University	[email-masked]
Paul Havlak	U. of Maryland		[email-masked]
Rob Schreiber	HP			hplpp3.hpl.hp.com
Henk Sips	TNO/Delft U of Tech.	[email-masked]
Jaspal Subhlok	Carnegie Mellon		[email-masked]
Jerry Wagener	Oklahoma U.,X3J3	[email-masked]
Joel Williamson	HP/Convex		[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>
---------------------------------------------------------------------------