Present:   S G Brazier         - United Glass

Chris Burse         - ULCC

P C Chapman         - Retired

Stephen Evans       - London Hospital Medical College

Bill Flexner        - Retired

D P Fordned         - BBC

C Hall              - NPL

Chris Lazou         - ULCC

David Lomas         - UMST

D J Holmes          - Rolls Royce Ltd, Bristol

Mike Metcalf        - CERN

A Mason             - ULCC

K Normington        - Coventry Polytechnic

Mike Nunn           - CCTA

T L van Raalte      - MQD

J Roberts Jones     - Liverpool City Council

Nick Saville        - Private Consultant

J L Schonfelder     - University of Liverpool

Alan Wilson         - ICL

John Wilson         - Leicester University

        Address:  Chairman             - John Wilson

    Computer Laboratory

    University of Leicester

    Leicester LE1 7RH

Secretary           - Mike Nunn


    Riverwalk House

    157 Millbank

    London SW1P 5RT

Treasurer           - T L van Raalte

    Atomic Weapons Research Establishment




Apologies were received from Dave Vallance (Salford University).

1.      Minutes of Previous Meeting [6 June 1983]

Correction of last paragraph of "Treasurer's Report" on p3:

        "idea forum" should read "ideal forum"

2.      Matters Arising

        (i) "British Standard Fortran"

An OSI/5 sub-committee has been set up to work on the BSI Fortran proposal

called "Standard Method for Specifying FORTRAN Language Processors". Its

membership comprises:

D Muxworthy

B Meek

J Wilson

I Hill

with T Clarke and T Addyman as correspondent members.

They are working on a draft which will be issued for comment. Bill Flexner said

he would like to hear examples of how this proposal worked as compared with the

Standard itself, eg could he be shown concretely how it would improve Standard?

John Wilson said that in any area of the Standard. where there could be problems

with portability, implementors would need to either declare their interpretation

or give the user various options. To what extent the new BSI proposal document

could define all such situations was still under discussion. As soon as it was

satisfactorily drafted it would be brought to the attention of X3J3.

Lawrie Schonfelder wanted to make two general comments viz (i) there were loose

areas in the Standard because competing manufacturers represented on X3J3 did

not want a stricter definition in particular areas which would present them with

difficulties and (ii) X3J3 did not want the language "cast in concrete" because

they wanted it to be upwards buildable upon.

Nike Metcalf did not think the effort being put into the new BSI proposal worthwhile.

If it was going to be about 1986 before it came to fruition, 8X features will

already be on offer by then from many companies. Also being mainly USA based

they just would not be interested in the BSI effort.

        (ii) Fortran 77 Compiler Validation At NCC

Mike Nunn told the meeting that NCC, backed up by funding from DOI, will start

validating F77 compilers in the UK starting from October. They will be using

the same suite of test programs as the USA government's Federal Software Test

Centre (FSTC). Although the first compilers validated by NCC will be of UK origin,

they will also be testing American ones as well by arrangement with FSTC who

have more compilers awaiting test than they can cope with.

After FSTC have tested a compiler they produce a summary report which after


    (i) the compiler version and origin

   (ii) the hardware tested on

  (iii) the operating system used

reports the errors found (if any) in running the test site against the compiler.

For the foreseeable future NCC can supply summary reports on compilers tested by

either themselves or FSTC for free. Anyone interested in obtaining them should


Vony Gwillim

Senior Consultant

Standardisation Office

The National Computing Centre Ltd

Oxford Road.

Manchester M1 7ED

Phone 061-2286333

A list of compilers certified by FSTC is in appendix C. The first UK compiler

scheduled for test by NCO is ICL's for the 2900. This is expected to be about

mid January 1984.

(iii) Treasurer's Report

A cheque for £50 has been received from Academic Press who sponsored the

sending out of the last newsletter in return for enclosing a publicity notice for

Mike Metcalf's book on "FORTRAN Optimisation".

