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.


5.     ISO MEETING


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


6.      FORTRAN FORUM


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.


7.      X3J3 BUSINESS


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.