Subject: hpff: HPFF Minutes

From: owner-hpff
Date: Fri, 29 Dec 1995 18:04:55 -0600 (CST)

High Performance Fortran Forum Meeting
November 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
A major decision was made at this meeting to split the language document 
into two parts - the first,  substantially smaller that the existing HPF 1.1, 
called HPF 2.0;  and the remaining features of the language are contained in 
a larger section with a working designation of HPF2000. The primary 
distinction between subset HPF and HPF 2.0 is that HPF 2.0 contains all of 
Fortran 90 (95) {the subset does not}, and HPF 2.0  limits the kinds of 
distributions and alignments supported. More complex distributions, 
including CYCLIC (n) are part of HPF2000.  Also, HPF 2.0 does not have 
sequence/storage association which limits common block flexibility.  New 
language features accepted will become part of HPF2000, and the group may 
selectively chose to move the features to HPF 2.0.  

The group also 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:
     Indirect mapping of array elements (HPF 2000)
     C interoperability proposal 
     Explicit interfaces required in many cases (HPF 2.0)
     Generalized Transpose (extension of Fortran transpose routine) (HPF 2.0)
     Specification of shadow widths (HPF 2000)
     Derived type component mapping (HPF 2000)
     Simple reduction directive in loops (HPF 2.0)
     ASYNC I/O (HPF2000)
Proposals still in progress of second reading:
     Mapping to subsets of processors
Proposals in the process of first reading: 
     Task regions.
Proposals discussed in a preliminary review:
   External bindings such as MPI integration with HPF.

Another item of special note:  there was a change of voting rules requiring 
2/3 majority of all votes  (with abstain counting as no) to pass major issues 
and all second readings. 

The next HPFF meeting is schedule for Houston January 9-12. It will replace 
the annual HPF conference this year - and the longer time will allow more 
time for review of issues that require special discussion, as well as document 
reorganization.  

