MINUTES OF BCS FORTRAN SPECIALIST GROUP MEETING HELD AT ROYAL
INSTITUTE OF PUBLIC HEALTH AND HYGIENE, PORTLAND PLACE, LONDON ON
8 JANUARY 1987
Present: Stephen Brazier - Prime
David Burns - NCC
John Dyke - Huntingdon Research Centre
Miles Ellis - Oxford University
Anne Gooding - Air Products Ltd
David Hewitt - Coventry Polytechnic
Carol Hewlett - LSE
Peter Holland - SS(E)L
David Holmes - Rolls Royce
Chris Lazou - ULCC
Clive Massey - SWURCC
David Muxworthy - University of Edinburgh
Keith Normington - Coventry Polytechnic
Mike Nunn - CCTA
Kevin Pritchard - UMIST
T L van Raalte - MOD (PE)
Neil Smith - RAE, Bedford
Tony Webster - Salford University
Alan Wilson - ICL
John Wilson - Leicester University
John Young - MOD (PE)
1. APOLOGIES FOR ABSENCE
Apologies were received from David Griffiths, P Kraven and
Lawrie Schonfelder.
2. MINUTES OF PREVIOUS MEETING [16 October 1986]
Correction to page 5, paragraph 6 (iii). This should read:-
"The Chairman said that FORCHECK (an F77 verifier/checker) was
now available for PCs".
3. MATTERS ARISING
(i) Membership renewal form.
The Secretary had been drafting a membership renewal from
which all Group members would in future be required to
complete annually to indicate that they wished to stay on
the Group's mailing list. It would also be used as a
registration form for newcomers wishing to join the Group
and to collect annual dues (£5) from non-BCS members.
(ii) Fortran Forum
The Group intended to hold a Fortran Forum later this year
and there was some discussion on when this would be. It was
decided that no date could be set until after the next X3J3
meeting when it was hoped that the date for the release of
the draft 8X standard for public comment would be known.
All those registering for our Forum would be supplied with
copies of the draft. It would be sent out well beforehand
to give attendees sufficient time to digest it. Suggestions
for attractive venues for the Forum from members would be
most welcome - please contact the Secretary.
A sub-committee was appointed to organise the event. Those
offering to help included Chris Lazou, Miles Ellis and
John Wilson. John Reid (Harwell) who organised the agenda
and X3J3 speakers for the last Forum will be invited to help
as well. Because BCS Conference Section is heavily loaded
over the next eighteen months it was doubted whether they
will be able to offer much assistance. Any Group member
willing to help the sub-committee organise the Forum should
contact our chairman (John Wilson).
4. BCS BUSINESS
(i) BCS has yet to decide on its funding allocation to the
Fortran Group for the coming year. At present we have a
surplus of about £1,200 which it is intended to use to set
up the Forum. We would of course eventually hope to get the
costs back from receipts.
The Chairman suggested that some of the Group's funds might
be allocated to fund the cost of himself attending X3J3
meetings as an alternate for Miles Ellis when he was unable
to be there. It would enable our Group to have a close link
with X3J3 activity. However, after some debate it was
agreed that it would be more appropriate to reserve any
funds we possess to cover the costs of setting up the coming
Forum. we might, for example, wish to assist with the costs
of some key X3J3 committee member attending to give a
definitive view of the philosophy of 8X.
(ii) Members were asked to suggest subjects for talks at future
meetings and came up with the following ideas:-
Fortran compilers on PCs and micros;
Fortran compilers on parallel computers eg FX/8,
transputer, Meiko etc;
Interaction of data processing systems with knowledge
based systems ie expert systems/AI;
Fortran 8X v Ada;
Parallel algorithms in Fortran 8X;
Fortran 8X toolpack (NAG/Salford project);
SPAG structurizing tools (Polyhedron);
Visit to SERC Rutherford.
Any other suggestions for topics should be communicated to
the Secretary.
(iii) The Secretary mentioned that he had recently been talking
with Active Memory Technology who are developing DAP-3
as a successor product to the ICL PERQ DAP and they were
willing to provide a speaker at a future meeting. It was
agreed that they should be invited to give a talk at our
April meeting. [This has now been arranged -Secretary.]
It was also decided that the July meeting would take place
at Coventry Polytechnic. Keith Normington would make the
arrangements and confirm an exact date.
5. PROGRESS ON FORTRAN 8X AT WG5
The ISO working group WG5 is conducting a vote on whether 8X is
ready for public review. So far few votes have come in and the
cut-off date has been extended; votes received up to now are 14-2
in favour of release. The next WG5 meeting is in Liverpool from
3-7 August. Names of attendees must be approved by BSI by June.
Anyone interested in attending should write to David Muxworthy at
Edinburgh University.
At a BSI meeting last December the UK voted in favour of releasing
the 8X draft for public comment (see appendix A). Other voting
alternatives would have been "Yes, with editorial changes" and "No,
with technical reasons for whatever changes would enable a change
to a 'Yes' vote".
6. PROGRESS ON FORTRAN 8X AT X3J3
Miles Ellis had attended the latest X3J3 meeting in Albuquerque and
gave a summary of the main happenings as follows:-
The Albuquerque meeting, hoping to get the 8X draft out for
public review, had processed a huge number of documents. The
"obsolete" features category had now been renamed "deleted"
but this still seemed confusing. There had been some debate
about the procedure for releasing 8X; confusion existed within
X3J3 and the discussion got quite heated.
IBM and DEC felt the draft document was not suitable for
consideration as a standard. Peritus were also against it.
Two thirds of X3J3 have to be in favour of the draft before it
can be released. Those voting "No" must say what needs to be
changed for them to change their vote to "Yes". A straw vote
of voting intentions regarding releasing the draft for public
review resulted in 27 - Yes, 7 - No. Many of those against
believe that there have been too many late changes and some
stabilisation of the document is needed.
Eventually the draft must go to the X3 parent committee for
consideration. X3 does not actually meet but makes decisions
by correspondence. Alan Wilson says it is a vendor dominated
body. Miles Ellis understands that IBM's objections to the
draft standard have a basis that it fails to meet the market
needs for a language that can be learned easily and
implemented quickly. They also believe that the size and
complexity of 8X could lead to implementation errors and
confusion.
John Reid (Harwell) has provided a summary of the Albuquerque
meeting - see appendix B.
7. ANY OTHER BUSINESS
One of our Group members, Chris Lazou, has just written a book
titled "Supercomputers and their use" published by Oxford
University Press at £22.50. It describes the state of the art in
supercomputers. A brochure and purchase form appears in
Polyhedron Software have kindly sponsored the cost of sending out
this newsletter. A brochure on their software products is enclosed
and they will be giving a talk on them at our Coventry meeting in
July.
8. DATE OF NEXT MEETING
The next meeting will take place at 10.30 am on Thursday 2 April at
BCS HQ and will include the AGM. In the afternoon
Professor Denis Parkinson (QMC and Active Memory) will give a talk
on the new Active Memory Technology DAP-3. Both hardware and
software aspects will be covered.
A buffet lunch will be provided - but those wishing to participate
must complete the booking form and return it to the Secretary.
In the afternoon there were talks on "The implementation of
Toolpack" by David Hewitt (Coventry Polytechnic) and "Software
Tools" by David Burns (NCC). Summaries appear in appendices C and D.
MIKE NUNN
Secretary, BCS Fortran
Specialist Group
17 February 1987
PS. A report from John Reid on the February X3J3 meeting in
Los Angeles has just been received and is included in the appendices.
WG5 INFORMAL LETTER BALLOT
for Individual WG5 members
Subject: Revision of ISO 1539-1980 Date: Nov. 18. 1986
Reference Document: X3J3/58.103 Ballot Period: Dec. 1 - Jan. 5. 1987
Question: Do you approve the draft Fortran Revision (Fortran 8X) of ISO
1539-1980 (Fortran 77) enclosed with this ballot for submission to SC22 for
further processing as an International Standard?
_____ Yes
__X Yes, with comments supplied
_____ No, with comments supplied
Comments: (Additional pages of comments may be attached.)
One page of comment is attached.
Country
or
Mail to: Name United Kingdom
please print
Jeanne T. Martin Individual
L-300 Signature:
Lawrence Livermore National Laboratory D.T.Muxworthy (signed)
Livermore. CA 94550
USA Date December 19, 1986
-------------------------------------new page----------------------------------
WG5 INFORMAL LETTER BALLOT. COMMENTS ACCOMPANYING THE U.K. VOTE.
The U.K. votes "yes" in the WGS informal letter ballot in order
that the document may be issued for public comment. The vote does
not indicate that the document is yet ready to be registered as a
draft proposed standard.
The U.K. commends X3J3 for responding favourably to several of the
WGS Halifax resolutions, but expresses regret that no action has
been taken on other resolutions, including numbers 10 (conformance) ,
13 (deprecated features) and 14 (significant blanks); moreover the
U.K. records its disapprobation that X3J3 took action directly
contrary to resolution 22 (name-directed I/O).
The U.K. reaffirms its support for the WG5 Halifax resolutions.
Further explanation of these points is to be found in responses
from individual U.K. WG5 members.
[The Halifax resolutions are available at
https://wg5-fortran.org/N001-N1100/N205.pdf]
To: BCS, NAG, Fortran Forum, etc.
From: John Reid
Date: 4th December 1986
Subject: X3J3 meeting at Albuquerque
Note: This is a personal report of the meeting and in no sense does
it constitute an official record of it.
1. Summary
This was a very active meeting, with over 150 working documents, most
of which were corrections and improvements to the draft standard, S8.
The plan is to retypeset it immediately after the meeting (the chairman,
vice-chairman, and editor are all staying behind to help) and send
out to members for a postal ballot over the period December 1st to
January 5th. Only three members (IBM, DEC and Peritus) opposed holding
such a vote. when asked how they anticipated voting in this ballot, two
members (IBM and DEC) said 'no' and 5 abstained, so there seems every
prospect for the required 2/3 majority. The February meeting will be
devoted to considering the reasons for any 'no' votes and any comments
that accompany 'yes' votes. Hopefully, we will forward the document to
our parent committee, X3, in February. He will also forward it to ISO.
2. Editorial matters
A huge number of editorial changes to the draft standard were made. In
fact, to complete the consideration of all the changes proposed, the
editorial committee met until 11.30 p.m. on the last day. The major
changes involved the meanings of the terms 'object' (now includes
subobjects), 'program unit' (now has to be external), 'subprogram'
has to be a function or subroutine subprogram), 'real' (now includes
double precision as a special case), and 'deleted' (to replace
'obsolete', which is easy to confuse with 'obsolescent'), and changes to
the default bnf rules (there are now only three default rules and they
are never overridden).
3. Modules
A proposal to extend the USE statement to permit renaming of operators
(requested by ISO WG5) failed (10-23). Given that operators for
different types can have the same name, it was not felt necessary to
have this extension.
It was decided (29-0) not to allow the individual components of a
derived type in a module to be declared PRIVATE but to allow them all to
be so declared. This would be appropriate, for example, if it is desired
to retain the freedom to change the details of the type without having
to change code that uses it. A structure of such a type (or having a
component of such a type) would not be permissible in an i/o list except
in its own module.
Range lists and name lists were added to the list of entities that may
be used from a module (it was an accident that they were not already
allowed). It was also decided that derived types, range lists, and name
lists should join the list of local entities that are required to have
distinct names.
4. Derived-type comparison and assignment
It was decided (29-2) to remove the automatic definition of the
comparison operators .EQ. and .NE. for derived types because often a
simple comparison of the bit pattern is not wanted. For example, the
derived type
TYPE STRING
INTEGER LEN
CHARACTER(8O) CHARS
END TYPE
implements variable-length strings and the following function is
appropriate for comparison
LOGICAL FUNCTION EQUAL(A,B) OPERATOR(.EQ.)
TYPE(STRING) A,B
L = A%LEN
EQUAL = (B%LEN.EQ.L) .AND. &
ALL( A%CHARS(1:L).EQ.B%CHARS(1:L) )
END
It was suggested that the automatic definition of assignment might
also be removed, but this was felt to be much more useful. No harm is
done if some bits that will never be used are set.
5. Component selection syntax
Van Snyder, a guest from JPL, suggested that functional notation be
used for component selection. For example, the function EQUAL of section
4 would become
LOGICAL FUNCTION EQUAL(A,B) OPERATOR(.EQ.)
TYPE(STRING) A,B
L = LEN(A)
EQUAL = (LEN(B).EQ.L) .AND. &
ALL( CHARS(A,1:L).EQ.CHARS(B,1:L) )
END
This seems a rather natural notation and would incidentally avoid the need
to use the symbol % and would mean that arrays of arrays could be
associated with ordinary arrays without a confusing subscript
transformation caused by Fortran's use of column-wise storage order.
Arguments used against it were that it would make what is happening less
apparent, that it would lead to the over-use of parentheses, and that
care would be needed with the wording of the rules for overloading
function names. A straw vote (7-19-9) was unfavourable to the idea.
6. Generalized precision
Changes were made to simplify the interactions between generalized
precision, derived data, and passed-on precision, principally to prevent
any possibility of a system needing to generate a large number of
versions of a subprogram. The main changes were
(1) to require a derived type with precision attributes to have a
parameter called PRECISION and a parameter called EXPONENT_RANGE
and generally to behave very like REAL and COMPLEX, which have such
parameters, and
(2) to require passed-on precision always to take the form where both
PRECISION and EXPONENT_RANGE are passed on (have effective values
that match those of actual arguments).
7. Intrinsics
An optional argument was added to each of the functions ISCAN, INDEX
and VERIFY to permit them to process strings backwards (requested by ISO
WG5), CLOCK was renamed SYSTEM_CLOCK, and ISCAN was renamed SCAN.
8. Transfer function
The committee accepted my suggestions to the TRANSFER function to
avoid any loss of information when the data does not fit into a whole
number of array elements.
9. Allocation and deallocation errors
It was decided to add an optional flag to the ALLOCATE and DEALLOCATE
statements to allow error conditions to be indicated.
10. Interface blocks
ISO WG5 resolved at Bonn (1985) and reaffirmed at Halifax (1986) that
it should be possible to use the procedure interface block both to
define a procedure and to describe a reference to the procedure.
Unfortunately, X3J3 has found no acceptable syntax to express this, and
therefore resolved not to pursue the matter. I actually voted against
this resolution because, as far as I could see, the purpose of the WG5
request can be met by placing the procedure in a module and using it.
11. ISO proposed standard for language extensions on micros
X3J3 was asked to review a proposed ISO standard for extensions to
Basic, Fortran, and Pascal to include ways to access memory, I/O ports,
and arbitrary subroutines; to service interrupts; and to bind entities
to specific memory locations. The Committee was concerned about
incompatibilities with Standard Fortran and recommended that these be
resolved and the semantic descriptions be made much more complete and
rigorous before this is adopted as a standard.
12. Next meeting of X3J3
The Committee meets next in Los Angeles, February 9-13, 1987. The
premeeting deadline is January 5th.
[the following report was written after the Fortran SG meeting of 8 January
1987 but was included with the minutes of that meeting.]
To: BCS, NAG, Fortran Forum, etc.
From: John Reid
Date: 19 February 1987
Subject: X3J3 meeting in Los Angeles
Note: This is a personal report of the meeting and in no sense
does it constitute an official record of it.
l. Summary
A letter ballot of all X3J3 members was conducted prior to this
meeting, asking the question 'Do you approve the draft Fortran
Revision...enclosed with this ballot for submission to X3 for further
processing as an American National Standard?" The result was Yes: 9;
Yes with comments, 20; No: 7. Since less than l/3 voted "no", the
ballot passed. Short summaries of the reasons given for each no vote
appear in Section 2. It looks of 2 or 3 of these may change to yes
votes once all the comments have been processed, but the rest are
asking for drastic changes that are quite unacceptable to a majority
of the Committee.
The meeting was concerned with processing the huge number of
comments received with the ballots. A preliminary meeting (attended
by Jeanne Adams, Jeanne Martin, Walt Brainerd, Jerry Wagener, Brian
Smith and Dick Hendrickson) collated the comments and categorized them
(l for minor edits, 2a for editorial changes in style and taste, 2b
for editorial changes that might be controversial, 3 for substantive
changes, 4 for substantive changes requiring subgroup study, and 5 for
changes to the language that would be appropriate in the public
comment period). Most of them were labelled as recommended for
acceptance (**), covered by another recommended change (*), or
rejected (R).
Each committee member in turn was given the opportunity to
introduce his or her ballot and discuss items other than those in
categories l and 2, which were considered by the Editorial Subgroup
and moved in blocks. The changes in categories 3 and 4, and the
outright rejections, were passed to the technical subgroups to be
studied and moved singly. The only technical change made (other than
corrections of errors) was over requirements for processor conformance
(see Section 3), Substantial rewriting of text for host association
(the term adopted for access by internal procedures to host entities),
array constructors, and the IDENTIFY statement were adopted. It was
decided that the glossary should be included as an appendix and that
there should be an index of the bnf terms. There was some sentiment
in favour of limiting the intrinsic functions permitted in
specification statements, but the proposal was withdrawn for further
work. It was confirmed that entry statements are not permitted in
interface blocks (each entry has its own interface).
2. The no votes in the ballot
The no votes were as follows:-
1. Kevin Harris (DEC) wants
(a) derived data types to be removed and new intrinsic types to
be added for bit strings, general pointers, and varying length
character strings;
(b) to disallow modules to contain procedures or access other
modules; to add an INCLUDE facility;
(c) to remove generalized precision; to require minimal
accuracy standards for operations and intrinsic functions; and
(d) to reduce the obsolescent features list to noninteger DO
variables, ASSIGN, assignedGOTO, and assigned FORMAT specifiers;
to reduce the deprecated list to one item, the old source form.
2. Dick Hendrickson (Cray) wishes to see the large number of
technical errors and holes that he has found corrected.
3. Anil Lakwara (Peritus) believes that the document does not
conform with X3J3's Charter, that the language is too large and
complex, and that implementations will be too large and inefficient.
4. Len Moss (SLAC) feels strongly that X3J3 should not publish the
document until the whole committee is convinced that it is
understandable, and is concerned about the large number of editorial
and technical errors that remain in the document.
5. Ivor Philips (Boeing) wishes to change the Appendix F bit
facility to be based on bit strings and to add an OVERLOAD statement
that flags any overloading of procedures or defined operators.
6. Larry Rolison (Unisys) has found virtually no new feature that
will enhance either compiler or run-time performance and is concerned
that the committee has created a negative incentive for the average
user to move to an 8x implementation.
7. Dick Weaver (IBM) wants Fortran 8x to be reorganized into two
languages. One would be called Fortran and would consist of Fortran
77 plus data structures, array language as an option, bit string data
type, dynamic allocation, environmental inquiry functions, precision
specification, keyword and optional arguments on CALL statements,
IMPLICIT NONE, and the new form of DO. The rest would be processed as
a technical report, to allow implementation experience, testing and
evaluation.
8. Processor conformance
ISO Working Group 5 requested that processor conformance
requirements be extended, essentially to require static checking of
the syntax of a program for violations of the standard and for the use
of extensions. The committee accepted the spirit of the proposal, but
had some difficulty with the exact wording. After discussions in full
committee and ad hoc subgroups, the following was adopted (24-0):
1. Add to the body of S8:
A processor conforms to this standard if
(l) It executes any standard conforming program in a manner that
fulfils the interpretations herein, subject to any limits that
the processor may impose on the size and complexity of the
program.
(2) It contains the capability to detect and report the use
within a submitted program unit of a form designated herein as
deleted, obsolescent, or deprecated, insofar as such use can be
detected by reference to the numbered syntax rules herein and
their associated constraints.
(3) It contains the capability to detect and report the use
within a submitted program unit of an additional form or
relationship which is not permitted by the numbered syntax rules
or their associated constraints.
However, a processor is not required to detect or report the use
of deleted, obsolescent, or deprecated features, nor the use of
additional forms of relationships occurring in a format
specification which is not part of a format statement (10.1.1).
2. Add to Section Notes (Appendix C):
The standard requires a standard-conforming processor to be
capable of detecting and reporting the use within a program unit
of forms designated as deleted, obsolescent, or deprecated, or of
additional forms or relationships, where such use can be detected
by reference to the numbered syntax rules and their associated
constraints. It is recommended that the processor be accompanied
by documentation which specifies the limits it imposes on the
size and complexity of the program and the means of reporting
when these limits are exceeded, which defines the additional
forms and relationships it allows , and which defines the means of
reporting the use of additional forms and relationships or of the
deleted, obsolescent, or deprecated forms. Note that in this
context, the use of a deleted form is the use of an additional
form.
4. Further meetings
Because there is much work still to be done on the ballot
proposals, the Chairman has called for an extra meeting to be held at
Albuquerque, 23-27 March. This will be treated as a continuation of
the February meeting, without separate minutes. It should ensure that
processing of the ballots is completed at the meeting in Seattle,
11-l5 May. The premeeting deadline is April 6.
IMPLEMENTATION OF TOOLPACK
TALK BY DAVID HEWITT (COVENTRY POLYTECHNIC)
David Hewitt works in Computing Services Department of Coventry
Polytechnic where there are 5,000 students. A great deal of time
is spent on porting software from other sites onto their Harris
systems. Most of this is written in Fortran so when they read
about Toolpack they decided to try it out. Computer systems at
Coventry consist of:-
2 x Harris 800;
1 x Harris 1000.
Each has 3MB memory and 24-bit word length. Largest programs that
can be handled are 1M words. Total disk space available amounts to
1.5 GB shared between 5,000 users. Presently a total of 175 on-
line terminals are supported but this could be increased to about
220 if more ports were available. The Harris operating system VOS
can only support a single level file structure, ie files are
referenced relative only to the directory in which they reside.
Coventry use a wide range of languages and about 60 application
packages. These vary between quite small ones for performing
simple calculations to large engineering packages and interactive
graphics.
In implementing Toolpack a user can choose a stand-alone regime in
which each tool is invoked separately or an embedded regime (more
difficult to implement) which gives more freedom in invoking tools.
Coventry started by trying the stand-alone regime. Toolpack is
supplied as a series of large files which have to be broken into
source files, macro definitions, block data and test areas. A
split program is supplied for this purpose. Source areas then have
to be converted to Fortran using the TIEMAC processor. Its main
actions are to include declared files and process define
statements. The next step is to hook in the libraries that contain
the host dependent routines for I/O, file handling, terminal
handling etc.
To implement Toolpack took one person a total of 104 days spread
over 9 months. It has to be noted that Toolpack is not only a
suite of about 40 tools but also an environment in which they
operate and consists of about 250,000 lines of Fortran source code.
General experiences were:-
(i) Documentation provided although fairly detailed is not
easy to understand or use.
(ii) Conceptualisation of the different types of regimes and their
relative implications are difficult to understand.
(iii) It is surprising how many tools have to be run to accomplish a
single task.
(iv) Because tools originated at different sites they do not present
the user with a consistent interface.
(v) The tools can provide useful functions like converting all single
precision arithmetic to double.
Anyone interested in a very detailed set of notes that David has
produced on his experiences in implementing Toolpack should contact
him at Coventry Polytechnic.
"SOFTWARE TOOLS" - TALK BY DAVID BURNS (NCC)
The Software Tools Demonstration Centre (STDC) was set up via a
Department of Trade and Industry initiative in 1986 at the National
Computing Centre in Manchester. Its objectives are to:-
1. Promote the use of software engineering tools and methods.
2. Provide an independent demonstration centre for such tools.
3. Allow users to see and compare tools relevant to their needs.
4. Act as a focal point for exchange of expertise in software
engineering.
The DTI contract valued at £3M was for three years; so far STDC is
one year into the project. Any revenues have to be ploughed back
into STDC which will eventually become a self-supporting company.
NCC itself was set up as an enterprise 20 years ago by the
government but is now self sufficient as a commercial company.
STDC activities include:-
Demonstration of tools (in a highly professional manner);
Advice on tool selection;
Seminars/briefings/workshops;
Producing a newsletter on "tools and methods".
STDC maintains an information base on 200 tools including abstracts
of Alvey projects. STDC has 16 permanent staff and 3 temporaries. This
represents a doubling over the last year. The environment at the Centre
is very plush.
Hardware used includes:-
2 x IBM PCs;
IBM 4361;
ICL 2953 with CAFS;
VAX 8200 (under VMS);
Microvax (under Ultrix);
McDonnell Douglas 6830 (Pick);
2 x Tandems;
4 x Apricots;
4 x Macintoshes.
STDC database of tools is kept on the VAX 8200 using ORACLE software.
Equipment is on free loan from suppliers.
Tools currently available exist in the areas of software estimating,
project support environments, 4th generator systems, IKBS, project
management, graphics, verification and validation, implementation
analysis and design, configuration management, quality management.
STDC expect to have a balanced portfolio of 40 tools by April 1987.
They also hope to run a school to give attendees hands-on
experience of using the tools. In the near future they will also
be able to offer a series of tool starter/sampler packs.
For further information on STDC contact:-
STDC Administrator, National Computing Centre Ltd, Oxford Road,
MANCHESTER Ml 7ED. Tel: 061-228-6333
OXFORD SCIENCE PUBLICATIONS
SUPERCOMPUTERS AND THEIR USE
Christopher Lazou, Section Head, University of London
Computer Centre
Supercomputers are at the forefront of computer technology,
and are of immense practical importance in scientific research.
The speed at which they handle data makes them ideal
tools for researchers in such fields as aerospace, electronics,
and weaponry.
The first part of this book describes several different supercomputers,
discussing their architecture, the technologies used in building
them, and the constraints imposed by the available technology
on their design. The second part covers software, numerical
methods, and performance in terms of practical applications.
The book concludes with a discussion of future technological
possibilities and new hardware.
* Essential for all computer professionals and scientists
using large-scale computation
* Written in an informal style
* Aimed at a general, computer literate audience
* Technical details kept to a minimum and are clearly explained
whenever they are unavoidable
Contents: Introducing supercomputers; Organization of
building blocks; Supercomputer architecture in the 1970s;
Supercomputer technologies; Supercomputers of the 1980s
- made in the USA; Supercomputers of the 1980s - made
in Japan; Scientific computation; Software and scalar optimization;
Vectorization; Aspects of supercomputer performance;
Examples of practical applications; Future developments;
Appendix: Array features in FORTRAN 8x; Bibliography;
index.
0 19 853720 4, 240 pages, 57 line and 23 halftone illustrations,
Clarendon Press, November 1986 £22.50
OXFORD UNIVERSITY PRESS
WALTON STREET, OXFORD, OX2 6DP TEL (0865) 56767