Xref: utzoo comp.lang.fortran:838 comp.lang.c:10996 Path: utzoo!yunexus!spectrix!clewis From: clewis@spectrix.UUCP (Chris "where are you this week?" Lewis) Newsgroups: comp.lang.fortran,comp.lang.c Subject: Re: Should I convert FORTRAN code to C? Message-ID: <701@spectrix.UUCP> Date: 30 Jun 88 16:43:05 GMT Article-I.D.: spectrix.701 References: <2742@utastro.UUCP> <20008@beta.UUCP> <224@raunvis.UUCP> <750@garth.UUCP> <528@philmds.UUCP> <817@garth.UUCP> Reply-To: clewis@spectrix.UUCP (Chris "where are you this week?" Lewis) Organization: Spectrix Microsystems Inc., Toronto, Ontario, Canada Lines: 86 In article <817@garth.UUCP> smryan@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@lsuc afterwards) UUCP: {uunet!mnetor, utcsri!utzoo, lsuc, yunexus}!spectrix!clewis Moderator of the Ferret Mailing List (ferret-list,ferret-request@spectrix)