Are there any primary sources for the “passing constant by reference” behavior in old Fortran compilers?

Question

Occasionally I have heard references to a peculiarity of certain (old) Fortran compilers, with regards to subprogram argument passing. Here is an example, from an answer to a Stack Overflow question:

Some early Fortran compilers implemented constants by using a constant pool. All parameters were passed by reference. If you called a function, e.g.

f(1)

The compiler would pass the address of the constant 1 in the constant pool to the function. If you assigned a value to the parameter in the function, you would change the value (in this case the value of 1) globally in the program. Caused some head scratching.

The C FAQ also mentions ���FORTRAN's classic idiosyncrasy involving constants passed by reference” in a footnote.

I have no problem believing that some compilers behaved this way. However, I would like to have some contemporaneous documents that confirm it. The nature of the document doesn't matter too much; I merely want confirmation from a non-anecdotal source (although some kind of manual would be ideal).

Answer 1

That fact is explicitly mentioned in the (Russian) book Ошибки-ловушки при программировании на фортране, 1987 (Errors and pitfalls in FORTRAN programming), page 88.

One of the puzzles was to make the sequence of operators

      J=1
      PRINT 1,J
  1   FORMAT(' J = ',I1)

print 0.

The provided solution was

      PROGRAM TASK
      CALL ZERO(1)
      J=1
      PRINT 1,J
  1   FORMAT(' J = ',I1)
      STOP
      END
      SUBROUTINE ZERO(K)
      K=0
      RETURN
      END

Answer 2

I'm too young to remember really old Fortran compilers, but the behaviour that you described occurs in all current Fortran compilers. It's a core part of the language standard, so we can safely assume that any standard-conforming compilers in the past used to work this way as well.

Check out this example at https://godbolt.org/z/GKadP9rov (feel free to switch to Intel Fortran if you aren't a fan of gfortran):

subroutine foo(x)
    implicit none
    integer :: x

    x = 5
end subroutine

program test
    implicit none

    call foo(1)

    call bar(1)
end program

Because all Fortran subroutines by default accept all arguments by reference, the main program does not have any other option than to pass the constant 1 as a reference to a value in memory. The disassembly proves that the same location is used in both calls:

foo_:
…
        mov     DWORD PTR [rax], 5
…
.LC0:
        .long   1
MAIN__:
…
        mov     edi, OFFSET FLAT:.LC0
        call    foo_
        mov     edi, OFFSET FLAT:.LC0
        call    bar_
…

Of course, the constant will be placed into the read only data section on most modern platforms (except for those lacking an MMU). The write in foo() is thus going to trigger a segmentation fault at runtime.

Answer 3

In the 1990s, I worked for a UK company (Polyhedron Software) that produced a suite of code analysis and refactoring tools for Fortran, marketed as PlusFort.

The GXCHK module performed static analysis of Fortran code to look for common errors, including:

Subprogram argument mismatch or misuse (e.g. constant actual argument is illegally modified by subprogram).

Though I am no longer in contact with the company, I can remember this being an issue with Fortran-77 and before, as evidenced by the need of a QA tool to identify such bugs.

Answer 4

Using an emulated IBM 1130 running DM2, I can confirm Leo B.'s example. It took a little modification to run on the 1130:

// JOB
// FOR
*LIST SOURCE PROGRAM
*ONE WORD INTEGERS
      SUBROUTINE ZERO(K)
      K = 0
      RETURN
      END
// DUP
*DELETE             ZERO
*STORE      WS  UA  ZERO
// FOR
*LIST ALL
*IOCS(1132 PRINTER)
*ONE WORD INTEGERS
      J = 1
      WRITE(3, 2)
      WRITE(3, 1) J
      CALL ZERO(1)
      J = 1
      WRITE(3, 3)
      WRITE(3, 1) J
    1 FORMAT(' J = ', I1)
    2 FORMAT(' BEFORE -')
    3 FORMAT(' AFTER -')
      CALL EXIT
      END
// XEQ

The output of the program is:

BEFORE -
J = 1
AFTER -
J = 0

Since the value of J is only ever set to 1, it's clear that the program has set the value of 1 to 0 … 🤔

Answer 5

This discussion is in support of the previous answers. Hopefully, this is not the answer to some other question that was not asked. The question was in reference to passing values without restriction in old compilers, but no reference was given to how old. So lets start at the time of really old. This appears to be a non-standard feature used in Univac Fortran V (ca. 1973), and and also in Univac ASCII Fortran (ca. 1982). The implementation of Univac Fortran V on the 1100 mainframe system, is the predecessor of Univac ASCII Fortran, and predominantly set the standard for Fortran 77. Univac ASCII Fortran was the full version of Fortran 77 implemented on Univac 1108 system.

The feature mentioned in the question is very similar to the DEFINE statement in Univac Fortran V. Lets think a minute... Here we are writing a main program and several subprograms called by the main program. The nature of features like DEFINE was to allow control at the head of the main program, before stepping into execution, to set the values or name references of constants, variables and functions that were seen by the executable area of the main program and its subprograms. There were conflict restrictions the programmer had to consider in selecting variable naming conventions for the main program and subprograms, but DEFINE voided that restriction, but only for those constants, variables, and functions set by DEFINE. This gave the ability of the programmer to have program global control of DEFINE features to all areas of the program without passing arguments. Constants, variables, and functions set by DEFINE had unrestricted naming conventions. This was, at times, indispensable. This meant the programmer could set the value of a constant or variable without restriction, or DEFINE a function this way, and could access these defined features anywhere in the executable's environment. These features were defined after setting the type but before the first executable in the main program. The highly proscriptive programming, compilation, and execution environment on the Univac system prevented the modification of memory areas outside of that allocated to the program by the compiler and executive operating system, a protective memory addressing issue. An attempted write-protection violation was a very serious issue. DEFINE allowed a modification of this but only after the non-executable type-setting area of the program, before the executable section of the program. This is consistent with the stated address passing action mentioned in the question.

