MINUTES OF BCS FORTRAN SPECIALIST GROUP MEETING

                      HELD AT BCS HQ ON 1st OCTOBER 1987.


Present:        Mike Bennett       - CEGB Staff College

                John Dyke          - H.R.C.

                Miles Ellis        - Oxford University

                Mike Geary         - NAG

                Anne Gooding       - Air Products Ltd

                Dave Griffiths     - System Software Factors

                Valerie Harmer     - University of Surrey

                Peter Holland      - SSL

                David Holmes       - Rolls Royce plc

                Chris Lazou        - ULCC

                Clive Massey       - SWURCC

                Keith Normington   - Coventry Polytechnic

                Mike Nunn          - CCTA

                Kevin Pritchard    - UMIST

                Shaluzod Rahba     - QMC

                Julian Tilbury     - Salford University

                Damian Treanor     - QMC

                Paul Wardle        - Met. office

                John Wilson        - Leicester University

                John Young         - MOD (PE)


1.   APOLOGIES FOR ABSENCE


Apologies were received from Lawrie Schonfelder.


2.   MINUTES OF PREVIOUS MEETING [2 July 1987]


Corrections to previous minutes:


  (a)   Page 2 paragraph 5 (iii) should read


        "Previous standards were produced by ANSI as American

        Standards. ISO subsequently adopted these as International

        Standards. Since Fortran 77 was issued, however, this

        procedure has changed. In the current standardisation

        process ISO's Fortran Working Group (WG5) has delegated

        the responsibility for producing a new standard to ANSI.

        Their Fortran Committee (X3J3) is therefore producing two,

        identical, draft standards - one American and one

        International. It is hoped, and expected, that this will

        lead in due course to two identical Standards".


  (b)   Page 2 paragraph (vi)


        "Wajener" should be "Wagener".


3.   MATTERS ARISING


  (i)   At the coming January meeting it was intended to have a

talk on the array processor features of "8X" by Alan Wilson, John

Reid and Chris Lazou.


(ii)   At next April's meeting it was hoped to include a talk

comparing Ada and Fortran 8X.


4.   BCS BUSINESS


  (i)  John Wilson had attended a meeting of the Specialist

Groups Management Committee on 9th September. The Society was

holding a publicity campaign to attract new members and it was

now easier to become an affiliate - no sponsorship was needed.

Also, a working group had been set up to advise Specialist Groups

on auditing accounts without having to pay out big fees to

auditors.


 (ii)  BCS was currently going out to tender for a replacement

computer at HQ.


(iii)  BCS policy on mailing lists is not to make them available

to outside organisations. However, commercial material can be

sent out by the owner of the list providing there was adequate

payment in return.


 (iv)  Chris Lazou had been to a meeting the previous day of the

Software Engineering Committee which was looking at formal

methods for making standards; there will be Esprit funding for a

workshop on this subject. Apparently IEE/NCC were trying to

define a course curriculum package. More information should be

available soon.


 (v)   Chris had asked BCS to underwrite the cost of our coming

Forum on "8X". They had agreed in principle, deeming that this

type of 1-day event should not be subject to BISL's normal

commercial rates and felt such occasions should be encouraged.


5.  PROGRESS REPORT ON FORTRAN "8X"


  (i)  There had been two meetings at Liverpool in August. An ISO

WG5 working group meeting was followed by an ANSI X3J3 meeting.

WG5 and X3J3 have a somewhat complex relationship and recently

there has been a certain amount of worry about the proper

procedures to follow in releasing 8X.


 (ii)  At the WG5 meeting representatives attended from 9

countries, mainly European, but also a large USA delegation plus

delegates from Canada and Japan. One major discussion point at

this and the following X3J3 meeting was the Japanese demand for

Fortran to include extensions for coping with the Kanji character

set. In Japan most suppliers offer Fortran extensions at present

to cover Kanji.


(iii)  WG5 passed a number of resolutions concerning the "8X"

draft including:

         1) some sort of "pointer" should be offered

         2) blanks should be made significant in the new free

            format source form

         3) there should be a "BIT" data type


 (iv) The previous X3J3 meeting in Seattle had voted in favour

