Should I convert FORTRAN code to C?

[Chris "where are you this week?" Lewis]

In article <817 at garth.UUCP> smryan at garth.UUCP (Steven Ryan) writes:
>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

Not always - besides, do you really think the prologs have:
	if (stack is odd)
		align it
	??

>because somebody it calls may use the stack. 

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).  Especially
interesting is that FORTRAN subroutines tend to be far larger than C
ones.  This is frequently due to people learning FORTRAN on IBM 360
series stuff where the prologs and epilogs are enormous in time and 
space - I've worked (internals) on an 360 series version of C that 
used it's own super simple calling convention - ran considerably faster
(even tho 360's don't have stacks!).

C's calling convention is actually absurdly simple - usually little 
more than saving the return address and some registers (register
variables and temporaries) and decrementing the stack and then 
restoring same at the end.  Unlike most Pascals (or ADA for that 
matter) which frequently have some rather spectacular stack frames 
formats to handle.

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.  Eg: short stack offset instructions on 386, 
68020, VAXen(?) etc. are as short as two bytes instead of six for 
static - which at least saves you some additional memory fetches (which
are usually far more expensive than register adds) and your pipelining
gets to help a little more.  Eg: on a 68020, these are some representative
timings (in cycles):

			Best case	Worst case
	mov Rn,-(SP)	3		6
	mov Rn,n(SP)	3		7
	mov Rn,addr.L	5		9
	mov n(SP),m(SP)	6		13
	mov a.L,b.L	8		16

Similarly, for expression intermediaries, machines with short stack
offsetting modes can be a big win, and are usually less wasteful of
memory than most static memory schemes (unless you have a million 
registers ;-).

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

I've done some fairly substantial compiler benchmarking, and have noted
that auto variables are usually faster than static (depending on the
circumstances and the CPU).

>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.  I almost never use it in
C - but I do sometimes, and I'd greatly miss it in a language that doesn't
support it (I'd probably say "Oh sh*t - not another FORTRAN!" ;-).

>>                                                       (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.

Ah yes, but static memory allocation usually lead to programs that
are bigger - taking *longer* to load (usually on swapping systems).  
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).  And the stack model is 
especially convenient for "deep returns" (use of setjmp/longjmp to be able to 
conveniently recover from errors way down a subroutine tree - have you 
ever seen the insides of Oracle?  Sheesh!).
-- 
Chris Lewis, 
These addresses will last only til June 30: (clewis at lsuc afterwards)
UUCP: {uunet!mnetor, utcsri!utzoo, lsuc, yunexus}!spectrix!clewis
Moderator of the Ferret Mailing List (ferret-list,ferret-request at spectrix)