FSG minutes for 8 February 1982

BRITISH COMPUTER SOCIETY - FORTRAN SPECIALIST GROUP

Minutes of meeting held at BCS Headquarters on Monday, 8 February 1982

Present: P A Clarke Rothamsted Experimental Station

P Croft Unilever Computer Services Ltd

M R Dolbear B P International, London

G Harding ECMWF

D J Holmes Rolls Royce Ltd, Bristol

C Lazou University of London Computer Centre

D Lomas UMIST (Dept of Chem Eng)

D T Muxworthy University of Edinburgh

K Normington Coventry Polytechnic

M Nunn CCTA

T L Van Raalte MOD

R W Rodwell ICL

T Sankey Institute of Oceanographic Sciences (NERC)

A L Swarbrick UMIST (SERC)

L M Swarbrick Ferranti Computer Systems

D M Vallance University of Salford

(Chairman) J D Wilson Leicester University

1. APOLOGIES for ABSENCE

None received.

2. MINUTES OF PREVIOUS MEETING [30 November 1981]

Accepted.

3. MATTERS ARISING

The Treasurer is still not available to resolve the outstanding financial

matter. The Chairman is continuing to try to contact him. Action
Chairman

'Weathervane' is a personal document describing Fortran 8X written by

Loren Meissner.

4. X3J3 BUSINESS

The ISO Fortran Expert's meeting on 14-17 June 1982 at the Technical

University of Vienna. Applications from delegates wishing to attend

should be made via David Muxworthy, Room 2609, Kings Buildings,

University of Edinburgh, Mayfield Road, Edinburgh EH9 3JZ. Early

booking of accommodation is advised, as the meeting coincides with the

Vienna festival.

It is unlikely that the BCSFSG will be able to sponsor a representative;

intending delegates must therefore obtain their own funding. It is

intended that the British delegation will make a formal presentation

based on discussions and correspondence in the next few months. Action

All

There was discussion on compatibility between the existing and new standards.

It was felt that a set of standard compiler directives should be rigidly

defined for Fortran 8X. The current definition of Fortran 8X raises a

number of problems of source language compatibility (for example, fixed-

form v. free-form) and compatibility with existing libraries.

5. CHAIRMAN'S BUSINESS

The Chairman invited members to suggest items that the Group could produce

for BCS publication and to suggest areas of activity in which the Group

should be involved.

Three suggestions were made:

1) We should discuss our experiences with Fortran 77.

2) We should attempt to discuss the latest X3J3 minutes

and attempt to send comments to X3J3 in writing. It

was felt that this would best be done by seeking a

volunteer in advance of a meeting to lead discussions.

3) A report would be prepared which summarises the Fortran

8X proposals.

It is intended to prepare a summary of the various implementations of

Fortran 77. Members of the Group are invited to submit a short note to

the Secretary (David M Vallance, Computing Centre, University of Salford,

Salford M5 4WT), describing any implementations of Fortran 77 that they

are aware of under the following headings.

Compiler Identification

Hardware/Operating System

Conformance to ANSI Standard

Extensions and ability of compiler to flag use of these

Comments on 'quality' of compiler

(diagnostics, optimization, comparison with Fortran 66

compiler on same hardware, etc.)

A Fortran 77 booklist appears as Appendix A to these minutes. Anyone

who knows of other Fortran 77 text books should inform the Secretary so

that the list can be kept up-to-date.

The BCS has produced a list of its publications which was circulated at

the meeting.

The Group has been given an allocation of £110 from BCS funds for the next

financial year.

6. DATE OF NEXT MEETING

The next meeting of the Group (Annual General Meeting) is on Monday,

19 April 1982, at BCS Headquarters. In the afternoon David Muxworthy

will describe the main proposals in Fortran 8X.

7. AFTERNOON SESSION

Brian Shearing (Euro-Computer Systems) gave a talk entitled 'How to make

portable packages with almost any dialect of Fortran'. A summary of

his talk appears as Appendix B of these minutes. His address is