of freezing the draft Standard. Therefore the Liverpool meeting

spent quite a deal of time discussing items which seemed likely

to cause considerable comment during the public review period, so

that if anything was needed to be done about them at least X3J3

would have done their homework in advance.


  (v) There was considerable debate on the proper mechanism for

the public review period. It was concluded that there will be two

procedures:


        (1) The first one for ANSI:

                X3J3 voted in favour of sending the "8X" draft to

                the X3 parent committee at Seattle. Following

                this, X3 held a letter ballot of its 30 or so

                members to ask their feelings about it. This

                resulted in a 31-4 vote in favour. (Against were

                IBM, DEC, Unisys, Data General). It should be

                noted that not all computer companies have members

                on X3, whose members come from all types of

                computing backgrounds not just software). Although.

                X3 only needs a simple majority vote in favour,

                the rules state that if it is not unanimous there

                must be a second vote within 14 days to allow a

                rethink. This resulted 30-5 in favour. So ANSI

                will now release the "8X" draft for a 4 month

                public review period. Anyone can send in comments,

                all of which must be processed and responded to by

                X3J3.


        (2) The second one for ISO:

                SC22 (the ISO programming languages committee)

                held its annual meeting in Washington in September

                where with just one abstention, Japan, it voted in

                favour of releasing the draft for public review.

                ISO then works through national standards bodies,

                it being up to each individual country how to

                formulate its response. The ISO review period is

                to last 3 months starting about now. Very likely

                there will be a great deal of comment. If so, SC22

                will request WG5 to ask X3J3 to make revisions to

                the draft. Should such a revised draft be near

                enough to the present draft then it can be

                released; otherwise it will have to be sent out

                again for a further public review period.


 (vi) X3J3 has granted rights to distribute the "8X" draft in

the USA to a company called Global Engineering. However, ISO

bodies are allowed to make copies for the purpose of the public

review. (N.B. it cannot be further copied nor sold.) Those

booking for the BCS Fortran Forum will receive a copy after

receipt of their registration fee.


(vii) John Dyke expressed the view that casual Fortran users

don't want a new language implementation which does not allow

immediate porting of existing programs. John Wilson pointed out

that the complete Fortran 77 standard will be contained within 8X.


(viii) Mike Nunn mentioned an article in Electronics dated 6th

August which stated that Convex were galvanising a Fortran 8X

awareness campaign to organise opposition to the new standard.


 (ix) John Reid (Harwell) has provided a written report on the

Liverpool X3J3 meeting - see Appendix A.


6.  FORTRAN FORUM 87


Chris Lazou, reported that there had been a recent meeting of the

Fortran sub-committee to finalise plans. It will take place on

Monday 23rd November 1987 at the Institute of Mechanical

Engineering, 1 Birdcage Walk (near St. James park tube station)

and last from 9:45 to 17:00. The attendance fee had yet to be

determined but was likely to be around £40 for BCS (or Fortran

Group members) and £50 for others. The charge will include

morning coffee, lunch and afternoon tea. Delegates will

automatically receive a copy of the draft standard.


The proposed agenda is

      9:45               Registration and coffee

     10:15-10:30         Exposition of ISO/BSI Fortran

                         Standardisation process - by David

                         Muxworthy

     10:30-12:30         The features and philosophy of "8X" - by

                         John Reid and Lawrie Schonfelder

Afternoon session        Devoted to discussion of "8X" led by all

                         the UK X3J3 representatives viz Geoff

                         Millard (Edinburgh), Miles Ellis (Oxford

                         University), Alan Wilson (ICL), John Reid

                         (Harwell) and Lawrie Schonfelder

                         (Liverpool University).

                         Chris Lazou will chair the discussions

                         and David Muxworthy will sum up.


Miles Ellis has produced a memo describing Fortran Forum and its

purpose. It will be organised within the auspices of BISL,

subject to their charge for doing so not being excessive.


Anyone wanting a summary, rather than a copy of the full draft

standard, should write to John Wilson. John Reid and Mike Metcalf

(CERN) have written a book titled, "Fortran 8X Explained" - see