BCS have now accepted our accounts for the last financial year.

Non-BCS members are reminded that there is a £2 annual fee for membership of

the FORTRAN Specialist Group which automatically provides regular copies of the

newsletter giving minutes of meetings. Anyone who has not paid for this year

by 31 December will unfortunately have to be removed from the membership list.

Outstanding cheques should be sent to the Treasurer, Mr T L van Raalte.

3.  BCS Business

There had been no Specialist Groups Board meeting since the last FORTRAN Group


In future a separate page in "Computing" will be devoted to Specialist Groups

activities. "Computer Bulletin" will devote a double page as well.

4.  X3J3 Progress

Dr Lawrie Schonfelder (Liverpool University) and Dr John Reid (UK Atomic Energy

Authority) have been attending X3J3 meetings regularly. Lawrie described the

main discussion at the latest August meeting at Los Alamos. John Reid provided

a written summary. A combined synopsis of John and Lawrie's reports is in

appendix A.

5.  Any Other Business

   (i)  A new pocket book is appearing soon called

        "Pocket Guide to FORTRAN77" by Clive Page, (Physics Department

                                                     Leicester University)

  (ii)  The next FORTRAN experts meeting will be held at CERN in Geneva in

        April. The dates provisionally agreed are the 9-12th and its hoped

        to make these firm soon.

6.  Date of Next Meeting

5 December 1983 at 10. 30 in Room 4D, Birkbeck College, Malet Street, London WC1.

In the afternoon Lawrie Schonfelder will give a talk on Derived Data Types

in FORTRAN. By courtesy of IBM a film will be shown on the "History of FORTRAN".

7. Talk on "Fortran optimisation"

In the afternoon Mike Metcalf of CERN gave a talk on Fortran optimisation. This
is summarised in Appendix B.

Mike Nunn (Secretary)

18 November 1983



1. FORTRAN Information Bulletin

A lot of time was spent by both the full committee and its sub-groups in

discussing and improving the "FORTRAN Information Bulletin" which summarises

whats been passed so far for FORTRAN 8X. It is required by the parent committee

X3 but will be given a wider circulation and is likely to be more suitable

than S6 or S7 to those interested. It includes syntax charts developed by

Jerry Wagener a very clear and simple Bachus - Naur form which will eventually

appear in the Standard. It is hoped it will be approved at the next meeting.

2. Standing Documents S6 and S7

A revised cop of S6 containing all the changes s0 far approved from F77 was

handed out. The new working document is S7 and attempts to merge the new

proposals with the old F77 Standard but maintaining the structure of the F77

document. However it has become clear that this structure is not ideal for F8X.

So Jerry Wagener and the Editorial subcommittee are considering a restructure

which will reflect the central role of TYPE and bring together in one place the

notions of TYPE and DERIVED DATA TYPES in particular. The next few meetings

will be used to (i) expressing correctly in S7 material already passed and

(ii) considering new material altogether.

3. Derived Data Types

Proposals for derived data types have now been passed which provide for strong

typing of data structures. Declaration of the form of a data structure, now

termed a "type", must occur once only in any program scope. Function overloading

becomes legal and infix operators can be overloaded by an operator attribute being

added to the function statement for explicit functions. The proposals are the

work of Brian Smith, John Reid and Lawrie Schonfelder.

4. Bundles and Modules

After much discussion it was decided on a 12-9 vote to rename 'bundles' as

'modules'. It was felt the name 'bundle' would not be taken seriously but those

against the change pointed out that 'module' was already used elsewhere with

different meanings.

5. Event Handling

A form of the proposal passed at the last meeting, but reworded for 8X, was

passed after some detailed changes. A straw vote favoured activate/deactivate

being a block construct or a compiler directive.

An alternative approach to event handling was suggested by Kurt Hirchert who will

be discussing his ideas with the EWICS group in the hope of reaching an agreed


6. Array Proceasing

John Reid's proposal to remove the - * section selector and write the * selector

