Path: utzoo!attcan!uunet!husc6!mailrus!ames!hc!lanl!beta!jlg From: jlg@beta.lanl.gov (Jim Giles) Newsgroups: comp.lang.fortran Subject: Re: Should I convert FORTRAN code to C? Message-ID: <20535@beta.lanl.gov> Date: 5 Jul 88 04:01:43 GMT References: <2742@utastro.UUCP> <20008@beta.UUCP> <224@raunvis.UUCP> <12302@mimsy.UUCP> Organization: Los Alamos National Laboratory Lines: 70 I guess my major complaint against C multi-dimensioned arrays is that the reference a[i][j] means different things depending upon the decl- aration of a. If these differences were transparent at the source level it wouldn't be so bad. But the user is REQUIRED to be aware of the differences. In Chris Torek's terms, the difference between 'flat' and 'row-vector' multi-dimensioned arrays requires explicit different treatment by user code - in spite of identical syntax. Fortran is superior in this case in that all arrays are 'flat' - in Fortran 8x this includes dynamically allocated arrays. In article <12302@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > [...] > I think that the noalias directive damages C far more than it improves it, > just as I think that rule in Fortran damages Fortran. > The rule against aliasing in Fortran doesn't hurt it because all arrays are 'flat' to begin with. If C had a way of declaring 'flat' arrays dynamically (like Fortran 8x and most large Fortran environments have) it wouldn't need 'noalias' either. (I declare dynamic arrays in Fortran all the time. It's non-standard, but it can be done in some way on all systems I now use.) To be sure, Fortran probably needs some way of allowing aliasing. But I think it should be with an explicit user request (an ALIAS statement) rather than the default assumed. Most frequently, aliasing is accidental, deliberate aliasing is comparatively rare. The rare usage is the one that should require extra oversite from the user. (And C DOES need 'noalias' in order to get a functionality that is otherwise difficult. A directive which gives extra flexibility to the user without an undue burden on those that don't use it is not really damaging to the language.) > [...] When > something is convenient, it gets used; when it is inconvenient enough, > it does not get used (for instance, I never use Fortran [*]). Hmm.... That's just exactly the reason that I rarely use C. > [*] Bet you took this one wrong! Instead, when I must, I use Ratfor. :-) Hmm.... I don't use RATFOR either (at least not for many years - it produces TERRIBLE code). Still, I would like a version of Fortran which allowed INTERNAL procedures - the ONLY useful item in RATFOR. > [...] This > gives a slight advantage to the flat-plus-row-vector version: when > speed is unimportant (or when your compiler is smart enough), use the > convenient row-vector access a[j][i]; when you have to play tricks to > convince the compiler to vectorise, use the inconvenient flat acess > a[0][j*m + i]. This last is just the sort of thing that simplistic compilers have trouble vectorizing. The statement: arr[4][i] = arr[5][i] turns into: *(M+i) = *(N+i) where M and N are the result of constant folding (of the array address and the product of the dimension size with either 4 or 5 respectively). If this is in a loop on i, the first version (with the syntax clearly displayed) is obviously free of dependencies. The second version requires additional calculation from the compiler to determine dependencies. In a more complicated expression, this additional work may be beyond the ability of the compiler. The rumor is that this very example killed the early Cray compiler (ie. the compiler incorrectly identified it as a dependency). Actually, I have no idea whether the Cray C compiler does this correctly even now - even for statically allocated arrays. It seems very strange to support a 'feature' which requires you to make dependency analysis harder in order to vectorize at all. J. Giles Los Alamos