Appendix B.


7.  ANY OTHER BUSINESS

The next meeting of the Group will take place on Thursday 14th

January at BCS HQ from 10:30 to 16:00. There will be talk in the

afternoon by Alan Wilson and Chris Lazou on the Fortran 8X Array

Processing extensions.


8.  TALK "FORTRAN COMPILERS ON MODESTLY PARALLEL PROCESSORS"

In the afternoon Dave Griffiths of System Software Factors gave a

talk on Fortran compilers on modestly parallel processors. His

firm was founded by himself and two others in 1979 to produce a

Fortran translator for the FPS Al20B. This was successful so they

expanded to develop implementations for other machines such as

MARS 432 and SNAP. They have now grown to 8 technical people and

3 administration staff and are based in Reading. A detailed

summary of David's talk appears in Appendix C.

MIKE NUNN

Secretary, BCS Fortran Specialist Group

8th October 1987.


                                  APPENDIX A


To:        Fortran Forum, BCS, NAG,..

From:      John Reid

Subject:   X3J3 meeting in Liverpool

Date:      19 August 1987

Note:      This is a personal report of the meeting and in no sense does it

           constitute an official record of it.


References:    [1]  ISO/TC97/SC22/WG5 N254. Liverpool resolutions.

               [2]  ISO DTR 9547. Test methods for

                    programming language processors -

                    guidelines for their development and

                    acceptability (Type 3).

               [3]  105(*)CDB-3. Some pseudo-random

                    thoughts on a pointer facility

               [4]  96(*)JKR-6. Names, alias pointers.

               [5]  105(16)CDB-5. MODULE approach Kanji support.

               [6]  105(16) CDB-4. Unbuffered bit I/O.

               [7]  l05(l6) JHM-01. Derived Type I/O.

               [8]  l05.JLW-4. Module for variable-length strings.

               [9]  105(*)RCA/CDB-1. Remove the EXPONENT LETTER statement.


1.   Summary


     Recent meetings have been concentrating on getting the draft standard

into a acceptable state, but this one was quite different. It

considered a fair number of technical issues that were either raised

by the ISO Working Group meeting in the previous week or which are

thought likely to be raised in public comments. The most time was

spent considering how multi-byte character sets can be accommodated,

and the Japanese observers were mandated to make a detailed

proposal. In addition, Lawrie Schonfelder was asked to make a detailed

pointer proposal, based on relaxations of ALLOCATABLE and ALIAS.


     An audit of Fortran 77 to check that it is all included

was begun and the glossary was reviewed at the request of

another ANSI committee, X3K5.


2.   Public comments


     SPARC (Standards Planning and Requirements Committee) reviewed

the draft standard at its July meeting and found that it complies with

its authorizing document. It has therefore been submitted for a 30-day

letter ballot of X3, closing on August 20. It seems likely that the

4-month comment period will be October-January. The document will be

available from Global Engineering Documents, Inc. by calling (714)

540-9870 at a price that will probably exceed $75. Private

reproduction of S8 is allowed within members' organisations.


     Three comments have already been received by X3 and passed on to

X3J3: Convex and Boeing both argued against public review of the

present draft, while IFIP WG2.5 asked for the draft to be sent out as

soon as possible.


3.   Meeting of ISO/TC97/SC22/WG5


     The ISO Fortran Working Group met at Liverpool in the previous week

and its opinions are summarized by its formal resolutions [1]. The voting

figures are both by individuals and by countries.


     The working group confirmed the action of its convenor in forwarding

S8 for processing as a draft proposed standard(28-7-0; 7-2-0). The countries

voting NO were Japan and France. It is hoped that ISO and ANSI processes

will be in step.


     The following resolutions amount to comments for X3J3:


R7:      The final standard should not contain an appendix of extensions.


R8:      Pointers should be added.


R9:      If pointers are adopted, they should be integrated into IDENTIFY or

         IDENTIFY should be dropped.


R11:     Deprecated features should be identified in the text.


R12:     Significant blanks should be reconsidered.


R14:     The index should be improved and more examples added.


R15:     References to the notes should be added to the text.


