Subject: hpff: HPFF minutes - July 96

From: owner-hpff
Date: Wed, 24 Jul 1996 18:40:08 -0500 (CDT)

---------------------------------------------------------------------------
[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
July 10-12,  Burlingame, CA
Record of Action:  Mary Zosel

Executive Summary
There were 17 people from 15 institutions present at the July 96 HPFF 
meeting..

The group processed the second reading of a number of language 
proposalas listed below and also worked on document organization 
and writing.

Proposals passing second reading:
Inquiry Routines.
Interprocedural ON
Base language is Fortran.
Additional Pointer clarifications.
Reorg. of extrinsic interface. to incorporate the C interop and F77 
   interfaces.
Limit inherit.

The primary order of business now is producing a document for
public review.  The public review period has been postponed until 
after the September meeting  (September 18-20San Francisco area).  
The review will take place during October and November, with a 
newly scheduled meeting - at Rice in Houston, tentatively December 
9-11 to process public comment and finalize the document text.

End of Executive Summary
____________________________

Detailed Record of Action

Plenary session Wednesday
The meeting began at 10:30 with Mary Zosel as temporary chair due 
to delay in the arrival of Ken Kennedy.

The group reviewed the first/second reading proposal status.
		1st	2nd
group E                                
	SPMD-Craft-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.	July

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

This was followed by a review of the status of the document chapters:
--------
chapter status
title - needs to inc version number
credits - needs HPFF 95 participants
overview - sad shape
	need area/chapter editor to go through & check outline
	Saday commented that it isnUt not useful for user, need 
              less on 
	history and hpf vs f90 vs hpf 2.0.  Plant model of "what 
is data parallelism" - very short description.  Some 
work is needed on the
	directives syntax.  And in general the chapter needs a 
rewrite. 
	Saday agreed to take on the task of proposing a 
reorganization of
	the material.
mapping chapters - good shape, thanks to Piyush Mehrotra and 
	Carl Offner.  All the content is there, possibly details need
	discussion.  Guy Robinson has volunteered for a lot of reading.
	These chapters are at the "proofreading stage" ... the dark corners 
	of pointers are still with us.
independent & reduce -
	Rob Schreiber will work on  revisions. The content seems
	to be there. The syntax needs to be unified.
hpf library - very good shape
	Carol has suggestions, new cci item
	should grade_up, grade_down return 1-based or array-
 	based numbers?  Also, we should remove maxloc & minloc, 
	since our
	HPF extension is now part of standard Fortran.  The 
	features with
	dynamic need to be moved to approved extensions.
extrinsics - old text, but no HPF 2.0 changes
	needs review for updates
on, resident, tasking -
	lots to do
		needs interprocedural ON, more tasking
new library - OK now, minor updates (see above)
hpf_local - recheck, needs update (hpf_local calling hpf_local)
hpf_serial - in proofreading stage
f77-local - we note that Fortran_local disappeared and was
		replaced with F77_local in document draft.  Fix this. 
	Really
	the F77_local (which needs second reading) may belong 
	in annex.
c interoperability -
	shouldn't this be called extrinsic(c)?
	needs compiler functionality to work - but so do other 
	extrinsics.
	Henry Zongaro is coming with revised proposal.
bnf - needs to regenerate, need to resection
extrinsic extrinsics -
		Needs new craft section and better chapter sections.
subset - 
		make sure there are no references to "subset" in rest of 
	text.
	"this is an appendix in the true sense of the word - a 
	vestigial 
	organ" with no current function.

-------
Following this, the group discussed conventions for syntax in the new 
document.  The split format presents the challenge of syntax rules that 
change with the different extended features.

First for extended features - add "extended-x" options with  a 
statement at the beginning of extended section, overview that 
"extended-x replaces all occurances of x".  Add "extended-declarative-
directives" etc. 
------

Finally, we reviewed ownership of chapters to make sure that there 
was someone present at the meeting associated with each chapter.

assignments - ownership of chapters
	ch 1 - saday
	ch 2 - pm
	ch 3 - offner
	ch 4 - schreiber
	ch 5 - schreiber
	ch 6 - offner
	ch 7 - meltzer
	ch 8 - pm
	ch 9 - pm
	ch 10 - chk
	ch 11 - lfm
	ch 12 - offner
	ch 13 - offner
	ch 14 - munroe
	ch 15 - pm
	app a - offline
	app b - zosel, meltzer
	app c - zosel
===========================================

After a break for lunch there were subgroup meetings for the 
afternoon.

The  HPFF Meeting reconvened Thursday AM, chaired by Ken 
Kennedy of Rice University.

In the traditional review of the vendor  slide, the decision was to 
move Lahey to interested and remove Ncube from the list altogether.

There was a review of subgroup status:  Group C reported that the 
CCIUs are finished, that gradeup/down and the processor lb/ub 
should all be 1-based - Also that the active number of processors and 
shape should be intrinsics;  There is still a second reading of 
interprocedural ON;  Group D reported that one or two of the CCIUs 
may need some text;  There are new D proposals that are ready;  
Group E reported a new proposal to collapse several chapters into a 
broadened idea of Extrinsic.

---------
GROUP C PROPOSAL PROCESSING

Rob Schreiber presented the LIBRARY & Intrinsics NEWS  July 11, 
1196.  This a play on KenUs complaint that the hotel didnUt carry the 
NY Times.  Highlights are:

GEN_TRANSPOSE NAME WILL COME BACK ... ALTERNATIVE IS 
GRNERALIZED intrinsics ... either it replaces the Fortran intrinsics or 
it is in the library with the generalized name . 

GRADE_UP, DOWN to go 1-BASED --- PROCS LB and UB RESULTS 
in distribution inquiries will also be 1-based.   (This is the same as 
maxloc and minloc)

New intrinsics:
Active_num_procs and Active_procs_shape ... these are the same as 
num_procs and Proc_shape if they are outside all ON constructs ... 
otherwise they refer to the inner-most enclosing , ON region.

grade-up/down  will be 1-based   official - 2nd reading  vote: 12 - 0 - 3

gen_transpose and library ... or  transpose and intrinsic .... overriding 
Fortran ...
intrinsic?   Adopt the latter:  14  0  1     NOTE: this is a difference from 
Fortran that should be noted in the early part of the document.

HPF_NUMBER >  HPF_NUMBER_MAPPED
HPF_MAPPING > HPF_MAP_ARRAY

Jaspal Subhlok:   Task - Back on popoular demand.  The write-up 
needs to be expanded - 
add another example and more advice to implementors and some 
wording changes

There was a vote about which terminology to use:

Instead of TASKREGION    
 TASK_REGION  ...END  TASK_REGION  - 7 
TASK_SECTION  or END TASK_SECTION - 4
TASKING  END TASKING  - 1
straw poll on name      TASK_REGION wins

Add the underscore to current proposal   14 - 1 - 0

------
Chuck Koelbel --- review of  interproceral ON

Do i-1,n

!HPF$ ON HOME (a(indx(i))) BEGIN
   a(indx(i)) = b(i)
   b(i) =c(indx(i))
!HPF$ END ON

END DO ...

Note This is now called END ON.  For the proposal in the draft 
document will reorder text for better presentation.

Now moving on to the principled of interprocedural ON:
There is always an active set of processors specified by innermost ON 
directive.
   see also  ACTIVE_NUM_PROCS() and ACTIVE_PROCS_SHAPE()  
... the shape will come from the home ON clause ...    irregular shapes  
have an answer but may not be able to map back to the global shape.

Calling a subprogram does not (alone) change the active processors 
set
Local variable are always stored on the active processors set.  
Dummy args are always on the active processors set.
ACTUALS may not be resident.
Global variables may be stored on passive processors.
   (so some one-sided communications are still required)

About Classes of processors Arrangements:

Universal arrangements - represent the set of all available processors 
including inactive ones.  They are used to distribute global data.. 
These are what we had in HPF 1.  The HPF compiler must support 
arrangements with Number_of _processor() elements.  Two Universal 
processors arrangements with the same shape are identical.

Active Processors Arrangements  represet the set of active processors.  
They are used to distribute local data.  HPF compiler must support 
arragements with ACTIVE_NUM_PROCS() elements.  Two active 
processros arrangements with the same shape are identical  if no ON  
directive is executed between their declaration.

Discussion of status of RstackedS active sets ... there will be passive 
processor sets, but they are not needed for the definitions.

Delarations of Local Variables:

Distribute must be ONTO an active processors arrangement :
   Explicit  ONTO has the obvious meaning
   An Implicit ONTO  - uses the active processors set (or maybe subset)

ALIGN must be to an ultimate align target that is distributed to an 
active procssors arrangemnt

Active processors set is determined at the time that the DISTRUBTE 
or ALIGN becomes instantiated.
     explitic shape (non-allocatable) is determined at the time of 
declaration
    deferred shape(ALLOCATABLE) is determed at ALLOCATE 
statement

Declarations of Dummy Arguments:

Actual argument must be RESIDENT if the dummy argument is 
mapped transcriptively.  This allows other locals to be ALIGNed to 
the dummy.

Otherwise, actual argument may be non-RESIDENT and dummy 
must be declared as a local variable.  Note: if a remapping takes place, 
the actual argument is moved to the active processors set.  Note also, 
If no remapping takes place the dummy is on the active processors set 
(and thus the actual is also).  Either way, the dummy is RESIDENT 
and other locals can be ALIGNED to it.

Question ---- about what calling LOCAL means from within a 
restricted procs set ... what set of procs get activitated? Only the active 
set.  But must have prescriptive mappings for any  GLOBAL arrays 
that are passed.

The   question remaining is .... Imagine I have a subroutine called 
from within ON with a COMMON block containing a globally 
mapped array.

ON ...
    CALL Foo

SUBR Foo
   Common a(N)
!HPF$ DISTRIBUTE A(BLOCK) ONTO P

The questions comes up when N is passed in someway ... so the 
compiler doesnUt
know for sure if P (N) is universal.  There needs to be some way to 
indicate this.  There was discussion of different options - ending up 
with a vote between Procs, Universal and Procs. Active.  A straw poll 
favored active 13 - 0 - ?  A suggestion to use restrictive instead of 
active was voted down.  So the notation will be:
     PROCS, ACTIVE: P(N)

Poll of opinions of vendors ... primary concern is access to non-
resident which is not a new problem ... it also exists in PURE.  

Second reading - approved extension for interprocedural ON   
10 - 4 - 1  (squeak).
---------
BREAK
-----------

Carol Munroe presented a problem involing   Inherit + Distriubte.

Example:
subroutine sub (s,y,z)
real, dimension (100,200)				:: x,y,z,w
!HPF$ INHERIT					:: x,y,z
!HPF$ DISTRIUBTE (BLOCK,BLOCK, CYCLIC)	:: x
!HPF$ DISTRIUBTE (CYCLIC)  			:: y
!HPF$ DISTRIBUTE (BLOCK<CYCLIC)		:: z

!HPF$  ALIGN w(:,:) WITH z(:,:) 			::??? (ed-missed it)

Templates of Inherited dummies ...
 - are nameless and of unknown rank
 - can be used in DISTRIBUTE (prescriptive, descriptive, transcriptive, 
mixed)
 - appear to break rule matching length of DISTRIUBTE spec-list to 
rank of object
 - Counter-intuitive, disturbing to users
 - not clear if they can be used to align locals
 - canUt be checked for consistency by compiler
 - of doubtful use to compiler  

main program

program main
real, dimension (100,200) :: a,b,c
$HPF! TEMPLATE, DIMENSION(100,200,300) :: ta
$HPF! DISTRIBUTE (BLOCK,BLOCK, CYCLIC) :: ta
$HPF! ALIGN a(:,:) WITH ta(:,:,*)

$HPF! TEMPLATE, DIMENSION (100)  :: tb
$HPF! DISTRIUBTE (CYCLIC) :: tb
$HPF! ALIGN b(*,:) WITH tb(:)

$HPF! TEMPLATE, DIMENSION (200,300) :: tc
$HPF! DISTRIUBTE (BLOCK, CYCLIC) :: tc
$HPF! ALIGN c(*,:) WITH tc(:,c)
   ! note same rank but unexpected alignment
call sub (a,b,c)
end

benefits of INHERIT + DISTBUTES

INHERIT + transcriptive DISTRIBUTE
  - most useful case:  guarentees no remapping
  - most natural:  transcriptive distribution and alignment
 - DISTRIBUTE * ONTO * is implied anyay, if not present

INHERIT + prescriptive DISTRIBUTE
   - partial remapping plus unknown alignment confusing
   - common alignment of multiple dummies is invisible to compiler
   - canUt align local variables with (remapped?) template
   - could still get variable alignment plus new distribution bu passing 
alignment strides, offsets, axis permutation, and align dummy 
explicilty.

INHERIT+descriptive DISTRIBUTE
 - explicit ALIGN with visible template would be more useful, as for 
prescriptive DISTRIBUTE

why was INHERIT + DISTRIBUTE in HPF 1.0?

 Because Subset HPF 1.0 included INHERIT and didnUt include 
DISTRIBUTE * ONTO *
   - Users needed to use an explicit (descriptive) distribute to 
accompany each transcriptive alignment
  - no non-explicitly-obtainable:  default mappings allowed

BUT INHERIT was dropped from Subset HPF 1.1 while transcriptive 
(all) DISTUTUTEs were now allowed.

Motivation gone, confusing syntax left.

Proposal
Add one rule to section 3.4.2
   A dummy argument may not have both the INHERIT attribute and 
the DISTRIBTE attribute.

Shorten or drop RcomplexS example in setion 3.4.3

Add comment that INHERIT always implies both transcriptive 
alignment plus trancriptive distribution

Passes 14 - 0 -1  decided to make formal 2nd vote.

Piyush:    Range clarification

Text change needed to specify that range- attr-stuff must be compatile 
with the ultimate align target of the ranger.

(current text talks about template - should be ultimate align tempate)

POINTER A
!HPF$ RANGE A(BLOCK)
!HPF$ DISTRIUTE B(BLOCK)
  A=> B(1:307:3)  ! ok since template of RHS (and this of A) is clock 
distriuted.

RANGE - clarificatiosn:

!HPF$ DISTRIBUTE  T(BLOCK)
!HPF$ ALIGN A(I,J) WITH T(I)

call sub(A)

----
sub(x)
!HPF$ INHERIT x
!HPF$ RANGE  X    (BLOCK, *)

2nd dimension of X has no corresponding dimension in the ultimate 
align target of the actual

Text to be added:
If there is not corresponding dimension, then a * or ALL mut be used 
as the range-attr.

real A(100,100,100)
!HPF$ dist A(block,*,cyclic)
call sub(A(:,:,1))  	! illegal
call sub (A(:,1,:))  	! ok
call sub (A(1,:,:)) 	! illegal

where:
sub(x)
real x(:,:)
!HPF$ inherit x
!HPF$ range x(block, cyclic)

second example - same caller  - but different things are legal: 
real A(100,100,100)
!HPF$ dist A(block,*,cyclic)
call sub(A(:,:,1))	!ok in second example
call sub (A(:,1,:))	! ok in second example
call sub (A(1,:,:))	! ok in second example
where:
sub(x)
real x(:,:)
!HPF$ inherit x
!HPF$  range  x(block,*), (block, cyclic), (*,cyclic)

vote on second clarification --- 14 - 0 - 1
vote on first clarification   - 13 - 0 - 2

NOW POINTERS AGAIN

If both actual and dummy pointes are dynamic what happens if 
dummy is redistriuted?
Note - if dummy is (re) allocated new storage is visible in caller!

Two options  (with subgroup votes):

Option 1   Redistrution of dynamic pointers not visible in caller - 
remapped to original - if new (re) allocation  - new storage with 
original distribution (if possible) visible in caller   2-2-2

Option 2:  If actual and dummy both dynamic - redistribution of 
dummy visible in caller - true for dynmic variables visible through 
use and host     3 -2 1

Committee talked about allowing this to work for pointers, but not 
variables - but decided that they should go together.

This is a clarification - one of the two options  (or maybe third or ...)

Henry proposes  variation - where couldnUt remap args but ok for 
things visible via modules, etc. ...

Proposal is to adopt option 2 for approved extensions ...

11 - 0 - 3

==========

After break

Saday presented a proposal for a new overview chapter.

current contents
 - introduction of key HPF concepts
 - guide to HPF2 doc
 - document differences and trace evolution

Proposal:   Have Overview do the first two and  move last to annex 
with appropirate pointers in the overview.

New 1.1 goals and Scope of HPF 2.0   (old 1.2)

1.2 HPF Model  (old 1.3, 1.9, 1.10)
	- philosophy of lang approach
	- f95 extension
	- data parallel model
	- data mapping directives
	- extrinsic interface for other lang/paradigm
	- new simple example such as LU

1.3 HPF language Features  (old 1.4, 1.7)
	- philosopy of document organization
	- pointer to appendix
	- base 2.0 lanugage features
	- hpf approved extensions

1.4 Organization of Document   (old 1.8)

1.5 Notation and Syntax  (old 1.6 and 1.11)

* Evolution of HPF (old 1.1, 1.5)  move to annex  --- changes and 
extensions

Goals and Scope of HPF

Primary Goals
- Portability across different architectures
- Data parallel programming (single threaded,global name space)
- High performance on parallel computer with non-uniform memory 
access costs
- Open interfaces and interoperability with other language (e.g. C) and 
programming paradigms (e.g. message passing with MPI)
 - Build on Fortran 

Subsidary Goals
 - Keep language understandable and implementable in short time 
span
-  Provide input to future standard  standards activities for fortra and 
C
 - Provide evolutionary path for adding advanced features in a 
consistent manner to the base language

========
Mary presented the subgroup E proposed revision of the extrinsic 
mechanism.

#1 EXTRINSIC ( HPF| HPF_SERIAL | HPF_LOCAL)
     or
     EXTRINSIC ([ [MODEL=] RstringS] [, [[LANGUAGE =] RstringS]
                              [ , [EXTERNAL_NAME = ] RstringS ]] )
     (or whatever the correct [] pairs are).  The idea is that this 
mechanism will now follow the keyword conventions of other Fortran 
constructs.
     The strings for  our oldnames are 
	HPF		MODEL = RglobalS, LANGUAGE = RhpfS
	HPF_LOCAL		MODEL = RlocalS, LANGUAGE = RhpfS
	HPF_SERIAL	MODEL = RserialS, LANGUAGE = RhpfS

#2 As part of HPF 2.0, if extrinsics are supported - include MAP_TO
- this is primarily to avoid explaining MAP_TO over and over for each
extended extrinsic name.

#3 MAP_TO generalized:
	MAP_TO (TYPE=RstringS, 
                              LAYOUT = RstringS, 
                              PASS_BY = RstringS)
where again these follow the Fortran keyword notation.  The strings 
are things like  Rint:S, R(int,double)S for types; Rc_arrayS for layout;
and RvalS, RrefS, RrrefS, RrrrefS. RrrrrefS for pass-by.
A given extrinsic might extend MAP_TO.

In approved extensions - the chapters for LOCAL, SERIAL, C, Fortran, 
and Fortran77 will be combined into one chapter with an outline of
	parallel models
	language interfaces
	libraries
	other {default}
	examples

 --- straw polled :  consensus for the approach ...

=======
Piyush presented more pointer discussion.

- pointers with an explicit mapping using a distribute or align
	- can be used to allocate
	- can be used to point to whole array with dimension by 
dimension
		compatible mappings
	- cannot be used to point to sections

- pointers can point to sections of distributed arrays via transcriptive 
mapping (distribute *)

- range can be used  to restrict the distribute * - rules of range apply

 - discussion of whether this is too restrictive - too much  -  or ???  
committee decided yes.

Remaining question about   Distribute * ONTO ...    for a dummy 
argument ... 

Andy Meltzer went over the 
HPF - CRAFT/DRAFT ... 

He described how he will rewrite the document to conform to outline.

Questions for committee:
1. are the sections an appropriate length?
        - 1 page intro
        ~ 2 page examples
        ~2 pages of functional specs
        ~6 page functional spec

2. are these the sections what we want?

Discussion about name  - whether to change the name to CRAFT_HPF 
...

HPF_CRAFT 4 -  CRAFT_HPF 3 - abstain 8

Second reading that this goes to the extrinsic extrinsic chapter - with 
the reorganization that Andy has outlined ...    9 - 1 -  3   external

There was some additional discussion about the names of the chapter 
and annex for these extrinsics.

The chapter will be  Approved Extrinsic Extensions
The annex will be   Recognized Extrinsics Interfaces

------

Discussion of document plan

Revised schedule - try to get it out very shortly after the October 
meeting.
Ask for input about  which of the approved extensions should the 
vendors give most priority to.

The meeting to process comments will tentatively be  Dec 9-11, 
probably at Rice.  Starting at noon on the 9th  to mid-day on the 11th.

User Meeting Proposal -   in Santa Fe in February  - try for  Feb  24-26 ; 
second choice 10-12; 12-14 third choice; 19-21 fourth choice.  Bob 
Boland is organizing this with LANL and CRPC as joint hosts.

On the agenda of the October meeting, we will plan the CCI process.

Agenda for Friday:   SC96, finish 2nd reading extrinsics; F77 as 
simplified; explicit interface clarified; interprocedural ON ; replan 
document;  E cciUs.

Adjourn Dinner ...

Friday, July 12.

Piyush:  pointer recap  to clarify the issue of compatibility mapping..

in HPF 2
if p is not explicitly mapped
	can be pointer associated with an object which has both been 
explicitly mapped
	compilers chooses mapping when allocated
	dummy - if and only if actual is also not explicitly mapped
Approved extension
if p is explicitly mapped with a non-starred mapping
 	allocated using the specified mapping
	can point to whole objects with dimension - by - dimension 
compatible mappings
	p is dummy - actual must be explicitly mapped - must be 
whole 
array  must have dim-by-dim compatible mapping

if p is transcriptively mapped
	-compiler chooses mapping on allocation
	-can point to anything
	-range can be used to restrict mapping of the ultimate align 
target of the target
	-dummy
		- actuals maybe anything legal in F90 which is explicitly 
distributed
		 - any reassociation must match the conditions of the 
actual on return
		- range can be used to restrict mappings of actuals

if p has the dynamic attribute
	- can be pointer associated with a target iff it has the dynamic 
attribute
	- a target associated with p can be remapped through p iff
		- the object was allocated  and
		- p points to the whole object

	Any other pointer associated with the target looses association 
(except see below)

	-range can be used to restrict what p can point to or 
redistributed to.  For non* distribute must contain specified 
distribution
	- on allocation
		- transcriptive distributions - compiler chooses
		- non-* distribution - specified distribution
	    In either case can be redistributed subject to the restrictions 
of range.

If p is dynamic and is a dummy  
	
	along with other restrictions, actual must also have the 
dynamic attribute
	on redistribution, actual does not loose association and new 
mapping is visible in caller
	any redistribution must match restrictions of the actual on 
return.

For pointers - transcriptive means   distribute *   NOT distribute * onto 
*

====

Saday raises the question about the current (HPF 1.0 restriction) that if 
pointer target
is redistributed through a pointer, then all the other pointers to that 
target become undefined. 

Saday moved that we remove this restriction.   If we redistribute 
through 
pointer, other objects to not lose association -     9 - 2 - 2   passes ....

Pointer compatibility recap .... 12 - 0 - 1

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

Extensions --- Two clarifications related to the document rewrite.
	In consideration of how this would be used in a serial Fortran 
program, switch the EXTRINSIC args for model and name so that 
model is last - require keyword for model if it is used.  

	In the HPF 2.0 chapter, it is ok to introduce HPF_SERIAL and 
HPF_LOCAL for discussion, even if these languages are in the 
extensions part of the chapter.  There was some discussion of the idea 
of making such language names hidden parameter strings, but this 
was not accepted.
========
Henry Zongaro - when is explicit mapping required?

Replace 3.5.1 p 66 line 35 through p. 68, line 10 of the draft 2.0 
document with:

The actual argument must be a named object.

The shapes of the ultimate align targets must be the same.  In 
addition, the ultimate align targets of the dummy and actual must not 
have been explicitly distributed, or the DISTRIBUTE directives 
specified for both the ultimate align targets must:
 	have an onto-clause specifying processors arrangements 
having 
the same shape; and
	must specify dist-format-clasues with the same dist-formats in 
corresponding positions, except blocking factors need only have the 
same values.

Each dimension of the actual and dummy must correspond to the 
same dimension of their respective ultimate align targets, and 
corresponding elements of the actual and dummy must be aligned 
with the same corresponding elements of their respective ultimate 
align targets.

Section 3.5 will be modified  to avoid describing these mappings as 
being the *the same*.

Question about how this applies to the active processor set.?

Summary: - to avoid requiring explicit interfaces, all arguments must 
have basically identical interfaces.

Question ... about how this applies to pointers ... pointer actual - array 
dummy ... make sure it is ok ...that the terminology  named-object is 
broad enough.

13 - 0 - 0  [trust Henry :-)]

