Xref: utzoo comp.lang.fortran:915 comp.lang.c:11339 Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!decvax!watmath!atbowler From: atbowler@watmath.waterloo.edu (Alan T. Bowler [SDG]) Newsgroups: comp.lang.fortran,comp.lang.c Subject: Re: Should I convert FORTRAN code to C? Message-ID: <19890@watmath.waterloo.edu> Date: 14 Jul 88 23:40:06 GMT References: <2742@utastro.UUCP> <20008@beta.UUCP> <224@raunvis.UUCP> <750@garth.UUCP> <528@philmds.UUCP> <817@garth.UUCP> Reply-To: atbowler@watmath.waterloo.edu (Alan T. Bowler [SDG]) Organization: U. of Waterloo, Ontario Lines: 22 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 >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. > Then again depending on the machine archetecture, access to something mapped to a stack frame may be cheaper and faster than statically allocated memory. It depends on the addressing mechanisms of the machine, and the skill of whoever does the stack design and call/return mechanism. The blanket statement that stack accesses were more expensive than static memory accesses was true in the past, but stopped being universally true sometime in the 1960's. As hardware caches become more important, and as addressing extensions are added to increase the address space of existing architectures, the tradoff between stack and static allocation changes.