Should I convert FORTRAN code to C?

[Steven Ryan]

>Not always - besides, do you really think the prologs have:
>	if (stack is odd)
>		align it
>	??
>
>>because somebody it calls may use the stack. 

On a previous machine I used, yes, the stack had to be kept at even word
boundary at all times.

>Some C (and other langs) compilers optimize a lot of function prolog and
>epilog stuff out.  Prolog and epilog for C code is usually not
>noticable (compared to, say IBM 360 series FORTRAN).

The compiler is cheaper if it never existed in the first place. I suspect
part of the size of prolog goes for adjustable arrays.

>Also, what's so bad about stacks?  Many machines can do some stack
>references faster than static - sufficient in many cases to greatly outweigh
>the calling convention.

I think this a base register+offset compared to a constant offset, which should
be avoiding in any case because it makes the code nonreentrant. Again, on the
previous machine I used, all data references were base register+offset so that
no time/space difference existed. Then again, if you want to consider a machine
designed for C, would you also consider a machine designed for fortran.

>So, blanket statements like "automatic variables are a lot of overhead"
>are frequently wrong - frequently they are *less* overhead.

All that is being compared is addressing modes.

>>However convenient it might be, recursion is not strictly necessary 
>>in practical
>
>Nobody is saying "recursion is necessary" - it's occasionally a handy
>tool to simplify some problems.  That's all.

For most problems, recursion is the most natural technique for me. Most times
I use loops is because compilers don't do recursion removal and most languages
make it difficult to define procedures.

Data structures also simplify many problems. The challenge is to design a
language as fast as Fortran but a shade more advanced (by about 30 years).

Fortran users are conservative and are already pushing their machines to the
limit. I have seen compiler complaints, not that the code is wrong, but that
uses one extra instruction.

>Ah yes, but static memory allocation usually lead to programs that
>are bigger - taking *longer* to load (usually on swapping systems).  

Unix has a disgusting loader, but this is not really a language issue. Also,
once loaded, a program may be run many times. In this case, a longer load
is offset by a shorter run.

>Without stacks and/or dynamic storage allocation programmers usually don't
>have the ability to decide how much memory he needs depending on the data -
>another potential optimization loss (the program's data structure has
>to be as large as the largest set of data, rather than being able to
>start smaller and make it bigger if necessary).

Some C programmers don't seem to notice--see previous complaints about Yacc.