British Computer Society - Fortran Specialist Group
Minutes of Meeting held at BCS Headquarters on Monday, 8th September 1980
Present: G. L. Harding (Chairman) ECMWF
D. Anderson St. Thomas' Hospital
P. A. Clarke Rothamsted Experimental Station
P. Craggs Hydrographic Dept., Taunton
J. L. Dyke Huntingdon Research Centre
D. A. Franklin Logica Ltd.
D. J. Holmes Rolls Royce Ltd., Bristol
J. Larmouth Salford University
C. Lazou University of London Computer Centre
D. H. Marwick Heriot-Watt University
J. D. Murchland 35 Rectory Park, Sanderstead, Surrey
D. T. Muxworthy Edinburgh University
K. Normington Coventry Polytechnic
M. Nunn CCTA
G. O'Llions Shell International
N. Price Shell International
L. van Raalte M.O.D.
J. D. Wilson (Secretary) Leicester University
1. Minutes of Previous Meeting [27 May 1980]
The minutes were approved.
2. Matters arising
Contrary to the statement at the end of section 4.1, it appears that ANSI
have initiated a participation fee of $100 per annum for principal and alternate
and $50 per annum for observers. It was agreed that the Fortran Specialist Group
would pay for one copy of the X3J3 minutes. The minutes and any other X3J3
literature available will be kept by D. Muxworthy: a list of all documents held
will be maintained by the group secretary.
3. X3J3 Activities
A. Wilson sent his apologies for not being able to attend to report on the
recent X3J3 meeting. B. Meek expects to attend the Fort Lauderdale meeting,
13th-17th October 1980.
J. Murchland said he felt X3J3 should address the weaknesses and shortcomings
of FORTRAN 77 with a view to revising it before defining a new FORTRAN 8X standard.
The main items of concern were:
- no INTEGER*4 etc. facility
- lack of a generalised DO loop
- lack of NAMELIST
- zero-trip DO
The last item can be dealt with by a compiler option but there is no standard way
of communicating with the compiler.
D. Franklin was concerned that there was no acknowledgement of analogue -
digital conversion requirements in the language.
J. Murchland agreed to collect together problems encountered with FORTRAN 77
compilers with a view to submitting an article for SIGPLAN Notices.
A list of new language features recently provisionally adopted by X3J3
was given in the latest edition of FOR-WORD. It includes the following:
- variable-length Character Type
- Intrinsic Functions for Character handling
- global "COMMON" declaration
- generalised precision attribute
- variable array subscripts within declared range
4. Other Fortran Group Activities
4.1 ISO Fortran Experts Meeting ( - Amsterdam October 20th-23rd 1980)
The U.K. delegation is expected to be A. Clarke, J. Reid, D. Muxworthy
and L. Schoenfelder (1 day). Anyone else interested is asked to get in touch
with D. Muxworthy. The items of particular interest to the U.K. are:
- significant blanks
- core-plus-modules, mechanism and interfaces
- error handling and structure of the core
- numerical precision
- Completeness or Conformity Module Proposal
J. Murchland pointed out that IEEE have published a very detailed and specific
proposal for numerical precision in the January 1980 edition of the IEEE Computer
Society's Journal "Computing". This is quite different from either Reid's or
Smith's proposal but is based on new hardware.
Completeness/Conformity Module
A. Clarke discussed a number of prepared questions and answers on the Module.
A modified version is given in Appendix A. J. Larmouth questioned the desirability
of a separate module rather than going through the FORTRAN 77 text and filling in
the gaps.
4.2 Fortran Forum
In view of the fact that the Dutch Group are holding a Fortran Forum on
Friday 24th October 1980 and the difficulty in arranging a British Forum on
a suitable date, it has been decided simply to arrange the next Fortran
Specialist Group meeting for Monday 27th October 1980. This will be mainly
to report and discuss the ISO meeting and it is hoped a number of X3J3 members
will be present. A detailed agenda and notice will be published in the Computer
Press.
5. BCS Business
5.1 BCS 80 (incorporating Datafair) will be held on lst-3rd July 1981 at the
Institute of Education, London. A call for papers has been made; Abstracts
by 21st November 1980; full paper (5000 words approx.) by 14th February 1981.
Details may be obtained from G. Harding.
1982 is the 25th anniversary of the BCS. Jubilee celebrations are being
organised. The AGM on 14th October 1982 will be combined with a technical
conference on the theme "The next 25 years".
5.2 The Algorithmic Languages Group has been re-formed to represent Algol 60,
Algol 68, Pascal and ADA. Several members of the Fortran Specialist Group
objected to this title which, it was felt, should thereby include Fortran!
6. Any Other Business
(i) IBM have announced a new compiler which will support FORTRAN 77.
(ii) A complete index to FORTRAN 77 has been published as a NPL Report -
details from J. Murchland.
7. Next Meeting
The next meeting will take place on Tuesday 28th October 1980 at the
BCS Headquarters (see 4.2 above).
N.B. The meeting was originally arranged for Monday 27th October but has
been changed to avoid a clash with a meeting in Oxford.
Draft Question-Answer notes about Conformity Module proposal
Q1. Does the Conformity Module prevent a supplier from extending Fortran as
he pleases?
A1. No, it does not. The Conformity Module is an optional module. If the
user does not request its invocation, then the Fortran system may be
exactly the same as current implementations, i.e. standard Fortran plus
supplier extensions.
If the user does invoke the Conformity Module then it is likely that this
would prevent some extensions.
Q2. Is the Conformity Module much of an overhead?
A2. No. Most of the features in the Conformity Module already exist in most
implementations. The efficiency of Fortran should not be affected
significantly.
Q3. Does the Conformity Module trap all non-standard occurrences (or all non-
standard status conditions)?
A3. No. It is currently impractical to do this for reasons of efficiency etc.
The proposal will include two lists, GREEN and RED: Items on the GREEN list
will be trapped and handled, items on the RED list may or may not be included
depending on the consensus view of the standards committee - some implementors
may have difficulty implementing these, many items almost certainly will not
be included because of efficiency reasons or because they are outside the
scope of current processors or because they require re-design of some core-
Fortran feature. The long-term aim of the conformity module proposal is
to be able to trap as many non-standard status conditions as possible but
this will not happen overnight.
Q4. Will the Conformity Module put restrictions on implementation methods
e.g. in the way statements must be passed or whether statements must be
compiled or interpreted?
A4. It may cause some restrictions, but it is hoped that the features included in
the GREEN list will cause very few.
Q5. Will the Conformity Module hinder the future development of Fortran?
A5. No. It may help it. By making it easier for users to ensure their programs
are standard conforming, it will contribute to upwards compatibility of
programs. It will also highlight those features of Fortran which have been
designed without regard to safety and perhaps stimulate some improvement.
Q6. Can a supplier extend the Conformity Module?
A6. Yes. It's just the same as any other module in this respect. At the next
revision of the standard suppliers extensions may find their way into the
standard Conformity Module. Because of the restrictive nature of the
Conformity Module, extensions could only take the form of additional restrictions
Q7. Is the Conformity Module a debug package.
A7. No, not primarily. The main aim is to ensure conformity and safety. Debugging
may become slightly easier where a program is being developed on several
different machines at one time - because of greater consistency between
the processors. In general, debugging facilities in current processors
need not be changed.
Q8. Can a program be standard conforming without the Conformity Module?
A8. Yes it can. A standard conforming program.need only conform to the
Core-Fortran specifications.
Q9. Could the majority of implementors agree on the content and actually
implement this module?
A9. Yes. The items on the GREEN list have been implemented by a majority of
implementors already. If there are any serious problems with an item on
the GREEN list, it could be removed from the list. The GREEN list will
still contain a substantial number of items on which a consensus exists.
A. Clarke
10.9.80
PORTABILITY OF FORTRAN 77
(Edited version of notes taken by J. Murchland
of a discussion by J. Larmouth, Salford University)
1. The NBS Study
The United States National Bureau of Standards placed a contract with
Salford University for a a portability study of Fortran 77. The study has
taken a year, is largely complete, and will be published at least as a NBS
Software Engineering Handbook - contact J. Larmouth for details. (Of course
part of the impetus for placing the study was Dr. Larmouth's double article,
'Serious Fortran', Software - Practice and Experience 3 (1973) 87-107 and
197-205.)
Excluded from the study were:
- the Fortran 77 language per se,
- Fortran 66 compatibility,
- the Fortran 77 subset.
It was concerned with:
- bugs in F77 compilers, that is standard conforming F77 programs
that a particular compiler won't accept,
- identifying, and rejecting, extensions made to the F77 language,
- establishing rules which ensure portability.
The study looked at 10 individual compilers, 3 originating in the UK and
7 in the USA. (The IBM compiler, which has only just been announced, was not
included.) The individual compilers will not be identified in the final report.
It should be noted that many of the bugs found will be corrected by the suppliers
At this time there is a test suite for the Fortran 77 subset, but not for
F77 itself.
2. Bugs found and their avoidance
The study developed ten or so short programs which, between them, defeated
every compiler.
Some of these bugs arise from the difficulty in distinguishing between
character and non-character arguments to subprograms. In F77, a character
argument must be passed as an address and a length. Ambiguities may arise if
non-character arguments are not also accompanied by a length-like quantity to
identify them clearly. This problem is severe for one-pass compilers.
The examples are omitted in the notes below, and only the rule for avoiding
the trouble is given.
(i) Never put intrinsic functions in a TYPE statement.
(ii) One-pass compilers have difficulty sorting out subprogram arguments of
type character. Users should declare all subprograms invoked by a
subprogram in an External statement - this is also very good for
documentation.
(iii) Problems arise with the file specifiers in OPEN statements for files
which are already open or preconnected. The only remedy is to segregate
OPENs so that they can be readily changed.
(iv) Right and left tabulations in Formats can give difficulty.
(Remember that F77 does not specify that blanks are inserted by
tabulation.) Users should avoid tabulations beyond the end of the
record.
(v) In list-directed input/output, character constants extending over
more than one line don't always work. Users should avoid this.
(vi) Some compilers won't accept a Parameter value with an exponent:
A = 3.7**6. Users must simply avoid this.
(vii) For characters it is essential to use ASCII and not ISO-7(UK).
This affects $#£ and ¢. Never use ISO-7(UK)!
(viii) Users should avoid overlapping Complex values by means of EQUIVALENCE.
(ix) Boundary alignment problems (different size of reals, integers etc.)
are inescapable and users should prevent them in the usual ways.
(Common Blocks restricted to one type only or variables in Common
Blocks in order by decreasing size or numbers of variables of particular
size or array dimensions made a multiple of 2 or 4 to ensure alignment.)
(x) Value and Reference Calls
Example
A = 4.0
CALL FRED((A),A) -- (A) to make expression
END and so pass value
SUBROUTINE FRED(B,C)
C = 5.0
PRINT *,B -- should give 4.0 not 5.0
END
Don't be clever! Use another variable.
Al = A
CALL FRED(Al,A)
(xi) Users must be aware that concatenations of substrings may overflow
(or appear to the compiler to overflow) the maximum allowed string
size in the particular compiler.
3. Extensions offered by compilers which are not Fortran 77
(i) Mixing characters and integers in storage.
(ii) Integer*n
(iii) Only one Implicit statement and only one Type statement for a variable,
and in the correct order (declaration before use).
(iv) Use distinct names for Common Blocks and for Parameters.
(v) Alternate returns from function subprograms are not part of Fortran 77
and should not be used.
(vi) Do not:
- use the extra keywords most compilers provide in OPENs,
- allow more than one program to read the same file at the same time,
- overlap Character assignments or Formats and Reads,
- output prompts to a terminal by non-standard I/O statements,
- use Namelist,
- use Encode or Decode,
- include a newline in list-directed input data within a complex
constant.
(vii) Avoid recursion.
(viii) Make no use of extended range of DOs.
(ix) Do not use Hollerith data. (Compilers will accept either the new
character datatype or Hollerith, but get very confused with both.)
(x) Call Exit or Return must not be employed in a main program.
(xi) Do not call a subprogram with an array argument which is declared
as a scalar variable within the subprogram.
(xii) Intrinsic functions must not be employed in Parameters.
4. General Portability Rules
(i) Don't exceed 255 characters in a string. (255 is the lowest value
amongst the 10 compilers examined.)
(ii) Use only those intrinsic functions specified in the Fortran 77
standard.
(iii) In each function subprogram ensure that a value is always assigned
to the function name (so that it is never left undefined).
(iv) Never allow undefined values to be copied. (For example don't read
part of a vector and then, in another subroutine, copy the whole of
it. This restriction reflects modern hardware, which may detect
reference to an undefined variable.) It may be necessary to initialize
all variables!
(v) Beware of side effects from function evaluation. Must F be called twice
in A = F(X)+F(X) (for example, when F is a random number generator)?
Even A = B*F(X) is borderline (if a zero value of B is detected and
the multiplication skipped). A safe procedure is a simple assignment
A=F(X).
(vi) Specify all floating-point constants with the largest number of digits
which could ever be relevant on any machine and in double precision.
(Fortran 77 allows this, but note that the subset does not.)
(vii) Use parentheses freely to ensure that exactly the numerical result
desired is obtained.
(viii) Provision of check-output which program must produce, character by
character, is difficult (owing to the freedom which the standard allows
in overflowed fields).
(ix) Don't assign a real value to a double precision variable in a Data
statement.
(x) Intrinsic and External declarations should be used freely. Declare
every subprogram as External (to avoid a clash with an idiosyncratic
intrinsic function which would silently replace it).
(xi) Use SAVE in every routine.
(xii) Don't make use of lists in Assigned G0 TOs.
(xiii) Do-loops on a real variable have an uncertain number of repetitions
unless the upper limit is adjusted by an appropriate rounding constant
(for an increasing loop add half the increment).
(xiv) Avoid ENDFILE,STATUS=UNKNOWN. Avoid an INQUIRE after an ERR= .
Avoid any reliance on ERR= for detecting the output of numbers which
are too large (print as ***...*).
(xv) Trap errors on NEW by first deleting. Always use REWIND at start, and
in an OPEN always specify the blank significance option (Blank = ) .
(xvi) Similarly, always specify SP or SS in Formats and don't rely on the
default.
(xvii) Don't try to be clever (unless essential).
(xviii) Don't use the + printer control character in formats to obtain
overprinting (this still has no uniform significance).
(xix) Don't assume that the DELETE keyword actually deletes a file from the
file system. (It may only detach it from the job, and hence it isn't
possible to write a private operating and file system in FORTRAN 77.)
(xx) Never use lower case characters, even in Comments.
(xxi) Use LLT not .LT. etc. for characters.
(xxii) Don't use the CHAR or ICHAR functions (except on the way, via a table,
to ASCII values).
(xxiii) Parametrize all unit numbers.
(xxiv) It may be practical to use an Include/Insert facility, even though it
is not standard. It was present in all compilers examined, and remember
that Parameters are not global to the whole program, but only local to
the subprogram in which they occur.
(xxv) Parametrize all program parameters. This new facility of F77 works and
should be employed to the full.
(xxvi) Provide complete boundary alignment (as mentioned earlier).
(xxvii) Don't use the IFIX, IDINT, FLOAT, SINGL, AMAX0, MAX2 etc. functions,
which are likely to be deleted in the forthcoming Fortran 8x.
(xxviii) Similarly, use C for comment, not *.
(xxix) Watch out for illegal definitions of the form F(A,A) when the arguments
must be different variables.
(xxx) Do not rely on shortcut evaluation of logical expressions in IFs.
For example
IF (X.EQ.0 OR. A.LE.W/X) ...
must be split into separate IFs.