Present:         John Appleyard      - Polyhedron Software

                 Mike Bennett        - CEGB Staff College

                 Ray Crawford        - RAE Pyestock

                 Miles Ellis         - Oxford University

                 Mike Geary          - NAG

                 Dave Griffiths      - SSF

                 Carol Hewlett       - LSE

                 Keith Normington    - Coventry Polytechnic

                 Mike Nunn           - CCTA

                 David Palmer        - British Coal IT Dept

                 Kevin Pritchard     - UMIST

                 Lawrie Schonfelder  - Liverpool University

                 Jim Smith           - Siemens SDG

                 Neil Smith          - RAE Bedford

                 Julian Tilbury      - Salford University

                 Richard Tough       - SSGB Glasgow

                 John Wilson         - Leicester University

                 John Young          - MOD (PE)


Apologies were received from Chris Lazou, David Muxworthy, David

Vallance and Alan Wilson.


Corrections to previous minutes:

  (i)     Appendix A (Treasurer's Report)

               meeting dates "25.7.87" and "16.10.87"

               should read "25.7.86" and "l6.l0.86"

  (ii)    Page 4 paragraph 1

                  "complete language" should read "complex language"


  (i)     Chris Lazou has taken over from John Wilson as our Group's

          representative on the BCS Software Engineering Technical

          Committee for the immediate future. However, Chris would

          like to hear from anyone willing to help with this

          function - please note that BCS reimburses any expenses

          incurred in attending.

  (ii)    Dave Griffiths offered to give a talk on Fortran compilers

          on moderately parallel processors at our next meeting in


  (iii)   At our January 1988 meeting Alan Wilson and Chris Lazou

          will organise a presentation on parallel processing

          features in Fortran 8X.

  (iv)    At our April 1988 meeting we hope to have a talk comparing

          Ada with Fortran 8X.

  (v)     John Wilson pointed out that X3J3 would like a "concerted"

          UK view on Fortran 8X. To this end there would probably

          need to be a BCS meeting devoted to a discussion of that


  (vi)    John had spotted a minor arithmetic error in the

          expenditure listed in appendix A of the Treasurer's

          Report. Meeting costs totalled £312-49 not £322-49, and so

          total expenditure should be £386-22 not £396-22.

4.        BCS BUSINESS

(i)       A working party has been set up on formal methods in

          developing Standards.

(ii)      BCS has now become a BSI member, which will assist in

          obtaining discounts on BSI publications.

(iii)     Joint meetings of BCS representatives on standard

          committees and BSI have been taking place - from our Group

          Brian Meek and John Wilson are involved.

(iv)      John Young asked whether there was any news on the new

          Chartered Engineer category but apparently no information

          is yet available.


Miles Ellis had attended the May X3J3 meeting in Seattle and

summarised the main happenings:

(i)       A vote on the 8X draft resulted in a two thirds majority

          in favour of its readiness to go out for public comment.

          The draft has formally been passed up by X3J3 to the X3

          parent committee. There has been some confusion within

          X3J3 on the procedures to be adopted in releasing the


(ii)      Of significance is the fact that most of the major

          manufacturers, except Cray Research, have voted against

          the 8X draft.

(iii)     Previously ISO delegated ANSI to produce the Fortran

          Standard which it would subsequently rubber stamp as the

          international standard. However, ISO has now taken back

          such authority and tasked WG5 to check out the X3J3 work.

          SC22 is the ISO parent body.

(iv)      The Japanese are pressing to have the Kanji character set

          built into Fortran processing capability.

(v)       X3J3 will have to respond to all comments received on the

          8X draft, which should be available about the end of


(vi)      Jerry Wajener (X3J3) had offered to provide an unbound

          edition of the draft from which our group could print

          copies. After some discussion at the Coventry meeting it

          was decided that, to avoid infringing ANSI copyright on

          F8X, we would need a letter from the committee giving

          permission to copy.

          John Reid (Harwell) had produced a detailed report on the

          May Seattle meeting which was included in our last


          [I have recently seen a report in the excellent American

          computer journal "Computerworld" which discusses some of

          the objections of major suppliers to the 8X draft - a copy

          appears in appendix A.]

6.        FORTRAN FORUM 87

Our Group will hold a "Fortran Forum" in London, once 8X has been

released for public review, at which there will be both a number

of talks by those associated with the development of the new

standard together with an opportunity for open audience

discussion. Most likely date is late November. Those booking to

attend will receive a copy of the 8X draft some weeks before the

event so they have adequate opportunity to digest its content.

Your committee is currently considering possible venues so anyone

with bright ideas please pass them on to the Secretary. We need a

room able to hold, say, 150 people with good visibility and

preferably suited to those wishing to take notes. It also needs

to have facilities at hand to cope with a buffet lunch for the

attendees - possibly brought in by outside caterers.


The Group's thanks are due to Keith Normington, one of our

longstanding members who is also Director of the Coventry

Polytechnic Computer Centre, for allowing us to hold the July

meeting there. Afterwards Keith took members on a most

interesting tour round the computer facilities which include

systems supplied by Sequent Balance, which are fairly new to the

UK scene but are performing well at Coventry.


Our next meeting will be held on Thursday 1st october starting at

10:30am at BCS HQ. At the afternoon session starting at 2pm there

will be a talk given by David Griffiths of Systems Software

Factors titled, "Fortran compilers on moderately parallel




In the afternoon John Appleyard of Polyhedron Software gave a

talk on Productivity Tools for Fortran Programmers. A summary

appears in appendix B together with some information sheets on

Polyhedron products.


Secretary, BCS Fortran Specialist Group

18th August 1987.

                                  APPENDIX A

                              COMPUTER WORLD NEWS

Opponents bemoan ANSI Fortran 8X additions


        CW STAFF

Although opponents of the proposed Fortran 8X standard differ in

their opinions of specific features, a cross section of those

surveyed last week appears to agree that too much has been added

to the language.

        "We thought the ANSI X3J3 Committee was taking the language

to a much greater order of change than we thought judicious,"

said Michael Maynard, a Unisys Corp. spokesman at company

headquarters in Blue Bell, Pa.

        "The stand we took was that the language was too large and

incorporated too many experimental features," said Robert C.

Allison, senior engineer in the compiler development group of

Harris Corp., another opponent of the standard.

Heavy hitters opposed

The X3J3 Committee submitted the proposed standard, currently

called Fortran 8X to reflect the uncertainty of the year of its

likely approval, to its parent committee after a 26-9 vote in

June. Among the nine opponents were a number of key Fortran

compiler writers and users, including IBM, Digital Equipment

Corp., Unisys, Harris and Boeing Computer Services.

        DEC's X3J3 representative, Gary Robinson, manager of

corporate standards, said Fortran is one of the languages most

often used by DEC customers and that the firm wants to see a new

Fortran standard emerge. Nevertheless, DEC strongly opposes the 8x


        Robinson said the X3J3 Committee is attempting to add array

processing to Fortran compilers at a time when the job can be

done better in hardware. Two start-up manufacturers offer the

feature. Putting array processing into the standard now will

retard the development of this new technology, he charged.

Out with the old?

Robinson also attacked the committee's proposal to name

"deprecated features" in Fortran with the understanding that they

will be dropped in the next full version of the language.

Robinson said such a move will make Fortran 77 programs

incompatible with the new standard and that users will

converting to the new standard.

        He drew an analogy to the Cobol 85 opposition that emerged in

the user community when it became known that compilers meeting

the new standard would not be able to compile programs written

under earlier versions. "These languages are just too old. We

can't say we don't want to use their older features," Robinson


        In addition, Robinson said the committee had a number of

options to invoke that ensure 16-,32- and 64-bit machines yield

the same answer to a mathematical problem but chose none of them.

DEC advocated this issue be addressed, he said.

        Another feature that DEC wants to see revised is the INCLUDE

statement in the Fortran 8X proposal. During a compile, an

INCLUDE statement prompts the compiler to take code from an

outside file. "The user is better off if the outside file is

defined and certain limits put on it in the original program. The

committee left it open-ended," Robinson said.

        Brian L. Thompson, senior technical staff member at

Concurrent Computer Corp., said he voted in favor of the proposed

standard as a "good faith effort" to reach a compromise within

the committee but that "we morally side with those who are

against it."

        Although the opponents include a number of sizeable compiler

writers and manufacturers, there were several compiler producers

besides Concurrent who voted in favor of Fortran 8X.

IBM representative Richard Weaver could not be reached for


                                  APPENDIX B

            Spaghetti Unscramblers and Software Reconditioning

In recent months, a new class of software, colloquially called

"spaghetti unscramblers" has come on to the market. In this

short article, I will examine the ways in which these tools can

be used, with particular reference to the unscrambling of Fortran

spaghetti code.

What does a Spaghetti Unscrambler do?

A spaghetti unscrambler takes the sort of "rats-nest" code

commonly found in older programs and produces a re-structured

version which is logically equivalent to the original, but much

easier to understand. The restructuring involves the conversion

of old-fashioned control constructs (such as GOTO, arithmetic IF,

computed GOTO etc.) to a more modern and structured FORTRAN 77

equivalent, and the re-location of blocks of code within the

source file. This does not change the meaning of the code, or the

order in which statements are executed, but only the way the

program logic is represented in source form. Any bugs in the

original will be faithfully re-produced in the re-structured


Unscrambling is surprisingly effective. Fig 1 shows a "before

and after" example taken from a public-domain chess program. Of

course, the results may not always be so good, and it would be

possible to devise examples which could not be unscrambled.

However, there is no doubt that for the overwhelming majority of

"old-style" Fortran, unscrambling produces a genuine and

worthwhile improvement in clarity and maintainability. Table 1

attempts to quantify the benefit for a typical 1000 line

program. The two columns show the number of statement labels

(excluding FORMATs and DO terminators) in each of the 10

sub-programs before and after unscrambling. About half of the

labels which remain in the re-structured version are there only

because FORTRAN 77 has no way of representing some perfectly good

constructs (such as DO..WH1LE) without using GOTOs. If these are

eliminated from the count, the overall improvement factor

increases to about 8.

Table 1 - Statement label count before and after re-structuring

                                  Before        After

                        MAIN        67            15

                        HEUR        45             7

                        MYCAS       10             4

                        TREE        54            10

                        FMOVE       19             3

                        WMOVE       33            10

                        BMOVE       33            10

                        MYGO        11             1

                        ISGO        21             4

                        ISCAS       12             4

                        Total      308            68

Fig 1 "Before and After" example of Fortran Unscrambling

            Original                    Unscrambled using SPAG 2.00

            program bit                 PROGRAM bit

            IBON=0                      ibon = 0

            IF(KON)35,19,35             IF ( kon.NE.0 ) THEN

        19  IF(NSQ-56)24,22,24              IF ( mark(nmove).LT.0 ) THEN

        22  IF(LSQ-46)5,28,5                   ibon = -5

        24  IF(NSQ-55)29,27,29              ELSE

        27  IF(LSQ-45)5,28,5                   ibon = 5

*       28  IBON=2                          ENDIF

            GO TO 5                     ELSEIF ( nsq NE.56 ) THEN

        29  IF(LSQ-32)30,31,30             IF ( nsq.NE.55 ) THEN

        30  IF(LSQ-39)39,31,39                IF ( lsq.EQ.32 ) THEN

*       31  IBON=-5                              ibon = -5

            GO TO 5                           ELSEIF ( lsq.EQ 39 ) THEN

        39  IF(LSQ-35)52,51,52                   ibon = -5

        52  IF(LSQ-36)5,5l,5                  ELSEIF ( lsq.EQ 35 ) THEN

*        51 IBON=10                              ibon = 10

            GO TO 5                           ELSEIF ( lsq.EQ.36 ) THEN

        35  IF(MARK(NMOVE))36,37,37              ibon = 10

        36  IBON=-5                           ENDIF

            GO TO 5                        ELSEIF ( lsq.EQ.45 ) THEN

        37  IBON=5                            ibon = 2

        5   end                            ENDIF

                                        ELSEIF ( lsq.EQ.46 ) THEN

                                           ibon = 2



The starred statements in the original code occur more than once

in the unscrambled version.

What about Efficiency?

With few exceptions, an unscrambler does not change the way in

which computation is done, but only the way in which control is

passed between one computational section of code and another. As

a result, there should be little or no change to either the size

or speed of the object code when a program is unscrambled. What

happens in practice is, of course, highly compiler-dependent, but

more often than not, the unscrambled version is slightly larger

and very slightly slower than the original. It appears that many

compilers produce better object code from an arithmetic IF than

from the equivalent block IF.

In a few cases, the unscrambler may deliberately make changes

which effect the object code speed and size. These include

     (1)   Code duplication. An unscrambler may be able to do a

           better job if it is allowed to duplicate statements (see

           the example above). This may increase the object code


     (2)   Computed GOTO. Computed GOTOs may be converted to an

           equivalent block IF..ELSEIF..ELSE .ENDIF. This may

           affect both the size and speed of the object code.

These changes seldom have a noticeable effect on performance, but

ideally, it should be possible to suppress them.

Ease of Use

A spaghetti unscrambler should be as easy to use and as fast as a

compiler. Programs of any size should be processed within a few

minutes and with no user intervention.

Software Reconditioning

The most obvious use for spaghetti unscramblers is in

reconditioning old software to extend its useful life. Given

that the cost of re-writing programs may easily exceed £15 per

line, it is not difficult to justify the relatively insignificant

cost of re-conditioning.

However, it is essential that the job be done in a disciplined

manner, and with the maximum possible support from software

tools. Repetitive editing should never be done by hand, as

mis-typing could introduce many new errors into a program.

Changes should be made in an incremental fashion, with regular

testing of intermediate versions, so that problems can be

identified while it is still possible to undo their causes.

Software tools can be used to build important parts of the

program documentation. For example, utilities which produce an

analysis of the calling structure of a program ("where is this

subroutine called from") are far more efficient and reliable than

any manual alternative. Examples of the output from such a

utility are shown in Fig. 2. In short, the guiding principle of

software reconditioning is "Never do it by hand if there is a

tool that can do it automatically".

A Less Radical Approach

If you do not plan to change or enhance a program, but would like

to understand and document it, then there is a good argument for

using a spaghetti unscrambler as a crystal ball for seeing the

code more clearly, whilst leaving the original as the master copy

("if it ain't broke, don't fix it"). This style of use should

also appeal to those who need to build confidence in the tools

before committing themselves to a full-scale re-conditioning


In other situations, there may be no option; for example if you

are receiving updates from a third party which are based on the

original code, then you cannot safely change the master copy,

though the spaghetti unscrambler and other tools can still be

used as an aid to understanding.


A spaghetti unscrambler can be of particular value when a program

is being translated to a different language. For example, much

of the point of switching to a block structured language such as

Pascal or C is lost if spaghetti code is translated literally. A

good unscrambler will also modernise the program syntax, for

example by converting Holleriths to character constants, and

ensuring that all DO loops are terminated by a separate CONTINUE

or ENDDO. This removes some problems which would otherwise have

to be tackled as part of the translation.

A Software Reconditioning Workbench

The spaghetti unscrambler is in fact only one (though an

important one) of the tools which can be used to support the

activities described above. Others include a programmable

text-editor, compilers or other programs which can diagnose

illegal or dubious code, programs to document the calling

structure, cross reference generators etc. These tools could be

integrated into a "software reconditioning workbench", which

would, I suggest, substantially improve the productivity and job

satisfaction of the many programmers who have to work with poor1Y

structured and documented programs.

Fig. 2 Example of Program Structure Documentation produced by CRAM

OCLOSE is called by MAIN

ODELET is called by MAIN

OEXIST is called by MAIN

OGENV  is called by MAIN


OOPEN  is called by MAIN

OSFPAT is called by MAIN










1  2  OTRIM            ----- unresolved external


1  2  SWTOKN           ----- see later overlay

1  2  SFBRAC

1  2  SWFRAG

1  2  3  PWMOVE        ----- unresolved external

1  2  3  OLOCAS        ----- unresolved external

1  2  3  OUPCAS        ----- unresolved external

1  2  3  SWTOKN        ----- see later overlay


PWMOVE          is unresolved

   called from SCPATH      (line 81 of SCPATH.FOR )

   called from SWFRAG      (line 23 of SWFRAG.FOR )

   called from SWTROF      (line 37 of SWTROF.FOR )

   called from SWSTAT      (line 130 of SWSTAT.FOR )

Calls to SWSTUN               have different argument counts

        SWSTUN expects        2 args (line 1 of SWSTUN.FOR )

        SCPATH calls it with  2 args (line 322 of SCPATH.FOR )

        SFNUM  calls it with  1 args (line 71 of SFNUM.FOR )

        MAIN   calls it with  2 args (line 92 of MAIN.FOR )

        SRTROF calls it with  2 args (line 288 of SRTROF.FOR )

SWSTUN               is called recursively

        SWSTUN          calls SWSTAT

        SWSTAT          calls SWFRAG

        SWFRAG          calls SFNUM

        SFNUM           calls SWSTUN


                        What's Wrong with MAKE?

The UNIX style MAKE utility is an invaluable tool for software

developers. Its primary use is to rebuild a program after

changes to the source code. It does this with the aid of a

dependency file provided by the user. Typically, the information

in this file may be summarised as follows:

(1)     The executable file depends on a specified set of object

        files. If any object file has a modification time which is

        later than that of the executable file, the program must be


(2)     Each object file depends on a source file. If the source

        file has been modified since it was last compiled, then it

        must be re-compiled.

(3)     Source files may include text from one or more other files.

        If any of the included files has been modified since the

        last compilation, the source must be re-compiled, even

        though the source file itself is unchanged.

        executable >>>>  object  >>>>  source  >>>>  included

          file     >>>>  files   >>>>  files   >>>>  files

Provided that the information in the dependency file is accurate

and up to date, the system works well, but consider the

consequences of a little human error. Suppose that the user

omits the dependency of a source file on an included file. The

MAKE procedure will then fail to re-compile the source file when

the included file is changed. The program may then appear to be

correctly rebuilt, but there could be trouble in store. For

example, if the included file contains changed declarations, the

consequences may not be immediately apparent, but could be

extremely serious and hard to trace. This is precisely the sort

of problem that MAKE is supposed to avoid.

What is needed is a tool which automates the generation of the

dependency data, and in particular the dependency of source on

included files. A tool called CMAKE which does just that is

included in the PRISM toolkit. CMAKE builds and maintains the

dependency file itself, without any user intervention. When a

source file is changed, CMAKE scans it to find any included files

and updates the information in the dependency file. Then when an

included file is changed, CMAKE ensures that all files that

depend on it are re-compiled. CMAKE handles nested INCLUDE files


CMAKE assumes that the source files (but not the included files)

for each program are kept in a single directory, and that they

can be identified using a simple template (e g. *.c or

A*.for). In this sense it is less general than MAKE, but most

would accept that it is merely enforcing good programming

practice, and that generality when abused is just a licence to

foul things up.

             Keeping Machine Dependent Code under Control

No matter how hard you try to make programs portable, there

always seem to be little bits that have to be changed when

programs are moved between machines. In part, this is because

the required functionality is not part of the language standard -

many languages do not even specify a standard way of getting the

current time and date! Then, there are real differences between

machines which have to be taken into account - for example, word

length, file naming conventions, character codes etc.

How can these variations be included in the source code? The

first and most obvious step is, of course, to localise system

dependent code into a library of small routines which are

tailored to each machine. This is a good enough answer by itself

for many types of system dependence, but not for others. For

example, changes to array dimensions cannot be handled this way.

The thing to avoid at all costs is ad-hoc patching of the code.

At best, this wastes time, as the patches have to be re-done

every time a new version of the program is ported. At the worst,

it can lead to uncontrollably diverging versions of the program;

if the two versions are developed in parallel, even for a short

period, it becomes difficult or impossible to consolidate them.

The only way of regaining control is to scrap one or other


One way round this problem is to use a pre-processor of some

sort. The different versions of the source code might be held in

an external file and pulled in by the pre-processor in response

to directives embedded in the source code. This is only

effective if all changes are made to the un-preprocessed code,

and the pre-processor is regarded as an integral part of the

compiler. This is effective but clumsy.

A simpler solution is to put all the different versions into the

master version of the source code. Those sections of code which

are not required for the current host are present but commented

out. Each section must be flagged to show the conditions which

will cause it to be activated. A simple FORTRAN example would be

        *-IF VAX

        *-      PRINT * , 'Digital Equipment VAX version 1.1'

        *-      file = '[users.john]prog1.for'

        *-ELSEIF IBM37O

        *-      PRINT * , 'IBM 370 MVS version 1.1'

        *-      file = 'USJOHN.SOURCE.FORT(PROG1)'


                PRINT * , 'UNIX version 1.1'

                file = '/usr/john/source/progl.f'


        *-      PRINT * , 'Vanilla version 1.1'

        *-      file = 'PROG1.F77'


In normal use, no pre-processing is needed, and when the program

is ported from machine to machine, it is necessary only to

comment out some sections and un-comment others. The same

mechanism can be used for other types of variation in the

program. For example, you could use it to change array sizes, to

switch between single and double precision, or to add debugging


A software tool which automates the commenting and un-commenting

of the different sections is included in the PRISM toolkit. The

tool, which is called QMERGE, is intended primarily for use with

FORTRAN source code. It handles nested conditionals and obtains

the status of flags either by prompting, or from the command

line. De-activated sections may optionally be removed altogether,

though the output is then not capable of acting as the master