R16:     Each successive draft should indicate what changes are made.


R17:     X3J3 should look into the possibility of requiring a report on any

         size or complexity, violations by a program.


R18:     Add examples to clarify the use of interfaces.


R19:     Add a facility for very large character sets such as those of Chinese

         or Kanji.


R21:     WG5 is concerned about the use of square brackets, which are reserved

         for national use in ISO 646, in the syntax.


R22:     Restore BIT data type.


R23:     There are some detailed problems re passed-on precision.


R24:     Delete RANGE (votes of 12-10-12, 4-3-2).


4.   Responses to WG5


     On Resolution 7, X3J3 favoured eliminating Appendix F from the

final standard (17-4-11) and replacing it by some kind of discussion

document (24-6-6).


     On Resolution 12, it was decided (16-7-4) to wait until the

February meeting before reconsidering significant blanks, so that the

public comments can be gauged.


     On Resolution 22, Brian Smith and Jerry Wagener considered the

possibility of parameterizing LOGICAL to provide a facility for

bits. Though it was agreed that this would provide virtually identical

facilities to the BIT data type in Appendix F, it was not favoured by

those strongly wanting bits and the committee as a whole was undecided

(6-7-4) on whether such a proposal should be prepared for the next

meeting.


     Resolutions 8,9 and 19 were considered in more detail (see Sections 6

and 7).


5.   Test methods for programme language processors


     A draft ISO technical report [2] on test methods for language

processors was considered by the committee and did not provoke any

detailed discussion.


6.   Pointers


     Carl Burch [3] suggested the provision of pointers through

allowing recursive data structures, permitting objects to have both

the ALIAS and ALLOCATABLE attributes, allowing an ALIAS to move from

host to host, and extending ALLOCATE to scalars. In fact, this is very

similar to a proposal [4] that I placed before the committee about two

years ago. This approach has the merit of requiring comparatively

little change to the draft standard. The committee wanted to see a

complete and detailed proposal at the next meeting (23-1-9).


7.   Multi-byte character sets


     There was a very long discussion on how to accommodate a request

from Japan for facilities that handle character sets containing many

thousands of different characters.  Carl Burch [5] suggested a module

containing a type NCHAR(LENGTH) that contains LENGTH 2-byte

characters, preceded and succeeded by 3-byte escape sequences. The

escape sequences allow CHARACTER and NCHAR data to be mixed freely on

output, using A format. However, there are problems over specifying

field widths in formats, defining constants, and assigning to

substrings. These led the committee to reject the approach (1-27-5). I

was the one person to vote in favour, believing that there was room

for detailed improvement and that we should look to enhancing the

module facility. It was decided that the best approach is to

parameterize CHARACTER, and the Japanese were asked to provide a

detailed proposal for the next meeting.


8.   Unbuffered I/O


     There was a discussion of unbuffered I/O, along the lines of

CDC's BUFFER IN and BUFFER OUT, but without the asynchronous aspect,

see [6]. A straw vote (l2-7-13) was mildly in favour of the subgroup

pursuing this.


9.   Derived Type I/O


     Jim Matheny [7] asked the committee to consider whether further

facilities for derived type I/O were needed.  Currently, a structure

is simply treated as a list of its ultimate components. More general

output is available by placing a character function in the output

list, but nothing comparable is available for input. None of the ideas

discussed seemed to be entirely satisfactory, and the committee

decided against having a proposal for the next meeting (2-11-7).


l0.  Glossary


     John Wood, chairman of X3K5, wishes to include a Fortran glossary

in the proposed American National Standard Dictionary for Information

Systems (ANSDIS) and has been looking at the Fortran 8x glossary of

May 1986. He would really like a glossary that covers both Fortran 77

and Fortran 8x, but the editorial subgroup felt that working on a

Fortran 77 glossary ten years late was inappropriate. It therefore

decided instead to take advantage of Wood's comments to improve the

Fortran 8x glossary and include notes on terms whose meaning was

different in Fortran 77. A revised glossary will be brought to the

next meeting.  Kurt Hirchert was appointed as Vocabulary

Representative and will liaise with John Wood.