Euro-Computer Systems, 16/18 Station Road, Redhill, Surrey RH1 1NZ.

APPENDIX A

Books on FORTRAN 77

All prices are approximate and refer to paperback versions unless stated

otherwise.

------------------------

Language Textbooks.

FORTRAN 77 - Harry Katzan Jr.

Van Nostrand Reinhold (1978).

FORTRAN 77 Programming - W. S. Brainerd, C. H. Goldberg & J. L. Gross

Harper & Row (1978).

Programming in Standard FORTRAN 77 - A. Balfour & D. Marwick

Heinemann Educational Books (1979) Price £5-50 (also in

hardback) A comprehensive textbook aimed at both novice and

experienced user: not aimed at any particular discipline. Contains the

full language syntax in an appendix. The authors are in the Computer

Science department of Heriot-Watt University, Edinburgh.

FORTRAN 77 featuring Structured Programming - Loren P. Meissner & Elliott

I. Organick - Addison-Wesley (1979) Price £10.

A comprehensive textbook aimed at both novice and experienced user. One

of the authors (Meissner) is secretary of ANSI X3J3.

FORTRAN 77, Principles of Programming - Jerrold L. Wagener

John Wiley (1980)

The author is a member of ANSI X3J3.

Structured Fortran, a FORTRAN 77 Programming Course - T. M. R. Ellis

University of Sheffield Computing Services (1980) Price £2-60

Handbook designed to accompany a series of l0 video-tape lectures .

produced at Sheffield University. The course is aimed at novice users and

covers most of the language; the rest being provided as an Appendix. The

full syntax diagrams are included as an Appendix. The book is essentially

a transcript of the tapes plus examples, language variants etc.. A more

comprehensive textbook is due to be released mid 1982.

FORTRAN 77 for Humans - R. Page & R. Didday

West Publishing Co. (1980)

Programming with FORTRAN 77 - J. Ashcroft, R. H. Eldridge,

R. W. Paulson & G. A. Wilson - Granada Publishing (1981)

Price £5.

A textbook for Mathematicians and Scientists. The authors are in the

Mathematics department of Salford University and the book is written in

the style of a mathematics textbook.

Programming FORTRAN 77 - J. M. P. Hume & Holt

Reston Price £8-40

FORTRAN 77 - D. M. Monro

Arnold Price £8-50

Application or Method Oriented Books

Fortran with Style, Programming Proverbs - Henry F. Ledgard &

Louis J. Chmura Jr. - Hayden (1978) Price £6-50

Programming in Fortran, Structured Programming with FORTRAN IV & FORTRAN 77

Vladimir Zwass - Barnes and Noble Books (1981)

Price £4.

Business Programming in FORTRAN IV & ANSI FORTRAN 77, a Structured Approach

Asad Khailany - Prentice Hall (1981)

Problem Solving and Structured Programming in Fortran (2nd. Edition) -

F. Friedman & E. Koffman

Addison Wesley (1981)

New edition compatible with FORTRAN 77. Intended to provide more than

APPENDIX B

HOW TO MAKE PORTABLE PACKAGES WITH FORTRAN - Page 1

Some notes on:

"How to make portable packages

with almost any dialect of Fortran"

a lecture given to

The Fortran Specialist Group

The British Computer Society

8th February 1982

METHOD

A small program of 1378 lines is used to illustrate the

methods used by Euro Computer Systems for making

packages that work with little change on a wide variety

of computing systems.

BACKGROUND

The company (trading until October 1980 as Alcock

Shearing & Partners) has been concerned with the

production of portable programs for, primarily, civil

engineers over a period of sixteen years, The most

well known product of the company is probably the

General Engineering System GENESYS now marketed by

GENESYS Limited, In designing and implementing GENESYS

we learnt the horrible truths about how 'standard con-

forming' the various Fortran compilers really are.

(Believe it or not in those far-off days manufacturers,

i,e, people good at making hardware, used to also

supply complicated software like Fortran compilers.

You can imagine how well strategies like that worked

out!)

Since delivering GENESYS in 1971 the company has

