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