11.  Fortran 77 audit


     All the subgroups began an audit of Fortran 77 to check that it has

all been included.


12.  Editorial work


     The editorial subgroup considered some suggested editorial changes,

most of which were approved by the Committee. A list of such approved

changes will be maintained.


     The subgroup also reviewed which parts of the document were in serious

need of rewriting. The final list consisted of source form, IDENTIFY,

DO constructs, and interface blocks.


13.  Module for variable-length strings


     Jerry Wagener [8] considered building a module for

variable-length strings based on a type containing an integer and a

character variable of fixed length. The integer holds the current

length and the character variable holds the string. The most awkward

aspect is I/O, once again illustrating that better facilities for

derived-type I/O are needed.


14.  EXPONENT LETTER statement


     The EXPONENT LETTER statement has been criticized as being a clumsy

solution to a minor problem. Bob Allison and Carl Burch [9] therefore

considered two possibilities for its deletion, illustrated by the examples


     REAL(PRECISION=10)::A,B,C,'L'

and

     REAL(PRECISION=10,EXPONENT LETTER='L')A,B,C


both of which introduce undesirable irregularities. A straw vote (6-8-4)

indicated that the committee did not feel that the current syntax presents a

problem.


15.  Next meeting of X3J3


        The next meeting of X3J3 will be in Fort Lauderdale, November 9-13. The

premeeting distribution deadline is October 5.


P.S. For those who wish to see an informal description of Fortran 8x. Mike

Metcalf and I have written a book called "Fortran 8x Explained", which will
be available in November, published by OUP.


                                                              APPENDIX B

Oxford University Coat of Arms


OXFORD SCIENCE PUBLICATIONS


                         Fortran 8x Explained


Michael Metcalf, Data Handling Division, CERN, Geneva,

Switzerland, and J K Reid, Computer Science and Systems

Division, Harwell Laboratory, Oxon, England



The undoubted success of Fortran as the predominant

programming language in the field of scientific and

numerical computing is due in part to the steady evolution

of the language. Following the publication of the first two

standards of 1966 and 1978, the technical committee

responsible for their development, X3J3, has been working

for a decade on a new standard suitable for use in the

1990s. The new standard, at present still in draft form,

will contain the new features required for large-scale

computing on modern supercomputers, but still retain all of

the familiar features which have made the language so

popular.


This book is a description of this new language, for the

moment called Fortran 8X. It is intended to provide

potential users of the language with a comprehensive guide

to all its features, so that they can judge its merits and

prepare for its introduction. Its authors are both members

of X3J3 and have many years of experience in the use of

Fortran.





0-19-853751-4, 288 pages, November 1987, £22.50

0-19-853731-X, Paper covers £10.95



OXFORD UNIVERSITY PRESS

WALTON STREET, OXFORD, OX2 6DP TEL (0865) 56767




                                                                                   APPENDIX C


        Fortran Compilers on Modestly Parallel Processors


Dave Griffiths,

System Software Factors

1st October 1987


System Software Factors is a small software _house specializing in writing

program development tools for attached processors. An attached processor is

typically modestly parallel.


1 What Is A Modestly Parallel Attached Processor?


Basically it's a go faster box for a general purpose mini or supermini computer.

They may even be attached to an IBM PC though more usually they are added to

VAXes. They may be bought for a specific application such as signal processing

or simulation, they may be bought to speed up any compute or memory bound task.

They cost from 20,000 to 500,000 and run Fortran benchmarks at from 1 to 10

MFlops (Millions of Floating point operations per second) Although special

purpose math library routines can be much faster.


The host machine handles the I/O and the AP gets on with the computation.


2 Architectural Overview


The modest parallelism is due to one or more floating point arithmetic units

operating in parallel with an address generating processor and possibly a

control processor. A massive cross-bar is used to connect the inputs and

outputs from the arithmetic unit to the memory and register banks. The whole

thing is driven from a large or very large instruction word. Much of the

instruction word is taken up with the control of the cross bar, enabling data

paths to connect registers with each other and the arithmetic units. In fact

the inputs to and outputs from the arithmetic units and memories can also be

