COMPUTING SCIENCE 370
Programming Languages

Fortran -- Syntactic Structures and Control Structures

Historical Overview

FORTRAN, the IBM Mathematical FORmula TRANslating System, was designed and implemented by a team at IBM led by John Backus.

Versions of FORTRAN

1954	FORTRAN I	- specified
1956	FORTRAN I	- implemented for the IBM 704
1958	FORTRAN II
1958	FORTRAN III
1962	FORTRAN IV	- still an important dialect
1966	ANS FORTRAN	- ANSI standard FORTRAN IV (2 versions)
1977	FORTRAN 77
1990	FORTRAN 90

Structural Organization

• imperative
• compiled (see The Compilation Process)
  • independently compiled subprograms (separate compilation)
  • linker combines relocatable object files with no checking of interfaces
  • if modified, only that module needs to be recompiled, then all re-linked
  • programming in the large -- a program may be constructed as a series of calls on library procedures

Syntactic Structure

• fixed-format lexics -- the position of characters on the line (card) is significant

  Columns	Purpose
  1 - 5	statement number
  6	continuation
  7 - 72	statement
  73 - 80	sequence number

• free format in statement part
  • blanks ignored
  • no reserved words -- token separation by context

    DO 20 j=1,100       (DO statement)
    DO 20 j=1.100       (assignment to DO20J)

SYNTACTIC CONSISTENCY PRINCIPLE

Similar things should look similar.
Different things should look different.

Control Structures

GOTO

unconditional branch to a labelled statement
e.g., GOTO 400

IF

conditional execution of a statement
e.g., IF (X .EQ. A(I)) K=I-1
or IF (J.GT.3) GOTO 100

Computed GOTO

branch to one of several statements depending on the integer value of a variable
e.g., GOTO (10, 20, 30, 40), J

Assigned GOTO

branch to the statement whose address has previously been ASSIGNed to an integer variable
e.g., GOTO N, (10, 20, 30, 40)

DO loop

repeat statments up to a labelled CONTINUE statement, and increment a control variable by a fixed amount each time, terminating when the specified maximum is reached; e.g.,

      DO 100 J=1, N, 3
      A(J)=A(J)*2
100   CONTINUE

• Heavy reliance on GOTO shows machine dependence.

PORTABILITY PRINCIPLE

Avoid features or facilities that are dependent on a particular computer or a small class of computers.

• IF and GOTO used for leading-, trailing-, and mid-decision loops.
  • Combined with the (typical) lack of indentation, this makes visualizing the execution behavior of the program difficult.

  Leading-decision loop

  100   IF (loop done) GOTO 200   
        . . . body of loop . . .
        GOTO 100
  200   . . .

  Mid-decision loop

  100   . . . first half of loop . . .
        IF (loop done) GOTO 200
        . . . second half of loop . . .
        GOTO 100
  200   . . .

  Trailing-decision loop

  100   . . . body of loop . . .
        IF (loop not done) GOTO 100

STRUCTURE PRINCIPLE

The static structure of a program should correspond in a simple way to the dynamic structure of the corresponding computations. (E.W. Dijkstra)

• Assigned and computed GOTOs are easily confused (a violation of the Syntactic Consistency Principle).

• Weak typing -- Integer variables are used to hold addresses and character strings.
  • The system can't check if the variable in an assigned GOTO actually contains an address.

DEFENSE IN DEPTH PRINCIPLE

If an error escapes detection by one line of defense (e.g., syntactic checking), it should be caught by the next line of defense (e.g., type checking).

PROBLEM in language design: foreseeing problems due to the interaction of features (e.g., between the syntax of GOTOs and the decision to use integer variables to hold the addresses of statements).

• FORTRAN has a linear rather than hierarchical structure.
  • DO-loops may be nested, but can be jumped into and out of.
  • Other statements may be nested in an IF, but only a simple unconditional statement (assignment, GOTO).

• Optimization -- the DO-loop provides the compiler with enough information to optimize performance.
  • Combined with restrictions on array indexing formulas, array handling was highly optimized.

PRESERVATION OF INFORMATION PRINCIPLE

The language should allow the representation of information that the user might know and that the compiler might need.

Subprograms

• declared by

        SUBROUTINE name (formal parameters)
        body
        RETURN
        END

• invoked by

        CALL name (actual parameters)
  

• procedural abstraction (Abstraction Principle) -- a repeating sequence of instructions is factored out and called when needed
  • reduces a large problem to several smaller subproblems

• no way to specify parameter modes (e.g., in or out)
  • All parameters have mode in/out (update).
  • Most compilers implement this mode using pass by reference: the name of the formal parameter is bound to the address of the actual parameter at run time (RT).

    +	Time and space efficiency for arrays (no time to copy, no extra space to store).
    -	Time inefficiency for look-up due to indirection.
    -	Side effects to parameters meant to be in-only are possible. E.g., SUBROUTINE SETVAL (N) N=3 RETURN END CALL SETVAL(2) This changes the constant value 2 to 3, as constants are kept in a literal table.

  • Pass by value-result (copy-restore) is an alternative for implementing in/out mode:
    • The value of the actual parameter is copied to the formal parameter at activation.
    • The value of the formal parameter (result) is copied back to the actual at deactivation.

    +	Although side effects are possible, security is maintained by the compiler -- it can omit the copy-out if the parameter is a literal or an expression.
    -	Passing arrays is inefficient.

SECURITY PRINCIPLE

No program that violates the definition of the language, or its own intended structure, should escape detection.

Activation Records

An activation record (AR) is a data structure which contains all of the information (the state) of one activation of a subprogram.

• Maximum of one AR per subprogram in Fortran --> no recursion.

• Space for the AR is allocated at load time (LT) and remains until execution ends (static).

• Purposes:
  • save the state of the caller: variables, registers, instruction pointer (IP)
  • transmit parameters to the callee
  • pass the callee a pointer to the caller's AR -- a dynamic link -- so it knows which caller to resume

    dynamic chain

    the sequence of dynamic links pointing back from each callee to its caller, from the currently active subprogram to the main program

Subroutine S calls F(p, q)

Activation Unit (caller)	Activation Unit (callee)
AR CS PAR DL IP TMP LOCAL code	AR CS PAR DL IP TMP LOCAL code
Subroutine S	Subroutine F(p, q)

Subprogram Call

1. Save the state of the caller in the caller's AR.
   • registers to AR(S).TMP
   • return address to AR(S).IP
2. Place the parameters in the callee's AR.
   • AR(F).PAR[1] <-- address(p)
   • AR(F).PAR[2] <-- address(q) [call by reference]
3. Set the dynamic link in the callee's AR.
   • AR(F).DL <-- address(AR(S))
4. Activate the callee's AR at its first instruction.
   • GOTO entry(F)

Subprogram Return

1. Use the DL to restore the state of the caller.
   • restore registers from (AR(F).DL).TMP
2. Use the DL to branch to the return address.
   • GOTO (AR(F).DL).IP
3. If the callee was a function, place the return value in a fixed location (a register or the callee's AR).

The two steps for return may be reversed if the caller is responsible for restoring its own state.