Xref: utzoo comp.lang.fortran:864 comp.lang.c:11076 Path: utzoo!attcan!uunet!husc6!mailrus!cornell!uw-beaver!teknowledge-vaxc!sri-unix!garth!smryan From: smryan@garth.UUCP (Steven Ryan) Newsgroups: comp.lang.fortran,comp.lang.c Subject: Re: Should I convert FORTRAN code to C? Message-ID: <850@garth.UUCP> Date: 1 Jul 88 20:18:41 GMT References: <2742@utastro.UUCP> <20008@beta.UUCP> <224@raunvis.UUCP> <750@garth.UUCP> <528@philmds.UUCP> <817@garth.UUCP> <701@spectrix.UUCP> Reply-To: smryan@garth.UUCP (Steven Ryan) Organization: INTERGRAPH (APD) -- Palo Alto, CA Lines: 63 >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.