Paul Keinanen <keinanen@sci.fi> writes:
>mojaveg@mojaveg.iwvisp.com (Everett M. Greene) wrote:
> 
> >Fortran not supporting recursion is an industry myth
> >probably a side-effect of early implementation techniques.
> >There is nothing in the ANSI Fortran standard 
> 
> That may be the case with Fortran 77 and later versions, but I was
> referring to Fortran II and Fortran IV.
> 
> >which
> >precludes a stack-oriented implementation thus allowing
> >recursion.
> 
> If you put the local variables into a stack, it would break quite a
> lot old Fortran programs (including some widely used library code)
> that assume that the local variable values are maintained between
> calls.

I just said the standard doesn't preclude reentrancy.

Since the standard doesn't define the behavior, different
programs written for different implementations may rely on
the behavior of a particular implementation.

On Wed, 19 Jan 2005 09:27:34 PST, mojaveg@mojaveg.iwvisp.com (Everett
M. Greene) wrote:

>Fortran not supporting recursion is an industry myth
>probably a side-effect of early implementation techniques.
>There is nothing in the ANSI Fortran standard 

That may be the case with Fortran 77 and later versions, but I was
referring to Fortran II and Fortran IV.

>which
>precludes a stack-oriented implementation thus allowing
>recursion.

If you put the local variables into a stack, it would break quite a
lot old Fortran programs (including some widely used library code)
that assume that the local variable values are maintained between
calls.

Paul
 

In comp.arch.embedded Everett M. Greene <mojaveg@mojaveg.iwvisp.com> wrote:

> Fortran not supporting recursion is an industry myth probably a
> side-effect of early implementation techniques.  There is nothing in
> the ANSI Fortran standard which precludes a stack-oriented
> implementation thus allowing recursion.

You're missing the point, I think.  The fact that the Fortran standard
doesn't preclude a stack-based implementation allowing allow
recursion, by no means implies that Fortran "supports recursion".  To
back up a claim that Fortran (as such, rather than a particular
implementation) supported recursion, the language standard would have
to *enforce* that it's possible.  I'm quite sure it doesn't

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

"Everett M. Greene" <mojaveg@mojaveg.iwvisp.com> wrote in message
news:20050119.79EFC40.8B9E@mojaveg.iwvisp.com...
> Paul Keinanen <keinanen@sci.fi> writes:
> > On Sun, 16 Jan 2005 16:56:34 -0500, "mc" <mc_no_spam@uga.edu> wrote:
> > >Interesting.  I knew of the Control Data XJ (Exchange Jump).
> > >
> > >In those days there was almost no recursion.  As recently as 1980,
recursion
> > >was an "advanced" technique that ordinary programmers weren't expected
to
> > >master.
> >
> > IMHO, recursion is highly overrated, some people even want to convert
> > a simple loop to a recursion :-).
> >
> > Languages which were commonly used in 1960/70, such as Cobol and
> > Fortran did not even support recursion. This caused some problems in
> > some very rare cases .e.g. when evaluating complex arithmetic
> > expressions with complex function parameter list, but it is
> > definitively doable, while of course this would be easier to do with
> > recursion.
>
> Fortran not supporting recursion is an industry myth
> probably a side-effect of early implementation techniques.
> There is nothing in the ANSI Fortran standard which
> precludes a stack-oriented implementation thus allowing
> recursion.

 I just proted a compile and virtual machine write in fortran in the early
70's that ran on a PDP11. both the compiler and the virtual machine handled
recursion.
Pat

On 2005-01-19, Everett M. Greene <mojaveg@mojaveg.iwvisp.com> wrote:

>>>In those days there was almost no recursion.  As recently as
>>>1980, recursion was an "advanced" technique that ordinary
>>>programmers weren't expected to master.
>> 
>> IMHO, recursion is highly overrated, some people even want to
>> convert a simple loop to a recursion :-).

Recursion aside, it's re-entrancy that really matters. I
suppose if the OS doesn't support multiple processes, then that
doesn't matter either.

-- 
Grant Edwards                   grante             Yow!  It's OKAY -- I'm an
                                  at               INTELLECTUAL, too.
                               visi.com            

Paul Keinanen <keinanen@sci.fi> writes:
> On Sun, 16 Jan 2005 16:56:34 -0500, "mc" <mc_no_spam@uga.edu> wrote:
> >Interesting.  I knew of the Control Data XJ (Exchange Jump).
> >
> >In those days there was almost no recursion.  As recently as 1980, recursion 
> >was an "advanced" technique that ordinary programmers weren't expected to 
> >master.
> 
> IMHO, recursion is highly overrated, some people even want to convert
> a simple loop to a recursion :-).
> 
> Languages which were commonly used in 1960/70, such as Cobol and
> Fortran did not even support recursion. This caused some problems in
> some very rare cases .e.g. when evaluating complex arithmetic
> expressions with complex function parameter list, but it is
> definitively doable, while of course this would be easier to do with
> recursion.

