BRITISH COMPUTER $OCIETY - FORTRAN SPECIALIST GROUP
MINUTES OF MEETING HELD AT BCS HQ, MANSFIELD STREET, LONDON ON
10 SEPTEMBER 1984
Present: Alan Clarke - Scicon
Mike Dolbear - BP International, London
Chris Lazou - ULCC
Geoff Millard - ERCC
Mike Nunn - CCTA
L Schonfelder - Liverpool University
Steve Watkins - UMIST
Alan Wilson - ICL
John Wilson - Leicester University
Addresses:
Chairman John Wilson
Computer Laboratory
University of Leicester
LEICESTER
LE1 7RH
Secretary Mike Nunn
CCTA
Riverwalk House
157 Millbank
LONDON
SW1P 4RT
Treasurer Keith Normington
Computer Centre
Coventry (Lanchester) Polytechnic
COVENTRY
CV1 5PB
1. APOLOGIES FOR ABSENCE
Apologies were received from D Vallance and K Normington.
2. MINUTES OF PREVIOUS MEETING [18 June 1984]
The minutes were accepted.
3. MATTERS ARISING
(i) Draft BSI Standard document "Method of Specifying Requirements
for FORTRAN Language Processors"
The Chairman said this should have been released, but had heard
no definite news.
(ii) Treasurer of BCS Fortran Specialist Group
Mr T L van Raalte had resigned as Treasurer for personal reasons.
The Group expressed their thanks for all the work he had
performed so diligently. K Normington had agreed to take on
the Treasurer's position in combination with his role as
vice-Chairman.
(iii) BCS Specialist Group Board
The meeting on 19 September would include a British Telecom
demonstration.
(iv) FORTRAN Forum 1985
ANSI members attending the X3J3 meeting in Oxford in July 1985
have said they would be happy to participate in a BCS FORTRAN
Forum, assuming it followed immediately afterwards. This
could most conveniently be held in London and for that
purpose the Institute of Education has been booked on
Monday 15 July 1985. John Reid (AERE, Harwell) will
organise the speakers and the general content of the Form.
John Wilson will control the initial arrangements. To make
the Forum a success they could both do with some help. So
they would be very pleased to hear from people willing to
offer assistance in organising it.
The Group anticipate 100-150 people will attend and a buffet
lunch will be provided. The fee will be decided soon.
(v) The Chairman has been in correspondence with Mr D W Harding
(Secretary General, BCS) on how to obtain better
administrative support to our Group from BCS HQ.
(vi) Anyone with suggestions for topics for afternoon talks
at future Fortran Specialist Group meetings should
contact John Wilson.
4. BCS BUSINESS
(i) The Secretary distributed various papers received for
perusal including:
- The press release announcing that BCS now has a Royal
Charter.
- A programme for the Data Communication Specialist Group
- Minutes received of the February X3J3 meeting in Austin.
(ii) British Telecom are organising a colloquium on December 3 on the
topic of "IKBS - the path to user-friendly computers"
(see appendix B).
(i) A letter had been received from Mr D Payne (Director, CAD
Centre) who felt certain dissatisfactions with the prospective
content of F8X. This was discussed by the Group. In
particular:
BIT data type - Lawrie Schonfelder who regularly attends X3J3
meetings, said the chances of getting this into
"8X" were slim. At ANSI meetings there had
been conflicting demands for this structure
and in any case implementation was tricky.
However, it was well known that a lot of
people were asking for a BIT data type.
Event handling/recursion - John Wilson pointed out that these
structures are already specified t0
appear in 8X.
File handling - Incompatibilities between operating systems gave
problems with defining named files.
It was agreed that Alan Wilson would pass the letter onto X3J3 and also
formulate a response to Mr Payne. (see Alan's letter in appendix C).
(ii) Alan Wilson and Lawrie Schonfelder, who regularly attend
X3J3 meetings, gave an update on recent progress. The
stage has been reached at which ANSI has switched gear
from language design to documenting the new 8X standard.
It has been decided to re-write the S7 specification
document with a structure more suited to 8X. In the
meantime the Fortran Information Bulletin, written by
Jerrold Wagener which summarises 8X content, has appeared
"unofficially" in ForTec newsletter. The idea behind FIB
is that X3J3 want to tell the world at large "this is how
we see 8X".
(iii) On the 8X array extensions front Alan indicated that the CRAY
NFT compiler will include some of the new 8x array features
well before the new standard appears. The forthcoming Eta GS1O
machine is expected to do likewise.
[A report by John Reid on the August 1984 X3J3 meeting is in Appendix A.]
6. ANY OTHER BUSINESS
(i) Recent Fortran books to appear include:
"Pascal for Fortran Programmers" - Perrott and Allison (Computer
Science Press)
A new version of McCracken - appearing soon
"Effective Fortran 77" - Mike Metcalf (Oxford University Press)
7. DATE OF NEXT MEETING
The next meeting of the group will be held on Monday 10 December 1984 from
10.45 to 16.00 at BCS Headquarters. In the afternoon Dr David Bailey
will speak on "Mixed Fortran and Prolog".
8. THE ICL FORTRAN 77 OPTIMISING COMPILER - TALK BY GEOFF MILLARD (ERCC)
In the afternoon Geoff Millard from Edinburgh Regional Computer Centre
gave a talk on the ICL Fortran 77 optimising compiler. A synopsis of
this appears in appendix D.
MIKE NUNN
Secretary
28 October 1984
To: NAG, BCS, DAP, etc.
From: John Reid
Date: 11 August 1984
Subject: Report on X3J3 meeting at Jackson, 6-10 August 1984
References:
[1] 9l(11)JKR-10(Roth) Position of an unconnected file.
[2] 87(12)JHM-5 Sl Questions.
[3] 90(*)JKR-5 Conformance to the standard.
[4] 90(*)JTM-l Proposed intra-language compatibility policy.
[5] 90(7)KWH-11 Pointers.
[6] 9l(2)JAMS-l Multitasking.
[7] 9O(7)KWH-l CONDITION/ENABLE proposal.
[8] 9l(6/7)JKR-4 The meaning of IN, OUT and INOUT.
l. Summary
There were no dramatic developments at this meeting. Most
of the time was spent on tidying-up proposals and the
consideration of potential deletions arising from the Boston
"hit-list". It is hoped that all sections of the reformatted
document will be written between this and the next meeting. The
S7 that results from this meeting's changes will be the last and
the new document will be called S8. Whether any major
outstanding proposals will be accepted (e.g. BIT, error handling,
pointers) is doubtful.
2. Subcommittee organisation
A new subcommittee structure will operate from the next
meeting, to correspond with sections of the final draft document
as follows:
Subgroup Sections
14 1. Introduction
2. Fortran terms and concepts
3. Lexical elements
15 4. Data types
5. Data objects
18 6. Expressions and assignment
16 7. Execution control
8. Input-output
9. Format specification
17 10. Program units
11. Procedures
18 12. Intrinsic procedures
14 13. Entity scope, association and definition
14. Deprecated features
I will be vice-chairman of subgroup 17.
The new subgroups will take responsibility for checking and
revising their sections. The new document will be called S8.
3. Source form
Jim Matheny's proposal to delete significant blanks failed 11-11
(on the chairman's casting vote). His proposal to delete multi-
statement lines failed 3-2l. His proposal to add column position
rules to the new source form for compatibility with the old form (not
attractive since retention of significant blanks prevents full
compatibility) failed 5-19. However a straw vote favoured (19-0-7)
extending the old source form to include features of the new source
form as far as possible. A proposal to include in an appendix
algorithms for converting between the two forms and to state that "the
source form selection is specified in a processor dependent manner"
passed 25-0. The proposal that a processor might determine the form
by examining source records was rejected (l-17-11), as was a proposal
for specific compiler directives (11-12). The proposal that a
standard-conforming processor must be able to accept records of length
132 as accepted (16-4).
The proposal to allow <, <=, etc as alternatives to .LT., .LE.,
etc failed (11-12) . The counter arguments were that not all operators
could be treated this way and that <,> are more valuable as another -
kind of bracket pair.
My proposal to permit underscores within constants to represent
blanks was passed (16-3). It was agreed that they should be allowed
for input-output too.
My proposal to add an inquiry function to permit RECL to be
specified portably in OPEN statements was criticized for its
dependence on the I-O UNIT and for not allowing for the additional
space needed for control information. A straw vote (7-3-7) favoured
the functionality. I will present a fresh proposal at the next
meeting.
4. Input-output
A proposal to add a "PROMPT=" specifier to the READ statement,
which would output a short prompt then start reading from the same
line, failed (6-14). The subgroup favoured another specifier that
would avoid automatic new lines at the beginning of any READ/WRITE pp
statement, and I promised to work on it. My proposal to specify this
in the OPEN statement was not favoured because of its big impact on
the language description and because of the greater flexibility of the
other approach.
Because of Michael Roth's paper [1], Jim Matheny asked the
committee to reconsider his proposal [2] to interpret Fortran 77 as
specifying that the position of a sequential file on OPEN is at its
initial position. Opinions are strongly held on this topic since some
implementations do otherwise. A straw vote was against (5-12-5). Jim
agrees with Michael's ideas and will bring a fresh proposal to the
next meeting.
5. Conformance
My ideas [3] on conformance were discussed by the steering group
who agreed with me in respect of the static properties of the program
but not for run-time checks. This view was endorsed by the full
committee (static checks: 19-7-3; run-time checks 7-17-6) and I
agreed to write a proposal for the next meeting. This will not be
easy since the standard does not recognise the concept of a compiler
in order to permit interpretative systems.
6. Intra-language compatibility
There was a discussion of X3's draft proposed intra-language
compatibility policy [4]. This lays down guidelines for the
justification of language features in a revised standard that may give
conversion difficulties for programs written for systems conforming to
the previous standard. It will not affect Fortran 8x since X3J3 is
committed to keeping Fortran 77 as a subset, but it does have
implications for F9X. Some committee members felt that it was far too
demanding of scarce committee resources, but personally I support it.
Some detailed changes were suggested and it was endorsed (9-6-2).
7. Array features
I presented my personal proposal to delete OTHERWISE. A
modification to change the keyword to ELSEWHERE was passed (23-0) but
its deletion was not (2-19), though the chairman illustrated my case
by showing that she had misinterpreted the semantics.
I also presented my personal proposal to ban many-one aliases
(created by the IDENTIFY statement) and received a straw vote of 3-8-19.
The chairman asked the committee to consider the issue prior to
my representation of the proposal at the next meeting.
A proposal for an inquiry intrinsic to find out whether an
allocatable array is allocated was accepted (21-0). The array group
did not like the suggestion that the ALLOCATE statement should include
a "space left" specifier because of difficulties with respect to what
units should be used to measure the space and uncertainties over space
needed for indexing information. However a logical specifier to
indicate whether the allocation had succeeded was favoured (19-2-6).
A proposal was accepted (23-0) to move from SHAPE to SIZE the
facility for inquiring about the size of a particular dimension of an
array.
The form of brackets for array constructors was discussed.
Given that .GT., .GE., etc remain, the angle brackets < > could be
used but were not favoured (5-20-l) probably because they would imply
very long-term non-use of ( , > for their mathematical meanings. Adding
the alternatives (/ and /) was accepted (22-0).
Intrinsics for finding the locations of the minimum and maximum
elements of arrays were discussed but no firm proposal was available.
Similarly there was a discussion on adding INITIAL_VALUE arguments to
DOTPRODUCT and MATMUL to permit accurate calculation of residuals, but
again no firm proposal was available.
My proposal to replace vector-valued subscripts by intrinsics
was not liked by the array subgroups. I will present this as a
personal proposal at the next meeting. In the many-one case, the
effect of assignment is currently processor-dependent. The full
committee considered this and straw voted in favour of disallowing
such an assignment (13-4-4).
A proposal to split the facilities offered currently by RESHAPE
between two simpler functions that reshape an array and permute its
dimensions failed (9-12).
8. Data types
Jerry Wagener suggested that COMPLEX should be considered as an
intrinsic data type. This would not affect any of the present usage
but would regularize and thereby simplify the language. It would lead
to alternative means of accessing the parts (e.g. Z%REAL) and defining
constants (e.g. COMPLEX(l.,l.)). However, the idea was not favoured
(10-12-7).
The possibility of restoring BIT data type, which is in S6 but
has been labeled as waiting for Fortran 9x, was considered. Simpler
features that might provide the functionality were considered by small
ad-hoc groups. I suggested a set of intrinsics based on holding sets
of bits in integer arrays, but the idea was felt to be too inelegant.
It is possible that a proposal for a bit type holding a single bit and
needing arrays to hold strings might be presented at the next meeting,
but it looks too late.
A motion for deleting entity-oriented declarations was passed
(12-9). Opinion is clearly divided, but the subgroup has committed
itself to proposing further changes in this area so that all the
information about an object can be collected together . In particular,
a replacement for the INITIAL statement is needed, given that DATA is
deprecated. A four way straw favoured extending DATA (13) or
initialization within the TYPE statement (7) as opposed to two
alternatives for changing INITIAL (3 for the two together).
Deletion of variant data types was not favoured (3-22-2).
Kurt Hirchert made a further presentation in favour of his kind
of pointers [5] but has not worked this up to a proposal.
9. Event handling and multitasking
W. Knies made a proposal [6] in favour of extending the present
event-handling chapter of S7 to multi-tasking. Its impact on the
language is large and there are a number of details still to be
resolved, which makes it hard to_see how this can be included in
Fortran 8x. The proposal was rejected (5-11) but the following motion
passed (24-0): "X3J3 strongly supports continued work on events. If
there is not time, it will be considered as a language extension
module or a collateral standard". A similar motion having "events"
replaced by "multitasking" also passing (24-0).
The option was expressed that multitasking is very important, but
that it is too early to standardize because many different approaches
are being considered.
Kurt Hirchert presented his proposal [7] on error handling from
the last meeting, but the committee had clearly not given it
sufficient attention (straw vote 6-0-21).
10. Control structures
The committee was clearly divided over my proposal to add a
WHILE clause to the block DO statement, but the proposal passed (12-10).
Replacing commas by colons in the block DO statement was not
favoured (7-17) , nor was the_ idea of replacing the "n TIMES" syntax by
omission of the DO control variable (1-27-6).
A proposal to delete the keyword INTERNAL from the INTERNAL
procedure statement passed (17-5) after an amendment to make the
keyword optional failed (6-14).
A proposal to name control blocks by placing the name ahead of
the first statement of the block and followed by a colon was accepted
(17-4) after much discussion provoked by the similarity between the
new form of block names and labels.
My proposal [8] to change the definition of IN, OUT and INOUT was
accepted. The main difference is that an IN or INOUT dummy argument
need not necessarily be defined on entry.
11. Next meeting
The next meeting will be extended by three days to allow
editorial work on the new standing document (S8). The pre-meeting
deadline (for receipt of papers in USA) is October 8.
[British TELECOM headed paper; too faint to be reproduced]
Mr J D Wilson
BCS FORTRAN Group
Computer Laboratory 11th October 1984
Leicester University
Leicester
LE1 7RH
Dear Mr Wilson,
Please find enclosed details of a colloquium which I am organising
on behalf of the IEE. I am contacting the Special Interest groups
in the BCS, and affiliated organisations, as I feel that the topic
of the colloquium (IKBS - the path to user-friendly computers), may
well be of interest to its members. If the BCS FORTRAN Group
produces a newsletter I would be grateful if the colloquium could be
mentioned in it.
Many thanks.
Yours sincerely,
Miss C J Alexander
Enc:
IKBS - The Path to User-Friendly Computers December 3 (1984)
Organised by the IEE and co-sponsored by the London
Ergonomics Society this colloquium will consist of UK
seven presentations on aspects of the role which IKBS
techniques have to play in improving the usability of
the man-computer interface.
Mrs J Hall LS(CG) , The Institute of Electrical Engineers
Savoy Place, London WC2R OBL Tel: 01-240 1871 x330
(Venue: IEE, Savoy Place)
Mr. D. W. Payne
CADCentre Limited
High Cross
Madingley Road
Cambridge CB3 OHB
England
Dear Mr. Payne:
Thank you for your letter of 20th August 1984 concerning
the need for standardization in certain areas of FORTRAN
which you feel may be in danger of being overlooked in the
current FORTRAN 8X language.
The information we have been able to pass along to you on
FORTRAN 8X has not been comprehensive, but there is now
available a document that describes all the work done to
date.
I enclose a copy of the joint ACM SIGNUM Newsletter and
ACM FORTEC Forum publication "Status of Work Toward Revision
of Programming Language Fortran" by Jerrold Wagener.
I believe that Jerry Wagener's document will answer to most
of your requirements, though perhaps not all: pointers and
bit data type are not included but are still under active
study. Recursion is there. Modules provide a powerful
include facility.
Your letter will be passed along to X3J3 at its November
1984 meeting.
Yours sincerely,
Alan Wilson
for British Computer Society Fortran
Specialists Working Group
15 October 1984
THE ICL FORTRAN 77 OPTIMISING COMPUTER - TALK BY GEOFF MILLARD (ERCC)
Edinburgh worked on the optimiser with guidance from ICL. They were influenced by
IBM's H level compiler. The design consisted of 3 phases:-
phase 1 preparation identification of blocks
analysis of variable usage (note all inner and
topological analysis outer loops)
phase 2 optimisations subsumption - replace wherever
reference to a
variable the value
that is assigned to it
eg A=1.0 A=1.0
IF(X.EQ.A) -> IF(X.EQ.1.0)
special case processing
eg A * 2.0 -> A + A
A/2 -> A * 0.5
(A*B)+(A*C) -> A * (B + C)
A/B/C -> A / (B * C)
- A/constant -> A/(- constant)
A ** - 2 -> 1/(A ** 2)
common expression elimination
backward movement
strength reduction
test replacement
eliminate redundant tests
phase 3 architectural mapping
allocate temporaries
guide register usage
Optimisation at all 3 levels is carried out at the Subroutine level.
General
(i) Compile time using the optimising computer is about 2.5 times the
non-optimising compiler
(ii) Subjective views on competing optimising systems:
IBM and DEC VAX - comprehensive optimising capabilities
Prime - limited set of optimisations
Perkin-Elmer - offers global optimising
(iii) Current benchmarks have shown the greatest optimising gains are from
- coding of array accesses in loops
- removal of invariant subscript calculations
- amalgamation of counting and subscript incrementing
Global optimisation offers most significant gains.
(iv) Achieving 25 - 30% execution speed improvement would be near the top of
what one would expect from an optimiser.
(v) C is the right language for writing compilers in the future which need
retargeting
(vi) PERQ - PNX has better organised code than POS.
(vii) Pricing policy for the new Fortran 77 optimising compiler is determined by ICL.