----------
CHK will take responsibility  for identifying all the context where 
Rprocessor setS should actually be RactiveS processors set.

---------

F77_local interface changes to the proposal handout

Extrinsic (LANG-SF77S, MODEL - RLOCALS)
	Rules for MODEL- RLOCALS described in RApproved 
ExtensionsS
Argument passing via MAP_TO(LAYOUT-S...S, PASS_BY= R...S) 
	Extrinsic kind F77_local determines defaults ( ...)
	Default for arrays:  LAYOUT-SF77_ARRAYS - local data is 
packed/unpacked into sequence associate  {missed something here - 
ed.}
	PASS_BY = RREFS - pass local assess of start of array

Other supported MAP_TO options:
	LAYOUT = RNO_CHANGES - pass whole distributed HPF 
array as is.
	PASS_BY = RHPF_HANDLES - Pass address of a data structure 
to be used in local inquiry functions only.    or should this be 
RDESCRIPTORS?)

 Question:  Should we have a LAYOUT option to create automatically 
replicated SEQUENCE array?  (must users remap these in advance)

Should this go into Approved Extensions 11-0-2

--------
In the recognized extrinsic interface  (library)
F77 inquiry functions - unchanged in Annex as Rrecognized extrinsic 
interfaceS
	one global function HPF_SUBGRID_INDO to find actual local 