Fortran not supporting recursion is an industry myth
probably a side-effect of early implementation techniques.
There is nothing in the ANSI Fortran standard which
precludes a stack-oriented implementation thus allowing
recursion.

On Sun, 16 Jan 2005 16:56:34 -0500, "mc" <mc_no_spam@uga.edu> wrote:

>"Tauno Voipio" <tauno.voipio@iki.fi.NOSPAM.invalid> wrote in message 
>news:N0BGd.698$ar4.124@read3.inet.fi...
>
>> The method of storing the return address at the
>> subroutine entry location and starting the execution
>> at the next instruction was an industry standard
>> in the minis of those times. The notable exceptions
>> were Data General Nova and Digital PDP-11 which
>> stored the return address in a register.

While it is technically correct to say that PDP-11 stored in the
return address in a register and it was also used extensively in some
older code when using R0 .. R5 as the link register, in which case it
was easy to use the link register to access the in-line parameters.
However, some compiler generated code pushed the parameters on the SP
stack and then called the subroutine, using the PC as the link
register, which effectively pushed the return address on top of the
stack, thus creating a pure stack architecture.

>Interesting.  I knew of the Control Data XJ (Exchange Jump).
>
>In those days there was almost no recursion.  As recently as 1980, recursion 
>was an "advanced" technique that ordinary programmers weren't expected to 
>master.

IMHO, recursion is highly overrated, some people even want to convert
a simple loop to a recursion :-).

Languages which were commonly used in 1960/70, such as Cobol and
Fortran did not even support recursion. This caused some problems in
some very rare cases .e.g. when evaluating complex arithmetic
expressions with complex function parameter list, but it is
definitively doable, while of course this would be easier to do with
recursion.

In high reliability systems (which are often discussed in these
newsgroups), it is not acceptable that the thread/process stack would
_ever_ overflow. If recursion is used on such systems, there must be a
well defined absolute maximum number of recursions that can occur, in
order to fit into the allocated stack. 

For instance walking through a binary tree with a recursive routine is
nice, but what if the binary tree is due to the creation order
actually a simple linear linked list, then the levels of recursions is
the same as the number of elements in the linked list. With a large
stack frame in the recursive routine, the stack size requirement can
be larger than the size of the linked list. 

Thus, in order to use a recursive binary tree routine, some
precautions must be done to reorganise (balance) the tree to avoid
such pathological cases as the binary tree becoming a linear linked
list, before calling the recursive binary tree walker routine.

Paul
 

In article <41e9df9b$0$82339$a1866201@visi.com>,
	Grant Edwards <grante@visi.com> writes:
>
> I remember that from the days not so long ago when the UofMinn
> used to torture students by making them program on a 6600.  I
> always wondered how one did recursion or re-entrancy on a 6600,

That was done in software. The prelude of the called function would
save the value written by the return jump on the (software) stack.

In article <7KwGd.698$Rs.117@newsread3.news.atl.earthlink.net>,
	"Nicholas O. Lindan" <see@sig.com> writes:
> "Dick Wesseling" <free@securityaudit.val.newsbank.net> wrote
>> "Nicholas O. Lindan" <see@sig.com> writes:
>> >
>> > by such subtle methods as writing a JMP instruction to the caller's
>> > "return-to" address at the end of the called subroutine -
>> 
>> That would require the caller to know the end of the subroutine.
>  
> And?  The caller has to know the entry point, yah?  Knowing the
> exit point is somehow interdict?

I figure that having to know both the entry point and the exit
point is twice as much work as having to know the entry point
only, but ...

>> You are probably referring to the CDC.
> 
> No, I am not.  Why, because as you so state:
> 
>> [A CDC mainframe] would write a jump back
>> to the caller at the *first* word of the callee and begin execution
>> at the 2nd word
> 
> This was an improvement, for modern day dilettantes.

.. I stand corrected

"Tauno Voipio" <tauno.voipio@iki.fi.NOSPAM.invalid> wrote in message 
news:N0BGd.698$ar4.124@read3.inet.fi...

> The method of storing the return address at the
> subroutine entry location and starting the execution
> at the next instruction was an industry standard
> in the minis of those times. The notable exceptions
> were Data General Nova and Digital PDP-11 which
> stored the return address in a register.

Interesting.  I knew of the Control Data XJ (Exchange Jump).

In those days there was almost no recursion.  As recently as 1980, recursion 
was an "advanced" technique that ordinary programmers weren't expected to 
master.