Contact us Heritage collections Image license terms
HOME ACL Associates Technology Literature Applications Society Software revisited
Further reading □ Overview □ 1962: An outline of Fortran □ 1962: Operating experience with Fortran □ 1962: Implementation of Fortran on Atlas □ 1962: Proposed target language (BAS) □ 1962: BAS binary card □ 1963: Intermediate Atlas symbolic programming language (INTERASP) □ 1963: Addendum □ 1963: A primer for Fortran programming □ 1964: Atlas Fortran manual: Part I □ 1964: Part II □ 1964: Using HARTRAN □ 1965: System note 4 □ 1966: Fortran on Atlas □ Atlas 2 at AWRE □ 1965: BAS subroutines □ 1965: System notes □ 1966: S3 Fortran □ Titan □ 1966: System note 1 □ 1966: System note 2 □ 1966: Fortran on Titan □ 1966: Compile Master on Titan □ 1966: System Note 3 □ 1966: Differences between S3 dialect and Fortran II □ 1966: Magnetic tape library subroutines □ 1967: T3 Fortran reference manual
ACD C&A INF CCD CISD Archives Contact us Heritage archives Image license terms

Search

   
⟶ ACL ⟶ Applications ⟶ Hartran :: Hartran and Fortran on Atlas
⟶ ACL ⟶ Applications ⟶ Hartran :: Hartran and Fortran on Atlas
ACL ACD C&A INF CCD CISD Archives
Further reading ⇓

□ Overview □ 1962: An outline of Fortran □ 1962: Operating experience with Fortran □ 1962: Implementation of Fortran on Atlas □ 1962: Proposed target language (BAS) □ 1962: BAS binary card □ 1963: Intermediate Atlas symbolic programming language (INTERASP) □ 1963: Addendum □ 1963: A primer for Fortran programming □ 1964: Atlas Fortran manual: Part I □ 1964: Part II □ 1964: Using HARTRAN □ 1965: System note 4 □ 1966: Fortran on Atlas
Atlas 2 at AWRE
□ 1965: BAS subroutines □ 1965: System notes □ 1966: S3 Fortran
Titan
□ 1966: System note 1 □ 1966: System note 2 □ 1966: Fortran on Titan □ 1966: Compile Master on Titan □ 1966: System Note 3 □ 1966: Differences between S3 dialect and Fortran II □ 1966: Magnetic tape library subroutines □ 1967: T3 Fortran reference manual

Differences between the S3 Dialect and Fortran II

B C Chapman

25 August 1966

1. Introduction

The following notes describe the main differences between the S3 dialect of Fortran now available in Titan and the Fortran II language as described in the IBM 709/7090 Fortran Reference Manual and later notes describing double length arithmetic, etc. Most of these differences will apply also to a comparison between S3 and the Fortran dialect in use at SRC Chilton, but in addition the Chilton version contains many extensions to the Fortran language both along the lines of Fortran IV (e.g. function names, logical operators) and others peculiar to itself (e.g. PUBLIC). Both S3 and Chilton allow mixed integer real arithmetic, which is not part of Fortran II.

In general the Fortran II user should find that his programs will compile under S3. It is however necessary for the user to initialise COMMON array storage. This is done in a special additional subroutine known as a PRELUDE. In return for this trouble, the user can now alter the sizes of his COMMON arrays (and private arrays with dimensions in COMMON) at load time without need for recompilation.

The make-up of card decks is described in the manual The S3 Fortran System on Atlas 2 and will not be repeated here.

2. Facilities not provided by S3

The following facilities are not provided by the S3 compiler.

  1. Arithmetic Statement Functions
  2. Boolean Arithmetic
  3. Complex Arithmetic
  4. Double Length Arithmetic
  5. The use of subroutine or function names as arguments of subroutines or functions.
  6. The use of Hollerith characters as arguments of functions or subroutines, or in Arithmetic or IF statements.

The following statements are ignored by the S3 compiler. Control always passes to the next statement, even when in cases as a, b, c or d the next statement is labelled neither n1 nor n2.

  1. IF (SENSE SWITCH) n1, n2
  2. IF ACCUMULATOR OVERFLOW n1, n2
  3. IF QUOTIENT OVERFLOW n1, n2
  4. IF DIVIDE CHECK n1, n2
  5. PAUSE
  6. FREQUENCY

3. Other Differences

  1. Mixed expressions are allowed in S3.
  2. Execution is terminated by anomalous arithmetic expressions such as SQRTF(-2), LOGF(0) or even (-3)**2.0 (for negative arguments the exponent must be in integer mode).
  3. A program may be terminated by the instruction STOP, CALL EXIT, CALL EEXIT (abnormal end giving selective printing) or a RETURN from a main program. It is necessary that each subroutine contains either a RETURN statement or one of these terminating statements with a theoretical flow of control to it. I.e. it is not good enough to merely program a stop through exhaustion of data, even though the job will in fact stop in this manner.
  4. END cannot share any parameters following it. A flow of control to an END statement is regarded as a RETURN.
  5. CALL CHAIN is used to call the next chapter of a chain job. It needs only one argument - the number of the next chapter. A second argument will be ignored. It is not recognised by the S3 compiler as a permanent transfer of control, and so must always be followed by STOP or RETURN etc.

