SPAG – Questions and Answers

Is it worth hanging on to programs which are just badly designed?

      It’s tempting to wash your hands of badly designed code, but programs have content as well as form. Old Fortran programs may look awful, and seem impossible to understand, but there is often real treasure buried in them, in the form of algorithms, data, and information of all sorts.

Don’t just throw it away – recondition it!


Can SPAG handle extensions to the ANSI standard?

    Yes. Each version of SPAG is tailored to accept the extensions to the ANSI standard which are supported by the host system compiler. For example, the VAX version supports all of VMS Fortran, and the MVS version all of VS Fortran. The PC version accepts almost all the extensions supported by the Salford, Lahey, Microsoft and Watcom compilers.

Are there limits on the size of program that can be processed by SPAG?

    Yes, but they are almost never a problem. Most versions can handle any number of sub-programs, each of which could have up to TEN THOUSAND statements. GXCHK places some limits on overall program size (typically the limit is between 500K and 1,500K statements).

What happens to comments when the code is restructured?

    Comments are presumed to be attached to the statement that follows them, and as the code is restructured, are moved around in the same way as that statement. VAX style end-of-line comments, are an exception, and are attached to the statement with which they share a line. Another exception is comments preceding statements which are removed from the program (e.g. CONTINUE or GOTO statements which are not needed in the unscrambled code). These are attached to the statement following the redundant statement. The net result is that SPAG preserves comments and usually puts them in the right place.

Does SPAGged code run slower?

    With few exceptions, SPAG 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 slightly faster than the original. The increased speed probably comes about because compilers find it easier to optimise register usage for well-structured code.

How does SPAG restructure spaghetti code?

      SPAG transforms spaghetti code by the cumulative effect of thousands of “elemental” operations. These are small changes which improve the structure of the code, but leave the meaning unchanged. An important advantage of this approach is that major changes to program structure are brought about by a small number of relatively simple and thoroughly reliable procedures. Look at the example below: the apparently small change between the initial and final states is in fact the result of five elemental operations.

 

SPAG elemental operators – A Worked Example

Before Stage 1
IF ( A.GT.B ) GOTO 10  
    R1 = 2.0
    CALL SUB
 10 PRINT * , R1
IF ( A.GT.B ) THEN  
       GOTO 10
    ELSE
       GOTO xx
    ENDIF
 xx R1 = 2.0
    CALL SUB
 10 PRINT * , R1
Stage 2 Stage 3
IF ( A.GT.B ) THEN  
       GOTO 10
    ELSE
       R1 = 2.0
       CALL SUB
       GOTO 10
    ENDIF
 10 PRINT * , R1
IF ( A.GT.B ) THEN
    ELSE
       R1 = 2.0
       CALL SUB
    ENDIF
    GOTO 10
 10 PRINT * , R1
Stage 4 Stage 5
IF ( A.GT.B ) THEN
    ELSE
       R1 = 2.0
       CALL SUB
    ENDIF
    PRINT * , R1
IF ( a.LE.b ) THEN
      r1 = 2.0
      CALL sub
   ENDIF
   PRINT * , r1

 


Does it just amount to removing all GOTOs?

      Of course, there is more to producing readable code than just eliminating GOTOs. Pascal and C programmers know that too much nesting can make programs almost as obscure as too little. SPAG has elemental operators which allow it to reduce nesting by use of the ELSEIF statement. Look at the example below:

 

Example of Indentation Reduction

Before After
IF ( z.NE.'ONE' ) THEN
       IF ( z.NE.'TWO' ) THEN
          IF ( z.NE.'THREE' ) THEN 
             IF ( z.EQ.'FOUR' ) THEN 
                x = a(4)
             ENDIF
          ELSE
             x = a(3)
          ENDIF
       ELSE
          x = a(2)
       ENDIF
    ELSE
       x = a(1)
    ENDIF
IF ( z.EQ.'ONE' ) THEN       
       x = a(1)                  
    ELSEIF ( z.EQ.'TWO' ) THEN   
       x = a(2)                  
    ELSEIF ( z.EQ.'THREE' ) THEN 
       x = a(3)                  
    ELSEIF ( z.EQ.'FOUR' ) THEN  
       x= a(4)                   
    ENDIF

 


Can I be absolutely sure that SPAG will not change the logic of my program?

      A good question, which deserves a careful answer.

In the first place, SPAG is now a mature program. Since it was first released in 1986, SPAG has successfully unscrambled billions of lines of spaghetti Fortran, and it does its job without fuss or incident.

Secondly, the way SPAG works – by the repeated application of simple operators – makes it inherently robust.

A third point is that SPAG is largely fail-safe. The compiler acts as a second line of defence, checking the restructured code generated by SPAG. You are far more at risk from compiler bugs!

In fact SPAG provides a way to REDUCE the risk which inevitably goes with change. Using SPAG is certainly orders of magnitude safer than changing your code by hand!


The Next Steps

Ready To Buy?