treated as registers. Frequently the cross bar is incomplete due to lack of

space in the instruction word or physical limitations in the hardware, the

ability to connect anything to anything through the cross-bar greatly assists

the code generators optimisation strategy.



Architecture diagram


3 Developing Fortran Programs For An Attached Processor


Ordinary FORTRAN programs can be compiled and executed in an AP under the

control of the host machine. The microcode generated by the Compiler is

optimised to make excellent use of the AP architectural facilities. The main

features of the FORTRAN Development System are as follows:


        * The FORTRAN Compiler produces modules of optimised AP microcode.


        * A program can be controlled from the host using the symbols that are

         contained in the FORTRAN program.


        * A program can be exercised in the AP using a symbolic debugger.


        * The Fortran development suite offers two libraries. One library is

         used to link with the AP program and contains code for the intrinsic

         routines such as SIN and LOG; the other library contains all the

         routines required to drive the loading, data transfer and execution

         control of an AP program. These routines are written in FORTRAN and

         are intended to be included in a user written host FORTRAN program.


The FORTRAN Development System consists of:


        * FORTRAN Compiler

        * Linker

        * Symbolic Debugger

        * Librarian

        * Runtime support library

        * Host interface library



Stages in the Program

Development Process

Development stages diagram


3.1 The FORTRAN Compiler


The Compiler accepts a restricted set of FORTRAN 77 statements and converts each

FORTRAN module into a separate module for linking. Broadly speaking, the major

restrictions are that there are no input or output facilities in the FORTRAN

language dialect. Included in the output module are executable code and data

values, and symbolic information for use by the Symbolic Debugger and host

control program.


The FORTRAN Compiler endeavours to make full use of the AP architectural

facilities; in particular it will overlay the evaluation of FORTRAN statements

one with another in an attempt to keep both arithmetic processor and data

highway pipelines busy. In addition, it makes use of a sophisticated register

management technique to hold as much information as possible in the fast

registers.


The compiler supports a very rapid through-the-register access to most of the

intrinsic routines such as SIN, COS, EXP, SQRT etc, and in some cases generates

inline code for these references, for example REAL, INT and NINT.


3.1.1 Optimisation


The compiler applies a range of optimisation techniques to enable it to produce

faster run-time code. These can be divided into two classes:


        General Optimisations


                Strength Reduction

                Compile-time Arithmetic

                Common Sub-expression Elimination

                Array Addressing

                Redundant Code Elimination


        Loop Optimisations


                Loop Counter

                Code Motion

                Loop Index

                Register Usage

                Loop Elimination

                Addressor Registers


3.1.1.1 Strength Reduction


Some computationally expensive calculations can sometimes be performed more

cheaply by respecifying them in a functionally identical, but computationally

different way. A list of all strength reduction cases which will be optimised

follows ('i' represents an integer variable, and 'r' a real variable) :


        i + 0  -> i                r   + 0.0  ->  r

        0 + i  -> i                0.0 + r    ->  r       


        i - 0  -> i                r   - 0.0  ->  r

        0 - i  -> -i               0.0 - r    -> -r


        i * 0  -> 0                r   * 0.0  ->  0.0

        0 * i  -> 0                0.0 * r    ->  0.0

        i * 1  -> i                r   * 1.0  ->  r

        1 * i  -> i                1.0 * r    ->  r

        i * 2  -> i + i            r   * 2.0  ->  r + r

        2 * i  -> i + i            2.0 * r    ->  r + r


        i / 1  -> i


        r / 1.0               -> r

        r / <constant>        -> r * <reciprocal>


        i ** 0  ->  1             r   ** 0.0 ->  1.0

        i ** 1  ->  i             r   ** 1.0 ->  r

        i ** 2  ->  i * i         r   ** 2.0 ->  r * r


3.1.1.2 Compile-time Arithmetic


This is the calculation at compile-time of all expressions and sub-expressions

containing only constants. For the sake of clarity a programmer often uses

constant expressions, or PARAMETER based expressions to express other constants.


        eg      PARAMETER (HMAX=1000.0)

                PARAMETER (HMIN=10.0)

                        .

                        .

                        .

                HRANGE = MAX - HMIN


