blaine (myname.delete@this.acm.org) on March 21, 2021 12:55 pm wrote:
> rwessel (rwessel.delete@this.yahoo.com) on March 21, 2021 11:34 am wrote:
> > rwessel (rwessel.delete@this.yahoo.com) on March 21, 2021 11:26 am wrote:
> >
> > > Wasn't the come-from instruction/statement defined by a (humorous) Datamation article
> > > back in the 70s, as a response to the structured "goto-less programming" proponents.
> >
> > Datamation, December 1973:
> >
> > https://web.archive.org/web/20180716171336/http://www.fortran.com/fortran/come_from.html
>
> Since I graduated in '73 perhaps this is a case of early onset cryptomnesia (the scourge of inventors)
>
> Mine used a come-from stack that compared the top of stack to the pc and returned to the top of the
> loop (stored on the stack along with the come-from address). It would have been great for handling
> COBOL perform statements since you could in theory perform code from any paragraph(?, think block).
> So an arbitrary paragraph might drop thru or return to a point after an invoking perform. Performs
> were sort of parameter-less subroutine calls, where the subroutine was any arbitrary group of paragraphs.
> If I screwed up the description, it was a result of time and trying to forget COBOL.


I could certainly see how you could consider PERFORM A THRU B as roughly equivalent to [GOTO A, COMEFROM (the end of) B].

But yes, that executed an arbitrary sequential group of paragraphs (with some slight differences if sections were involved).

The typical implementation stored a pointer for the end of each paragraph, where the paragraph would branch to after completing, and that pointer would get reset to "next paragraph" each time it was hit. Obviously this played heck with any notion of recursion.

Unfortunately neither of us appears to have managed to forget enough Cobol yet...