written operating systems and compilers for mini-

computers and has continued to use Fortran to provide

engineering packages for mainframes, mini-computers,

and micro-computers.

Here is how production of a package might progress,

assuming that the specification was already complete:

HOW TO MAKE PORTABLE PACKAGES WITH FORTRAN - Page 2

STAGE 1 - THE USER'S MANUAL

Before any program is coded the User's Manual is

written in its entirety, including worked examples,

mock-ups of output, and so on.

By definition a manual written ahead of the software it

describes must be independent of computer, language,

and quirks of implementation. More importantly, a

manual written at the stage of a project when the

original objectives are still fresh in the mind will

certainly prove a better introduction to the new user

than a 'write-up' produced after the author has been

concerned for months with the minutiae of the software.

Another happy by-product of writing the User's Manual

first rather than last is that most design mistakes are

discovered during the writing. Explaining one's work

is a harrowingly effective way of discovering logical

inconsistencies.

[ Reference: The MISTRESS User's Book,

Donald Alcock and Brian Shearing,

Software--Practice and Experience,

Volume 3, Pages 255..301 (1973) ]

WHAT LANGUAGE?

Availability and degree of standardization dictate that

the only serious candidates for choice of programming

language are Pascal and Fortran. Although Pascal is

much to be preferred there are two reasons why, for the

moment, we reluctantly stick with Fortran:

(1) Pascal has only one precision of REAL.

(2) The lack of UNIVERSAL type (although present in

some extensions of Pascal designed for system

software) makes the writing of memory-management

software almost impossible. (Consider the problem

of moving a wodge of information from one place to

another without knowing its type.)

HOW TO MAKE PORTABLE PACKAGES WITH FORTRAN - Page 3

We can produce a double-precision version of a program

from its single-precision form in Fortran by a sequence

of systematic global edits. For example:

(1) Declare all reals in a REAL statement, Then

"REAL" can be replaced throughout by "DOUBLE

PRECISION".

(2) Write all real constants with a trailing "E0".

Then all such can be replaced throughout by "D0".

(3) Introduce a global variable called IPR which is

preset in a BLOCK DATA subprogram to hold the

number of integers per real (e.g. 1, 2, 4 or even

3 or 6).

WRITING THE PROGRAM

We separate the program into the program proper and a

realization of the program in Fortran.

Once upon a time (like GENESYS time) we used flowcharts

to write the program proper. Apart from the

essentially unstructured nature of flowcharts the

almost impossible task of updating them rules them out

for use with maintainable programs.

Instead of flowcharts we use a notation called "3R" to

describe the logic of the program. we devised the 3R

notation firstly to make programs readable, secondly to

make them writeable. and finally to enable them to

exhibit their arithmetic. The 3R notation has been

designed with today's typical text-maintenance and

word-processing programs in mind.

[ Reference: Dear Mrs. Stacey.

Brian Shearing.

Euro Computer Systems Limited, 1981

Reference: Report on the programming notation 3R,

Andrew P. Black,

Programming Research Group,

Oxford University Computing Laboratory ]

HOW TO MAKE PORTABLE PACKAGES WITH FORTRAN - Page 4

In the same way that we complete the whole of the

User's Manual before starting to program, we complete

the whole of the program in 3R before starting its

realization in Fortran.

The separation of a program from its realization helps

portability because when writing the program proper we

concentrate solely on the logic. when realizing the

program we concentrate solely on producing efficient

and, of course, portable code.

At this point the project is 80% complete but not a

word of Fortran has been written.

REALIZING THE PROGRAM

The program is realized in a dialect of Fortran chosen

to be acceptable to compilers on computers large and

small. The dialect is based on ANSI X3.9-1966, with

restrictions to compensate for known inadequacies in

popular compilers and for the incompatibilities between

the standard of 1966 and that of 1978 (i.e. Fortran 77).