The HRANGE expression is '1000.0-10.0' on arrival in the Optimisor and will be

'990.0' on exit. The compiler itself generates constant expressions when

performing array subscript calculations, and when calculating the number of

times to execute some loops.


3.1.1.3 Common Sub-expression Elimination


Multiple calculations of the same expression within a block are prepared by the

Optimisor as a single expression, which is referenced several times.


3.1.1.4 Array Addressing


Any constant part of an array subscript is incorporated into a modified array

base address. In the case of the subscript being constant, the array access is

made to look identical to a simple variable access.


3.1.1.5 Redundant Code Elimination


All code following a 'RETURN' or 'GOTO' instruction will be ignored until a

label or entry point occurs. A special case is where a test in a conditional

statement has been evaluated at compile-time to '.TRUE.' or '.FALSE.'. The test

can then be discarded and the subsequent statement processed or ignored. This

can be useful for debugging purposes where a debug flag may be initialised in a

PARAMETER statement.


        eg      LOGICAL DEBUG

                PARAMETER (DEBUG = .TRUE.)

                        .

                        .

                        .

                IF(DEBUG)CALL TRACE(X,Y,Z)


Also note that less block-splitting will be needed if some conditional

statements can be discarded.



3.1.1.6 loop Optimisations


Loop optimisations are only considered for the inner-most loop. This

restriction is imposed for several reasons :


        * complexity, especially of a comprehensive multi-loop code migration

          scheme.


        * difficulty in correctly allocating registers to the most needy objects

          if more registers are required than are available.


        * most benefit is to be gained by fully optimising the inner-most loop.

          It is important not to compromise those optimisations in an attempt to

          provide other, less effective optimisations.


        * sensibly written code seldom benefits at all from multi-loop

          optimisations.


3.l.l.6.l Loop Counter


The compiler-generated loop counter is maintained in a register. The counter is

initialised to the number of times the loop must be performed, and decremented

each time round.


3.l.l.6.2 Code Motion


Invariant statements are removed from the inner-most loop. If the result of an

invariant assignment is used within the loop, then that value is maintained in a

register for the duration of the loop. Invariant expressions are also removed

and their value assigned to registers throughout the loop.


3.l.l.6.3 Loop Index


The loop index (ie the program loop counter) is maintained in a register

throughout the loop and written to store on exit from the loop.


3.l.l.6.4 Register Usage


As we have previously discussed, registers are used to hold the loop index, and

the results of migrated objects, for the lifetime of e loop.


3.l.l.6.S Loop Elimination


There are two cases when a loop can be eliminated. The first is when the loop

index count can be calculated at compile-time, and its result is not positive.

The second is when all the code in the body of the loop has been migrated (or

there was no code in the body of the loop) and the loop itself can then be

discarded.


3.l.l.6.6 Addressor Registers (SPADs)


Addressor registers are used to access arrays within loops whenever possible.

Most loop array accesses are indexed by a function which is invariant,.except

for the loop index ( eg a(i), a(i+2), a(i,j) ). In this case it is possible to

set up, for each array access within the loop, an initial address pointer and an

address increment expression. A constant increment expression of one is a

special case, which may be mapped on to special addressor register increment

instructions on some machines, and so must be treated differently. As

previously discussed, addressor registers are only used within the innermost

loop.


3.2 The Linker


The purpose of the Linker is to combine modules created by the FORTRAN Compiler

into an executable AP program. The Linker can be used to include routines from

Math Libraries as well as from user generated libraries. User generated

libraries are created directly from FORTRAN or from assembler compilations, or

faster access libraries can be created using the Librarian utility.


In most cases, the user requires the Linker to produce a loadable binary program

which is loaded into the AP program source memory and then executed by the

symbolic debugger or control program by way of either the program entry point or

by a subroutine entry point. To cater for these needs, the Linker outputs

symbolic information describing each object, whether common or local, and its

dimensions. For the symbolic debugger, the Fortran compiler has to create

trace-points in the binary program so that the symbolic debugger can control the

allocation of trace-points and break-points.