Here is an example -

       DEFINE F(X,Y) = X + Y        a type definition of a function

followed by

       A = F(U*V,V)         results in A = U*V + V where A,U,V are *real*

or, for example

       D = F(I*J,K*I)   I,J,K are double precision, D is double precision by propagation

resulting in

       D = I*J + K*I     a double precision expression...

(Pretty cool! Especially if one does not have to mess with naming restrictions!!)

Univac Fortran V documentation states the following...

4.2 DEFINE PROCEEDURES
A DEFINE generates inline code when it is referenced. Thus, it is analogous to an 1108 assembly procedure, rather than to an external or internal FUNCTION, which generates a closed subprogram. The overhead of a subprogram is eliminated and the optimization capabilities of the compiler are allowed to operate. The FORTRAN IV arithmetic statement functions are a subset of the DEFINE procedure.

Univac ASCII Fortran documentation shows the definition is little changed and gives the following characterization...

The statement function generates inline code when it is referenced. This allows efficient references to the defining expression without referencing the expression each time.

In other words, DEFINE(expression) is a statement function definition that is global (i.e. unrestricted) within the allocated program environment. This would be extremely useful.

Examination of documentation for two other versions of Fortran 77 shows this feature is recognized as a Fortran 77 feature in Lahey Fortran, 1994, and also recognized in Microsoft Fortran 5.0/5.1 1991, the predecessor of Compaq Fortran mentioned below. The Lahey unavailability may likely be due to memory protection issues necessary for the operating-system environments of non-mainframe systems.

Examination of documentation for Compaq Fortran version 6.6A (May 2002), the industry standard pc-implementation of VAX Fortran 77 at the time, showed the feature is recognized as non-standard and operates in very much the same way mentioned in the question.

The following is noted -

15.1.5 DEFINE and UNDEFINE Directives -
The DEFINE directive creates a symbolic variable whose existence or value can be tested during conditional compilation. The UNDEFINE directive removes a defined symbol.
...
Rules and Behavior -
DEFINE and UNDEFINE create and remove variables for use with the IF (or IF DEFINED) directive. Symbols defined with the DEFINE directive are local to the directive. They cannot be declared in the Fortran Program.
Because Fortran programs cannot access the named variables, the names can duplicate Fortran keywords, intrinsic functions, or user-defined names without conflict. To test whether a symbol has been defined, use the IF DEFINED (name) directive. You can assign an integer value to a defined symbol. To test the assigned value of name, use the IF directive. IF test expressions can contain most logical and arithmetic operators.
Attempting to undefine a symbol that has not be defined produces a compiler warning.
The DEFINE and UNDEFINE directives can appear anywhere in a program enabling and disabling symbol definitions.
Examples - Consider the following

   |DEC$ DEFINE  testflag  
   |DEC$ IF DEFINED (testflag)  
       WRITE( * , * ) 'Compiling first line'
etc...

In the above example, IF DEFINED (testflag) is true, Compiling first line will be written.

The following documentation may be of interest...

Univac 1100 Series Fortran V Programmer Reference, UP-4060 Rev. 2, 1973

Sperry Univac Series 1100 Fortran (ASCII) Level 10-R1 Programmer Reference, UP-8244.2, 1982

Compaq Fortran Language Reference Manual, Order Number: AA-Q66SD-TK, September 1999

Compaq Fortran is now Intel Fortran.

So we went from really old, to maybe not so old. Hope this answer was of some help...

Answer 6

Here is an explicit example of the behavior mentioned by texdr.aft in their posted question...

       Program testzog
       !DEC$ DEFINE flag=3
  c ...... executable statements and some overly technical mumbo-jumbo
       call zog
       end
       subroutine zog
       !DEC$ IF (flag .eq. 3)
          WRITE (*,*) "This is compiled if flag equals 3."
       !DEC$ ELSEIF (flag .ge. 4)
          WRITE (*,*) "Or this compiled if flag greater than or equal to 4."
       !DEC$ ELSE
          WRITE (*,*) "Or this compiled if all preceding & conditions .FALSE."
       !DEC$ ENDIF
       END  

Please note, DEFINE is a directive setting the value of flag equal to 3. Poorly written compilers, or lack of familiarity with the Fortran language constructs, can produce results that are not expected. In this case, however, results are as expected and consistent with the behavior mentioned by the OP in their question. The compiler used was Compaq Fortran version 6.6A.

For testzog, DEFINE flag=3 is a pre-executable directive setting the value of flag equal to 3. As mentioned previously, a DEFINE directive, if used, must occur after setting the type for variables in the main program. Note that the call to subroutine zog includes no reference to flag as a calling argument passed to zog. Compilation and execution of testzog will result in "This is compiled if flag equals 3" for flag=3 and "Or this compiled if flag greater than or equal to 4" for flag=4. The value of flag determines executable actions in subroutine zog and indicates the value of flag is passed by reference, a compiler optimizing procedure invoked when program testzog and companion subroutine zog were compiled.