extens before call
	One local version of same F77_SUBGRID_INFO 

For the library  recognized  :  straw poll ...    9 - 0 - 6

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

August 7 Is the date for next HPF DOC.  September 4th is the date for 
the distribution just before the meeting.

==============
At the next meeting, we need an agenda item to talk about the
longer term plan for HPFF.  Create a   FUTURE ROADMAP.

For SC96, Mary will send in a BOF proposal. Preference is early in the 
week.  This BOF will focus on presentation of HPF 2.0 and extensions 
- for public comment.

=========
And  LPF is back in action ...

HPF2 slogan proposal for a tee-shirt ...
If we canUt make it faster - at least we can make it more (complicated)  
crossed out ... feature rich.

the  tee-shirt only comes in xl and xxl   velcro straps for approved 
extension

LPF   3.1415i
Goals of LPF:
	Opportunity to visit identical hotels all over the country to sit 
in a windowless conference room, spend long days with computer 
geeks, then to home
	-   the entire low-performance community
	- Anger the entire language/compiler community
	Give HPF users a positive path forward.

LPF new platform list:
	TRS-80 with 800 MB memory or more
	500 megahertz apple Iie
	- Superscalal implementation for IBM Xt
	- Any abacus with a 2MB video card
	barefoot people with nine fingers and twelve toes
	and of course:
		any platform supporting full HPF

