Minutes of the BCS Fortran Specialist Group Meeting

  held at BCS HQ, 13 Mansfield Street, London on 28 June 1990

Present:   Miles Ellis          Oxford University

           E Golton             RAL

           Carol Hewlett        LSE

           Peter Holland        SSL

           Chris Lazou          ULCC

           Brian Meek           Kings College London

           David Muxworthy      University of Edinburgh

           M J Roth             AEA Technology

           John Young           PE-MOD


        Apologies for absence were received from Mike Nunn, Les

Russell, and John Wilson. In the absence of the Chairman, John

Wilson, the Vice-Chairman, Chris Lazou, chaired the meeting.

2.      MINUTES OF THE LAST MEETING [10 May 1990]

        The Secretary, John Young, apologised to the meeting for not

finishing the minutes of the last meeting due to pressure of

work. The meeting decided to postpone its discussions on the

minutes to the next meeting.


        David Muxworthy announced that the Fortran Panel of the BSI

would be meeting on 10 July 1990 at 2 pm. He was seeking ideas

on the future of Fortran to present to the Panel. The meeting

decided to discuss this item in the afternoon session.


        The X3J3 Representative, Miles Ellis, reported that there

had been work done on the draft Fortran standard in only one

area. All other technical issues in Fortran 90 had been

finalised. This one area is known as the Forward Reference issue

and has to do with the definition of procedures whether they are

external or internal. A similar problem occurs in Modules. If

the information on procedures is not available when calling a

procedure an extra pass on compiling may be necessary making less

efficient compilation. This item has become a major issue in

Fortran 90 and has to be included in this standard.

        Miles re-iterated that the May meeting of X3J3 had completed

work on the Standard and that it had been passed to ISO but not

to ANSI. The DISC processing of the Standard was just starting.

The August meeting was being held in Oxford from 20th-24th August

1990 and would be mainly concerned with processing the public

comments from the second review.

        The BSI representative, David Muxworthy, gave a brief

report. He said he was preparing for the WG5 meeting to be held

in Rotterdam in August. He was seeking suggestions for revising

Fortran. He also felt that it was essential to keep the Fortran

experience in X3J3.

        Brian Meek then announced that Lawrie Schonfelder had been

appointed Chairman of the Programming Languages Committee for the

BSI. He then said that he felt the Forward Reference issue was

correcting an oversight at a late stage and that there was no

need for another ballot. New guidelines say that a new ballot

needs to be held for technical changes. On the future of Fortran

Brian said he felt it was a technical and tactical error to

immediately start revising Fortran 90. First WG5 needs to become

the new Fortran body with a small editorial group to produce

documentation on Fortran 90. New items he would like to see are

varying characters strings and event handling. Applications

could be modules in addition to Fortran 90 and there could be

"Incremental" Standards and Additional Standards.

        21st Birthday Celebrations

        In the absence of Mike Nunn, Chris Lazou reported on the

progress on the 21st Birthday Celebrations. It was reported that

the cost of the event at Imperial College would be around £25 a

head. The cost of the event at the Science Museum was definitely

too expensive. The celebration should be low-key but with a key-

note speaker. Various names were put forward and discussed.

There seemed to be a definite bias towards a day meeting with

lunch. The meeting decided that a day meeting would go ahead.

Mike Nunn was to be kept informed.


        Specialist Group's Executive

        It was announced that the Specialist Group's Executive,

Karen McPhilemy had left and that the post would be filled

temporarily until someone permanent could be found.

        BCS HQ Move

        It was still not known when the BCS would be moving its HQ.

        Date of Next Meeting

        The next meeting of the Group would be held at the

Rutherford Appleton Laboratory on 25 October 1990.


        In the afternoon, E Golton gave a short illustrated talk on

the collection and processing of Space data (summarised in

Appendix A). Then John Young briefly described the collection

and publication of Earthquake data emphasising the importance of

Fortran in Seismology (see Appendix B). Finally, David Muxworthy

led a discussion on the future standardisation of Fortran seeking

ideas from the meeting (summarised in Appendix C).

John Young, Secretary

