Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!lll-winken!ubvax!ardent!sim!afs
From: afs@ardent.com
Newsgroups: comp.lang.fortran
Subject: Re: How much illegal are these?
Keywords: illegal subscripts vectorization
Message-ID: <7896@ardent.UUCP>
Date: 19 Aug 89 20:36:31 GMT
References: <11640001@uxa.cso.uiuc.edu>
Sender: news@ardent.UUCP
Reply-To: afs@ardent.com
Followup-To: comp.lang.fortran
Organization: Ardent Computer Corp., Sunnyvale, CA
Lines: 44

Hugh Song asked about illegality of Fortran constructs that come up
in vectorizing programs. (Judging by the name of his machine, I'd
guess that it is one of ours... \_/ ). Perhaps a few observations are in order:

1. IF his intention is to make use of the subscript 0 as a legitimate
element of his arrays, ANSI 77 provides a mechanism for declaring this:
	real a(0:10,0:10)
which makes both of his subscript expressions legal.  
	
2. IF the intention is to make use of the forced overlap of array element
subscripts with each other, the official mechanism is (assuming valid 
declaration of a as having 0 as a valid subscript):
	equivalence (a(0,0),c(10,10))
where c is suitably declared as an array elsewhere.

3. It IS legally the decision of the compiler as to where arrays are placed
in storage; they do NOT have to be stored in the order in which they
are listed in the declarations statement.  Thus, the result of his
execution of an statement addressing   a(0,i) which precedes the 
beginning of the declared region of memory CAN produce a segmentation
fault type error instead of picking up a zero from another array.  

4. Vectorization of programs does NOT force the accessing of array elements
outside of the defined boundaries of arrays.  If the goal is to force
particular elements to "appear" as elements of an array so that they
may be accessed by a "vector" operation, the array declarations should
be made (and/or equivalenced) so that what the programmer has in mind
is explicitly declared.    Vectorization / Optimization generally does
not proceed well when non-standard assumptions are made about the 
object code/memory layout.

-----
Al Shpuntoff              afs@ardent.com or afs%ardent.com@uunet.uu.net,
Ardent Computer           408-732-0400
880 West Maude Avenue
Sunnyvale, CA 94086        

                UUCP:   {hplabs, ubvax,decwrl, ucbcad, uunet}!ardent!afs
                Dialcom:    134:CMP2016
-----
-----
Al Shpuntoff, Senior Instructor/Course Developer
Ardent Computer            408-732-0400
880 West Maude Avenue