End of Executive Summary
(apology for delay in minutes - the last 6 weeks haven't existed)
____________________________

Detailed Record of Action
Nov 1:  Subgroup meetings chaired by Rob Schreiber, David Loveman, and 
Guy Steele were held from 1:30 through the evening.
Nov 2:
Ken Kennedy called the meeting to order at 8:40.  Introductions and the 
initial count of installations were made.  26 people from 23 (22 voting) 
institutions were present.

===================
In the review of the vendor list, 

Announced Products
Applied Parallel Research, Digital, Hitachi, Intel,  Meiko, Motorola, NA 
Software, NEC, Pacific Sierra Research, The Portland Group, Inc. (PGI), 
SofTech 

Announced Efforts
ACE,  Fujitsu, IBM , Lahey, MasPar, NAG, nCube, Thinking Machines 

Interested
  Cray Research ,  EPC,  Convex, HP, Silicon Graphics,  Sun

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

First topic was a presentation by David Loveman addressing the definition 
of  success or failure  for HPF.  Following are excerpts from his talk.  

This question can be addressed from several perspectives:  user (application 
ISV, role-your-own end users), vendors (system,, performance, desktop), and 
researchers.  The requirements for success are different.

Some requirements for HPF success: are vendor independence and 
acceptance providing application portability across vendor's platforms; 
performance of application; ease of use by application developers; 
standardization and stability; sizzle.

What is the order of importance of these requirements?  ISV order (1 2 3 4 5); 
End user order (3 2 1 4 5), Vendor order (1 2 3 4 5).

So what language for technical applications development?   Fortran?  
designed for technical computing, standard, widely available, efficient 
implementations, well understood, low level, dull.  Fortran 90?  designed for 
technical computing, standard becoming available, implementations 
becoming efficient, not understood, high level, dull (perceptions).  HPF?  
designed for technical computing, evolving, not available, not (yet) efficient 
implementations, not understood, low level.  C++  designed to support 
abstraction, standard (??), widely available, not (yet) efficient 
implementation, not easy to understand, sexy. Something else? Ada? Don't 
laugh.  Ada is standard available, efficient, supports abstraction, explicit 
tasking, etc. etc.

Is Fortran the RrightS language?  If we really believe that Fortran is the 
RrightS language for technical computing, we need to sell it.  We need to stop 
saying:
Ryou can't solve problem X without new feature YS and RWithout feature Y 
users won't use HPFS and concentrate on what can be done with HPF as it is 
now.  How is problem X being solved right now? Neither Fortran, nor C nor 
C++ has feature Y now and problem X can always be solved in HPF as it 
currently is in Fortran, C or C++, plus HPF has modules, private data, 
explicit interfaces.  The problem is not missing language features in HPF.

There is a lack of F90 experience - its benefits need to be sold.  C is better 
than Fortran, if you mean standard Fortran 77.   Fortran 90 is better than C or 
C++ unless you need C++ inheritance (which causes all the problems ...).

David asserted the HPF process is broken.  HPF 1.0 was based on consensus 
and agreement on what we agreed on, rather than simple majority.  The 
typical vote was often something like 24-1-2  The HPF 2.0 is assumption 
seems to be "let's add this neat feature" without clear majority.  (There was 
some question if actual votes taken bear this out.)  We need to  spend much 
less effort on new language features, spend much more effort on sales and 
marketing, promotion and teaching ( in a successful product, less than 20% 
of the investment is in engineering), avoid over promising, and be proud of 
what HPF can do, rather than stressing what it can't do.

HPF must be the consensus intersection of HPF features that can be readily 
implemented, i.e. the HPF kernel. Other features must be HPF extended for 
features not formally in HPF but for which there is agreement on syntax, or 
HPF Journal of Development  for proposals not yet accepted but worth 
preserving.

There must be an effort toward illustrative examples of how to use HPF well.
------------

At this point there was a discussion about the name of the language and
the implications for document organization.

A variety of opinions were expressed:  there are parts of HPF1.1 that we 
shouldn't deal with;  what problem do we solve when features won't be 
implemented for years? one reason for definition now is so that eventual 
implementations will spell things the same way; it's important for marketing 
that "full" HPF be something small that vendors cat get out now; but we 
need the future language definition in place; architectures are changing 
faster than languages - features we discuss might not be needed in 2000.

Guy Steele provided a procedural suggestion - that in ANSI work, 
substantive changes require 2/3 votes and abstains are not allowed.  This 
was made into a formal proposal for a change of our rules:  all 2nd reading 
institutional votes require 2/3's with no abstains.  Since this was a rule 
change vote it also required a 2/3 vote.  A friendly amendment was made 
that abstains would be allowed, for recording purposes, but they would 
count a s a "no" vote.  This proposal passed.
 21-1- 0.

So HPFF has new voting rules.

Now on to discuss the language split.  Jerry Wagoner point out that X3J3  
started out with  the idea of core + satellites, but the idea didn't fly (for a 
variety of reasons). 

Ken: we should take our previous document vote as a 1st reading. 

Proposal:
"HPF 2.0" is "a kernel" and some-other-name is the full thing.

There was a discussion of where the voting was required - to take things out 
of the language? to put things in? to put in full language - and then to move 
to kernel?  Ken proposed that we start with an empty kernel and move 
things in.

VOTE:  (yes= split the language with base part that is HPF2)   At the end of 
this vote - HPF2 will be defined to be an empty language  (runs very fast 
everywhere) :-)
20 - 2 - 0   (with some pain)

Guy proposed that we move all of 1.1 into HPF 2.0 (with the understanding 
that we move things out later).    Is it harder to get things in or to get 
things out?
This failed:  6 - 16    So we start with empty language for HPF2.

======
At this time there was a break - followed by an intentional switch to 
technical issues.
Guy Steele presented some Group D items:

CCI 11: In September the subgroup said pointers cannot point to sequential, 
but the full group vote said try again.      So the new recommendation is:

  (a) Pointers with the HPF SEQUENCE attribute may point only to targets 
with the SEQUENCE 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

-----
Indirect mapping of array elements second reading:

The proposal:
Add to H309
dist-format is ...
                     or INDIRECT (int-array)
The int-array must be of rank 1 and its extent must equal the extent of array 
or template dimension being distributed.

If int-array is an array variable, changing its value later does NOT change 
the mapping.

Elements must be valid indexes of the processors arrangement.
In last line of example, change DISTRIBUTE => REDISTRIBUTE

*Does it mean an ONTO clause MUST appear?
*Need change to inquiry intrinsic?

