Should I convert FORTRAN code to C?

[Jim Giles]

In article <1189 at mcgill-vision.UUCP>, mouse at mcgill-vision.UUCP (der Mouse) writes:
> In article <20340 at beta.lanl.gov>, jlg at 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