BRITISH COMPUTER SOCIETY - FORTRAN SPECIALIST GROUP
Minutes of meeting held at University of Salford Computing Centre on
Monday, 30 November 1981
Present: J A Blair-Fish Edinburgh Regional Computing Centre
S G Brazier Structural Dynamics
R Carpenter Hydrographic Dept MOD
P A Clarke Rothamsted Experimental Station
J L Dyke H.R.C.
J D Hargreave University of Salford
C K Mackinnon UKAEA Risley
D T Muxworthy University of Edinburgh
A R Norway BP Oil Ltd
T D Palmer Compower Ltd (N.C.B.)
A Swarbrick UMIST
L M Swarbrick Ferranti Computer Systems Ltd
D M Vallance University of Salford
T L Van Raalte MOD
(CHAIRMAN) J D Wilson University of Leicester
1. APOLOGIES FOR ABSENCE
Apologies were received from Dr R E Thomas and Mr P D Bond.
2. MINUTES OF PREVIOUS MEETING [7 September 1981]
The Group recorded its thanks to Mr Van Raalte for taking the minutes
at the previous meeting.
3.1 "The Treasurer_is still unavailable ...
5. (4th paragraph) "Brian Meek offered to contact Richard Field ...
7.1 (line 2) ... Fortran-to-Ada conversion ...
3. MATTERS ARISING
Item 3.1 The Treasurer is still unavailable to complete the Continuing
transfer of the agreed donation. Action
J Roberts-
The organising committee has acknowledged our Jones
support for the meeting in a letter to the Chairman.
Item 7.2 Dave Vallance has sent information on the Salford
Fortran 77 compiler for GEORGE3.
Item 8 The Secretary has apologised to Brian Shearing for
the confusion over his speaking at Salford. He
will now speak at the meeting on 1 February 1982.
4. BCS BUSINESS
The Chairman attended the meeting of the Specialist Groups' Board on
10 September 1981.
All Specialist Groups have been asked to submit budget requirements
for 1982 by December 1981. We have sent a preliminary requirement
to the BCS which includes a request for some funding for speakers' and
certain committee members' expenses.
Two new Specialist Groups had been formed. They were
Technology of Software Protection
Computers in Primary Health Care
The meeting was concluded with discussion on liaison between Specialist
Groups and Local Groups.
There was very little Fortran business of note.
Some points of interest were
- The People's Republic of China has adopted the Fortran (77) Standard.
- Japan votes purely on financial grounds
Zavie Miller (Canada) is hoping to get funding for a PFORT77 verifier
to be written in Fortran 77.
There will be an ISO Fortran experts meeting in Vienna in June 1982.
X3J3 will have completed the core proposals for Fortran 8X by
February 1982 and will want to have feedback from the user community.
David Muxworthy would like to hear from anyone who can participate in
the evaluation of the X3J3 'S6' document in order to produce feedback
for the Vienna meeting. (It is hoped to do much of this by mail to
avoid excessive travelling expenses.) Participants will obviously be
welcome at Vienna providing they can obtain funding from their own
sources. (David Muxworthy, Room 2609, Kings Buildings, University of
Edinburgh, Mayfield Road, Edinburgh EH9 3JZ.)
Exactly 100 people attended the Forum.
The Forum was a success from the organisational viewpoint and publicity
was adequate although it was noted that BCS Information seemed to be
unaware of the Forum one working day before it took place. Most
delegates seemed to feel that the Forum was worthwhile.
The Chairman expressed his thanks to all involved both as speakers and
as administrators. Mr Vallance thanked the organising sub-committee
on behalf of the rest of the group.
The Edinburgh Forum was equally successful.
There was discussion on the reasons why Fortran 77 has not yet fully
permeated the user community. It was felt that manufacturers had
not yet produced compilers which were as good as existing Fortran 66
compilers and that users had yet to be convinced that they needed the
new features of Fortran 77.
It was felt that a set of abstracts from the Forum should be circulated.
It was noted that the 'S6' document would provide much of the technical
background. 'Weathervane', produced by Loren Meissner, is a more
readable version than S6 itself. Copies of the 'S6' document are
available from D M Vallance, Computing Centre, University of Salford,
Salford M5 4WT at a cost of E5.00 to cover the costs of photocopying
and postage.
Owing to financial stringencies, five of the six members of the X3J3
Steering Committee are now under threat of having no funds to attend
the X3J3 meetings. Many Subgroups are poorly supported with often only
2 or 3 members.
The main technical problem is still the content of the 'core'.
8. ANY OTHER BUSINESS
The next meeting of the Group is at BCS Headquarters on Monday,
8 February 1982, at 10.45 a.m. NOTE this is not as agreed at the meeting.
9. AFTERNOON SESSION
Mr D M Vallance, Computing Centre, University of Salford, gave a talk
entitled 'Portable Fortran 77 Compilers'. A summary of the main points
of this talk appears as Appendix A to these minutes.
APPENDIX A FORTRAN 77 COMPILER PORTABILITY
D M Vallance, Computing Centre, University of Salford
A starting point for any system is a statement of the features and
performance that are required. For a good Fortran 77 compiler, these
are:
- Fast compilation speed
- Small size
- Efficient object code and optional optimisation
- Good compile-time diagnostics (English messages)
- Run-time debugging and diagnostics
- Run-time statement count (profile)
- Source language compatibility with existing Fortran 66
compiler
- ANSI checks as an option
- No arbitrary restrictions on complexity of statements,
number of labels, etc.
- Cross reference and storage map available
- Easy maintenance and development
- Good documentation (inside and out)
Software is very expensive to produce and even more expensive to
maintain and transport to new hardware. Even today, compiler writing
is considered by many people to be 'different' but, in reality, a
compiler is just another applications program whose output depends on
the particular hardware for which it is targetted.
Many Fortran programmers are not concerned with the mysteries of the
operating system or hardware but simply with productivity - how quickly
can a program be developed and debugged. To this end, the Fortran 77
compilers written at Salford try to present the user with a 'Fortran
machine'.
Why do we want a portable compiler? Software costs are rising, and
there is little sense in rewriting a whole program for new hardware
when only a part of it need be altered. The reasons can be summarised
thus:
- Economy
- Fewer bugs found and fixes can be applied
across a variety of hardware
- Easier to port applications if the same compiler
is found on a variety of hardware
In an ideal world, all hardware would support the same order code, and
every user would write standard-conforming programs in Fortran 77. In
the world in which we live:
- Almost every architecture is different
- Every linking loader has its own idiosyncrasies
- Every vendor's users want extensions which are
never quite the same as everyone else's
So we are presented with a moving target and clearly only a part of our
compiler can be totally portable. This part is, nevertheless,
substantial. For the remainder, we are left with two main practical
(as opposed to academic) approaches:
- Generate intermediate code (such as P-code)
which can be post-processed into relocatable
binary form for the target hardware.
- Generate relocatable binary code directly
from internal form
We choose the latter approach as it leads to more efficient object code
for the target hardware.
Most Fortran compilers are either good at diagnostics or claim to
produce very good object code. (There are also quite a few which are
capable of neither!) Traditionally, universities have produced the
former, mainly for teaching purposes, and manufacturers and software
houses have produced the latter. The two approaches can be combined
by allowing the user to choose, by means of compile-time options, which
facilities he wants (for example, DEBUG, ANSI, OPTIMISE and so on).
There is very little contemporary software that is not written in a
high-level language and our compilers are no exception. We have used
Fortran (77) as an implementation language (some, no doubt, would argue
that this is not a high-level language!) for the following reasons:
- Fortran 77 is an approximate superset of
Fortran 66 which is almost universally available
- It is easy to find programmers who can exploit Fortran
- Using your own software (this implies the compiler must
support itself and is bootstrapped) is a very good way to
get it debugged quickly.
It is interesting to note that many of the commonly available languages
have been used to implement themselves (PASCAL, C, ALGOL 68, BCPL) so
as to produce portable compilers.
It is worth noting the extensions (inevitably!) that we have added to
Fortran 77 in order to write a compiler. A compile-time option (ANSI)
exists in order that these extensions can be flagged.
- CODE/EDOC (in line assembly code) This facility uses the
assembler syntax and mnemonics of the target hardware.
(We have now admitted that not all the compiler is Fortran
but we have calculated the amount of assembler at less than
5% of the compiler.)
- EXTRA INTRINSIC FUNCTIONS such as AND, OR, NOT etc. These
functions are implemented so as to produce in-line code
rather than a procedure call and are thus efficient.
Compilation speed could be sacrificed by using external
functions for the purpose.
- INTERNAL PROCEDURES mean faster compilation speed. They are
implemented by using a GOTO as a call and an
ASSIGNed GOTO as a RETURN.
- OCTAL AND HEXADECIMAL CONSTANTS
- WHILE STATEMENT
None of the above extensions are vital to compiler development but all
are obviously convenient.
In order to achieve fast compilation speeds we use one-pass compilation.
The source program is thus read once, and all subsequent operations on
it are performed in store, usually on a statement-by-statement basis.
The text books describe this technique in a way which is not applicable
to modern hardware which typically has a much larger main store
capacity than was the case even a few years ago. This larger main
store, and consequent removal of many 'traditional' constraints, allows
us to do a great deal in a one pass compiler that makes it look
somewhat like a multi-pass compiler.
The internal data structures in the compiler almost all use a basic
unit of l6-bits. Data structures fall into two main categories:
- Those which are simply lookup tables of some kind such
as the intrinsic function table, error message list and
the instruction table for the code generator. These
tables are converted from human readable text files into
Fortran DATA statements for the compiler by a number of
utility programs. Thus it is possible to edit text and
yet give the compiler a data structure in a form to which
access is most efficient.
- Those which are generated during compilation such as the
symbol table, syntax trees, stacks and logical line buffer.
These structures, all formed of 16-bit words, are organised
in such a way that part of the stack can, for example,
masquerade as part of the symbol table or as a
logical line buffer. It is thus possible to generate,
for example, pseudo statements, which look
a bit like Fortran text and are thus machine independent,
in order to generate text for variable array bounds and
subroutine entry code.
Further discussion of compiler internals is perhaps out of place here.
The Fortran 77 library is a major project in its own right. It is
written in Fortran and assembler is only used in critical or awkward
places.
- Intrinsic functions such as SIN, EXP etc are thus almost
wholly portable and are a good compiler test.
- Many input/output routines need work to interface them
properly to a new operating system, but the basic structure
remains the same.
- The debugging and error trapping facilities must usually
be rewritten for a new implementation.
How do we start afresh when required to retarget the compiler for new
hardware. There are two possibilities:
- All the source code is transferred to the new machine and
attempts are made to compile it with the existing Fortran
compiler. If the existing compiler does not support
certain features, a pre-processor is written and used to
massage the compiler source.
- Work continues on the existing host machine until the
bootstrap stage. This is more viable for micros as we
probably want a cross-compiler as well.
What have we achieved? The compiler was originally written for ICL
1900 Series (24-bit) and is now available on PRIME 50 Series (16-bit).
- 95% of the code is Fortran (77)
- 70% of the code is totally portable after bootstrapping.
Much of the remainder only requires minor modification.
- 8-9,000 lines per minute compilation speed is averaged
on a 1 MIP machine and the object code produced for user
programs is at least as fast as that produced by the
manufacturer's existing Fortran 66 compilers.
- We feel the compile-time diagnostics and optional run-time
diagnostic facilities are second to none.