For the future, subcommittee must address whether feature is into HPF2000 
and second vote on into the kernel.

Subcommittee vote was 3 - 0 - 2
Vote on into large language ... HPF2000 ... 17 - 3 - 2  (passes)

Separate vote ... Is the ONTO required ....
If there is no ONTO  clause ... then it is impossible for the user to know that 
the values in the int array are legal.       20 - 0  - 2.

-----
Mapping to subsets of processors: (Second Reading)

dist-target is processor-name [(processors-subscript-list)]
    or * processor-name [(processors-subscript-list)]
    or  *
    or subproc-name ?
processors-subscript is subscript
              or subscript-triplet
     [must be specification-exprs]

subgroup - directive is
   SUBGROUP SUBPROC-NAME
        [(EXPLICIT-SHAPE-SPEC-LIST)]
    OF PROC-NAME (PROCESSOR-SUBSCRIPT-LIST)

{eliminate from the bottom of the written things

First some examples were given of the various options:

Part 1:  Simple subgroups   (1-1-3)
!HPF$ Processors P(10)
!HPF$ DISTRIBUTE A(BLOCK) ONTO P(2:5)
!HPF$ SUBGROUP Q (4)  of P (2:5)
!HPF$ DISTRIBUTE  B(CYCLIC) ONTO Q

Question about whether the (4) is required? In simple case not needed, but is 
needed for the reshaping?

Part 2:  Reshaping  0 - 2 - 3
!HPF$ PROCS P(10,10)
!HPF$ SUBGROUP Q(50) of P(6:10,1:10)
! HPF$ SUBGROUP R(5,10) OF  P(1:5, 1:10)
! HPF$  SUBGROUP S(3,4,5) OF P(3:8m1:10)

Are Processors are default base 1? {no}.

There were some technical difficulties  with the written proposal: needed to 
be able to use subscript OR subscript triplet list. Delete the rule processor-
name is proc-name or subproc-name - this gets rid of allowing sub-groups of 
subgroups.

Amendment: A subgroup may not have size zero.

Part 1 Down to (excluding) the last paragraph on the written page.  

Can the onto be a subset of procs?
Can there be a name for such a subset?
Can we reshape subsets?

The recommendation was to revert to straw polls and table until next 
meeting

onto subsets .... straw poll - 20 - 1 - 5
onto named subsets .... straw poll  - 14 - 5 - 7
reshaping .... straw poll - 9 - 11 - 6

----------------
BREAK FOR LUNCH AT 12:15

HPF Kernel:  Andy reviewed areas in the kernel where full committee 
guidance was required before the final presentation could be made.

First a question about when variables are identically mapped:
	When they share identical alignment, distribution, and processors 
directives (e.g. mapping only syntactic; refers to directives)
	Whole objects may be identically mapped, but it is possible for two 
objects to be identically mapped, even though not all directives are specified.  
(e.g. identical mapping is synonymous with having identical memory 
layout)
	Subobjects (for example rows of an array) may be claimed to have 
identical mappings.

And then a question of how restrictive the processors directive should be:
Processors directive (7-0-1) 
	- The product of the extents must exactly match the number of 
processors in the partition or must be a scalar.
	-only one processor arrangement declared for each rank
	-If an onto clause is not specified, a default arrangement is 
provided which is identical for distributees that have identical shape and 
identical dist-formats

Item 3 above applies to HPF2000 as well as HPF kernel.
Institutional vote for HPF 20000    20-2-0  (item 3 above)

Straw poll for item 1 in the kernel proposal ... 24-0-1
Straw poll for item 2 in the kernel proposal ... 1 - 15 - 9

Pointers in the kernel:
(5-0-2)  A pointer may only point to identically mapped objects.
(1-1-5) The object a pointer points to may be mapped, but the pointer may 
only point to a whole array or scalar object.

Should we restrict the mapping of pointees?  13 - 1 - 9

Wording to be determined.

Chuck noted that -much of the kernel write-up  is Rthese features deleted 
from HPF 2000.  This is going to be a challenge for documentation.

=========
Andy presented the Interoperability proposal (2nd reading) with 2 issues for 
discussion - from the written proposal.

Controversy over which is a better way to indicate that the RC-styleS address 
of a variable should be taken. Possible intrinsics are loc, or address_of,   or 
symbol:  @, *  The recommendation is to  (let X3J3 pick one for us).  A 
strawpoll of the group about the address-of function was taken:
loc - 4  ... address_of ... 2    @ - 13   * - 1

Another change proposed from the original: The NAME clause of the 
extrinsic some felt was a poor choice of keyword. Alternatives with 
subcommittee preference:
	CASE
	EXTERNAL_NAME  (5-0-2)
	NAME

There are two unresolved issues that the proposal doesn't address:
	Allowing user to provide a map function to convert user types and 
	Requiring conversion intrinsic functions to convert data

There is a ISO / IEC Technical Report available via:
   http://www.uni-karlsruhe.de/~SC22WG5/

Institutional vote  on Interoperability proposal for HPF2000: 20-2 - 0

=============
Next was a second reading about explicit interface requirements - tabled at 
the last meeting.

Rewrite 3.10 to include
Required except when
1. Fortran 90 does not require one
AND 
2. No dummy arg is passed transcriptively or with the inherit attribute
AND 
3. Either of the following cases applies so each pair of corresponding actual 
and dummy arguments:
	(a) they are both implicitly mapped
	(b) they are both explicitly mapped and the mapping are the same.

The intent is Rthe sameS means the old definition of when we can call the 
subroutine descriptively  (assert it is coming in here).

4.  Either of the following cases applies so each pair of corresponding actual 
and dummy arguments:
	both are sequential
	both are nonsequential.

This proposal also eliminates the distinction between prescriptive and 
descriptive.   

Institutional vote about when explicit interfaces are required: passed - 17 - 2 - 
3

This was followed by a discussion of pros and cons of eliminating the 
distinction between prescriptive and descriptive arguments.  The argument 
in favor is that it simplifies examples, syntax, understanding, etc.  One 
argument against is that there still may be meaning - in that the user is 
asserting that "I believe you don't have to change this", so a warning message 
about redistributions might be appropriate in the case where the user uses 
the descriptive form and data motion is required.

Rewrite section 3.10 to eliminate descriptive directive syntax , and in 
addition make the  appropriate changes to proceedings sections (examples 
etc.) :  institutional vote( 11 - 3 - 8).  The distinction will remain.

=========
Rob presented a second reading of generalized transpose
Extend Transpose (array,order)
	optional order
	integer order(rank(a))
	array- any type, shape, rank > 0

If order isn't specified, it is as if order - (/n,n-1..., 1/)

Result:
Element j1, j2, ... jn of the result is element ARRAY [j(order(1)), j(order(2)), ..., 
j(order(n)))

(Let's license this to X3J3 ... exchange for frame-maker licenses)

Institutional vote. 18 - 0 - 1  This was treated as a second reading.

========

Carl Offner presented Shadow Widths Proposal:

The problem motivating this is that arrays with shadows  that are generated 
implicitly by the compiler are costly to move across subroutine boundaries. 
The concept of shadow widths is familiar to users - and they can help choose 
reasonable defaults, as well as give input about what is coming across 
boundaries.

Proposal
Replace H209  (page 26) with
dist-format   is BLOCK [(int-expr [, shadow-spec-or-int-expr])]
        or BLOCK (shadow-spec)
        or CYCLIC {(int-expr[,shadow-spec-or-int-expr])]
        or *
shadow-spec-or-int-expr   is shadow-spec
        or int-expr

shadow- spec  is SHADOW - int-expr
       or LOW_SHADOW - int-expr [,HIGH_SHADOW = int-expr]
       or  HIGH_SHADOW - int-expr [,LOW_SHADOW - int-expr]

Note - shadow=0 might be useful , e.g. for external interfaces.
useful for external interfaces.  Some possible syntax simplifications were 
proposed.

Institutional vote :   (syntax open)    18 - 2 - 2

=============
ASYNC I/O Proposal - Larry Meadows:
Example
	READ (10, ID=I, REC=10) A
	READ (10, ID=J, REC=11) B
	...
	WAIT (ID=I); WAIT (OD=J)
Syntax:
	New I/O Specifier:
	ID - scalar - int-var
	
New Statement:
	WAIT ([UNIT=n] [, ID=n] [,ERR=LABEL]
       [, IOSTAT=ivar] [, DONE=lvar])

Between READ/WRITE and WAIT
	No redistribution, undefinition, change in mapping or pointer 
association for any I/O variable.
	For READ, no access to any I/O variable.
	No other I/O operations on same unit.
	No WRITE to same record.
	All READs or all WRITES.

READ/WRITE
	Preserves sequential semantics
	No function call in I/O list!
		read (99, ID=J, rec=s) I, A(F(I))
		When is F(I) evaluated?

Problem with doing it --- this will require several changes to the F95 chapter.  
Explicit text will be presented Friday.

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

Second reading of proposal for Derived type component mapping  
(subgroup vote 3-0-2).

distributee is object-name
   or template-name
   or structure-component

alignee is object-name
   or  structure-component

1) Allow ALIGN, DISTRIBUTE, DYNAMIC within a derived-type-def to 
specify attributes of its components.
2) may map a component or variable only if  it is pointer or its type is not a 
derived type having a mapped subcomponent.
2. Alignee or distributee may be a structure-component in REALIGN or 
REDISTRIBUTE only.

