Program slice browser - Department of Electrical Engineering ...

Program Slice Browser Yunbo Deng, Suraj Kothari, Yogy Namara Department of Electrical and Computer Engineering Iowa State University Ames, IA 50011, U.S.A. {ybdeng, kothari, ynamara} @iastate.edu

Abstract

programs. It has continued to be a topic of considerable research [9, 271. Different notions of program slices, as well a5 a number of methods to compute them have been proposed in the literature [27]. An important distinction is static vs. dynamic slice. A static slice is computed without making assumptionsregarding a program's input, whereas a dynamic slice relies on some specific test caqes for the input [27]. We consider static slices in this paper. This paper addresses the problem of how to extract useful information from a program slice that is too large and complex. Clearly, viewing a program slice simply as a sequence of lines is not adequate [161. PSB is proposed as an interactive visualization tool with novel features to assist users in making effective use of program slicing. It provides new abstraction mechanisms, navigation capabilities, and integration with other components for visualizing software. We expect that PSB will be useful for addressing a number of applications. One novel application is relative debugging [l, 261. We have integrated PSB as a part of a reengineering environment with a special focus on parallelization of widely used legacy Fortran codes. Relative debugging is applied in practice to find defects in a parallel program by comparing it against its serial version. A relative debugger such as GUARD [261 allows the user to set breakpoint? in a code and compare (between parallel and serial and versions) values of a set of variables as the execution steps through the breakpoint. The user has to decide where to set the breakpoints and which variables to monitor. These choices are very critical and without proper choices, the debugging can be very time consuming. This is especially so in cases where the execution takes a lot of time. For a small program, the user can perform a quick logical analysis in head and come up with a hypothesis for debugging. This is very difficult to do for large and complex program [8] and that is where PSB capabilities are useful. It can be applied to speed up debugging by providing the user a tool to determine the breakpoints effectively, without getting lost in details of a program slice.

Program slicing is usefulfor addressing many softwareengineeringproblems as it allowsfocusing attention on just the relevant part of the program. However, this part could still be huge and dificult to comprehend and thus diminish usefulness of program slicing. This is a serious problem in working with legacy codes for scientific computing. To address this problem, the Program Slice Browser (PSB)' is designed as an interactive and integrated tool that is particularly valuable for extracting useful information from a complex program slice. PSB incorporates following novel features: adaptable layoutfor convenient display of a slice, multi-level slice abstractions, integration with other software visualization components, and capabilities to support interaction and cross-referencing within different views of the software.

1. Introduction There is a large ba5e of legacy software for a wide spectrum of scientific computing that includes weather forecasting, long-range climate modeling, gene identification, and numerous engineeringdesign applications. The legacy software is a valuable resource, used by scientists all over the world. Legacy software continues to evolve. Scientists routinely enhance legacy programs to add new parameterization schemes, to couple models, to parallelize a program and so on. These activities often take enormous amount of time. Clearly, there is a need for program understanding and software reengineering tools to assist scientists who are working with legacy software. Program slicing was introduced by Mark Weiser [28] as a technique to facilitate understanding and debugging of 'This research has been supported by the U.S. Environmental Protection Agency's Science to Achieve Results (STAR) program, the ISU Center for Advanced Technology Development (CATD), and the Iowa State University Research Foundation (ISURF).

50 0-7695-1 131-7/01 $10.00 02001 IEEE

3 Program slice model

The rest of this paper is organized as follows. In section 2, we provide the context for PSB by describing the overall environment for our system. In section 3, we describe our program slice model. In section 4, we discuss specifics of PSB. In section 5, we present concrete examples involving use of PSB. In section 6, we summarize our conclusions,

We consider backward slices [22]. The mechanics for slicing, as implemented in our SRE, is described in this section. A program slice, with reference to given variables and a given line in the program, is defined as follows. Definition: Given a variable vector V in which each element of is a variable to be checked, and a location point p (a line number) of program, the program slice SLICE(V,p) is the sequence of statemem which influence the definition of each variable Vi E V at point p. Formally, SLICE(V,p) can be defined recursively as described below.

2, A system overview

1.

SLICE(V,p) =

(SLICEl(K,P)) Vi€V

11.

SLICE1(K,p) = {dj} where at statement di, the variable is defined as a constant and that definition can reach p , Or ...

111.

SLICE1(V,,p)= { q } U SLICE(Read_set-~ecto(q),q) Figure 1. Schematic design of the SRE where Vi is defined at statement q and the definition can reach p. Readset-vecto(q) is the vector of variables used in statement q.

PSB is designed as a part of a software reengineering environment (SRE) [14]. This SRE uses a four-step

reengineering process that is implemented with four modules, shown in Figure 1 as Parser, Diagnostic, Analysis, and Transformation. SRE has a sojiiare visualization environment, which consists of a code browser, a block-level abstract syntax tree (BLAST) viewer, template viewer, and PSB. We have used an integrated design and a combination of syntactic and semantic abstractions as the foundation for creating a powerful visualization environment. Using the integrated environment, the user can visualize the software at different levels: the actual code, syntactic structure of the code, program slice to focus on specific parts of the program, or the semantic structure of the code. Note that these directly correspond to the four visualization components integrated into the environment. These components are integrated with a cross-referencing capability that helps in relating together different views of the software. By using compacted and simplified views, the user can get a handle over the complexity of large software and not be lost in micro-level details. Syntactic and semantic forms of compact views are provided through BLAST viewer and template viewer respectively. Simplifications are possible through abstraction mechanisms.

3.1 Read and write sets The program slice is obtained by ud analysis [4]. Our ud analysis is based on the results from phase two (Diagnostic phase in SRE), when the read set and write set are built. In our system, read/write set are computed at three levels statement, block, and procedure. For an assignment statement, read and write sets contain respectively the variables appearing on the right side and the left side. For a block, read and write set contain respectively the variables used in the block and the variables defined in the block. We have three types of blocks, ordinary block which contains a linear sequence of code, subroutine block which is a call statement and control blocks such as IF and DO blocks. We refer readers to [21] for more details. It is worth pointing out that the read and write sets of a subroutine contains respectively variables used or dejned in the subroutine. Thus, we can treat a subroutine a$an ordinary block in the analysis of the caller. However, obtaining readwrite sets for subroutine calls requires inter-procedural analysis.

51

e.g. GOT0 statements, and “aliasing”, e.g. arrays and pointers. We have applied essentially the same strategy as Lyle’s [ 181 to deal with the array analysis. We will explore other precise analysis techniques as our work progresses.

3.2 Intra- and inter-procedural analysis In Fortran, two situations require inter-procedural analysis. First, common or global variables are modified through subroutine calls. Second, all actual parameters are subject to modification because in Fortran parameters are passed by reference. During intra-procedural analysis, we trace back the control flow. When a call statement (i.e. a call block) is reached, we check whether the variable to be traced is a common variable or an actual parameter. If that variable a is a common variable and belongs to the write set of the subroutine, we apply backward slicing to the called subroutine on a starting from the end of that subroutine. If variable a is an actual parameters and in the write set, we must map a to its corresponding formal parameter b and get program slice of b starting from the end of the subroutine. When the start point of the subroutine is reached, we export all nonterminated variables to outside - we proceed to the callers of the current subroutine and get the program slice of exported variables in the caller staring from the point where the current subroutine is called.

4 Program slice browser Users need to be able to comprehend and manage information obtained by program slicing. Some of program slicing tools [6, 13, 16,22,30] have incorporated the visual environments to assist users with program comprehension. SeeSlice [6], SWCOBOL [22] and Codesurfer [13] provide line-oriented visualization of program slices. The users can click highlighted lines to obtain further dependence and other relevant information. In our PSB work, we provide an interactive visual program slice diagram. PSB incorporates following features: 0

0

3 3 Conservative analysis We depend on static analysis. Our branch analysis considers IF branch, ELSE branch and the block immediately before the IF branch, which is necessary when an IF statement doesn’t have an ELSE branch. Our program slice contains the union of these three blocks when a branch is encountered. The union is considered because it is not possible to predict through static analysis which branch will be taken. 1: 2:

B = l A = C + D

3:

I F COND THEN A = l

4: 5: 6: 7:

0

Abstraction mechanisms, based on syntactic and semantic information, to extract useful information from a program slice: Ability to rearrange (panning, zooming, move nodes, group nodes, resize the tree etc.) the program slice tree to suit the user’s preferences for viewing the slice in a convenient manner. Pruning of the directed graph that depicts the program

slice. The user can remove parts of the graph that are not relevant to the current analysis. 0

Ability to instrument the code for relative debugging.

4.1 Program slice diagram

ELSE

To begin with, PSB displays a slice as a directed graph with three types of nodes corresponding to: statements (that are part of the slice) within a selected subroutine, variable references that are outside the subroutine, calls made to other subroutines that should be considered as a part of the program slice. We support two mechanisms to customize the layout of program slice to suit the user’s requirement. One mechanism is called the multi-column layout in which nodes are positioned according to the order of corresponding statements in the source code. For instance, the node representing the statement at line 12 is positioned before (closer to the top of screen) the node representing the statement at line 98. A multi-column layout is used to reduce overlapping of edges. The user can control the number of columns through a toolbar. The second mechanism is

B = B + 1 END I F

8: 9:

An integrated visual environment with crossreferencing capability to relate together the program slice and other displays for visualizing the software.

D = B + A

Figure 2. Conservative branch analysis

For example, referring to Figure 2, {1,2,4,6,9} C SLICE({ D } ,9). In this work, we focus on addressing user’s capability to interact and extract useful information from complex program slices and applying that information to solve practical problems. Other research papers [2, 3,5,7, 11, 12, 17, 241 have addressed the problem of more precise analysis of program slices in the presence of “unstructured” control flow,

52

r l

called the upside-down-treelayout in which nodes are positioned according to the data flow pattem. The tree layout is created by applying the breadth first search algorithm. The root node, placed at the bottom, is the point where the program slice begins, and the nodes at the top are the points where the program slice ends. The user can adjust the tree layout by setting the parameters width, height, and the spread factor. The user can also change placement of individual nodes.

code gem

eratwn

A Figure 4. interaction between program slice browser and other modules

are highlighted corresponding to statements in which a and b are modified. PSB is integrated with other components for software visualization. When a node is clicked, PSB notifies the event to the code browser and the BLAST viewer so that their displays are synchronized with PSB by highlighting the statement in the code browser and the corresponding block in the BLAST viewer. The interaction and integration provides useful capabilities for navigation and instrumentation. For example, it is often necessary to backtrack through a chain of statement? to understand how a given variable is modified. This type of backtracking can be done by using the combination of PSB and the code browser. Next, the user can obtain even more meaningful information by combining the display from the BLAST viewer. For instance, it may be more useful to identify that a relevant variable is first checked (read) in an if statement and then modified (written) in a do loop as opposed to simply knowing that there is read access in one place followed by a write access in another place within the program. This is difficult to identify through code browser when a control statement spans across several lines or pages of a program. We have found this to be a problem with many legacy programs. The cross-referencing capability provides a solution. The control block containing that statement is highlighted in the BLAST viewer so that the user can relate the access patterns and the control structure of the code. PSB provides a convenient visual interface to instrument code for debugging. After navigating through the code, suppose the user identifies a point for setting the break point for debugging. The user can direct the system to instrument the code through the debugging toolbar. The code for instrumentation is automatically inserted by the system. The user has the choice of viewing and customizing the instrumented code through the code browser. This is possible because of the integration with the code generation module as shown in Figure 4.

Figure 3. An example of program slice Figure 3 is an example of a program diagram displayed using upside-down-tree layout. In Figure 3, three components of program slice browser are presented. In the main window, a program slice is displayed as an upside-down tree. The small toolbox (upper-left) allows user to determine the parameters width and height. Plus, the toolbox accommodates four buttons recovery button, procedure-level abstraction button, block-level abstraction button and elimination button. The abstractions are discussed in a later section. The third window (lower-left) is the slice control window. In this example, it indicates that a program slice of variable ui3 starting from line 46 is computed.

4.2 Integrated and interactive environment As shown in Figure 4, PSB is integrated as a part of our software reengineering system. PSB is interactive. User can click on nodes or edges of the program slice diagram. When a node is clicked, the edges emanating from that node are highlighted so that the user can see immediate dependencies. For instance, if node for the statement z = a + b is clicked then the two edges

53

to only a small part of the slice. Block-level abstraction is also useful in bottom-up debugging. The expert who is familiar with the program can use bottom-updebugging. Usually a block of code is a meaningful computation unit. The expert can easily verify the correctness of a block of code with high-level knowledge. Once he/she identifies the correctness of block, the verified block can be abstracted so that internal details are hidden from the expert. This helps the expert concentrate on the remaining unverified parts. Procedure-level abstraction: A procedure level abstraction simplifies a program slice by retaining only the information about procedure calls. For example, suppose in statement 10, a common variable A is read and in statement 20, a local variable B is read. In procedure DUMMY, both A and B are changed because they are passed into DUMMY as actual parameters. After the procedure level abstraction, the nodes representing statement 10 and 20 in the slice diagram are removed. A new edge labeled “A, B” points to the “DUMMY” node indicating variables A and B are changed in DUMMY. In this way, programmer can easily grasp the dependence relationships between current procedure and other procedures. This is especially useful in case of Fortran programs because of the pervasive use of common (global) variables and the use of reference parameters. The user can enable this abstraction by clicking the “procedure level abstraction” button on the PSB toolbar. Formally, the procedure level abstraction on a slice S is a unary operation defined as follows: PROC(S) = (S - { ( e ,d , V)l neither e nor d is a call block} U {(z,y, V)13 a path p from call block z to call block y in S and V is the dependence vector along p that may be changed in y}. We will describe a scenario to illustrate the use of procedure level abstraction for relative debugging. The subject of analysis is a subroutine called HZETA from an electromagnetic application program written in Fortran. Suppose a discrepancy is observed between the serial and parallel outp u t ~for the variable H. Using the code browser, it can be determined that H is modified in the subroutine HZETA. However, we cannot rule out the possibility that the problem lies with modification of another variable in a different subroutine. That modification has a bug and it is indirectly (possibly through a long chain of subroutine calls) causing the observed discrepancy between serial and parallel programs. In practice, it is very difficult to perform this type of analysis manually. This scenario is in fact motivated by a similar problem we have faced in debugging a widely used regional climate model code called MM5. This model has close lOOK lines of code with more than 200 subroutines. The procedure level abstraction is very useful for relative debugging,especially in scenarios such as the one described above. To illustrate the use, we show in Figure 7 in section

4 3 Program slice abstractions Program slice abstractions are introduced to make it easier for the user to manage and understand complex program slices [23]. These abstractions can be of different types. The papers [ 15, 163 considers procedure-level abstraction to facilitate program understanding. Additional abstractions are needed to facilitate debugging, and performance analysis. PSB is designed to incorporate four types of abstractions correspondingrespectively to code blocks, procedures, graphs, and domain-specificsemantic entities. We have used the following notation. For formal definitions of abstractions, we represent a slice S as follows: S = {(e,d, V ) } ,where (e,d)is the edge from node e to node d in S and e is dependent on d because there is single (or multiple) variable in vector V which is defined in d and used in e and that definition can reach e. Block-level abstraction: Blocks are syntactic units. There are three types of blocks - ordinary blocks, call blocks, and control blocks. A block level abstraction encapsulates statements belonging to a block and represen$ them as a single node of the program slice diagram. This new node is labeled by the block type and the source code line numbers defining the boundary of the block, e.g. D0[10, 231. Formally, the block-level abstraction on a slice S and a block B is a binary operation defined as follows: BLOCK(S,B ) = (S-{(e,d,V)le~ B o r dB ~ }) U { (c, d , V)13(e,d, V ) E S where e E B and d $ B} U { (e,c,V)13(e,d,V ) E S where d E B and e $ B} c is the new node representing the merged block B. The user can enable this abstraction by clicking the “block level abstraction” button on the PSB toolbar and then, by using the BLAST viewer, select the block to be encapsulated. This clearly requires interaction between BLAST viewer and PSB. This interaction is shown by the edge labeled “1” in Figure 4. This abstraction encapsulates information intemal to a block and simplifies a program slice by reducing the number of nodes and also the number of edges. The nodes belonging to each selected block are merged together to form a new node. This new node retains the dependence relation between the merged nodes and rest of the nodes, but all relations within the block are hidden. This abstraction is useful for top-down debugging. Debugging is done at block-level to begin with, the intemals of the block are checked after a defective block is identified. For complex legacy codes, top-down debugging is often desirable. Without its use, i.e. checking at the statement-level for the entire slice, can be very time consuming (especially considering the instrumentationinserted into a loop that will be repeated many times) and tedious. With top-down debugging, it is possible to limit the statement-levelchecking

54

5 a PSB display after the procedure level abstraction applied. Note that the objective is to analyze the subroutine HZETA in order to gain a procedure-level understanding of how the variable H is updated. The PSB display in Figure 7 shows us that all the variables (relevant to the computation of I?) are coming from MAIN. Thus, the user can ignore other subroutines and concentrate on HZETA and MAIN for solving the debugging problem. Graph-level abstraction: A graph-level abstraction is used to simplify a slice based on graph characteristics. Weiser and Lyle called it program dicing in [19]. The objective of this graph abstraction is to enable the use of graph characteristics and algorithms to find efficient solutions for debugging problems. Similar to the link-fault-detection problem in networks, relative debugging is viewed as a problem of identifying faulty links in a program slice diagram. Then, efficient graph algorithms can be applied to find the bugs, now viewed as faulty links.

plate for a class of programs. We believe that the semanticlevel abstractions will be useful in context of a variety of application domains. However, to have a focus and validate our ideas with real-life test cases we are using semantic knowledge associates with jnite element method (FEM) and thejnite difference method (FDM) and applying that knowledge in case studies of legacy software for scientific computing. We are currently working on template viewer to enable semantic abstractions. The template is defined in terms of abstract data structures and logical steps which manipulate these abstract structures. The template represents high-level understanding of the program. Theses structures and steps may be dispersed through the program and they are bound to the program during the interactive diagnostic phase. Semantic abstractions are based on either abstract data structures or logical events that are identified through a domainspecific template. The user clicks on an abstract data structure seen through the template viewer. Then, all the nodes (in a program slice) corresponding to modifications of this abstract data structure are grouped together as one single node. This new node is labeled with the name of the abstract data structure. Another semantic abstraction is based on logical events. The user clicks on a logical event seen through the template viewer. Then, all the nodes (in a program slice) corresponding to statements or subroutine calls that are bound to the specified logical event are grouped together a5 one single node. This new node is labeled with the name of the logical event. Semantic abstractions simplify the slice and provide more useful information as the user can relate the slice to meaningful data structuresandor logical events.

,

I I“.

11

.:.

i. ’..

5

A preliminary quantitative experiment

PSB is a visualization tool. Its abstraction mechanisms are useful and we have provides some illustrations of their use. This section describes a simple quantitativeexperiment in which PSB is applied to understand and analyze a program slice. The experiment is based on a real-life debugging experience. The subject of analysis is a subroutine called HZETA from an electromagnetic application program written in Fortran. HZETA contains 175 lines of code including comments and blank lines and 29 common variables. The BLAST tree for HZETA consists of 20 blocks. The program slice is based on array variable H, to track its modification starting at the end of the subroutine HZETA. Figure 6 shows the program slice diagram and the BLAST viewer. As seen, the slice (right) is large. It contains altogether 65 nodes, and 168 arcs. First, consider the effect of procedure-level abstraction on the slice diagram. Figure 7 shows us that only MAIN and HZETA itself are responsible for modification of H. It

Figure 5. “Super node” in program slice We will present an example to illustrate how this abstraction can be used. Consider the program slice shown in Figure 5. One can easily observe that the graph has two “super nodes” (each representing a group of ordinary nodes) connected by one link. This graph characteristic can be exploited to make debugging efficient. By checking the correctness of SZT on connecting link “129+70”, it is possible to eliminate the top super node and thus quickly reduce the size of the debugging problem. In addition to simple visual inspection, this technique can be further improved by making use of clustering algorithms to form appropriate super nodes. Semantic-levelabstraction: A semantic-level abstraction is provided to extract information from a slice using domain-specific knowledge encapsulated in form of a tem-

55

4

Figure 7. Procedure-level abstraction on the program slice diagram

Figure 6. An example of program slice diagram and BLAST viewer

also tells us that 10out of 29 common variables contributing to modification of H are possibly modified in MAIN. Next, effects of block-level abstractions are considered. The block labeled “ORD 0 6” in the BLAST viewer is an ordinary block from line 26 to line 48. It is inside a twolevel nested loop. This loop is to compute unit vectors of a locally orthogonal system. All 20 statements within the selected block (excludingtwo blank lines) belong to the slice. Suppose after a review of this piece of code, the programmer decides that it is not necessary to debug the code within the selected block. Programmer checks the block-level abstraction toggle button and click the “ORD 0 6” node in the BLAST viewer to instruct the browser to merges all 20 statements into one super node labeled D0[26, 481. After this abstraction the slice diagram contains 45 nodes and 106 arcs. From line 102 to line 145, it is another two-level nested loop block “DO 0 11”. This DO loop is there to compute transformed variables in a contra-variantcomponent. After this block is abstracted, the reduced diagram contains only 33 nodes and 67 arcs. Finally, suppose the programmer determines the temporary variable HP5 at line 86 is computed correctly. The programmer checks the elimination toggle button and clicks the node 86 to issue an elimination instruction to cut off a branch of the tree. After applying this graph abstraction, only 30 nodes and 54 arcs are left. The final result is shown in Figure 8. We have summarized the results of the experimentin Table l.

I

Operations Effects Original program slice diagram 65 nodes, 168 arcs With procedure-levelabstraction 11 nodes, 10 arcs With first block-levelabstractions 45 nodes, 106 arcs With a successive block-level ab- 33 nodes, 67 arcs straction With a successivegraph-level ab- 30 nodes, 54 arcs straction Table 1. Summary of the effects of the abstractions on subroutine HZETA

6 Conclusion

This paper describes a program slice browser (PSB) that is integrated as a part of a software visualization environment. The main purpose of PSB is to help the user in extracting critical information without getting lost in details of a large and complex program slices. This is illustrated through several examples.

This is an ongoing project. Some of the features described in the paper are implemented and others are at various stages of design and implementation. For the features that are implemented, we have shown actual screen displays. Currently, we are still working on semantic abstractions and code instrumentationthrough visual interfaces. 56

[6] Thomas Ball and Stephen G. Eick. Visualizing program slices. In IEEUCS Symposium on VisualLanguages. St. Louis, Missouri, October 4th, 1994. pp. 288-295. [7] T. Ball and S. Honvitz. Slicing programs with arbitrary control-flow. In Proceedings of the First International Workshop on Automated and Algorithmic Debugging. 1993. [8] C. Beckstein and G. Tobermann. Algorithmic Debugging and Hypothetical Reasoning. Automated Software Engineering. Volume 4, pp.151-178,1997. [9] D. Binkley, and K. Gallagher. Program Slicing. Advances in Computers. Volume 43, 1996. [103 Robert W. Bowdidge and William G. Griswold. Sup-

porting the Restructuring of Data Abstractions through Manipulation of a Program Visualization. ACM Transactions on Software Engineering Methodology. 7(2). 1998. [ l l ] J.D. Choi, M. Burke, and P. Carini. Efficient flow-sensitive interprocedural computation of pointerintroduced aliases and side effects. In Conference Record of the TwentiethACM Symposium on Principles of Programming Languages. ACM. 1993. pp. 232-245

Figure 8. The final snapshot of the program slice diagram after blocks merging and elimination

[12] J.D. Choi and J. Ferrante. Static slicing in the presence of GOT0 statements. In ACM Transactions on Programming Languages and Systems. 16(4) pp. 10971113. July 1994.

References

[ 131 [13

David Abramson et. al. Relative Debugging and its Application to the Development of Large Numerical Models. Proceedings of the 1995 ACMLEEE Supercomputing Conference, 1995.

Code Surfer.

. [14] Yunbo Deng, et. al. ParAgent - A Software Reengineering Tool for Parallel Computing. Twelfth ZASTED International Conference on Parallel and Distributed Computing and Systems. Las Vegas, Nevada. November, 2000.

[2] H. Agrawal. On slicing programs with jump statements. In Proceedings of the ACM SIGPLAN '94 Conference on Programming Language Design and Implementation. Orlando, Florida. 1994.

[151 Michael D. Emst. Slicing pointers and procedures (ab-

[3] H. Agrawal. R. Demillo, and E. Spafford. Dynamic slicing in the presence of unconstrained pointers. In Proceeding of the ACM Fourth Symposium on Testing, Analysis, and Verijcation. 1991. pp. 60-73.

stracts). Microsoft Research technical report MSR-TR95-23, January 13,1995. [16] Daniel Jackson and Eugene I. Rollings. Abstraction mechanism for pictorial slicing. In IEEE Third International Workshop on Program Comprehension. pp. 8288. 1994.

[4] V. Aho, R. Sethi, and J. D. Ullman. Compilers Principles, Techniques and Tools. Addison Wesley Publishing Company, Reading, Massachusetts, 1998.

[171 W. Landi and B. Ryder. A safe approximate algorithm

[5] T. Ball. The Use of Control-Flow and Control Dependence in Software Tools. Ph.D. Thesis. University of Wisconsin-Madison. 1993.

for interprocedural pointer aliasing. In Proceedings of the 1992 ACM Conference on Programming Languages Design and implementation. San Francisco. 1992.

57

6.1 Appendix

[18] J. Lyle. Evaluating Variations on Program Slicing for Debugging. Ph.D. Thesis. University of Maryland. 1984.

*The layout of the code has been altered to fit the page.

[19] J. Lyle and M. Weiser. Automatic bug location by program slicing. In Proceedings of the Second International Conference on Computers and Applications. Beijing, China. pp. 877-883. 1987.

Al. Code of b l o c k "ORD 0 6" SSZT=SQRT(SZT(I, J,K, 1 ) **2+SZT (I,J,K,2 )

**2+SZT (I,J,K,3)**2) SSZT=AMAXl ( S S Z T , S S ) RSSZT=l.O/SSZT UK1 (J,K)=SZT (I,J,K, 1)*RSSZT UK2 (J,K)=SZT (I,J,K, 2) *RSSZT UK3 (J,K)=SZT (I,J, K, 3) *RSSZT

[20] J. May and E Berman. Retargetability and Extensibility in a Parallel Debugger. Journal of Parallel and Distributed Computing 35(2), 1996. [21] S . Mitra. A cIass based approach to pardlelization of legacy codes. Ph.D. Thesis, Iowa State University. 1997.

C

RX=X(I+l, J+l,K+l)-X(I+l, J,K+l) RY=Y(I+l, J+l,K+l)-Y (I+l,J,K+l) RZ=Z (I+l,J+l,K+l)-Z (I+l,J,K+1) UIX=RY*UK3 (J,K ) -RZ*UK2 (J,K) UIY=RZ*UKI (J,K) -RX*UK3 (J,K) UIZ=RX*UK2 (J,K) -RY*UKl (J,K) SUI=SQRT(UIX**2+UIY**2+UIZ**2) SUI=AMAXl (SUI,S S ) RSUI=l.O/SUI U11 (J,K) =UIX*RSUI U12 (J,K) =UIY*RSUI U13 (J,K)=UIZ*RSUI

[22] Jim A. Ning, Andre Engberts and Wojtek Kozaczynski. Automated support for legacy code understanding. Communications of the ACM. 37(5), pp.50-57. May 1994. [23] A. Nishimatsu and M. Jihira and S . Kusumoto and K. Inoue. Call Mark Slicing: An efficient and economical way to reducing slice. In Proceedings of the International Conference on Software Engineering. Los Angels, CA. 1999. [24] K. Ottenstein and L Ottenstein. The program dependence graph in a software development environment. In Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering Symposium on Practical Software Development Environments. 1984.

C UJ1 (J,K)=UK2 (J,K) *U13 (J,K) UK3 (J,K) *U12 (J,K) U J 2 ( J ,K ) = U K 3 ( J ,K ) *U11 ( J , K )

-

UK1 (J,K )

1251 T. Reps, and G. Rosay. Precise interprocedural chopping. In SIGSOFT '95: Proceedings of the Third ACM SIGSOFT Symposium on the Foundations of Software Engineering. Washington. DC. October 10-13, 1995.

*U13 (J,K) UJ3 (J,Kj =UK1 (J,K) *U12 (J,K) UK2 (J,K) *U11 (J,K)

[26] R Sosic and D.A. Abramson. Guard: a relative debugger. Software - Practice & Experience .Vol 27(2). pp. 185-206. February 1997.

A2.

Code o f block "DO 0 11"

DO 5 K=2,KLM KM=K-1 KP=K+1 DO 5 J=1,JLM

[27] Frank Tip. A survey of program slicing techniques. Journal of Programming Languages. Vol. 3, 1995. [28] Mark Weiser. Program slicing. IEEE Trans. On Sofware Engineering. SE-10(4), pp. 352-357. July, 1984.

C C RECONSTRUCT THE DATA AT THE CELL INTERFACE, C KAPA C UPl(J,K)=Ul(I,J,K,l)0.25*RP* ( (1.O+RK) * (U1 (I,J,K, 1)U1 (I,J,KM,1)) + (1.0-RK) * (U1(I,J,KP,l)-Ul(I, J,K,1)))

[29] M. Weiser and J. Lyle. Experiments on slicing-based debugging tools. In Proceedings of the 1st Conference on empirical Studies of Programming. pp. 187197.1986. [30] Wisconsin program slicing project.

.

58

UP2 (J,K)=U1(I,J,K,2)0.25*RP* ((l.O+RK) *(Ul(I,J,K,2)U1 (I,JrKM,2))+(1.0-RK) *(U1(I,J,KPr2)-Ul(I,J,K,2))) UP3 (J,K)=U1 ( I,J,K, 3 ) -0.25*RP * ( (1.0+RK)*(Ul(IrJ,K,3)U1 (1,JrKMr 3)) +(l.O-RK)*(Ul(I, J,KP,3)U1 (1,J,Kr 3 ) ) 1 UP4 (J,K)=U1 (I,J,K,4)0.25*RP* ((1.OtRK) *(UI(I,J,K,4)U1 (I,J,KM, 4)) + (1.0-RK) * (U1(I,J,KP,4)-U1 (I,Jr K, UP5 (J,K)=U1(I,J,K,5)0 - 25* RP * ( ( 1 .0tRK) * (U1(I,J,K, 5)U1 (I,J,KM, 5) ) + (1.0-RK) *(U1(I,J,KPr5)-U1(I,J,K,5))) UP6 (J,K)=U1 (I,J,K, 6)0.25*RP* ( (1 O+RK) *(Ul(I,J,K,G)U1 ( I,J,KM, 6) ) + ( 1 0-RK)

HM (J,K, 2 ) =U12 (J,K M ) *HMl+UJ2 (J,KM)*HM2 HM (J,K, 3)=U13 (J,KM) *HMl+UJ3 (J,KM) *HM2 HM (J,K, 4)=U11 (J,KM) *HM4+UJ1 (J,KM)*HM5 HM (JrK r 5)=U12 (J,KM)*HM4+UJ2 (J,KM)*HM5 HM (J,K, 6)=U13 (J,KM) *HM4+UJ3 (J,KM) *HM5

5 CONTINUE

A3. S t a t e m e n t 86. HP5= 0.5* (-C3*UCl+Cl*UC5)

.

.

*(Ul(I,J,KP,6)-Ul(I,J,K,6)))

C C COMPUTE THE CONTRAVARAIANT COMPONENTS C UC1=UI1 (J,KM) *UP1 (J,K) +U12 (J,KM) *UP2 (J,K) +U13 (J,KM) *UP3 (J,K) UC2=UJ1 (J,KM) *UP1 (J,K)+UJ2 (J,KM) *UP2 (J,K) tUJ3 (J,KM) *UP3 (J,K) UC4=UI1 (J,KM) *UP4 (J,K)+U12 (J,KM) *UP5 (J,K) +U13 (J,KM) *UP6 (J,K) UC5=UJ1 (J,KM) *UP4 (J,K) tUJ2 (J,KM) *UP5 (J,K) +UJ3(J,KM)*UP6(J,K) C

C SPLIT FLUXES IN LOCALLY ORTHOGONAL SYSTEM C HMl=-O.5* ( Cl*UCl+C2"UC5) HM2= 0.5*(-Cl*UC2+C2"UC4) HM4= 0.5*( C3*UC2-C1*UC4) HM5=-0.5" ( C3*UCl+Cl*UC5) c C TRANSFORM SPLIT FLUXES FROM LOCALLY ORTHOGO-NAL C TO (XI,ET,ZT) SPACE C INVERSE MATRIX IDENTICAL TO TRANSPOSE C HM (J,K, 1)=U11 (J,KM) *HMl+UJl (J,KM) *HM2

59