Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site bu-cs.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!bu-cs!root From: root@bu-cs.UUCP (Barry Shein) Newsgroups: net.lang Subject: Re: What language do you use for scientific programming? Message-ID: <605@bu-cs.UUCP> Date: Sat, 24-Aug-85 02:19:13 EDT Article-I.D.: bu-cs.605 Posted: Sat Aug 24 02:19:13 1985 Date-Received: Sun, 25-Aug-85 02:14:20 EDT References: <909@oddjob.UUCP> <163@ho95e.UUCP> <367@ttrdc.UUCP> <1612@watdcsu.UUCP>, <371@ttrdc.UUCP> Organization: Boston Univ Comp. Sci. Lines: 66 (Re: Recursion in F77) >From: levy@ttrdc.UUCP (Daniel R. Levy) >Subject: Re: What language do you use for scientific programming? >I presume this adds to the number-crunching efficiency when >recursion is disallowed since there would need be no provision for stuffing the >old variables on the stack and reinitializing them upon calling an already >called procedure, and restoring them when the call returns. Unix f77 and >(I believe) VMS Fortran allow for this. This idea that recursion is inefficient for speed is a common and by and large completely wrong idea, given any reasonable machine architecture. Look at the code generated by a UNIX C compiler and how it addresses automatic variables, they are just memory references relative to the stack, when they are register variables it is true, they must be stored on *any* call if the registers might be used in the called routine(s), recursive or not. All stack relative addressing requires for efficiency is some sort of base+displacement architecture. The IBM 360/370 series has no hardware stack, but again this does not in any way detract from recursive coding, a perusal of ASM code from a 370 C is instructive. One protest against recursion was the inability to predict the potential depth of the stack, a simple compile-time analysis can not determine this in general as it usually depends on termination conditions rather than who calls whom. Back when cars had fins (ie. the days of Fortran) memory was generally allocated on a system at job initiation time (eg. MVT) and it was important to be able to predict the maximum memory your job needed. Things like malloc() [via sbrk()] would have been only in the domain of true system hackers, not application programmers. Recursion defied these schemes for the general case, about all you could do was allocate for the worst case. An important feature of UNIX from its V6 days (on) was its silent expansion of the user's stack region, typically growing down towards the data area (though not necessarily.) This was handled by recognizing that an illegal memory reference by the user was due to a stack relative reference beyond the currently allocated stack. Rather than raising the typical signal (Segmentation Violation or whatever) it just allocated more stack and re- scheduled the job. This of course did cause slight interruptions in the running of a program, though generally the chunks allocated were big enough that a program rarely faulted. Other systems (not IBM) at least had a provision for requesting some amount of stack space separate from other requests. At any rate, the point is, the protest is not against speed, but rather memory predictability (given enough memory to start this becomes less important, remember, when Fortran was important time-sharing systems had 64K of memory, big ones maybe 256K, that was for everyone!) So, the resistance to recursion by Fortran is historical. At this point many Fortran coders consider a reference to a function by the same function an error, so they may see allowing recursion as removing a desired error message. I also suspect it is just some backwards compatibility hold-out. Oh, another important point, on most pre-F77 fortrans variables were all *static*, when a routine was re-entered it was not unusual for a program to assume the values of variables were as they were left the last time the routine was exited. Fortran had no way of specifying a static versus automatic variable (except, perhaps, by abuse of common). Recursion requires this distinction for any real usage. If all variables were suddenly made automatic I am sure there is a fear that all the promised forwards compatibility from F66->F77 would be lost as many programs would mysteriously fail (eg. many many user written rand() routines.) -Barry Shein, Boston University