15 October 1990



    E. Golton

        This is a brief summary of the talk on some aspects of space

data handling and some suggestions for extensions to Fortran 90.

        The quantity of raw data produced by scientific experiments

continues to rise dramatically; in both remote sensing and astro-

nomical imaging from satellites and in nuclear physics rates of l

GB/week, sometimes per day, are common. Data often take the form

of 8 and 16 bit counts, but other lengths, eg. 6, 9, and 12 bits

are common. Traditionally, such data have had to be handled ini-

tially with specially written assembler code because of the limita-

tions of Fortran. Apart from having completely non-portable code,

this often results in storing unpacked data, occupying even more

space, before use in Fortran analysis programs. Also, the problem

of interchanging space data and accessing archive data, perhaps in

formats from machines which no longer exist, has led the major

space agencies to set up working groups charged with developing

powerful data description languages, encompassing many aspects of

data structure and also binary format descriptions (viewgraphs were

shown on this). Fortran 90 development has been very extensive in

particular directions, but perhaps now it should develop to help

the raw data handling community, by adding binary I/O facilities?

        Before considering how this might be done, it is useful to

consider some related matters concerning the convenience and

efficiency of traditional processing methods. Raw data often

form continuous series, e.g. timeseries from instruments or series

of image lines. These are usually stored in a record form e.g. on

tape, perhaps blocked, then copied using disc I/O possibly with

some different record format: underneath this the computer operat-

ing system (OS) will store the data in physical disc sectors or

tracks along with error correction codes, etc. Thus in general we

may have a 3-level process to store the data and the reverse to use

it. What the user wants is usually the timeseries, or some section

of it, but he has to go through the reverse process of handling

records with complex code, spanning one record to the next as soon

as any multi-element operations such as filtering are needed,

possibly with double buffering and error checking as well. In two

or more dimensions with rolling buffers the code is an order of

magnitude more complicated (and expensive) than code using say an

array A(I,J) as passed to a subroutine. More importantly, it is

difficult to test such code thoroughly and difficult to maintain or

modify reliably. Alternatively, data can of course be copied into

one large array first, but this may be impossible or too expensive

because of size.

        Two developments in computing are relevant to improving this situa-

tion; virtual memory (VM) and file mapping.

- VM enables only those sections of a large data array (or code)

needed at any one time to be held in real memory, the bulk being

held on disc and handled by demand paged I/O by the OS. Program

code can thus use address space much larger than the size of real

memory. VM may not be a panacea for all ills and there may be

situations where record oriented code can be more efficient. But

with sensible algorithm organisation and use of VM optimisation

user parameters available with the better OS, those cases should be

few and unlikely to outweigh the code advantages indicated above.

- File Mapping is a related facility which allows a disc file in

suitable form to be treated as part of VM space. Of course, not all

machines will provide such a facility and we require Fortran to be

machine independent; in such cases the default of copying into a

real array can be done.

        Thus we arrive at the possibility of using raw data directly

from disc, mapped as a VM array e.g. A(I,J) in Fortran code. Such a V

process would by-pass completely the middle level of the 3-level

record-based model above, gaining in efficiency and simplicity.

This would work for data which happened to be in the form of a

standard machine word. But what about the question of 'non-

standard' binary data word lengths we first addressed? It would

seem quite straightforward, in principle, to handle these in a

similar very efficient, transparent way. Assuming the existence of

an 'n-bit' data type and arrays, a matching pointer, and a suitable

file definition, the following steps are needed:-

a) map the pointer to the data file on disc, using information

on data array size. In Fortran 90 terms, an 'array pointer'

plus 'shape' information would be matched to a file, instead

of doing an ALLOCATE operation;

e.g. FMAP (PBNARRAY,shape,stream)

b) a few machine instructions (set up by the compiler) unpack

the required next n bits 'on the fly' into a standard word

for use in the algorithm loop. The users code could use the ~

bit array element directly, or do explicit assignment;

i.e. I = PBNARRAY(K).

        In the above way, raw binary data, or compact processed data

written out in binary form could be processed directly without

first copying into larger standard-word arrays and without inter-