in the subgroup ... this was amended:

- An alignee or distributee that is a structure-component must have every 
part-ref, excepting possibly the rightmost, be scalar(rank zero).
- A component in a derived type may be explicitly mapped only if the 
derived type is not a SEQUENCE derived type.

partial example from handout

DO I=1,n
      ALLOCATE (grid(i)%bl(grid(i)size))
!HPF$ REDISTRIBUTE grid(I)bl(BLOCK) ONTO P(grid(i)%lo: grid(i)%hi) 
end DO

In the printed copy of the proposal, the first Definition paragraph should 
read:
Definition: A derived type is said to be an "explicitly mapped type" if any of 
its non-pointer components is explicitly mapped or if any of its non-pointer 
components is of an explicitly mapped type.

Institutional  vote: passes -   16 - 3- 3.

===========
Second reading on proposal for reductions:

!hpf$ independent
  do i - 1,n
   !HPF$ REDUCE
    x = x+expr
enddo
Some points to consider are:
1. No reduction clause
2. Reduce directive might be optional when reduction var is a whole array 
name,scalar name.
3. Forms of reduction statement:
   x = x op expr
   x =  expr op x
   x = fn (x, expr)
   x = fn (expr, x)
4. Combine fn is "same" (has same name as) reduction function.
5. Pure functions and operators only
6. Associatively is required of user reduction functions.
7. Only intrinsic assignment in reduction statements.
8. Operators may not be mixed.
9. If operator is - then it's treated as +  A-B => A+(-B)
   If user defined, then unary - must also be defined.   May also mix intrinsic * 
