5

This question has been prompted by a recent question about the assigned GOTO operator.

It appears that some early FORTRAN implementations supported a non-obvious construct: using an indexed variable in the ASSIGN operator and the GOTO operator, e.g.

ASSIGN 10 TO IGO(K)
...
GOTO IGO(K)

This allowed to mimic recursive functions (with appropriately managed local variable frame, if needed) even on platforms with no call stack.

The following program compiles and executes correctly on PDP-11 UNIX V5:

Paul Nankervis - paulnank@hotmail.com

Boot> boot rk0
@unix


login: root


chdir /tmp


cat > fact.f


  integer st(100),ptr,f
  ptr=1
  n=10
  assign 10 to st(ptr)
  goto 100



10 print 1,n,f
    1 format(' factorial of ', i2, ' is ', i10)
      stop
  100 print 2,n
   2  format(' called: factorial of ', i5)
      if (n.gt.1)goto 101
      f = 1
      goto st(ptr)
  101 n=n-1
      ptr=ptr+1
      assign 102 to st(ptr)
      goto 100
  102 continue
      print 3,n,f
    3 format(' fact(',i2,') =', i10)
      ptr=ptr-1
      n=n+1
      f=f*n
      goto st(ptr)
      end


fc fact.f


./a.out


called: factorial of    10
 called: factorial of     9
 called: factorial of     8
 called: factorial of     7
 called: factorial of     6
 called: factorial of     5
 called: factorial of     4
 called: factorial of     3
 called: factorial of     2
 called: factorial of     1
 fact( 1) =         1
 fact( 2) =         2
 fact( 3) =         6
 fact( 4) =        24
 fact( 5) =       120
 fact( 6) =       720
 fact( 7) =      5040
 fact( 8) =     40320
 fact( 9) =    362880
 factorial of 10 is    3628800

(an aside: allowing quoted strings instead of Hollerith style had been an early enhancement, apparently)

A BESM-6 FORTRAN compiler, directly derived from the CDC 1604 compiler, accepts the code and produces an identical result. A newer (post-1977) BESM-6 compiler rejects it.

G77 rejects the code as well:

fact.f:4: 
         assign 10 to st(ptr)
                      ^
Expression at (^) has incorrect data type or rank for its context

It looks like when FORTRAN was being standardized, the syntax was tightened.

The question is: Was the liberal reading of the syntax, allowing assigning labels to array elements, an "official" one, that is, originated by IBM, or was it an unrelated initiative, adopted by competing vendors (at least DEC and CDC)?

Leo B.
  • 19,082
  • 5
  • 49
  • 141
  • Is there a DEC (not Unix) PDP-11 FORTRAN compiler with this extension? By personal testing, the DEC F77 compiler on RSX-11M+ rejects subscripts on ASSIGN and assigned GOTO, but then, it's post-standardization. – dave Aug 27 '20 at 01:36
  • @another-dave By F77, the requirement that an assigned label must be a simple variable appears to be well-standardized (having been formulated in the Fortran 66 standard), so it has to be an older compiler. On the emulator page, I've tried RT11 and Ultrix, neither seems to include a Fortran compiler. – Leo B. Aug 27 '20 at 05:03
  • Later DEC PDP-11 documentation has a single FORTRAN language manual for multiple operating systems, so I assume the compiler core is common. If any compiler has the extension, it will be pre-F77. I vaguely recall RSX/IAS compilers called FOR and F4P. But perhaps the PDP-11 question is moot, since @WalterMitty has found PDP-10 documentation with the extension to subscripted variables. – dave Aug 27 '20 at 12:32

3 Answers3

6

I can't say whether IBM invented this extension or even whether any IBM compiler ever supported it, but at least as of the IBFTC FORTRAN IV compiler for IBSYS version 13 (manual dated 1968), subscripted variables were explicitly prohibited in an ASSIGN.

Assuming the vendor's documentation to be accurate :-)

A System/360 FORTRAN IV manual says the same thing (see page 32). As does this 1982 manual for S/370 - page 46.