mediate copying into record oriented disc files, and using much

simpler and more reliable code. In practise it would be much more

useful if the assumption above of a bit data type included defini-

tions relating to the outside world, and not just be a virtual type

with details known only to the machine; i.e. capable of handling

signed and unsigned, big and little-endian binary numbers. But here

we are back to data description languages, where we started.




   J. B. Young

        The following is based on the notes used to describe the

publication of earthquake data and the use of Fortran programs.

(1)     ISS - International Seismological Summary -

        Based at Kew, England from about 1918 - 1963.

        Hypocentres were computed by hand using globes, maps,

             and tables, and published as a printed hard-cover book.

        Data published some years in arrears

             e.g.  the 1918 data after WWI published in 1923,

                   the 1945 data after WWII published in 1955,

                   the 1963 data (the last year) published in 1969.

        By the late 1950's the world-wide seismological community

                felt this delay was unacceptable.

(2)     ISC - International Seismological Centre -

        Started in Edinburgh, Scotland from 1964 - 1975,

        Moved to Newbury, England in 1975 and then to

             Thatcham, near Newbury in 1986 in purpose built premises.

        Hypocentres were computed using "electronic computing machines"

             after a young programmer named van Raalte demonstrated that

             Fortran programs could do the job previously done by hand

             but many times faster.

        Aim to publish all seismological data after a two year delay;

             The 1964 data was published in 1967.

             By 1972 the two year delay had been achieved and is still

             maintained today. Currently, data has to be at the Centre

             22 months after the event to be included.

(3)     ISC - Some Facts and Figures -

        All computational programs written in Fortran 77 for a DEC

             Microvax 3400.

        International exchange of data - even with 22 month delay some

             data is still missed.

        Data published in a soft-cover book printed on 'bible' paper.

        Every year over 30,000 hypocentres are computed from about

                1,200,000 readings.

        The 'Historical Earthquake File' dating from the early 1900's

             contains nearly 400,000 events.

        All data will soon be available on compact disks (CD-ROM).

        Future plans include a large increase in the number of readings

             published with large earthquakes.


Summary of discussion on future standardisation of Fortran

  David Muxworthy

The meeting agreed in principle that Fortran should be further developed,

i.e. that the Fortran 90 standard should be revised. The reasons are

essentially the same as for the revision of Fortran 77. It was suggested

that it was too soon to put forward a new work item proposal, and that

the Summer 1991 WG5 meeting would be an appropriate time to attend to
this.  Concern was expressed at the loss of knowledge about Fortran 90
should X3J3 be dispersed. It was suggested that members of X3J3 and WG5

should consider producing an Information Bulletin on why things have

developed as they did.

Topics members would like to see addressed in a revision were

(in no particular order):

- bit handling

- event handling, possible on the Ada model

- "real time" computing

- parallelism and multi-tasking, with reference to X3H5 work

~ extension of deprecation

- possible implementation of core and modules

- examination of features in other languages which cause them

  be used in preference to Fortran

- more extensive notes in the Standard including advice on use

- retention of emphasis on efficiency and of independent


- ability to cross call other languages

- acknowledgement that the underlying hardware is likely to

  change substantially in the lifetime of the Standard

- possible definition of graphics interface, e.g. for micros,


- ability to force serial execution, e.g. by compiler directly

- arbitrary character sets in identifiers

- register of character kinds in Fortran 90

- store mapping of files


Your subscription fee for membership of the BCS Fortran Specialist

Group is now due for the year 1990-91. Please complete as below :

        *     I am now a BCS member. My membership number is :

        *     I wish to continue my membership of the BCS Fortran

              Specialist Group and enclose a cheque or postal order

              for £5 made payable to "BCS Fortran Specialist Group".

        *     I no longer wish to be a member of the BCS Fortran

              Specialist Group.

        *     Delete as applicable.

Please send this completed renewal form (and subscription

if appropriate) to :

                                          Specialist Groups Executive,

                                          British Computer Society,

                                          13 Mansfield Street,

                                          LONDON, WIM 0BP.

                                          Telephone 071-637-0471