and /.

Commutative attribute:
!HPF$ commutative reduction-name !HPF$ NONCOMMUTATIVE RN-
NAME   ! THIS IS DEFAULT CASE
Reduction will work better for commutative operations.

User defined functions were also discussed, but not considered for the vote.

Motion is to accept the intrinsic reduction.
Amendment: - #2  REDUCE is optional.    7 - 11 - 4  So REDUCE is required.

#9 ... can intrinsic plus and minus  (and */) be used together as exception to 
no mixed reductions. 18 - 0 - 4.

Institutional vote as amended with #9:
simple proposal (no functions)  19 - 1 - 2

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

Ian Foster presented an overview of the issue of an MPI binding for HPF.

There are two different approaches  when HPF is mixed with message 
passing.
(1) SPMD calls HPF  (complement of extrinsic)
(2) coordination libraries - based on extrinsic  HPF communicating with 
other HPF

For an HPF binding with MPI - the primary issue is definition of the Fortran 
90 binding for MPI.  Examples were given where the code is a simple 
message passing source when HPF directives are ignored.

The problematic F90 issues are  array subsections, derived types, and 
sequence association - MPI assumes mostly linear memory model.

In addition to F90 binding there are many implementation issues to consider 
such as   gather to thread 0, sends to thread 0 of second HPF program,  
scatter;  or parallel exchange , etc.

Summary
HPF binding for MPI is important - provides rapid access to new 
applications
It is primarily an MPI problem but MPIF might not address it.  There may be 
minor HPF issues such as startup, extrinsic/local library.  It may also 
motivate MPI extensions such as full channels.