as:,was passed by 24-1. Some concern was expressed in the subgroup that this

will make it more difficult to distinguish between array sections and character

substrings. The full committee was concerned at the loss of convenience (but

not functionality) in removing - *.

User elemental functions are now deleted because they could not be expressed in

a satisfactory way. A proposal from John Reid to allow zero length arrays

(termed "zero sized") was passed without opposition.

7. Character Data

The length parameter in character data will now have a form analogous to the

PRECISION or RANGE attributes of REAL viz:

                        CHARACTER (LEN = length)

8. Other Items

Time was spent on detailed I/O changes including the problem of handling variable

length records input from terminals. At the next meeting a proposal for intrinsic

functions for date and time will be considered.


John Reid has attended all the meetings of the array subgroup. Discussions have

centred on the proposals put to the full group described in appendix A section 6

and on modifying the FORTRAN Information Bulletin. It was agreed that names of

keyword arguments should be used in the descriptions of the array intrinsic

functions and that several functions such as RANK and EXTENT should be extended

to all data. types. J Reid undertook to produce formal proposals to put before

the next meeting.



1.      Mike related there was a myth that a famous guru had two basic miles:

        (1) Do not optimise

        (2) If you must - do it tomorrow!

Mike believes such people are living in an unrealistic world; with codes as

large as ones in use at his home base of CERN optimisation is really important.

He himself runs courses there on optimisation but with time also devoted to

portability and F8X.

2.      Why do we need to optimise?

This could be answered from three viewpoints:

The individual user

     (i)   Mainframes users who can shorten their jobs will be allowed into job

           classes with better turnround times.

    (ii)   In a virtual machine environment a VM demanding too much cpu time

           will be penalised by the scheduler and its turnround time will be


   (iii)   Extra-large jobs become possible within the machine time available.


     (i)   Better use will be made of expensive resources (despite fall in

           hardware costs).

    (ii)   Congestion on the system will be relieved.

The user community

     (i)   Optimising the few large programs which use a substantial part of

           total computer resources will benefit the turnround time of everyone.

3.   The cost balance

There is no point in making expensive improvements to programs if new hardware will

arrive next year needing to run the non-optimised version.

4.   Various Issues

     (a)   Algorithm Search

           - This could be called the most important optimisation method

             ie there is no point in optimising until you have the best algorithm

             for the job in hand.

           - You need to refine algorithms and check their sensitivity to data.

           - They must be appropriate to task eg very general ones may have

             features that are slow for specialist applications.


     Example   To sum the series S = Σ (-1)I .I


               we could simply write in FORTRAN:


                                                DO 1 I=1,N


                                                1 CONTINUE

               but we could to better by summing odds and evens separately:


                                                DO 1 I=1,N,2


                                                1 CONTINUE

                                                DO 2 I=2,N,2


                                                2 CONTINUE

[This would only be about 5% of the original time for N=100,000]

but better still by inspection would be:


                        IF (MOD(N,2) .EQ. 1) S=S-FLOAT(N)

