Subject: Chapter 3

From: Rob Schreiber <[email-masked]>
Date: Tue, 13 Apr 93 10:45:31 PDT

Chapter 3:  I like the new writeups and additional explanations.  But I would like
to suggest some changes for additional clarity:

page 43:, line -5:  "... specifies that a dummy argument should be aligned to a copy of the
template of the corresponding actual argument in the wame way that the actual argument
is aligned."

page 44: line 2:  (in a) may ...    take out the "in a"

page 44: lines 4--5.   I think the restriction against general expression actuals with
inherited dummies is so severe it makes the use of inherit in library routines impossible.
Instead, I think we can use the following theory.

a.  It is allowed.

b.  Every actual argument has a describable mapping, and hence it is ultimately aligned to
some template (of the compiler's choosing if it is not an array or regular section of an
array).   This includes sections like A(INDEX_VECTOR), which must, therefore, be moved to
a temporary.

page 44, line 8:  type "mappoing"

lines 7--9:  I thought that INHERIT is out of SS HPF anyway!

Just before Section 3.10:   An example would be very good here.  Like:

	REAL DOUGH(100)
!HPF$	DISTRIBUTE DOUGH(BLOCK(10))
	CALL PROBATE( DOUGH(7:23:2) )
	...
	SUBROUTINE PROBATE(BREAD)
	REAL BREAD(9)
	INHERIT BREAD

the inherited template of BREAD has shape [100]; BREAD(I) is aligned with element 5 + 2*I
of it and, since BREAD does not appear in a prescriptive DISTRIBUTE directive,
it has a BLOCK(10) distribution.

Page 45, just after the inner itemized list.   This comment applies to the three cases above,
not the three bulletted cases above that.   So it should indent at the level of the bulleted
items.   Better to say "in these three cases ... "

page 45, line -2:  I think this is clearer:
"Therefore the template of TANGO is a copy of the 128 element template of the whole array
TWIST.   TANGO(I) is aligned with element 3*I of it.  It is mapped like this:"

page 46, after the first diagram:   You are slyly introducing the notion of the
"pre-existing" mapping, one not otherwise possible in HPF, of the natural template of the
dummy.  This is a mapping that cannot be inherited (since then the natural template does not
live) cannot be prescribed and cannot be described.   DO you really want to deal with this
idea in the draft -- it confused me for a bit, and I think it will confuse others.  Can we
say:

"But the template of FOXTROT has the same size 14 as FOXTROT itself.   THe actual argument,
FRUG(1:40:3) is mapped to the 16 processors in this manner:

		Abstract	Array
		processor	elements

		...		...

It would be reasonable to understand the mapping of the template of FOXTROT to
coincide with the layout of the array section,

diagram

but we shall shortly see that this is not permitted in HPF.   Within subroutine
TERPSICHORE it would be correct to make the descriptive assertion... "

Page 47, lines 9ff.   The thing in parens seems essential to me, so I suggest it be a
separate, nonparenthetical paragraph.

In the example, there is a missing asterisk:

!HPF$ ALIGN FOXTRO(J) WITH *GURF(3*J-2)

------- Rob Schreiber