Strawpoll about importance of a F90 binding for MPI ... 24 - 0  2
=========
Scott Baden spent a few minutes on  2 cases for SPMD to HPF interfaces.
In the simple case there is a single HPF program.  There is requirement 
initialize HPF - invocations are procedures ... there is no HPF main.

Life gets interesting with multiple HPF invocations.
Each invocation on a single node  spmd calls local hpf program and do
coordination.  Motivating application - multi-block code each block 
identified with a single node - each node maybe an smp (or not).  HPF 
execution appears serial from SPMD layer.  Data motion between blocks 
handled at SPMD layer.

Requirements are  ability to return mapped hpf allocatable back to extrinsic 
spmd; query functions lb etc access to blocks of data; and  mapped array 
section copy.

Break at 6PM
=========
Friday 8:15
Andy  - Kernel Proposal - to put initial values into HPF 2.0

Summary of differences from HPF v 1.1.
BLOCK(N) and CYCLIC(N)   distribution formats are removed.
DYNAMIC , REDISTRIBUTE, REALIGN, not in kernel.
Processors:
   The product of extents must exactly match the number of processors or 
must be scalar.
   If an ONTO clause is not specified, a default arrangement is provided 
which is identical for distributees that have identical shapes and dist-
formats.
ALIGN
   Alignment must be direct, no offsets or strides
   Dimensions may not be permuted
INHERIT:  Not part of kernel HPF 
POINTERS: Pointers may point only to identically explicitly mapped 
objects.	
SUBROUTINE Interfaces
	Carl's explicit interface proposal
	Dummy args may not be mapped distribute * onto *
	Assumed size arrays are not allowed
REDUCE: (add the intrinsic reduction proposal that passed yesterday)
No sequence and storage association in HPF 2.0

HPF2.0 Proposal
   let's put a stake in the ground and make progress
   we can see future proposals to amend this but with this could take forever
   we will need amendments for ON and maybe REDUCE anyway.
   If you think for functionality needs to be added, vote for this then propose 
the new features

Guy Steele raised a parliamentary point of order:  amendment s can be 
passed by simple majority.  Later changes will require 2/3 vote.

MZ - add cyclic(n) - 2-15-2
RS - add  transcriptively passed dummy say INHERIT (needed for libraries)
Long discussion pro and con about goals of HPF 2.0 ... Ken, rather than max 
performance  as the highest priority,   we want to design for maximum  
acceptance.  Institutional vote   11-6-2   passes by simple majority.

Straw vote to include REDUCE   10 - 5 - 6
DL: remove the REDUCE directive -   formal vote:  6 - 11 - 2 - failed.
Move to add generalized transpose: 11 - 3 - 5

VOTE on full proposal: 16 - 3 - 0   (all NO votes were vendors)

Extended discussion about the what the expectations are for HPF 2.0  - vs the 
other features that are HPF 2000.   

Group E --- committee will process changes to HPF 2.0. Work on all first 
readings for that at the January meeting in Houston.

========
There was discussion of a European Meeting.  Based on current changes, the 
best thing is to have a 1-day workshop in conjunction with HPCN with 
presentations from the members of the group.  Alok will be program chair.  
Chuck will get a list of people.    Ken will write a letter - for a 1-day 
workshop  at the HPCN - presentation from the members of the group.

Summary of meetings coming up is:

SC95 - document meeting and BOF.
Jan 9-11 - Houston
March 13-15 - Arlington
European Meeting - one day HPCN Brussels 19 April
May 1-3 - Arlington

Straw poll favored staying in this hotel for March and May rather than 
Denver.

===============
There was a spirited vote for name of the extended feature HPF language 
among candidates: HPF2000, HPF Extended, HPF 99, HPF 9x, HPF Pro, HPF 
2.x.  After some elimination. HPF2000 11 and HPF 9x tied at 11 - 11. And 
finally there was vote switch to make the official name HPF2000.
================
BREAK ....

BOF Plan
Ken: Refinement of Direction   HPF 2.0/2000  and what is it.
Implementations, booth pointers, platforms.

Rob will summarize the new features.
Ian will present HPF/MPI binding issues.
We will try for user reports from
John Prentice (Chuck contact) and someone from Ames (Rob will get name).

