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.
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
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.
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.
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
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.
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
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
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.