Processors who's stack grows up

Jim Stewart <jstewart@jkmicro.com> writes:

> I believe a pdp 8 did the same thing.  The return was an indirect
> jump to the first word.

Yes,

SUBR:   +0
        ...
        JMP I SUBR

(we only had ASR33s, no idea if PAL III would have accepted lower
case!)


-- 
Simon Wright                               100% Ada, no bugs.

"Dick Wesseling" <free@securityaudit.val.newsbank.net> wrote:
> "Nicholas O. Lindan" <see@sig.com> writes:
> >
> > The

"A traditional ..." would have been a better choice of words.

> > traditional method (like we got traditions in computer design)
> > of returning from subroutines was by forming a linked list.  Sometimes
> > 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.
> 
> You are probably referring to the CDC. It would write a jump back
> to the caller at the *first* word of the callee and begin execution
> at the 2nd word.

I should not these methods are all software implementations.  Where 
the return address and parameters are stored in older [and some newer]
machines is a matter of software convention.

Whirlwind, CDC, PDP-8 ... methods can be used on [almost] any processor.
PPP [People who Program Pics] know of even more bizarre methods.

-- 
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
Remove spaces etc. to reply: n o lindan at net com dot com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/

Nicholas O. Lindan wrote:
> 
> Whirlwind, CDC, PDP-8 ... methods can be used on [almost] any processor.
> PPP [People who Program Pics] know of even more bizarre methods.
> 

Plenty of the PIC bizarrities are directly from the minis
of the sixties: PDP-8, HP-2116, Honeywell DDP-312 and
DDP-516 & co.

----

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.

-- 

Tauno Voipio
tauno voipio (at) iki fi

"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.

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

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.

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
 

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 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            

"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