An announcement is needed.

=======
In a review of proposal status:
		1st	2nd
group E                                
    	kernel	done	
	interop	done	
	format	Jan	Mar	
	explicit interf	done	
	SPMD-HPF	Jan	Mar	
	local_global func	Jan	Mar	

group D                              

	irreg map	done	
	dist exten	dead
	dist ranges	Jan	Mar
	seq. nonmap	Jan	Mar	
	subsets		Jan	
	derived type	done	
	shadow width	done	
	OOC	Jan	Mar	

group C                          
	async	done	
	on	Jan	Mar	
	reduct	Jan	Mar	
	task	Jan	Mar	
	gen transpose	done	

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

The LPF Report: Andy Meltzer

LPF 2.0
LPF is very jealous
It didn't think of deleting every single feature from the language
It didn't think of carefully defining a complex syntax, explaining it in a 
lengthy discourse then finally telling users that it is meaningless and useless.

No marketing organization in history has come up with as clever a way to 
position a product in the future as making its new product number 1000 
times as big as the current product (2 vs 2000).

BUT LPF does have a better relationship with its users --- there are none 
(none left alive anyway).
The rational for adding a feature is not if a single user may want it like HPF, 
but only if no user would every want it.

Yet more - LPF has never been so successful making it its committee 
unhappy.

LPF2  
New Directives
- !LPF$ REDUCE
	This is directed at the overweight user.
	He or she must then restrict his or her code to the kernel's original 
recipe.

- !LPF TRIBUTE
	This directive can only be used on the DISARRAY construct.
	Operations on a TRIBUTEed dissarry will always produce 
unknown, messy, and probably late results.
	An individual element of a DISARRAY is often called a MESS
	One can have a MESS without a DISARRAY if it is replicated it can 
only be accessed by the ?? PW, referred to as the SLOB
- A user may DISINHERIT a SLOB
LPF2 has found HPF2's naming conventions very appealing.
	LPF2.0 contains the entirety of all programming languages every 
defined.
	more will be added as needed
LPF20000000 (obviously better than a mere 2000)
	everything not in LPF2.0
	the kitchen sink

In LPF2 all proposal reading are final, official readings until just before the 
vote, at which point they must be withdrawn.

Next LPF Meeting
January 12-15 , 1992
======================
This was followed by a virtual LPF Bachelor's party presented by Guy Steele 
in honor of Andy's pending marriage shortly after the meeting.

True to the LPF tradition, instead of actually implementing  a party, we're 
just going to show you a list of party features.
   There was a long detailed vote, skillfully directed by Ken to determine the 
list of names to consider for the occasion, and we finally decided on a Multi-
Block Parti.
   After looking at the program, we optimized a schedule ....  