[This might be 100,000 times faster still]

     (b)   Rules of thumb

           (1)   10% of the code very often uses 90% of the time

           (2)   for short programs - code first, optimise later

           (3)   for large programs - much more important to apply optimising

                 techniques at the design stage.

     Identifying "hotspots"

     Tools   - static counts of operations (in loops etc)

             - dynamic counters (insert counters at strategic points in programs and

               print their values on completion)

             - clock routines to time sections of code

             - statement counters (print analysis of how many times each statement


             - address histograms (eg on same CDC machines one can inspect the address

               of the current program instruction at a frequency which allows the

               address to be entered into a histogram covering the program's address

               space. Peaks will indicate areas which need attention),

     (d)     Clarity

             Clear code helps the compiler to optimise.

             However optimisation can lead to unclear code - is it worth it?

             One should use plenty of comments but you could decide optimised code

             is not worthwhile because of difficulty in understanding.

     (c)     Portability

             Use of

                   local bit handling features

                   machine code

                   fast I/O facilities

aids optimisation but leads to non-portable code!

use these sparingly, comment well and also provide the standard FORTRAN equivalent

code so that users understand what the original was designed to do.

[The unusual section labelling both here and below is a true copy of the original


     (f)    Space optimisation

Although main memories have become larger as memory became cheaper

the size of problems being attacked are now larger as well. So

space optimisation is still important and causes little conflict

with time optimisation. In fact optimising compilers produce

faster code primarily via their transformations of source and

intermediate text and their superior choice of machine instructions

which actually result in fewer and faster instructions being generated

in the object code, and therefore require less space. [There may be

exceptions when heavy use of in line code is used but this is usually

avoided when using the highest optimisation level in a compiler.]

Ways of space saving include:

placing infrequently used arrays on backing store

compressing large arrays containing lots of redundant information

packing several data items to a word

sharing storage between different program parts using a

"dynamic memory manager" (data is kept in banks and when no

longer needed the banks can be re-used)

using overlays

5.   Ways to Optimise

     (i) Avoid DO loops. [because they require the following steps:

                          calculating number of iterations

                          test for zero (and branch if necessary)

                          retaining value of control variable

                          decrementing loop counter and incrementing

                          control variable

                          test for loop completion]

     NB: The overheads on small loops can exceed the execution time for

     the loop body!

     (ii) Nest loops where possible so that the most repeated loops are

          the innermost ones.

          eg  DO 1 I=1,100               No of initialisations = 1

              DO 2 J=1,10                                      100

              DO 3 K=1,2                                      1000

                  .                                    Total  1101


              3 continue    No of tests for loop completion = 2000

              2 continue                                      1000

              1 continue                                       100

                                                       Total  3100

Had these loops been tested in reverse order the total initialisations would be

reduced from 1101 to 23 and completion tests from 3100 to 2022.

    (iii)  Combine loops (to reduce loop processing overheads)

     (iv)  Remove invariants outside loops or use IF ...THEN...ELSE

      (v)  Unroll short loops

     (vi)  Reduce strength of operators

    (vii)  Branching instructions- be aware of their relative execution speeds

           Rough order (starting with fastest):

Unconditional GO TO

        Assigned GO TO

Logical IF

Arithmetic IF

Computed GO TO

           In particular testing against zero is usually fast:

           eg IF (I.NE.0)  will be better than IF (I.EQ.1)

With multiple condition logical IFs order the conditions so that for:

Multiple ANDs - place the condition first that is most likely to fail

Multiple ORs  - place the condition first that is most likely to be satisfied.

   (viii) Avoid mixed mode arithmetic, as the conversions required impose overheads

     (ix)  I/O

           (a) Use unformatted I/O in preference to formatted where possible

               (formatted requires conversions)

               [Also if you must have formats prefer explicit ones to avoid evaluation

                at execution time.]

           (b) Use simple I/O lists

               eg: WRITE (NOUT) A ............ may generate 1 call to output

                   routine but WRITE (NOUT) (A(I), I=1,50)

                                            ...................may generate 50 calls to

                                            output routine on some compilers.

           (c) Use simple FORMAT statements:

               eg: 1 FORMAT (10F11.3)

                   is more efficient than either

                   1 FORMAT (1X, F10.3, 1X, F10.3)


                   1 FORMAT (10 (1X, F10.3))

                   as the space is included in the edit descriptor, and the repeat

                   count is explicit.

      (x)  Usually (but this is a complex subject) its faster to use COMMON rather

           arguments to transfer data. between subprograms.

     (xi)  Where possible initialise variables at the beginning of a program by a

           DATA statement rather than using an explicit assignment at execution


6.   Optimising Compilers

     (i)  To achieve the greatest optimisation:

          - use an optimising compiler at the highest level

          - switch off debugging aids

          - turn off traceback

          - choose inline intrinsic function generation

          - switch off array bound checking

    (ii)  Improvements which optimising compilers make include:

          reducing strength of arithmetic operations -

                replace divisions by multiplications

                         eg X = Y/2  ->    X - Y*0.5

                replace exponentiation by repeated multiplication

                         eg A***5    ->    (A*A)*(A*) *A

                         [sic, but it doesn't make sense]

                on machines with faster additions than subtractions

                         eg  -A-B     -> - (A+B)

                change multiplications in some cases to additions

                         eg 2* X     ->   X+X

   (iii)  Help the compiler recognise repeated calculations and remove repetitions

                         eg (a) A = X*Y + 2.0 + Y*X

                                should appear as

                                A =(X*Y) + 2.0 +(X*Y)

                            (b) in the sequence

                                A = B-C




                                D = C-B

          the second statement should be D= -(B-C)

   (iii)  Regroup expressions to save numbers of divisions

          eg                    X = Y*Z/A

                                T = Y*V/A

                                should be rewritten

                                X = (Y/A) * Z

                                T = (Y/A) * V


Those particularly interested in the subject of optimisation are recommended to

read the book by Mike Metcalf called:

        "FORTRAN Optimisation" published by Academic Press (cost £12.80)

The book covers more aspects of optimisation, and in a lot more detail than that

given in the above summary of Mike's BCS talk.



This section identifies the current list of certified FORTRAN compilers by the

level for which they are certified. [Nb. Some compilers listed will be error-

free,others will contain errors. The summary reports will detail them.]

Subset Level

Apple                         APPLE /// FORTRAN Version 1.0

Burroughs                     B20 FORTRAN Release 3.0

Conv. Tech.                   CT FORTRAN 8.0

Cray Research                 CRAY FORTRAN Translator (CFT) Version 1.10

DEC                           PDP-11 FORTRAN Version 4.1

DEC                           DECsystem-10 Model 1091 FORTRAN-10 Version 7

DEC                           DECsystem-20 Model 2020 FORTRAN-20 Version 7

NCR Office Sys                NCR FORTRAN Release 3.0

NCSS                          IBM VS FORTRAN Release 1

TRW DATACOM                   TRW FORTRAN Version 8.0

Full Level

Burroughs                     Large Systems FORTRAN 77 Version III.4

Burroughs                     Medium Systems FORT77 Version 6.6

Burroughs                     Small Systems FORTRAN 77 Release 10.0

CDC                           CDC CYBER FORTRAN 5 Level 587

CSC                           CSTS FORTRAN Release FTN148

Data General                  AOS FORTRAN 77 Revision 2.11

Data General                  AOS/VS FORTRAN 77 Revision 2.11

DEC                           DECsystem-20 2060 Model B FORTRAN-20 Version 7

DEC                           VAX-11 FORTRAN Version 3.0

Gould, SEL                    Gould FORTRAN-77+ Release 3.1

Gould, SEL                    Gould FORTRAN 77/X32 Release 1.1

Harris                        Harris H800 FORTRAN 77 Version 2.1 (SAU)

Harris                        Harris H800 FORTRAN 77 Version 2.1 (Non-SAU)

Honeywell                     Level 6 Advanced FORTRAN Release 2.0

Honeywell                     DPS 8/44 FZ2.0 FORTRAN

Honeywell                     Multics FORTRAN Version 10

Honeywell                     DPS 8/44C FORTRAN 77 C00

IBM                           VS FORTRAN Release 3.0

MODCOMP                       MODCOMP NASA Extended FORTRAN 78

NCR                           VRX FORTRAN Ver. 23

Perkin-Elmer                  FORTRAN VII Release R05-01

Prime                         Prime FORTRAN 77 Rev 19.1

Sperry Univac                 1100 Series ASCII FORTRAN Level 1OR1A

Stratus                       VOS FORTRAN Release 2.4a

United Info                   CDC Cyber FORTRAN 5.1 Level 552