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