MINUTES or BCS FORTRAN SPECIALIST GROUP MEETING
HELD AT COVENTRY POLYTECHNIC ON 2ND JULY 1987.
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)
1. APOLOGIES FOR ABSENCE
Apologies were received from Chris Lazou, David Muxworthy, David
Vallance and Alan Wilson.
2. MINUTES OF PREVIOUS MEETING [1 April 1987]
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"
3. MATTERS ARISING
(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
October.
(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
subject.
(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.
5. FORTRAN 8X - PROGRESS REPORT FROM X3J3
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
draft.
(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
September.
(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
newsletter.
[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.
7. ANY OTHER BUSINESS
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.
8. DATE OF NEXT MEETING
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
processors."
9. TALK "PRODUCTIVITY TOOLS FOR FORTRAN PROGRAMMERS" BY
JOHN APPLEYARD OF POLYHEDRON SOFTWARE
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.
MIKE NUNN
Secretary, BCS Fortran Specialist Group
18th August 1987.
COMPUTER WORLD NEWS
Opponents bemoan ANSI Fortran 8X additions
BY CHARLES BABCOCK
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
proposal.
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
said.
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
comment.
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
version.
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
ENDIF
END
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
size.
(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
exercise.
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.
Translation
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
OLOCAS is called by SWFRAG SWSTAT
OOPEN is called by MAIN
OSFPAT is called by MAIN
OTRIM is called by SWINIT SWPEAK
OUPCAS is called by SFNUM SLOGIC MAIN SWCMNT SWFRAG SWTROF SWSTAT
PERRMS is called by SFPEAK SLINK
PERROR is called by SCPATH SFPEAK SLINK SRTROF
etc.
SCDEST
SCINT
SWSTUN
1 SWINIT
1 2 OTRIM ----- unresolved external
1 SWSTAT
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
etc.
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
etc.
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
re-linked.
(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
too.
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
version.
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)'
*-ELSEIF UNIX,XENIX
PRINT * , 'UNIX version 1.1'
file = '/usr/john/source/progl.f'
*-ELSE
*- PRINT * , 'Vanilla version 1.1'
*- file = 'PROG1.F77'
*-ENDIF
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
code.
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
version.