DO:
-Start with black and white home movies of old Fortran 2.0 programs.
-{Fill-in-your-favorite-risqu-group-activity} involving all  of the LPF users.
-A basket ball game with YMSSA (young men's sequence-and-storage 
association).
-A rehash of favorite times from the carefree days of HPF 1.0 such as 
recollections of discussions between Shapiro and Swift preceding votes of 2-
2-32.
-A subset to go bowling (that's irrelevant, but LPF is too).
-A raffle for a trip to the Bristol Suites with dinner out at the Chinese Buffet.
-And good conversation ... such as advice (which can be ignored) about 
relative performance of inter-operability interfaces: receptive, deceptive, and 
contraceptive.
 -We rejected a CRAFT fair because we thought it would take too long.
- Actually every activity was projected to take 10 times longer than expected, 
so we thought about trying them in parallel, but couldn't because they 
weren't all PURE.

Mellifluous Parti music was provided by a (guy) steel band with 
performance of selections from  a hit LPF  record, including:
	music from the Pointer sisters and Johnnie Cache.
	Here we go Loop-de-lou
	Forall (we ) know;
	If (I_were_a_rich_man) do do do do do do do ...
	One is the loneliest number
	Sweet little 2**4  
	... and    I am 2**4, you are 2**4 + 2**0
	IF ( I_were_a_programmer .AND. 	
		U_were_a_lady)
This was interrupted by a dummy syntactic argument about  relative merits 
of
	Would you marry me ,  anyway ?   Would you have my baby?
vs	Would you marry me ? Anyway ,   would you have my baby?
And (not) terminating with a hallelujah chorus of   FOR (ever .and. ever) ... 

Every good Parti has lots of food and drink ...

	We start with 2**7 bottles of beer on the wall   and card punch (which 
can't be spiked because we are not allowed to fold, spindle or mutilate).
	As appetizers:   bytes will be distributed on temPlates for digital food 
(no forks allowed).
	First course: catchup with turtle soup and molasses.
	MAIN course:   CALL  take_out_from_the_kernel  
	Dessert:  4 * atan (1.0)  with Java and Tea for 2.

SO ANDY:

    After you do double precision, 
life gets more complex, 
but you're a magnetic character 
and memories are made of this.

FORALL (TIME = NOW:ETERNITY)
	WHERE (EVER_YOU_GO)
		OUR_SALUTE(TIME) =
			BEST_WISHES(TIME)
	END WHERE
END FORALL

Best wishes from HPFF!  

=============
And back to business in the remaining time:

Larry Meadows presented proposal for  ASYNC I/O
	specific list for how the document would be modified ...

Changes are that WAIT should always have an ID
Example
	READ(10,ID=I, REC-10) A
	READ(10,ID-J, REC=11) B
 	....

	WAIT(ID=n [ERR=LABEL] [,IOSTAT=ivar] [,DONE=lvar])

Syntax - see written proposal,
Institutional vote for HPF2000    16 - 0 - 2

-----
Jaspal Subhlok started the first reading of the task region proposal.  The 
following text is incomplete.  
Assume there is a way to divide processors into subgroups - such as the 
processor  subgroup naming proposals that have been discussed earlier.
A task region is a section of code with an ON clause used to direct execution  
on processor subgroups.  

Specific rules are needed if it is ok that only P1 processors execute on P1 
region.

Following Restrictions:
(1) no restrictions on accessing Rread onlyS variables in the region.

(2) For a variable mapped to P1 only ON regions including P1 can access it.

(3) For "unrestricted" variables, all ON regions that access it must have at 
least one common subgroup.

All processors involved in an ON section have a barrier at the beginning of 
the section.

TASK REGION 
ON P1 ... ENDON
ON P1, P2 ... ENDON
... implicitly on P1, P2, P3 ....
ON P2 ... ENDON
END REGION

TASK REGION 
DO i=1,n
ON P1 ... ENDON
ON P1,P2 ... ENDON   on everything if  there are only P1, P2
ON P2 ... ENDON
end do
end region

Need to work on what happens if the do and task region are reversed. to get 
the barriers worked out.

Issue #1 - Should we support ON (p1,p2) or only ON P1 ... 
On P1, P2 is typically used to transmit data between P1 and P2.  If that is 
almost always the case, simpler model is sufficient.

Issue #2 subroutine CALL
A subroutine call is an ON P1 region - uses only this subgroup of processors 
This needs to spelled out in conjunction with the ON proposal.

Issue 3 Nesting Task Regions
Dynamic nesting / subdivision can be done through subroutine calls.
Straw poll ....  7 - 2 - 9  general direction
ON P1, P2 in addition to P1 .... 6 - 2 - 10

This concluded  what we had time for.

Meeting adjourned ~12:00 Friday.
---------------------------------------
Attending the Nov. 95 HPFF Meeting:    
Robert Babb		U. of Denver		[email-masked]
Scott Baden		UCSD			[email-masked]
Bob Boland		LANL			[email-masked]
Barbara Chapman		University of Vienna
	[email-masked]
Alok Choudhary		Syracuse U.		[email-masked]
James Cowie		Cooperating Systems	[email-masked]
Ian Foster		ANL			[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]
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]
Joel Saltz		U. of Maryland		[email-masked]
Rob Schreiber		RIACS			[email-masked]
Yosiki Seo		NEC	
Guy Steele		Sun Microsystems	[email-masked]
Jaspal Subhlok		Carnegie Mellon		[email-masked]
Jerry Wagener		Oklahoma U.,X3J3	[email-masked]
Joel Williamson		HP/Convex	 	[email-masked]
Hon W  Yau		NPAC Syracuse		[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>
---------------------------------------------------------------------------