dave
  • 35,301
  • 3
  • 80
  • 160
  • Lots of old IBM documents (including FORTRAN for the 704) at www.softwarepreservation.org/projects/FORTRAN. All those I have looked at require a 'non-subscripted' variable. – Ian Thompson Aug 26 '20 at 22:45
  • I was poking around bitsavers, and the IBM manuals I looked at all say the same. – dave Aug 26 '20 at 22:48
  • 3
    Back then, compiler writing was more an art than a science, so it's possible something like this "worked by accident" and programmers discovered it whether or not it was documented. There was definitely an attitude back then that the compiler itself defined the language, not the compiler documentation! – alephzero Aug 26 '20 at 23:04
  • Though by similar argument, one might expect the documentation to report whatever the compiler happened to allow. – dave Aug 27 '20 at 00:06
  • 1
    @alephzero I have an example of a compiler where it does not work by accident: the index in ASSIGN is ignored, as if st(1) had been written, and the GOTO requires a label list (it wants to see a comma is there is a parenthesis in an assigned GOTO), and also ignores the index. The fact that two independently written (I presume) compilers both accept the pattern and compile it properly makes me think that it is not an accident. – Leo B. Aug 27 '20 at 00:09
  • @another-dave The Fortran 66 standard says "integer variable name" (7.1.1.3), but the PDP-11 compiler clearly post-dates the standard, so the "extension" is likely deliberate. – Leo B. Aug 27 '20 at 00:26
  • Ditto for FORTRAN-77 – dave Aug 27 '20 at 00:41
4

DEC PDP-10 Fortran documentation says the target of an assigned go to can be a variable or an array element. It sounds like it would allow the construct discussed in this question.

see manual

This edition of the manual is dated 1972.

Walter Mitty
  • 6,128
  • 17
  • 36
2

The 1966 ANSI standard X3.9-1966 ANSI standard (https://wg5-fortran.org/ARCHIVE/Fortran66.pdf) just says

A GO TO assignment statement is of the form

ASSIGN k to i

where k is a statement label and i is an integer variable name.

so anything other than an integer variable name would have been an extension to Fortran 66.

From the compiler writer's point of view, whether to allow an extension or not would depend on the the syntax of the assigned goto. If it is defined as (Lahey, Fujitsu, ICL)

GOTO assign-variable [[,] (labels)]

It would mean that the comma was optional, so

GOTO st(10)

could mean goto ST and label 10 was one of the options or goto the label pointed to by ST(10). The problem is not really in the ASSIGN statement but in the GOTO. If the comma is compulsory i.e.

GOTO assign-variable [, (labels)]

then it shouldn't be a problem. Once you've gotten over that hurdle, it is quite easy to extend the language to allow assignment of labels to array elements.

OFF TOPIC

The other common use of assigned labels is in format statements. eg

ASSIGN 10 to COORD
...
WRITE(1, COORD) X, Y, Z

Bending the rules a bit, COORD could live in a common block and subroutines could use the same write statement and only have the FORMAT statement defined in one place.

cup
  • 2,525
  • 1
  • 9
  • 21
  • Only statement labels could be assigned using ASSIGN operators. Some early implementations (namely, the CDC 1604 one) had separate scopes for statement and format labels, so that PROGRAM MAIN<nl> 1 PRINT 1<nl> 1 FORMAT(’ GOTCHA’)<nl> END could be written. It works. – Leo B. Aug 27 '20 at 21:47
  • Using arrays in place of format labels was in the standard (see 7.1.3), obviating the need to assign format labels to variables. For example, a quine (self-printing program) could be written as in http://mailcom.com/besm6/runitnew.cgi (click on "FORTRAN quine") – Leo B. Aug 27 '20 at 22:20
  • I didn't make it clear that 10 was the label to a format statement. – cup Aug 28 '20 at 05:33
  • I understood that. However, not a single compiler that I have access to allows format labels in ASSIGN. My "gotcha" example shows that some of them would not be able to even if they wanted because of ambiguity, and my quine example shows that there was a standard way to have shared format strings. – Leo B. Aug 28 '20 at 05:41
  • 2
    Strange - I've been doing that since the mid-70s when I first started using Fortran. I used it on the ICL compilers and later on Data General. It even works on gfortran even though it moans about it. – cup Aug 28 '20 at 05:49
  • Then it is another "extension" among another group of vendors. The PDP-11 UNIX V5 Fortran errors out with "undefined label" when a format label is used in ASSIGN. – Leo B. Aug 28 '20 at 08:29
  • 1
    It is possibly one of those features that lots of vendors implemented. It seems to have made its way into F77 but got taken out when they dropped the assign statement in F95. – cup Aug 28 '20 at 11:52
  • good observation about the optional-or-not comma! – dave Aug 29 '20 at 20:12