don@chara.UUCP (Donald J. Barry) (07/11/90)
Running UWS 1.31 and the associated fortran and compilers on a DS 3100, I'm
finding it rather difficult to port a creaky fortran application over. The
code is roughly 6000 lines, still uses arithmetic if's, switches, etc, and
even has a few (gasp) hollerith constants here and there. Its fortran 77
and compiles and runs with no problems on both Microsoft Fortran 5.1 and
a Univac compiler. The problem seems to be one of passing arrays declared
in common as arguments to subroutines (I know, it's terrible programming, but
the trick is really needed in this case). Specifically, I have a function
of the sort
MAP(array1,array2,int,array3,array4,int2)
where all the arrays, and sometimes one or both of the scalars is also in
named common. Only the arrays suffer side effects from the call. If
I replace one of the scalars with a copy of it, rather than using the
original in common, the output changes. I have not yet tried making
copies of all the arrays because of the many permutations that this
routine is used with.
Is this a known compiler problem? Has anyone developed any workarounds?
Don Barry
Center for High Angular Resolution Astronomy
Georgia State University
--
Donald J. Barry (404) 651-2932 | don%chara@gatech.edu
Center for High Angular Resolution Astronomy | President, Astronomical
Georgia State University, Atlanta, GA 30303 | Society of the Atlanticmamros@cavdog.enet.dec.com (Shawn Mamros) (07/13/90)
In article <2373.269de8a0@csc.anu.oz>, axt654@csc.anu.oz writes: > [...] I can only guess that some sort of > assumption may be being made about byte-order, the PC and DS 3100 have opposite > byte order. Wrong. PC's (which use 80x86 microprocessors) and DS3100's are both little-Endian machines. Same byte order. -Shawn Mamros mamros@aiag.enet.dec.com or mamros@cavdog.enet.dec.com The above words are mine and mine only...
axt654@csc.anu.oz (07/13/90)
In article <173@chara.UUCP>, don@chara.UUCP (Donald J. Barry) writes: > Running UWS 1.31 and the associated fortran and compilers on a DS 3100, I'm > finding it rather difficult to port a creaky fortran application over. The > code is roughly 6000 lines, still uses arithmetic if's, switches, etc, and > even has a few (gasp) hollerith constants here and there. Its fortran 77 > and compiles and runs with no problems on both Microsoft Fortran 5.1 and > a Univac compiler. The problem seems to be one of passing arrays declared > in common as arguments to subroutines (I know, it's terrible programming, but > the trick is really needed in this case). Specifically, I have a function > of the sort > MAP(array1,array2,int,array3,array4,int2) > where all the arrays, and sometimes one or both of the scalars is also in > named common. Only the arrays suffer side effects from the call. If > I replace one of the scalars with a copy of it, rather than using the > original in common, the output changes. I have not yet tried making > copies of all the arrays because of the many permutations that this > routine is used with. > > Is this a known compiler problem? Has anyone developed any workarounds? > Don Barry > Center for High Angular Resolution Astronomy > Georgia State University > -- > Donald J. Barry (404) 651-2932 | don%chara@gatech.edu > Center for High Angular Resolution Astronomy | President, Astronomical > Georgia State University, Atlanta, GA 30303 | Society of the Atlantic I am also using 1.31 of this compiler and don't seem to be hitting the problem. I declare 5 dimensional several megabyte arrays and pass subsections of lower dimension to subroutines without problem. I can only guess that some sort of assumption may be being made about byte-order, the PC and DS 3100 have opposite byte order. I certainly don't think it's a compiler limitation as my arrays are also common blocked, and the code isn't even all that ugly - how else do you structure arrays of arrays of two dimensional objects? Andrew Tridgell tridge@aerodec.anu.oz.au