From jwagener@amoco.com Fri Sep 29 21:55:45 1995 Received: from interlock.amoco.com (interlock.amoco.com [192.195.167.2]) by dkuug.dk (8.6.12/8.6.12) with SMTP id VAA09853 for ; Fri, 29 Sep 1995 21:55:39 +0100 From: jwagener@amoco.com Received: by interlock.amoco.com id AA10450 (InterLock SMTP Gateway 3.0 for sc22wg5@dkuug.dk); Fri, 29 Sep 1995 15:54:06 -0500 Message-Id: <199509292054.AA10450@interlock.amoco.com> Received: by interlock.amoco.com (Protected-side Proxy Mail Agent-3); Fri, 29 Sep 1995 15:54:06 -0500 Received: by interlock.amoco.com (Protected-side Proxy Mail Agent-2); Fri, 29 Sep 1995 15:54:06 -0500 Received: by interlock.amoco.com (Protected-side Proxy Mail Agent-1); Fri, 29 Sep 1995 15:54:06 -0500 X-Openmail-Hops: 1 Date: Fri, 29 Sep 95 15:53:42 -0500 Subject: JLW informal report on the Sept 20-22 HPFF meeting Mime-Version: 1.0 To: sc22wg5@dkuug.dk Content-Type: text/plain; charset=US-ASCII; name="JLW informal report on the Sept 20-22 HPFF meeting" Content-Transfer-Encoding: 7bit I thought this was an excellent meeting, as good progress was made on several fronts. First some jargon - HPFF progresses work in terms of "readings". If a topic is included in the requirements for HPF 2 then it has a 1st and 2nd reading, at least a meeting apart. A technical proposal is presented at the 1st reading, discussed, and straw votes taken. A revised proposal is presented on the 2nd reading and is either accepted (after possible revision at the meeting) or rejected. There is no 3rd reading or further consideration of a given topic. On ocassion there is a 0th reading of a totally new topic, with straw votes on whether or not to move it on to a 1st reading at the next meeting. Irregular distributions (group D - distributions) ------------------------------------------------- BLOCK(int-array) 2nd reading 18-1-4 (passed) INDIRECT(int-array) 2nd reading 13-2-9 (withdrawn) INDIRECT(function-name) 1st reading 5-8-13 (withdrawn) In the first (BLOCK) form int-array(i) is the size on the ith processor; in the second (INDIRECT) int-array(i) is the processor number of the ith element. A 1st reading on mapping the components of derived types resulted in a 17-1-8 straw vote, so this will be progressed to a 2nd reading. A 1st reading on mapping to subsets of processors resulted in a 14-2-10 straw vote and so this too will be progressed to a 2nd reading. BLOCK(int-expr,shadow-spec) 1st reading 13-4-10 (pursue) The shadow-spec defines an array fringe, such as needed for finite difference computations, to reside in two (or more) places. Task parallelism (group C - control) ------------------------------------ ON HOME directive 1st reading 20-2-3 (pursue) Intrinsic reduction 0th reading 22-3-1 (pursue) Defined reduction 0th reading 17-6-3 (pursue) TRANSPOSE(array,order) 0th reading 17-1-4 (pursue) The ON HOME directive allows the user to specify which processor, or processor set, is to perform the computation. The reductions provide means for specifying parallel reduction operations. The TRANSPOSE proposal is to extend the F90 TRANSPOSE intrinsic. READ(...,ID=scalar-int-var,...) input-list WAIT(ID=scalar-int-var) The read-with-ID and wait is the asynchronous I/O proposal, I think this was a 2nd reading (for some reason my notes don't say), in which case it passed (but I didn't record the vote). The semantics are that if the io-control list contains the ID= specifier then the io process is generated asynchronously, and the WAIT stateent is used by the programmer at those spots in which the corresponding I/O process must complete before execution can proceed. There was a 0th reading on an explicit tasking proposal, which received a 17-2-5 straw vote and hence will be pursued. External interfaces (group E - external) ---------------------------------------- HPF kernel - I believe this was a first reading, and the straw vote was favorable so it will be pursued (again my notes are incomplete). The kernel is a subset of HPF, but with a different objective than the current subset: the current subset includes all the distribution directives; the kernel restricts the distribution directives to those that are most efficiently implementable. This is considerable interest in HPFF at this point for calling the kernel HPF 2 and superset HPF Extended. EXTRINSIC (C) ... 1st reading 16-1-7 (pursue) convert_to_C intrinsic Oth reading 13-1-10 (pursue) C_VOID_POINTER This proposal, which I will distribute separately because of the great interest in this topic in WG5 and X3J3, provides a means to specify interface blocks for C procedures. It has two key features: (1) it automatically triggers call-by-value and (2) it contains an optional MAP_TO attribute (e.g., MAP_TO(C-TYPE=double) ) in argument declarations that allows limited mapping to C internal formats. The C_VOID_POINTER is a new type defined in an intrinsic module that copes with the numerous uses of "opague" pointers in C and those of similar ilk. The **A technique used in C for argument indirection is proposed in either functional form (e.g., LOC(LOC(A)) ) or something similar to C (e.g., @@A - there is a lot of sentiment for this approach, but none for the ** syntax). As I understand it, call by reference also would use the @ technique (in place of %REF in David Levine's approach). ============================= At several ocassions there seemed to be a need for "purer than pure" procedures. These are procedures that also cannot access global variable values, or values of variables on different processors. If there is not such a "purer than pure" type of procedure, then some of the individual features will have to include the additional restrictions, as appropriate. There were a few other things discussed at this meeting, but these are the highlights, I believe. Jerry