[ Reference: A Review of Some Dialects of Fortran,

David Muxworthy and Brian Shearing,

Euro Computer Systems Limited. 1970

Reference: Serious Fortran,

J. Larmouth,

Software--Practice & Experience,

Volume 3, Pages 87..107 (1973)

Reference: Serious Fortran--Part 2.

J. Larmouth,

Software--Practice & Experience,

Volume 3. Pages 197..225 (1973)

Reference: The PFORT Verifier,

B.G.Ryder,

Software--Practice & Experience,

Volume 4, Pages 359..377 (1974)

Reference: Compatible Fortran,

A. Colin Day.

Cambridge University Press, 1978

ISBN 0 521 22027 0 ]

HOW TO MAKE PORTABLE PACKAGES WITH FORTRAN - Page 5

The references above specify rules that must be obeyed

if Fortran text is to be truly portable. Expressions

must be limited in complexity; declarations must be

carefully ordered; COMMON variables must be carefully

ordered; and so on. we obey these rules in writing our

Fortran but in the two areas of io and of characters we

side-step the problems rather than facing them head on.

We permit no io statements within the body of the

Fortran text. Instead all communication with the

operating system takes place from within a single

subroutine called CHAN. By calling CHAN the program

can open a file, read from it, write to it, and close

it. A file is either a sequential formatted file or a

direct-access unformatted file. Encoding and decoding

are done by simple routines within the program.

Implications of this approach include:

(1) Problem-oriented Free-Format io is achievable in a

natural way.

(2) It seems to be easier to write sound io routines

based on a stream of characters rather than on a

sequence of records.

(3) We have found the styles of available Fortran

formats to be unsatisfactory, particularly for

output, we encode floating-point values using a

subroutine whose single argument is the value to

be encoded, The effect of the subroutine is to

encode the value in a field of ten using one of

just four styles, as illustrated by the following:

±0.123456

±1234.567

±12345678

±1.234±12

One initially surprising outcome of this approach is

that io, particularly o, appears to be faster than when

using Fortran formatted io. Presumably this is because

of the necessity for the Fortran run-time system to

HOW TO MAKE PORTABLE PACKAGES WITH FORTRAN - Page 6

interpret the format before it starts the encoding or

decoding proper - in effect every encode or decode is

preceded by an extra implicit decode.

Portability is eased by having all io statements in one

place, when changes do have to be made such changes

are localized, for example unit numbers almost always

have to be changed from system to system, Another

common change is between "REC=n" and "'n".

Because the io statements within subroutine CHAN are so

simple it is often possible to invoke primitives of the

operating system directly and avoid the Fortran run-

time system altogether, thus recovering much useful

memory - particularly on small systems.

CHARACTERS

We avoid problems with characters by converting each to

a small integer on input and reversing the conversion

on output.

A small program is used to convert a given text into a

DATA statement initializing a vector of integers. For

example the effect of typing:

convert xyz TEXT

is to create a file containing the following:

DATA XYZ(1),XYZ(2),XYZ(3),XYZ(4)/212,197,216,212/

(The internal code is ASCII plus 128.)

PROBLEMS OF SIZE

A truly portable program should run on any computer,

irrespective of its size. In designing GENESYS we

tried to approach this ideal portability by underlying

the whole system with a software virtual memory. Our

present approach is less idealistic.

We separate the problem into one of size of code and

size of data.

HOW TO MAKE PORTABLE PACKAGES WITH FORTRAN - Page 7

In the last few months. overlaying link-editors have

become available for microcomputers, thus making it

possible to reduce the demands on main memory for code

irrespective of type of computer.

One way to reduce the amount of main memory needed for

data is to treat all data-structures but the smallest

as files. and that is what we do. To make this

approach viable we include a cache-memory scheme within

Subroutine CHAN. The more memory available the more

buffers we declare, and the less traffic there is

between memory and disk.

Brian Shearing

Euro Computer Systems Limited

16/18 Station Road

Redhill

Surrey RH1 1NZ

Telephone: Redhill 65500 and 63761

P.S. We would be happy to supply copies

of the documents referred to in this

text; in particular, "Dear Mrs.

Stacey" and the text of Subroutine

CHAN.