4. Input and Output

  1. READ, PRINT and PUNCH are available and are synonymous with READ INPUT TAPE 0, WRITE OUTPUT TAPE 0 and WRITE OUTPUT TAPE 15 respectively.
  2. READ INPUT TAPE n means "READ INPUT STREAM n" unless for n ≠ 0 there exists a tape with logical number n, in wich case the tape is read presuming it to be in Atlas variable length format.
  3. WRITE OUTPUT TAPE n means "WRITE OUTPUT STREAM n" unless for 1 ≤ n ≤ 14 there exists a tape with logical number n, in which case the tape is written in Atlas variable length format. Normally, output 0 appears an the line printer, and output 15 on seven track paper tape.
  4. READ DISC and WRITE DISC (DISC may also be spelt DISK or DRUM) are available. The actual medium is either tape or disc dependent on job description or the *TAPFILE loader directive. Each block contains 512 words. Block 0 must not be used.
  5. READ TAPE and WRITE TAPE give rise to transfers between core and a tape in Atlas variable length format.
  6. In all tape statements the logical tape member n must lie in the range 0 ≤ n ≤ 10
  7. FORMATs are treated in almost the same way as at SRC Chilton. Apart from O type, this is generally similar to the 7090 treatment with extensions.

5. Array Storage

Each array as associated with it an additional single word containing the base address of the array, e.g. the address of the cell containing A(0) i.e. one less then the address of A(1). If the array is private to a routine, the compiler and loader take care of its contents. If the array is to be COMMON the programmer must set the contents by an interlude at the start of loading using a subroutine PRELUDE. Instead of a large COMMON area, S3 uses a COMMON list, consisting of one word for each COMMON variable beginning at location 101 (decimal). A scalar has its value in the COMMON list. An array has its base address.

5.1 General Rules

  1. All COMMON, DIMENSION and EQUIVALENCE statements must precede any FORMAT or EXECUTABLE statement.
  2. All arrays are stored forwards in absolute location. Following DIMENSION B(L,M,N) the number B(I,J,K) will be found in location B + I + (J-l)*L+(K-l)*L*M where B is the base address of the array.
  3. Dimensions need not be defined until load time e.g. DIMENSION A(K), B(I,K) A and B may be either (a) identifiers private to the routine COMMON or (b) COMMON variables (c) dummy identifiers appearing in the argument list of the routine. In cases (b) and (c) I may either be in COMMON or transmitted through the argument list. In case (a) K and I must appear in COMMON and must be loaded with integer values during subroutine PRELUDE. They should be treated as invariants for the job. Alteration of their values during execution may cause peculiar errors.
  4. Don't use unsubscripted array names in I/O lists.
  5. When an array is the argument of a subroutine, the calling statement must contain the unsubscripted array name.
  6. If it is necessary that a subroutine operate on part' of an array, other than a scalar, then one can either (a) define a new array, using EQUIVALENCE, if the starting point is constant, or (b) use the subscript as an argument, or (c) calculate and plant the effective base address of a virtual array. I.e, instead of CALL SUB (A(I,J)) in case (b) use CALL SUB(A,I,J) with subroutine SUB suitable modified, or (c) use
    LOCAJ = A + (J-l)*I A (presuming DIMENSION A(IA,IJ) then
    CALL SUB (LOCAJ)
    so that subroutine SUB will refer to call LOCAJ for the base address of the array.

5.2 Subroutine PRELUDE

This must be provided whenever COMMON arrays, or private arrays with COMMON dimensions, are to be used. It may contain input and output statements and call other subroutines. The user must be aware of how the store is used in Titan. The locations 0-100 (decimal) are used for various system purposes. The COMMON list starts at 101 and goes up. Above this the various subroutines of the job, and the relevant library routines will be loaded. (The loader prints out this upper limit, in octal). The space between this limit and 32K is available for use by COMMON arrays.

Example

Suppose a subroutine SUBR1 contains the following statements:

      DIMENSION A(I,J), B(100), C(I,N), D(M), IA(J)
      COMMON P,A,B,C,I,J,N,X,M,Y,IA,Z

The following PRELUDE would be sufficient to set the COMMON list so that the arrays occupied space at the top end of store.

      SUBROUTINE PRELUDE 
      COMMON P,A,B,C,I,J,N,X,M,Y,IA 
      READ 100, I,J,N,M 
 100  FORMAT (4I6)
      A = 32767 - I*J 
      B = A - 100 
      C = B - I*N 
      IA = C - J 
      RETURN
      END

6. Equivalence

In S3 Equivalences, only two items may be equivalenced at a time, and the left variable is defined in terms of the right variable. For example EQUIVALENCE (A,B(l5)) is permitted but EQUIVALENCE (B(l5), A) is not. To attain the effect of a multiple equivalence, split into pairs e.g. replace EQUIVALENCE (A,B,C) by EQUIVALENCE (A,B), (B,C)

6.1 Equivalence and Common

In EQUIVALENCE (L,R) we have the following cases

  1. L,R common, L does not get a separate entry in the common list but uses the entry for R. The common list is constructed as if L had not been declared common.
  2. Only R common. L uses the space allocated to R. This case does not affect tho formation of the common test.
  3. Only L common, L takes its place in the formation of the common list, but the routine is compiled using the storage of R for L.

Note that equivalence does not re-order the Common list.

6.2 Equivalencing variables of different modes

Care must be exercised or peculiar results will be obtained. In particular remember that division by a LONG INTEGER currently called REAL will result in a division overflow stop. Integers are normally "short", unless otherwise specified, and generally held in B-registers. Confusion arises if the compiler is asked to equivalence an integer currently available in a B-register with a variable in core store. These remarks apply also to implied equivalencing through subroutine arguments or common list.

6.3 Dummy Common Arrays

A frequent practice is to reduce the number of COMMON declarations in a subroutine by replacing a string of declarations about actual variable by one for a dummy array of the same total dimension. This trick must not be used with S3 since the COMMON list has one number for each variable, and would thus become displaced.

⇑ Top of page
© Chilton Computing and UKRI Science and Technology Facilities Council webmaster@chilton-computing.org.uk
Our thanks to UKRI Science and Technology Facilities Council for hosting this site