New LPF Directives:
Begin
begin begin
end begin
end
begin end
end end

Example usage:  *
begin begin if
	begin if
end begin if
	begin begin block
		begin block
	end begin block
		(x/0 < 5)
	begin end block
	end block
	end end
	begin begin then
		begin then
	end begin then
		begin begin block
		begin block
		end begin block
			begin call
				call call()
			end call
		begin end block
		end block
		end end block
	begin end then
	end then
	end end then
begin end if
end if
end end
* of course LPF progs are not this nicely indented
+ No LPF user has ever written a program.

(One prospective LPF user wonders if this example is best understood 
if one hums begin the begine (sp?) while reading it??

More new directives: (Building on HPF ACTIVE)

	- proACTIVE processors arrangements:
		- anticipte what the user will want to do and do it ahead 
of time.  Their
		  smug perfection annoys other processors.

	- retroACTIVE processors arrangements:
		- wait until too late, get into the correct position, then 
declare that they 
		  were there all the time.

	-hyperACTIVE processors arrangements:
		-continually change position, destructive, with a short 
attentions span.
		- also called Attention Deficit Disorder processors 
arrangements.

Some thought s on HPF Directives:

	- HPF now has ON HOME and RANGE keywords -
		somehow HPF forgot the HOME ON the RANGE 
directive.

	parameter (from_dead_uncle=100)
	parameter(close=16)
	processors relatives(close)
	inherit lots_of_money(from_dead_uncle)
	distribute lots_of_money(cyclic) onto relatives

	or from a new father:

	distribute pee onto diaper
	distribute poo onto diaper
	align diaper with diaper_pail

The meeting adjurned at 10:30

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

The next  HPFF meeting is September 18-20 (again San Francisco 
area),  with the expectation that there will be a public comment period 
between during October and November. There will be a meeting   Dec 
9-11  , probably at Rice University.

-------------------------------------------------------------
July 96 Attendance:    
Robert Babb	U. of Denver	[email-masked]
Siegfried Benkner	Univ. of Vienna	[email-masked]
Bob Boland	LANL	[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]
Andy Meltzer	CRI/SGI	[email-masked]
Carol Munroe	Thinking Machines	[email-masked]
Carl Offner	Digital	[email-masked]
P. Sadayappan	Ohio State University	[email-masked]
state.edu
Rob Schreiber	HP	[email-masked]
Jaspal Subhlok	Carnegie Mellon	[email-masked]
Arun Venkatachar	Louisiana St. Univ.	[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>
---------------------------------------------------------------------------