To give access to the intrinsic routines, overlay handler and debugging

routines, System Software Factors supply a run time support library which must

be included in the link process.


3.3 The Symbolic Debugger


This is an extremely powerful tool for debugging an AP program. It can be used

in FORTRAN mode or in APAL mode to offer the facility of both high and low level

debugging. In the FORTRAN mode it can be used to control the execution of the

AP program in terms of tracing on labels and module entry points, and for

setting breakpoints at these places. All access can be symbolic, and can

include dimensioning. This even applies to dummy arguments which are

dynamically dimensioned by further dummy arguments. Another very powerful

facility worth emphasising is the evaluate facility which allows the user to

evaluate expressions involving typed AP program data items, including complex

arithmetic and using intrinsic routines. The result is to make the debugging of

AP programs a relatively simple task, and it can form an excellent alternative

to debugging the AP program in the host environment.


                       Summary of Symbolic Debugger Facilities


- help

- allot an AP

- initialise AP memories

- open binary file

- load program

- deposit data in AP memories

- journal file

- run program

- run subroutine

- set trace points

- set break points

- continue execution from breakpoint

- view data items

- print data items in journal

- change radix

- dictate form of floating point display


3.4 The Interface Control Library


This is a library of host routines, written in host FORTRAN, whose purpose it is

to supply control of the AP program to a host FORTRAN or other language program.

The control library offers the following facilities:

        * AP program segment loading


        * data transfer and conversion


        * symbolic access of subroutine names


        * symbolic access of common or data names


        * control of AP program execution through parameterless subroutine or

         program entry points.


The symbolic access of data and subroutine names is a very powerful one for the

user in that the user is not concerned with the problem of data memory

addressing; during program development, changes to the AP program do not

necessarily imply a recompilation or a rebuild of the host control program.


4  Compiler Structure


The Fortran development suite is coded entirely in 'C'. This is because the 'C'

language is very suitable for the development of system software and is widely

available. Our initial assumption that this would of itself make the Fortran

development system easily portable to many host computers proved to be naive and

SSF has spent several years acquiring a grab bag of utilities to ease this

portability problem. The most important of these is the SSF portable library of

'C' utilities. The porting work has now been focused into implementing this

library. The software has been implemented on many host computers including VAX

(VHS and ULTRIX) IBM PC, GOULD, CCC and various UNIX machines.


The compiler is composed of five phases which communicate via a temporary file

which is managed by a set of utilities called the workstream manager. On small

machines such as the IBM PC each of these phases is a separate program.



Compiler Structure


Structure diagram


4.1 The Frontend


This inputs the source files and generates listing and map information. The

executable code is passed on to the optimiser in a polish prefix notation.

Symbol information is sent to the microcode writer for inclusion in the object

file for later use by the debugger and host interface routines.


4.2 The optimiser


This performs the classical compiler optimisations. These are:


        * Compile time arithmetic

        * Strength reduction

        * Common sub-expression elimination

        * Invariant code migration

        * Redundant code elimination

        * Flagging loops as being suitable for a loop counter.

        * Flagging variables which could usefully be kept in registers.

        * Flagging array references which could make use of address registers.


4.3 The Microcode Generator


The Microcode generator knows the architecture of the target machine. ic

performs machine dependent optimisations such as:


        1. Performing logically independent operations in parallel and keeping

           pipelines full.

        2. Trying to use intermediate results immediately. Where this is not

           possible, using registers to store the intermediate results.

        3. Making use of specific hardware features such as, loop counters an

           address registers with auto increment.

        4. Using fast interfaces to intrinsic routines, knowing which registers

           are used by the intrinsics and making use of the others to save

           temporary results across the intrinsic call.

        5. Making use of information which the user may provide about the argument

           usage of subroutines and functions. For instance if the subroutine

           uses an argument as input only, it may be passed by value thought a

           register.


4.4 The microcode writer


The microcode writer contains a database of the layout of the AP's microcode

instruction word. It uses this to sent the instruction sequences from the

mircrocode generator to the object file.


4.5 The Listing manager


The listing manager collates the listing information from the various phases of

the compilation and sent it to the listing file.