Subject: Answers

From: Rob Schreiber <[email-masked]>
Date: Tue, 12 May 92 14:53:43 PDT

My opinions:

1.    The minimal subset should consist of the NUMBER_OF_PROCESSORS
and PROCESSORS_SHAPE intrinsics only.

2.    The idea of allowing a reduction intrinsic for every suitable
binary operator, and PREFIX, SUFFIX, and SEND intrinsics for every
reduction, is appealing, but maybe this places too great a burden on
the implementors?   Are all of these potentially useful?

3.   Answers to my own questions:
------------------------------------------------------
  POPCNT		

  POPPAR

  LEADZ

  ILEN

>>>>>>>>	Maybe.   I dont need them.

... Cray Fortran allows
these intrinsics to be applied to data types other than integers;
should HPF allow this also?

>>>>>>>>	No.

------------------------------------------------------
  extended MAXLOC   (with DIM argument)
>>>>>>>>	Yes.

  extended MAXLOC   (with DIM argument)
>>>>>>>>	Yes.

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

New reductions:

	AND
	OR
	EOR
	PARITY
>>>>>>>>	Yes.

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

For each reduction intrinsic XXX, introduce the parallel prefix and suffix
intrinsics:

	XXX_PREFIX(ARRAY, DIM, MASK, SEGMENT, EXCLUSIVE)
	XXX_SUFFIX(ARRAY, DIM, MASK, SEGMENT, EXCLUSIVE)

>>>>>>>>	Yes.

On PREFIX and SUFFIX:

>>> Outstanding issues: This proposal delimits the segments by indicating
>>> the *start* of each segment.  Cray MPP Fortran delimits the segments
>>> by indicating the *stop* of each segment.  Each method has its advantages.
>>> There is also the question of whether this convention should change when
>>> performing a suffix rather than a prefix.
>>> 
>>> Another way to delimit segments is to use a logical vector and say
>>> that a new segment begins at every *transition* from false to true or
>>> true to false; thus a segment is indicated by a maximal contiguous
>>> subsequence of like logical values:
>>> 
>>>         (/T,T,T,F,T,F,F,F,T,F,F,T/)
>>>           ----- - - ----- - --- -    seven segments
>>> 
>>> The main advantages of this representation are:
>>> 
>>> (a) It is symmetrical, in that the same segment specifier may
>>>    be meaningfully used for parallel prefix and parallel suffix
>>>    without changing its interpretation (start versus stop).
>>> 
>>> (b) It seems to be equally inconvenient for every existing
>>>    architecture.  :-)  However, it is not that hard to accommodate.
>>> 
>>> (c) The start-bit or stop-bit representation is easily converted
>>>    to this form by using a parallel XOR prefix or suffix.
>>>    Of course, we would need to define one (see separate proposal
>>>    for a PARITY reduction intrinsic).  Examples:
>>> 
>>>    SUM_PREFIX(FOO,SEGMENT=PARITY_PREFIX(START_BITS))
>>>    SUM_PREFIX(FOO,SEGMENT=PARITY_SUFFIX(STOP_BITS))
>>>    SUM_SUFFIX(FOO,SEGMENT=PARITY_SUFFIX(START_BITS))
>>>    SUM_SUFFIX(FOO,SEGMENT=PARITY_PREFIX(STOP_BITS))
>>> 
>>>    These might be standard idioms for a compiler to recognize.

>>>>>>>>    I think that alternating sequences is the best way since
>>>>>>>>    it is the easiest to remember.

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

For each reduction intrinsic XXX, introduce the send with combination
intrinsic:

	XXX_SEND(SOURCE,DEST,IDX1,...)

>>>>>>>>    Yes.
------------------------------------------------------

Sorting:

	GRADE_UP(ARRAY,DIM)

	GRADE_DOWN(ARRAY,DIM)

>>>>>>>>    Yes.
>>>	Question: should stability be guaranteed?
>>>>>>>>    Yes.

The alternative:

	INDEX(ARRAY,SUBS)

	GRADE(ARRAY1,ARRAY2,...)

>>>>>>>>    No.

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

	NUMBER_OF_PROCESSORS()  with optional DIM argument

>>>>>>>>>>   No.
The alternative:

	NUMBER_OF_PROCESSORS()  with no optional DIM argument and
	PROCESSORS_SHAPE()

>>>>>>>>>>   Yes.
Question:  Should these be allowed for processor_arrangements in HPF 
directives?
>>>>>>>>>>   Yes.

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