Should I convert FORTRAN code to C?

[Steven Ryan]

>So what IS FORTRAN's game?

Running big huge numerical models like a bat out of hell. Watching people
getting bigger and faster computers is like watching a heroin addict:
more! more! MORE!

People who say nasty things about fortran are right, but what have they to
offer?

>A few remarks:
>A C programmer can CHOOSE (note: uppercase 8-) whether he wants arrays
>to be global, static or automatic.

By only offering static allocation, the compiler does not have to support
any overhead at all. A C program must keep the stack pointer correctly
aligned and rest of the protocol straight even if it doesn't use the stack
because somebody it calls may use the stack. Similarily, in supporting
recursion, the stack has to be maintained in case some called program needs
the stack. Further, supporting recursion means all automatic variables must
be mapped into the stack because the procedure may recurse indirectly.
Forbidding recursion means the compiler can map automatic variables into
static areas.

However convenient it might be, recursion is not strictly necessary in practical
programs. In some numeric models, it would actually be inconvenient. This is
another case where fortran gives up something of questionable value (for them)
to simplify optimisation. (However, we can always use a transitive closure
which takes (?)cubic time to detect recursion, but most customers would
rather a fast compiler.)

>                                                       (zero overhead is
>rubbish; you always have to page or swap the data in, whether you use data
>/heap space or stack space, or you at least have to claim core).

Pagein cost vs. pagein + computation cost.

>                                             procedure frame are more
>or less for compiler builders: you can do without them, making it much
>harder for yourself

Unless it is impossible for a procedure to recurse, directly or indirectly,
local variables must be mapped onto the stack. You cannot avoid this
overhead without avoiding recursion.

>                                Dropping off these things (call, push ..)
>can only gain a few percent, at what other cost (inflexible subroutine
>scheme, permanent variables)? You can even totally rule out any use of
>subroutines if you're out for speed: large monolotic blocks with many
>pieces of repeated code, is that desirable?

Unfortunately--some people do find that desirable. As far as few cycles, look
back a few weeks when somebody said a C function should make the argument
list length available. Many jumped on the poor guy because they didn't
want their code to waste the single instruction necessary to load a register.

Please, don't suggest I want speed or I find this desirable. My favorite
compiler was an Algol60 compiler. I never turned off array bound checks or
switch range checks. I think call-by-name (real call-by-name with deferred
execution and not wimpy call-by-reference) is fun. The compiler permitted
assembly procedures to have variable length lists. The calling protocol
gave the parameter list length and a descriptor with type and kind for each
element in the list. And the address of dope vector was passed along.

>>Apparently some Fortran programmers equivalence different typed arrays to
>>create structures (shudder).

Some fortran programmers use the EQUIVALENCE statement to adjust the
beginning address of different arrays with different types so that 
they map their elements into interleaved storage. Don't know details--just
heard about some of things they do just to stay in fortran. Like using
blank common as a heap.