Xref: utzoo comp.lang.fortran:822 comp.lang.c:10963 Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!purdue!umd5!brl-adm!cmcl2!lanl!beta!jlg From: jlg@beta.lanl.gov (Jim Giles) Newsgroups: comp.lang.fortran,comp.lang.c Subject: Re: Should I convert FORTRAN code to C? Keywords: language conversions, complex, 2-d arrays Message-ID: <20454@beta.lanl.gov> Date: 28 Jun 88 08:43:12 GMT References: <2742@utastro.UUCP> <20008@beta.UUCP> <224@raunvis.UUCP> <1189@mcgill-vision.UUCP> Organization: Los Alamos National Laboratory Lines: 66 In article <1189@mcgill-vision.UUCP>, mouse@mcgill-vision.UUCP (der Mouse) writes: > In article <20340@beta.lanl.gov>, jlg@beta.lanl.gov (Jim Giles) writes: > > The Problem is that 2-d arrays are not optimizable because they are > > immediately turned into pointer-to-pointer-to-data type of > > constructs. > > Real 2-d arrays turn into pointer-to-array, not pointer-to-pointer. If > you have one of these dynamically-allocated arrays that have been > bandied about, which is really an array of pointers to blocks of data, > *that* is pointer-to-pointer. I'm sorry. To me a 2-d array is a 2-d array is a 2-d array is a .... Any routine that gets a 2-d array as an argument must assume that it is either static (which restricts you one way), or it must assume that it is dynamic (in which case it IS a pointer-to-pointer etc.). This means that you can't write a general routine which takes a 2-d array as an argument. This is EXACTLY the sort of problem that I meant originally when I said that C didn't have the concept of multi-dimensional arrays in the language. By the way, I've not seen any C compilers which optimize static 2-d arrays anyway. An early step in the compiler usually turns the array reference into a linear function on the indices - this throws out the dependency information. As a result, very similar code is actually generated whether the array was statically or dynamically allocated. C gives you the worst of both worlds - you can't treat them the same in source, and you can't get better optimization out of them in object code. > [...] > > type. Complex is more than just a pair of reals, [...] > > It's both more and less powerful. To put it another way, FORTRAN's > COMPLEX data type is NOT an adequate replacement for the ability to > define custom data types. I never claimed it was. To repeat: the ability to define derived data types, and the operations thereon, is very useful and Fortran SHOULD have it. This has NOTHING to do with the debate about whether COMPLEX should be built-in. It has NOTHING to do with the fact that C cannot do COMPLEX as efficiently as Fortran. > > > No use of C programming constructs can do this: [FORTRAN example] > > C provides no way to even do this calculation without function calls. > > Sure it does, it just takes a little more code than the FORTRAN > example. [... This 'little more code' that you're talking about does less than you think. Because COMPLEX is built-in to Fortran, the compiler writer is free to use his knowledge about the semantics of COMPLEX in designing optimizations. Whereas your 'little more code' spells out a specific sequence of operations to simulate complex artithmetic, the Fortran compiler is free to choose from all mathematically equivalent sequences for the most efficient one. User definable data types are useful, but commonly used data types should be built-in. > ...] But that's a strawman anyway. For every such example, I can > write one in C that FORTRAN similarly "can't" do. Please feel free to do so when someone asks the question: 'Should I convert C code to Fortran?' Why do you consider a direct answer to a question to be a 'strawman'? Or didn't you read the "subject" line on this article. J. Giles Los Alamos