Chain-Based Scheduling : Part I -LCB- Loop Transformations and Code Generation Peiyi Tang July 21 , 1992 Chain-Based Scheduling : Part I -LCB- Loop Transformations and Code Generation ? Peiyi Tang Department of Computer Science The Australian National University Canberra ACT 2601 Australia July 21 , 1992 Abstract Chain-based scheduling -LSB- 1 -RSB- is an efficient partitioning and scheduling scheme for nested loops on distributed-memory multicomputers . The idea is to take advantage of the regular data dependence structure of a nested loop to overlap and pipeline the communication and computation . Most partitioning and scheduling algorithms proposed for nested loops on multicomputers -LSB- 1,2,3 -RSB- are graph algorithms on the iteration space of the nested loop . The graph algorithms for partitioning and scheduling are too expensive -LRB- at least O -LRB- N -RRB- , where N is the total number of iterations -RRB- to be implemented in parallelizing compilers . Graph algorithms also need large data structures to store the result of the partitioning and scheduling . In this paper , we propose compiler loop transformations and the code generation to generate chain-based parallel codes for nested loops on multicomputers . The cost of the loop transformations is O -LRB- nd -RRB- , where n is the number of nesting loops and d is the number of data dependences . Both n and d are very small in real programs . The loop transformations and code generation for chain-based partitioning and scheduling enable parallelizing compilers to generate parallel codes which contain all partitioning and scheduling information that the parallel processors need at run time . ? This work is supported in part by the Australian Research Council under Grant No . S6600132 and by the donation of Fujitsu Laboratories LTD. . ii iii 1 Introduction The chain-based partitioning and scheduling -LSB- 1 -RSB- is an efficient scheme to execute nested loops with constant data dependences on distributed address space multicomputers . The idea is to take advantage of the regular data dependence structure to partition and schedule loop iterations in such a way that communication and computation can be overlapped and pipelined . Due to the large context switch overhead of operating systems , partitioning and scheduling at the loop iteration level of a program need to be managed by compilers . Like most other partitioning and scheduling algorithms proposed for nested loops on multicomputers -LSB- 2,3 -RSB- , the chain-based scheduling algorithm -LSB- 1 -RSB- is originally a graph algorithm on the iteration space of the nested loop . The cost of the graph-based algorithms is at least O -LRB- N -RRB- , where N is the total number of loop iterations . Note that the cost of the nested loop itself is also O -LRB- N -RRB- . In other words , the time for the compiler to run a graph-based partitioning and scheduling algorithm is at least as much as the sequential execution time of the nested loop itself . More importantly , graph-based partitioning and scheduling algorithms need a large data structure to store the result of the scheduling for each processor . The time cost of retrieving these large data structures from the disk at run time will be prohibitively high . The solution to the problems of graph-based partitioning and scheduling lies in compiler program transformations . In order to be practically useful in massively parallel systems , any partitioning and scheduling scheme has to be incorporated in program transformations . For nested loops , the most time-consuming parts of numerical scientific programs , the partitioning and scheduling as well as the communication primitives generation should be done through loop transformations . In this report , we present a series of loop transformations and code generation for chain-based partitioning and scheduling . A parallelizing compiler can use these transformations to generate SPMD -LRB- Single Program Multiple Data -RRB- style parallel programs , in which all the partitioning and scheduling information are incorporated . When the generated programs are executed by the parallel processors , the computation and the communication are overlapped and pipelined . In section 2 , the program model of nested loop with constant data dependences is introduced . Section 3 presents the program transformations for chain-based partitioning and scheduling . They include loop skewing , loop tiling , loop normalization and chain-based code generation . Section 4 concludes the paper with a brief discussion of performance of the generated chain-based parallel codes . 2 Nested Loops and Constant data dependences Nested loops consume most of the CPU time in scientific and engineering supercomputing . To speed up the execution of nested loops on massively parallel computers like Intel Touchstone Delta System and Fujitsu AP1000 , the computation needs to be parallelized , partitioned and scheduled to parallel processors . DO i1 = L1 , U1 ... DO in = Ln , Un B -LRB- i1 ; ? ? ? ; in -RRB- ENDDO ... ENDDO Figure 1 . Program model of uniform recurrence In this paper , we concentrate on a class of nested loops known as uniform recurrences . It covers many important classes of scientific computations including iterative methods for linear systems to solve partial differential equations . A uniform recurrence is a perfectly-nested loop with constant data dependences between the loop iterations . Figure 1 shows the program model of a uniform recurrence . Each loop bound , Lk or Uk , can be a linear function of the indices of the surrounding loops , i.e. Lk = ak ; 0 + ak ; 1i1 + ? ? ? + ak ; k ? 1ik ? 1 Uk = bk ; 0 + bk ; 1i1 + ? ? ? + bk ; k ? 1ik ? 1 The loop body of the nested loop , denoted as B -LRB- i1 ; ? ? ? ; in -RRB- in Figure 1 , is a sequence of assignments without if or exit statements . The nested loop in Figure 1 defines an iteration space I ae Zn : I = f -LRB- i1 ; ? ? ? ; in -RRB- 2 Zn : Lk < = ik < = Uk ; k = 1 ; ? ? ? ; ng A data dependence exists from iteration ~ i = -LRB- i1 ; ? ? ? ; in -RRB- and to iteration ~ i0 = -LRB- i01 ; ? ? ? ; i0n -RRB- if 1 . ~ i < > ~ i0 and ~ i executes before ~ i0 in the temporal order of the nested loop , and 2 . both iterations ~ i and ~ i0 access the same scalar or array element and at least one of the accesses is write , and 3 . there is no other iteration between ~ i and ~ i0 that writes to the same data element . If ~ i writes and ~ i0 reads the data element , the data dependence is true dependence , because it reflects a data flow between the two iterations . If ~ i reads and ~ i0 writes the data element , the data dependence is called anti dependence . If both ~ i and ~ i0 writes the data element , it is called output dependence . Anti and output dependences are caused by reuse of memory do i1 = ; 4 do i2 = ; 4 a -LRB- i1 ; i2 -RRB- = f1 -LRB- c -LRB- i1 ; i2 ? 1 -RRB- ; b -LRB- i1 ; i2 -RRB- -RRB- ; b -LRB- i1 ; i2 -RRB- = f2 -LRB- a -LRB- i1 ? 1 ; i2 + 1 -RRB- ; c -LRB- i1 ; i2 -RRB- -RRB- ; c -LRB- i1 ; i2 -RRB- = f3 -LRB- b -LRB- i1 ? 1 ; i2 -RRB- ; a -LRB- i1 ; i2 -RRB- -RRB- ; enddo ; enddo ; -LRB- a -RRB- Program i1 i2 2 4 2 4 -LRB- b -RRB- Iteration space Figure 2 . An Example of Nested Loop storage and , therefore , are not essential . They can be eliminated by scalar renaming and scalar or array expansion . For this reason , we consider only flow data dependences in this paper , assuming that all the anti and output data dependences in original programs , if any , have been eliminated by renaming and expansion . If there is a data dependence from ~ i to ~ i0 , vector ~ d = ~ i0 ? ~ i is called distance vector of the dependence . A distance vector is always lexicographically positive , i.e. , the first nonzero element is positive and not all elements are zeros due to the fact that ~ i0 is later than ~ i . The dependence is constant if the distance of the dependence is independent of the source , i.e. , it exists between every pair of ~ i ; ~ i0 2 I such that ~ i + ~ d = ~ i0 . A uniform recurrence is a perfectly nested loop whose data dependences are all constant . Figure 2 shows an example of a uniform recurrence and its iteration space with data dependences . There are three constant data dependences with distance vectors ~ d1 = -LRB- 1 ; ? 1 -RRB- , ~ d2 = -LRB- 1 ; 0 -RRB- and ~ d3 = -LRB- 0 ; 1 -RRB- associated with arrays a , b and c , respectively , all of which are flow dependences . The data dependences of a uniform recurrence can be represented by the set of distance vectors , D = f ~ d1 ; ? ? ? ; ~ dmg . If the rank of D , r , is less than n , the number of loops in the nested loop , we can transform the nested loop to a new nested loop of n loops in which the n?r outermost loops are DOALL loops -LSB- 4 -RSB- . A DOALL loop is a parallel loop without data dependences across its iterations . Outer DOALL loops can be efficiently executed on multicomputers without interprocessor communication -LSB- 5 -RSB- . If the rank of D is equal to n , the outmost loop can not be transformed to a DOALL loop . In this paper , we concentrate on this kind of nested loops . Using the hyperplan method -LSB- 4,6,7 -RSB- , such a nested loop can be transformed to a nested loop with n loops in which the outmost loop is a sequential loop and all the inner n ? 1 loops are all DOALL loops . However , the overhead of the fork-join synchronization for the outmost sequential loop could be very large . In this paper , a different parallelization approach is used . We use interprocessor communication to enforce the data dependences if the related iterations are allocated to difference processors . A parallel loop with dependences between iterations enforced by synchronization -LRB- as in shared address space multiprocessors -RRB- or communication -LRB- as in Algorithm 1 -LRB- Skewing Matrix -RRB- inputs : D : set of dependence vectors ; outputs : E : set of dependence vectors ; T : unimodular matrix ; T = identity matrix ; for i = 2 to n do A = identity matrix ; for each ~ d 2 D do if Pi ? 1 j = 1 aijdj + di < then let k be the smallest in f1 ; ? ? ? ; i ? 1g such that dk > 0 ; aik = max -LRB- aik ; d -LRB- ? di ? Pi ? 1 j = k +1 aijdj -RRB- = dke -RRB- ; endif ; endfor ; for each ~ d 2 D do di = Pij = 1 aijdj ; endfor ; T = AT ; endfor ; return -LRB- D , T -RRB- ; distributed address space multicomputers -RRB- is called DOACROSS loop . The chain-based partitioning and scheduling spread iterations of DOACROSS loops across parallel processors and use communication to enforce data dependences between the loop iterations . 3 Program Transformations for Chain-Based Scheduling In this section , we present program transformations to generate chain-based parallel programs for nested loops on multicomputers . The transformations are : -LRB- 1 -RRB- loop skewing , -LRB- 2 -RRB- loop tiling , -LRB- 3 -RRB- loop normalization and -LRB- 4 -RRB- chain-based partitioning and scheduling . 3.1 Loop Skewing The purpose of the loop skewing , as the first step of the series of transformations , is twofold : 1 . to facilitate the transformation for loop tiling ; 2 . to guarantee deadlock-free execution of tiles . The time to pass a message of n data -LRB- integer or floating-point number -RRB- from one processor to another in a multicomputer can be expressed as Tn = W + no -LRB- 1 -RRB- where W is the startup delay of the message and o is the data transfer rate . In current multicomputers , W is usually two orders of magnitude longer than o . It would be extremely inefficient to send messages with a single datum . Therefore , the computation of iterations of the nested loop need to be grouped so that the data to be passed between processors can be aggregated to form larger messages . Each group is called a tile and it usually is a set of neighbouring iterations in the iteration space . The computation of a tile is atomic with respect to message passing . In other words , the processor receives all the data it needs before it starts the computation of the tile . It does not sends data to other processors until the computation of the tile is finished . Irigoin and Triolet suggested to use hyperplanes to tile the iteration space -LSB- 7 -RSB- . Given an iteration space I ae Zn , a set of hyperplane families H = f -LRB- ~ h1 ; s1 -RRB- ; ? ? ? ; -LRB- ~ hn ; sn -RRB- g can be used to partition the iteration space into tiles . In particular , each -LRB- ~ hk ; sk -RRB- 2 H is a familay of parallel hyperplanes with the norm ~ hk and sk is the distance between them . A tile is the set of iterations between the parallel hyperplanes defined by H , i.e. a tile with index -LRB- q1 ; ? ? ? ; qn -RRB- is f ~ i 2 I : b ~ hk ? ~ i sk c = qk ; k = 1 ; ? ? ? ; ng Since tiles are atomic with respect to message passings , deadlocks are possible -LSB- 7 -RSB- . To prevent deadlocks , the following condition is sufficient : 8i 2 f1 ; ? ? ? ; ng ; 8j 2 f1 ; ? ? ? ; mg : ~ hi ? ~ dj > = Tiling with hyperplanes with arbitrary norms is too general to be used by a parallelizing compiler to generate simple and efficient parallel codes . After loop skewing transformation , we can use orthogonal hyperplane families to tile the transformed iteration space to rectangular tiles . Compilers can generate simple and deadlock-fee parallel codes for the rectangular tiles as will be seen shortly DO j1 = jmin 1 , jmax 1 ... DO jn = Gn , Hn B0 -LRB- j1 ; ? ? ? ; jn -RRB- ENDDO ... ENDDO Figure 3 . Nested loop after skewing Loop skewing is a loop transformation originally used to improve vectorization -LSB- 8 -RSB- . Loop skewing and other two loop transformation , loop interchange and loop reversing , have been recently unified into a single loop transformation called unimodular transformation -LSB- 4,9 -RSB- . An n ? n integer matrix T is unimodular if its determinant is ? 1 , i.e. j det -LRB- T -RRB- j = 1 . A unimodular matrix T transforms each index vector ~ i 2 I to an index vector in a new iteration space J = f ~ j 2 Zn : 9 ~ i 2 I such that T ~ i = ~ jg1 . Under a unimodular transformation , the new iteration space J is the set of index vectors ~ j = -LRB- j1 ; ? ? ? ; jn -RRB- confined in a convex hull determined by the new loop bounds . The methods of calculating these new loop bounds can be found in -LSB- 4,10 -RSB- . Since j det -LRB- T -RRB- j = 1 and the inverse of T is still an integer matrix . Therefore , for each ~ j within the loop bounds , there is an ~ i 2 I such that ~ i = T ? 1 ~ j . In other words , there is a one-to-one mapping between the two iteration spaces and there is no \ holes '' in iteration space J . The unimodular matrix T also transforms each dependence distance vector ~ d 2 D to a new distance vector T ~ d . A unimodular transformation T is legal if and only if for all ~ d 2 D , T ~ d is lexicographically positive . Under a legal unimodular unimodular transformation , all of the data dependences will be satisfied when the iterations in iteration space J are traversed in the lexicographic order . In this paper , loop skewing is used to transform a nested loop to be fully-permutable . A nested loop is fully-permutable if all elements of every dependence vector are nonnegative . Given a nested loop with the arbitrary data dependences represented by D , we want to find a unimodular matrix T such that each element of -LRB- e1 ; ? ? ? ; en -RRB- = ~ e = T ~ d for all ~ d 2 D is non-negative . Algorithm 1 shows the algorithm to construct such unimodular matrix T . In Algorithm 1 , T is constructed as a product of sequence of n ? 1 unimodular matrices Aj -LRB- i = n ; ? ? ? ; 2 -RRB- , T = AnAn ? 1 ? ? ? A2 . Define Ti -LRB- 2 < = j < = n -RRB- as AiTi ? 1 and T1 is the identity matrix . It can be seen from Algorithm 1 that , for all ~ d 2 D , the first 1Here , both ~ i and ~ j are column vectors . In this paper , we use comma-separated tuples to denote both column and row vectors and their usage can be figured out from the context of the formulae . do j1 = ; 4 do j2 = j1 ; j1 + 4 a -LRB- j1 ; j2 ? j1 -RRB- = f1 -LRB- c -LRB- j1 ; j2 ? j1 ? 1 -RRB- ; b -LRB- j1 ; j2 ? j1 -RRB- -RRB- ; b -LRB- j1 ; j2 ? j1 -RRB- = f2 -LRB- a -LRB- j1 ? 1 ; j2 ? j1 + 1 -RRB- ; c -LRB- j1 ; j2 ? j1 -RRB- -RRB- ; c -LRB- j1 ; j2 ? j1 -RRB- = f3 -LRB- b -LRB- j1 ? 1 ; j2 ? j1 -RRB- ; a -LRB- j1 ; j2 ? j1 -RRB- -RRB- ; enddo ; enddo ; -LRB- a -RRB- Program 2 6 8 4 4 j2 2 j1 -LRB- b -RRB- Skewed iteration space Figure 4 . The example after loop skewing i elements of Ti ~ d are non-negative . Tn gives the matrix T required . In Algorithm 1 , the elements on the diagonal of the matrix Ai are all 1 . All the other elements are 0 , except the first i ? 1 elements of the i-th row , aij ; 1 < = j < = i ? 1 . Assume that the first i ? 1 elements of each ~ di ? 1 = Ti ? 1 ~ d : ~ d 2 D are non-negative , after the -LRB- i ? 1 -RRB- - th iteration . In iteration i , the elements , aij ; 1 < = j < = i ? 1 , of Ai are determined to make Pi ? 1 j = 1 aijdi ? 1 j + di ? 1 i > = for every ~ di ? 1 = Ti ? 1 ~ d : ~ d 2 D. Note that aik ; 1 < = k < = i ? 1 never decrease and all di ? 1 1 ; ? ? ? ; di ? 1 i ? 1 are non-negative . It is clear that when ~ di ? 1 = Ti ? 1 ~ d are processed one at a time in the inner loop of the algorithm , the work done for previous vectors can never be undone . Since The first element of every ~ d1 = T1 ~ d = ~ d : ~ d 2 D is always non-negative , the above inductive reasoning leads to the correctness of the algorithm . Once the skewing matrix T is obtained , the nested loop in Figure 1 can be transformed to the nested loop shown in Figure 3 . The transformation consists of two parts : 1 . transformation of the loop body ; 2 . transformation of the loop bounds ; The transformation of the loop body is simple . Since ~ i = T ? 1 ~ j , replacing each ik , k = 1 ; ? ? ? ; n with the corresponding expression of j1 ; ? ? ? ; jn in the loop body produces the now loop body B0 -LRB- j1 ; ? ? ? ; jn -RRB- . The new loop bounds can be obtained by the method described in -LSB- 4 -RSB- . The low and upper bounds of the first loop is the minimum and maximum possible values of j1 , jmin 1 and jmax 1 , respectively . The loop bounds of the other loops are DO k1 = jmin 1 ; jmax 1 ; s1 ... DO kn = jmin n ; jmax n ; sn DO j1 = k1 ; min -LRB- k1 + s1 ? 1 ; jmax 1 -RRB- ... DO jn = max -LRB- kn ; G1n ; G2n ; ? ? ? -RRB- , min -LRB- kn + sn ? 1 ; H1n ; H2n ; ? ? ? -RRB- B0 -LRB- j1 ; ? ? ? ; jn -RRB- ENDDO ... ENDDO ENDDO ... ENDDO Figure 5 . Nested loop after tiling DO k1 = ; d -LRB- jmax 1 ? jmin 1 + 1 -RRB- = s1e ? 1 ... DO kn = ; d -LRB- jmax n ? jmin n + 1 -RRB- = sne ? 1 DO j1 = jmin 1 + k1s1 , min -LRB- jmin 1 + k1s1 + s1 ? 1 ; jmax 1 -RRB- ... DO jn = max -LRB- jmin n + knsn ; G1n ; G2n ; ? ? ? -RRB- , min -LRB- jmin n + knsn + sn ? 1 ; H1n ; H2n ; ? ? ? -RRB- B0 -LRB- j1 ; ? ? ? ; jn -RRB- ENDDO ... ENDDO ENDDO ... ENDDO Figure 6 . Nested loop after normalization of the form -LRB- k = 2 ; ? ? ? ; n -RRB- : Gk = max -LRB- G1k ; G2k ; ? ? ? -RRB- Hk = max -LRB- H1k ; H2k ; ? ? ? -RRB- where each Gpk or Hpk is a linear functions of the outer loop index variables , j1 ; ? ? ? ; jk ? 1 as follows : Gpk = d -LRB- gpk ; 0 + Pk ? 1 i = 1 gpk ; iji -RRB- = gpk ; ke Hpk = b -LRB- hpk ; 0 + Pk ? 1 i = 1 hpk ; iji -RRB- = hpk ; kc The unimodular matrix for skewing the nested loop in Figure 2 is T = '' 1 1 1 # The dependence vectors become ~ e1 = -LRB- 1 ; 0 -RRB- , ~ e2 = -LRB- 1 ; 1 -RRB- and ~ e1 = -LRB- 0 ; 1 -RRB- . The skewed nested loop and its iteration space with data dependences are shown in Figure 4 . 3.2 Loop Tiling Let E the set of transformed dependence vectors , E = fT ~ d : ~ d 2 Dg and we have ~ e > = 2 for all ~ e 2 E . Now we can tile iteration space J with the set of orthogonal hyperplane families : H = f -LRB- ~ h1 ; s1 -RRB- ; ? ? ? ; -LRB- ~ hn ; sn -RRB- g 2 ~ e > = if each element of ~ e is greater than or equal to 0 . do k1 = ; 2 do k2 = ; 4 do j1 = 2k1 ; min -LRB- 2k1 + 1 ; 4 -RRB- do j2 = max -LRB- 2k2 ; j1 -RRB- ; min -LRB- 2k2 + 1 ; j1 + 4 -RRB- a -LRB- j1 ; j2 ? j1 -RRB- = f1 -LRB- c -LRB- j1 ; j2 ? j1 ? 1 -RRB- ; b -LRB- j1 ; j2 ? j1 -RRB- -RRB- ; b -LRB- j1 ; j2 ? j1 -RRB- = f2 -LRB- a -LRB- j1 ? 1 ; j2 ? j1 + 1 -RRB- ; c -LRB- j1 ; j2 ? j1 -RRB- -RRB- ; c -LRB- j1 ; j2 ? j1 -RRB- = f3 -LRB- b -LRB- j1 ? 1 ; j2 ? j1 -RRB- ; a -LRB- j1 ; j2 ? j1 -RRB- -RRB- ; enddo ; enddo ; enddo ; enddo ; -LRB- a -RRB- Program j1 j2 2 6 8 4 k1 = 1 k2 = 2 k1 = 0 k1 = 2 k2 = 0 k2 = 1 k2 = 3 k2 = 4 2 4 -LRB- b -RRB- Tiled iteration space Figure 7 . The example after tiling and normalization where ~ h1 = -LRB- 1 ; ; ? ? ? ; 0 -RRB- ~ h2 = -LRB- 0 ; 1 ; ? ? ? ; 0 -RRB- ... ~ hn = -LRB- 0 ; ; ? ? ? ; 1 -RRB- and ~ s = -LRB- s1 ; ? ? ? ; sn -RRB- is called size vector of tiling . For every ~ e = -LRB- e1 ; ? ? ? ; en -RRB- 2 E , ~ hk ? ~ e = ek > = 0 , k = 1 ; ? ? ? ; n. Therefore , the tiling is legal and deadlock-free . The loop transformation of the orthogonal tiling above is straightforward . We only need to introduce n additional loops to control the execution of the tiles as shown in Figure 5 . These new k-loops for tiles are called controlling loops . The execution of iterations within a tile is still controlled by the j-loops . In Figure 5 , the lower and upper bounds of look kl , -LRB- l = 1 ; ? ? ? ; n -RRB- are jmin l and jmax l , the minimum and the maximum possible values of jl in iteration space J , respectively . The method to determine the lower and upper bounds of controlling k-loops as well as inner j-loops can be found in -LSB- 4 -RSB- . To facilitate the chain-based partitioning and scheduling , the controlling k-loops need to be normalized -LSB- 11 -RSB- . The normalized controlling loops are shown in Figure 6 . Notice that normalizing the controlling loops does not affect the loop body B0 -LRB- j1 ; ? ? ? ; jn -RRB- , because the index variables of the controlling loops are only used in the loop bounds of the inner j-loops . After tiling and normalization , the nested loop of the example and its tile space are do k1 = pid ; 2 ; 2 do k2 = ; 4 receive message from PE -LRB- pid ? 1mod2 -RRB- ; do j1 = 2k1 ; min -LRB- 2k1 + 1 ; 4 -RRB- do j2 = max -LRB- 2k2 ; j1 -RRB- ; min -LRB- 2k2 + 1 ; j1 + 4 -RRB- a -LRB- j1 ; j2 ? j1 -RRB- = f1 -LRB- c -LRB- j1 ; j2 ? j1 ? 1 -RRB- ; b -LRB- j1 ; j2 ? j1 -RRB- -RRB- ; b -LRB- j1 ; j2 ? j1 -RRB- = f2 -LRB- a -LRB- j1 ? 1 ; j2 ? j1 + 1 -RRB- ; c -LRB- j1 ; j2 ? j1 -RRB- -RRB- ; c -LRB- j1 ; j2 ? j1 -RRB- = f3 -LRB- b -LRB- j1 ? 1 ; j2 ? j1 -RRB- ; a -LRB- j1 ; j2 ? j1 -RRB- -RRB- ; enddo ; enddo ; send message to PE -LRB- pid +1 mod2 -RRB- ; enddo ; enddo ; -LRB- a -RRB- Chain-based parallel code j1 j2 2 6 8 4 k1 = 1 k2 = 2 k1 = 0 k2 = 0 k2 = 1 k2 = 3 k2 = 4 2 4 PE0 PE1 k1 = 2 PE0 -LRB- b -RRB- Communication between chains Figure 8 . Chain-based Scheduling of the Example shown in Figure 7 . Note that some tiles are incomplete or empty . The loop bounds of the inner j-loops will guarantee that only the relevant iterations will be executed -LSB- 4 -RSB- . 3.3 Chain-Based Partitioning and Scheduling After loop skewing and loop tiling and normalization of the controlling loops , we can form chains of tiles and schedule them to the parallel processors . Let us use the transformed nested loop in Figure 7 to illustrate the idea of chain-based partitioning and scheduling first . Suppose that there are p = 2 processors , PE0 and PE1 , in the multicomputer system . To execute the tiles shown in Figure 7 -LRB- b -RRB- , we can allocate all the tiles with k1 = to PE0 and all the tiles with k1 = 1 to PE1 . After PE0 finishes the tiles with k1 = 0 , it can proceed to execute all the tiles with k1 = 2 . The tiles with the same k1 index form a chain . A chain is a sequence of tiles connected by data dependences . The partitioning and scheduling of the example are shown in Figure 8 . Figure 8 -LRB- a -RRB- shows the code for PEpid . The processor identity is denoted by pid . In this example , pid 2 f0 ; 1g . After a processor finishes the computation of a tile , it packs a message and sends it to the next processor . It receives a message from the previous processor before the computation of the tile starts . The thick arrows on Figure 8 -LRB- b -RRB- represent the messages passed between processors . The rationale of chain-based partitioning and scheduling is as follows : ffl Allocating all the tiles of a chain to the same processor can save the message-passing for data dependences between the tiles . For example , the data dependences from the tile -LRB- k1 ; k2 -RRB- = -LRB- 0 ; 0 -RRB- to the tile -LRB- k1 ; k2 -RRB- = -LRB- 0 ; 1 -RRB- can be satisfied by executing the former first and using the local memory for data passing . ffl Due to the regular dependence structure of the computation , the interprocessor communication between chains can be aligned with each other and overlapped with the computation of chains in a pipeline fashion . ffl The code generation for such partitioning and scheduling is simple as shown in Figure 8 -LRB- a -RRB- . In this example , we use the inner controlling loop to form chains and spread the iterations of the outer controlling loop across the parallel processors . That is , the outer controlling loop is executed as a DOACROSS loop . In general , partitioning and scheduling tiles is a mapping M from tile space K to processor space P , i.e. , M : K ! P . A multicomputer has a network with fixed topology such as hypercube or mesh to connect processors . However , we can use an appropriate logical structure for processor space P for partitioning and scheduling and then embed the logical processor space into the physical parallel processors of the system . For a tile space with n controlling loops , we need at least one innermost loop to form chains . Assume that we are going to use q > = 1 inner controlling loops to form chains . This means that we are going to allocate all iterations of the q inner controlling loops to a single processor . The n?q outer controlling loops are DOACROSS loops and represent a -LRB- n ? q -RRB- - dimensional chain space , C , which contains all the chains . The data dependences between chains are regular and can be satisfied by communication between processors . The best way to pipeline the communication and computation among the processors is to fully interleave chains across the processors . Therefore , the logical processor space we need is a -LRB- n ? q -RRB- - dimensional mesh defined as follows : P = f -LRB- p1 ; ? ? ? ; pn?q -RRB- : < = qk < = Pk ? 1 ; k = 1 ; ? ? ? ; n ? qg where Pk is the size of the processor space in the k ? th dimension and P1 ? ? ? Pn?q is the total number processors used for the computation . Here we assume that the -LRB- n ? q -RRB- - dimensional mesh can be embedded into the physical topology of the network of the system . The chain-based partitioning now can be represented by the following function M : K ! P : M -LRB- k1 ; ? ? ? ; kn?q ; ? ? ? ; kn -RRB- = -LRB- k1 mod P1 ; ? ? ? ; kn?q mod Pn?q -RRB- According to the above partitioning function , the chain with k1 = w1 ; ? ? ? ; kn?q = wn?q will be executed by the processor -LRB- w1 mod P1 ; ? ? ? ; wn?q mod Pn?q -RRB- . In other words , the set of chains allocated to processor -LRB- p1 ; ? ? ? ; pn?q -RRB- is f -LRB- k1 ; ? ? ? ; kn?q -RRB- 2 C : kl ? pl -LRB- mod Pl -RRB- ; l = 1 ; ? ? ? ; n ? qg The processor will execute these chains in the increasing lexicographic order of DO k1 = p1 ; d -LRB- jmax 1 ? jmin 1 + 1 -RRB- = s1e ? 1 ; P1 ... DO kn?q = pn?q ; d -LRB- jmax n?q ? jmin n?q + 1 -RRB- = sn?qe ? 1 ; Pn?q DO kn?q +1 = ; d -LRB- jmax n?q +1 ? jmin n?q +1 + 1 -RRB- = sn?q +1 e ? 1 ... DO kn = ; d -LRB- jmax n ? jmin n + 1 -RRB- = sne ? 1 Receive and Unpack messages ; DO j1 = jmin 1 + k1s1 , min -LRB- jmin 1 + k1s1 + s1 ? 1 ; jmax 1 -RRB- ... DO jn = max -LRB- jmin n + knsn ; G1n ; G2n ; ? ? ? -RRB- , min -LRB- jmin n + knsn + sn ? 1 ; H1n ; H2n ; ? ? ? -RRB- B0 -LRB- j1 ; ? ? ? ; jn -RRB- ENDDO ... ENDDO Pack and Send messages ; ENDDO ... ENDDO ENDDO ... ENDDO Figure 9 . SPMD chain-based parallel code -LRB- k1 ; ? ? ? ; kn?q -RRB- . Therefore , the SPMD code for processor -LRB- p1 ; ? ? ? ; pn?q -RRB- is a program shown in Figure 9 . It is obvious that the program contains all the partitioning and scheduling information that each processor needs at run time . 4 Concluding Remarks We have presented a series of loops transformations to generate chain-based parallel programs for nested loops on multicomputers . They are loop skewing , loop tiling and normalization , and chain-based partitioning and scheduling . We are currently implementing these transformations in our prototype parallelizing compiler for Fujitsu AP1000 . We have been concentrating on the loop transformations for chain-based partitioning and scheduling . The code generation for message packing and unpacking in the chainbased codes will be discussed elsewhere . There are a number of factors that will affect the performance of the generated chainbased parallel codes : Size of tiles . The size of tiles determines the granularity of the parallel computation . The tile size should be such that the execution time of a tile should be roughly equal to the communication time of a message passing between processors . The balance between the computation and communication will hide the communication latency and offer good pipelining for the whole parallel execution . Regularity of chain length . Since the tile space is trapezoid instead of rectangular due to the possible loop skewing , chosing different controlling loops to form chains will affect the pipelining effect of interprocessor communication . In fact , all the n controlling loops are interchangeable and we can move any of them inwards to form chains . The question is how many and what loops should be moved inwards and used to form chains to achieve the best performance . Processor space . We need to decide the number of processors needed and the shape of the logical processor space to give the best performance . This problem is directly related to the size of tiles and the shape of the chain space . The thorough discussions of these issues go beyond the scope of this paper and we will address them in the next report : \ Chain-Based Scheduling : Part II -LCB- Granularity and Performance '' . References -LSB- 1 -RSB- P. Tang and G. Michael , \ Chain-Based Partitioning and Scheduling of Nested Loops for Multicomputers , '' Proceedings of the 1991 International Conference on Parallel Processing , vol . II , pp . 243 -LCB- 246 , August 1991 . -LSB- 2 -RSB- C. - T. King , W. - H. Chou and L. M. Ni , \ Pipelined Data-Parallel Algorithms : Part II -LCB- Design , '' IEEE Transactions on Parallel and Distributed Systems , vol . 1 , no. 4 , pp. 486 -LCB- 499 , October 1990 . -LSB- 3 -RSB- J-P . Sheu and T-H . Tai , \ Partitioning and Mapping Nested Loops on Multiprocessor Systems , '' IEEE Transactions on Parallel and Distributed Systems , vol . 2 , no. 4 , pp. 430 -LCB- 439 , October 1991 . -LSB- 4 -RSB- M. E. Wolf and M. S. Lam , \ A Loop Transformation Theory and an Algorithm to Maximize Parallelism , '' IEEE Transactions on Parallel and Distributed Systems , vol . 2 , no. 4 , pp. 452 -LCB- 471 , October 1991 . -LSB- 5 -RSB- G. Michael and P. Tang , \ Parallel Loop Code Generation for AP1000 , '' in Proceedings of the Second Fujitsu-ANU CAP Workshop , Canberra Australia , November 1991 , pp . D. 1 -LCB- D. 11 . -LSB- 6 -RSB- L. Lamport , \ The Parallel Execution of DO Loops , '' Communications of the ACM , vol . 17 , no. 2 , pp. 83 -LCB- 93 , February 1974 . -LSB- 7 -RSB- F. Irigoin and R. Triolet , \ Supernode Partitioning , '' in Conference Record of the Fifteenth Annual ACM Symposium on Principles of Programming Languages , San Diego , CA , January 1988 , pp. 319 -LCB- 329 . -LSB- 8 -RSB- M. Wolfe , \ Loop Skewing : the Wavefront Method Revisited , '' Kuck and Associate , Inc. , , 1987 . -LSB- 9 -RSB- U. Banerjee , \ Unimodular Transformations of Double Loops , '' in Advances in Languages and Compilers for Parallel Processing : Proceedings of the Third -LRB- 1990 -RRB- Workshop on Languages and Compilers for Parallel Computing , A. Nicolau , D. Gelernter , T. Gross and D. Padua , Eds . London , UK : Pitman , pp. 192 -LCB- 219 , 1991 . -LSB- 10 -RSB- K. G. Kumar , D. Kulkarni and A. Basu , \ Generalized Unimodular Loop Transformations for Distributed Memory Multiprocessors , '' Center for Development of Advanced Computing , FG-TR-014 , January 1991 . -LSB- 11 -RSB- H. Zima and B. Chapman , Supercompilers for Parallel and Vector Computers . Addison-Wesley Publishing Company , 1991 .

O B O O O O B I O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O B O B O O B I O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O B I O B O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O B I O O O O O O O O O O B I O B O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O B O B O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O B I O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O B O B O O O B I O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O B I O O O O O O O O O O O B O B O O O O O O O O O O O B I O O O O O O O O O O B I O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O B I O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B I O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O B I O B O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O B I O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B O B O B I O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O

loop transformations
multicomputers
nested loops
partitioning
scheduling


Semi-automatic Update of Applications in Response to Library Changes Kingsum Chow and David Notkin Department of Computer Science & Engineering University of Washington Box 352350 Seattle , WA 98195-2350 , USA -LCB- kingsum , notkin -RCB- @cs . washington.edu Technical Report UW-CSE 96-03-01 Abstract Software libraries provide leverage in large part because they are used by many applications . As Parnas , Lampson and others have noted , stable interfaces to libraries isolate the application from changes in the libraries . That is , as long as there is no change in a library?s syntax or semantics , applications can use updated libraries simply by importing and linking the new version . However , libraries are indeed changed from time to time and the tedious work of adapting the application source to the library interface changes becomes a burden to multitudes of programmers . This paper introduces an approach and a toolset intended to reduce these costs . Specifically , in our approach a library maintainer annotates changed functions with rules that are used to generate tools that will update the applications that use the updated libraries . Thus , in exchange for a small added amount of work by the library maintainers , costs to each application maintainer can be reduced . We present the basic approach , describe the tools that support the approach , and discuss the strengths and limitations of the approach . 1 Introduction Libraries provide leverage in large part because they are used by many applications . As Parnas -LSB- Parnas 1972 & 1979 -RSB- , Lampson -LSB- Lampson 1984 -RSB- , and others have noted , stable interfaces to libraries isolate the application from changes in the libraries . That is , as long as there is no change in a library?s syntax or semantics , applications can use updated libraries simply by importing and linking the new version . In principle , this is a great idea . However , David Ungar recently summarized the practical problems of this approach : Ungar cautioned that ? the notion of interface is much more of an illusion than people give it credit for . The problem is that nobody really knows how to formally write down the definition of an interface in a way that can be checked and will guarantee the thing will really work when used by different clients ... You try to get all your design decisions to hide behind interfaces so that changes percolate through as few levels as possible . But every honest programmer will admit there are times when you have to change your mind , and the interface changes . ? The problem of how to manage such changes has not been solved , particularly if components are in use across a number of organizations or if the components have been modified or built upon in any significant way -LSB- Pancake 1995 , p. 35 -RSB- There are many application maintainers -- since there are many applications -- and -LRB- logically -RRB- only one library maintainer -- since there is only one library . We require the library maintainer to annotate any changes they make to indicate what changes must be made to update the applications to accommodate the updated library . We then provide a set of tools that use these annotations to semi-automatically update any applications that use the updated library . The idea is that the small additional work by the -LRB- one -RRB- library maintainer can provide leverage to the many application maintainers . This is illustrated in Figure 1 . In this paper , we address this approach to reducing some of the costs of updating applications when a library upon which the applications depend changes in unstable ways : that is , the syntax and/or the semantics of the library change . Section 2 describes an example , taken from a programming support library for Borland C++ , that illustrates the general problem . Section 3 describes our approach to reducing costs , which consists of two parts : a set of rules that describe the changes from the earlier version of the library to the later version ; and a set of tools that apply these rules to applications to update them to properly use the updated library . The tools either make proper updates or else identify where they can not decided how to handle the library?s changes . Section 4 discusses the status of our approach , including its strengths and weaknesses . Section 5 places the work in the greater context of software maintenance , software restructuring , etc. . Section 6 discusses other benefits of our approach . Section 7 summarizes our work and suggests future research areas . 2 An example of an interface change To clarify why handling changes to libraries is hard for applications , we?ll use a simple example taken from a commercial library -LSB- Borland 1993a -RSB- .1 The example illustrates some interface changes involving overloaded functions and default arguments . Although the example is simple , Section 4.1 describes a much broader set of changes that can be handled by our approach and tools ; limitations on the kinds of changes that can be handled are addressed in Section 4.2 1 . The example is modified slightly to use the C language syntax to simplify the presentation . Figure 1 . Overview of our approach Old Source Library Source New library with New Source LIBRARY EACH APPLICATION Library Maintainer A set of tools interface changes The example addresses the assign function , which is used to copy values from one string to another . The original library function was : assign -LRB- char * , char * , int = NPOS -RRB- ; The first parameter is the target string , the second is the source string , and the third parameter gives the number of characters to copy . The default of NPOS for the third parameter means that the full source string will be copied . Later , the library maintainers decided to change the function to : assign -LRB- char * , char * , int = 0 , int = NPOS -RRB- ; In the new version , the first two parameters remain unchanged . However , the old third parameter -LRB- the number of characters to copy -RRB- becomes the fourth parameter , and a new third parameter is introduced . This new parameter indicates the position in the source string from which copying should start . For example , for the new version of the library : char * s1 = ? abcdef ? ; char s2 -LSB- 7 -RSB- ; ... assign -LRB- s2 , s1 , 2 , 3 -RRB- ; After executing this code , s2 should contain ? cde ? . -LRB- Remember , in C strings are arrays of characters and indexing takes place from the zeroth character . -RRB- We are going to look at a few scenarios of what can happen to an application maintainer whose application is already using the old version of the assign function in the library . In the first scenario , throughout the application all calls to the original assign function use only the first two parameters : char * s1 = ... char * s2 = ... assign -LRB- s2 , s1 -RRB- ; In this case , the code in the application does not need to be changed in response to the changes to the library . In the second scenario , the application contains some calls to assign that use three parameters . If the application maintainer imports the new library without making any changes to the application , the code will still compile : char * s1 = ... char * s2 = ... int i = ... assign -LRB- s2 , s1 , i -RRB- ; However , this time , the interpretation of i has changed from the number of characters to copy to the starting position to copy . The behavior of this piece of code is changed due to a change in the interface of the assign function in the library . This is hardly ever what the application maintainer wants . In the third scenario , the application has the same kinds of calls to assign as in the second scenario , but the application maintainer is now aware of the library change . In this case , the maintainer just needs to insert a third argument of 0 to the caller . This will make the application code behave the same as before . char * s1 = ... char * s2 = ... int i = ... ... assign -LRB- s2 , s1 , 0 , i -RRB- ; These scenarios identify several problems . First , if the application maintainer is unaware of the changes to the library -LRB- perhaps because they didn?t read the provided documentation carefully -RRB- , their application will almost surely stop working properly . Second , every application maintainer has to decide whether the changes will affect the application and , if so , update the potentially large number of call sites by hand . This example only considers one function in what might be a large library . Increases in the number of functions in the library that change may significantly increase the number of call sites that the application maintainer may have to update . Third , many applications will have some call sites that require changes and others that do not ; handling selective changes like this may increase the difficulty of the application maintainers ? job in handing library updates . This simple example is characteristic of many other kinds of changes that take place when libraries are modified . -LRB- See Section 4.1 for a description of other classes of changes we have identified as common . -RRB- Effective solutions to this problem should have two characteristics . 1 . They should relieve the application maintainers , as much as possible , from having to identify whether or not the changes to the library require changes to the application . 2 . They should , as much as possible , relieve the application maintainers from having to identify and manually update each of the locations in the application that must change in response to library changes . Reducing the number of locations that must be updated manually will necessarily reduce the number of additional errors introduced during maintenance -LSB- Collofello & Buck 1987 -RSB- . The next section sketches the basic approach we take , which is intended to satisfy these properties . It also provides technical details about the languages and tools we use to help automate such changes . 3 The design of our approach One approach taken to similar problems is , roughly , to change the application automatically when the library is updated -LSB- Griswold & Notkin 1993 -RSB- -LSB- Opdyke 1992 -RSB- . This approach requires that the full source code for the library and application be available at one time and on one computer , so that the needed changes can be propagated from the library to the application . But this approach does not transfer to situations in which the library and the applications are not on the same computer , since the changes can not be propagated directly . Our approach instead generates tools based on the library modifications , and distributes those tools along with the updated libraries . When an application maintainer decides to import the updated library , the supplied tools can also be run to update the application . To allow tools to be generated , the library maintainer is required to provide , in addition to the actual library updates , a description of how affected sites in the application must be updated to properly use the updated library . Figure 2 shows a more detailed view of our approach , which we describe below . Our approach requires a library maintainer to specify interface changes and how existing application code can be transformed to adapt to those changes . These are specified in the interface files -LRB- e.g. ? . h ? files for C/C + + or ? . spc ? files for Ada -LSB- USDoD 1980 -RSB- -RRB- that are distributed as part of a library . The specification of the library interface changes as well as the specification for the transformation are then extracted by a process on the application maintainers ? side . This process first checks for file dependencies on the interface changes and then adds the library change specification to a standard grammar specification file and a standard transformation specification file for the implementation language . These files are then used to build a parser and a syntax tree transformer . The parser constructs a syntax tree for the application program and then performs token level code transformation . The syntax tree transformer performs syntax tree transformation as stated in the transformation specification . A new application program , which has been adapted to the new library , is emitted at the end . The stages of our approach are summarized in the data Figure 2 . Overview of our design Old Source AST Library Source Change Rep Changed AST New Source LIBRARY APPLICATION Change Propagation Tool AST Extraction Tool Source Generation Tool Library Maintainer AUTOMATION Figure 3 . The data flow diagram for our design grammar spec transform spec interface files with changes grammar spec adapted to changes transform spec adapted to changes application source files file dependency extractor standard standard list of interface files Makefile CFLAGS partial file dependency change spec . change spec . extractor original grammar original transform spec grammar change transform change new grammar new transform spec Parser Tree syntax tree constructor syntax tree transformer grammar modifier transform spec modifier program source syntax tree new program source changed application source files Builder Transformer Builder flow diagram in Figure 3 . -LRB- We do not address every part of the figure in this paper , due to space restrictions . -RRB- In Figure 3 , a library maintainer revises a library with some interface changes . In addition to recording the change in the interface , the library maintainer writes a transformation rule that describes how to adapt the application code to work properly in the face of the interface change . When the application maintainer decides to import the updated library , its original source is extracted by a tool to construct some internal representation , e.g. a syntax tree . The internal representation is then modified by a change propagation tool into another internal representation , from which a new source code is generated . Although the change specification is released as part of the library code , the application maintainers still have the final decision as to update their source code or not . This is usually done by adding an extra target in the Makefile . An example of this target is given in Figure 4 . As we will describe in Section 5 , this is similar to work in program restructuring , except that the temporal and geographical distance between the library and application maintainers introduces significant technical problems , e.g. change specification , representation and propagation . 3.1 The language for describing library changes The library maintainer needs to specify the adaptation code for the interface change . Something like the following would be sufficient for the example presented earlier : ASE_BIN = / homes/gws/kingsum / thesis/ase/bin GRAMMAR_FILE = $ -LRB- ASE_PATH -RRB- / grammar.g TRANSFORM_FILE = $ -LRB- ASE_PATH -RRB- / transformer.sor update : $ -LRB- SRC -RRB- $ -LRB- ASE_BIN -RRB- / upgrade_source $ -LRB- GRAMMAR_FILE -RRB- \ $ -LRB- TRANSFORM_FILE -RRB- CFLAGS = $ -LRB- CFLAGS -RRB- SRC = $ -LRB- SRC -RRB- Figure 4 . A Makefile example showing the new update target . if there is any code that uses the function assign -LRB- -RRB- , check the number of parameters , if it is 2 , don?t do anything . If it is 3 , insert a third argument of 0 to the caller . In our current prototype , the actual change specification in the ? . h ? file would be specified in the following way -LRB- Figure 5 -RRB- . The details of the change specification language are not important here ,1 but the basics are clear . A function name is defined -LRB- FNAME , in this case -RRB- , which describes the function that the library maintainer has modified . The PATTERN describes a syntactic structure to be matched against any function invocation that matches the FNAME . In this case , it is basically matching those invocations of assign that have exactly three arguments -LRB- as determined by matching two commas -RRB- . If and only if that PATTERN matches , the tool applies the ACTION code . In this case , the action inserts the added 0 , as described above . In the case of a typed language , it may also be important to check the types of the arguments in additional to the number of arguments . In this case , a stricter condition can be added : if the first argument is ? char * ? and the second is ? int ? . An example is shown in Figure 6 . In this example , a guard command specifies the semantic condition that must be true before a transformation takes place . 1 . As we show in the next section , the specific syntax is motivated by the language processing system that we used to implement our toolset . Details of the specification are found elsewhere -LSB- Chow 1996 -RSB- . / * * _ ASE_BEGIN _ * FNAME = assign * PATTERN = # -LRB- fc : FCALL_assign id : ID lp : L_PAREN arg1 : gen_expr co1 : COMMA arg2 : gen_expr co2 : COMMA arg3 : gen_expr rp : R_PAREN -RRB- * ACTION = #gen_logical_expr = # -LRB- #fc , #id , #lp , #arg1 , #co , #arg2 , #co , 0 , #co2 , #arg3 , #rp -RRB- ; * _ ASE_END _ * / Figure 5 . A change specification example showing the addition of a third argument . Sometimes , the change may even depend on the actual value of an argument . Our matching language is rich enough to capture these and other kinds of patterns . However , since our approach is based on lexical , syntactic and semantic analysis , we can only detect values that can be determined at compile time . Test programs that use the old library interface can also be used to test the interface change specification that is produced . This allows the library maintainer to gain confidence about the interface changes by simply using existing test programs . 3.2 The implementation of our semi-automatic tool For our current prototype implementation , we use the readily available language processing tools , the Purdue Compiler Construction Tool Set -LRB- PCCTS -RRB- -LSB- Parr 1995 -RSB- and Sorcerer -LSB- Parr 1994 -RSB- , text processing tools such as perl -LSB- Wall & Schwartz 1990 -RSB- , and a collection of our C++ -LSB- Stroustrup 1991 -RSB- programs that work with PCCTS and Sorcerer . The file dependency extractor , the change specification extractor , the grammar modifier , and the syntax tree transformation specification modifier are all implemented in perl . Perl scripts are very convenient here because are very portable and versatile . The change specification is written in patterns that are similar to PCCTS/Sorcerer so that little conversion needs to be made for them to be used by the other tools in our approach . In particular , Sorcerer supports tree-to-tree transformations , and the language we use to describe needed application updates is taken almost directly from Sorcerer . / * * _ ASE_BEGIN _ * FNAME = foo * PATTERN = # -LRB- fc : FCALL_foo id : ID lp : L_PAREN arg1 : gen_expr co1 : COMMA arg2 : gen_expr rp : R_PAREN -RRB- * GUARD = -LRB- arg1 - > Same -LRB- Ptr -LRB- charType -RRB- -RRB- & & arg2 - > Same -LRB- intType -RRB- -RRB- * ACTION = #gen_logical_expr = # -LRB- #fc , #id , #lp , #arg1 , #co , #arg2 , #co , 0 , #co2 , #arg3 , #rp -RRB- ; * _ ASE_END _ * / Figure 6 . A change specification example showing the semantic checking . The source syntax tree constructor is implemented using PCCTS and a set of C++ programs that coordinate with the base PCCTS system to perform semantic checking such as scope analysis and type checking . PCCTS is similar to a more popular tool set , lex -LSB- Lesk & Schmidt 1975 -RSB- and yacc -LSB- Johnson 1975 -RSB- but we are using PCCTS for the following reasons : 1 . PCCTS generates C++ code , 2 . PCCTS coordinates very well with Sorcerer , a tree parser transformer , and 3 . PCCTS provides nice error messages . A comparison between PCCTS and lex/yacc is beyond the scope of this paper , however . The syntax tree transformer is implemented with the help of Sorcerer and some added C++ programs to help with activities such as unparsing . Changes at the token level are conveniently done during using PCCTS but changes that depend on a sequence of tokens , i.e. , tree patterns , are better done using Sorcerer . 4 The status of our approach In our approach , we provide a mechanism for the library maintainer to pass interface change specification and adaptation rules to the application maintainers . The mechanism that we employ does not have any restriction on actual kinds of the changes . It instead depends on the grammar of the programming language and the change specification using that grammar . To demonstrate our approach , we wrote a grammar for the C language with two interesting extensions : function overloading and default arguments . We added these two extensions to handle richer , more useful , sets of interface changes . We then wrote interface change specifications based on this grammar . 4.1 Current status of our implementation Our current prototype system can handle a number of common interface changes such as changing the names of include files , variables and functions and changing the order of parameters . Table 1 summarizes the various classes of changes that can be handled using our approach . A more detailed study of patterns of interface changes can be found in -LSB- Chow 1996 -RSB- . In our prototype system , the library maintainer needs to provide a standard release of the language grammar and transformation grammar . Of course , the interface specification changes must also be provided in the include files . The application maintainers only need to add a new target , say update , in the Makefile -LRB- see Figure 4 -RRB- . The new target simply runs our tool to preprocess the source files . This way , the library clients just need to type make update to apply our tool to all the source files . After that , the library maintainers may examine the changes made or proposed by the tool and proceed to making their projects if no change in their source code is required or if they are satisfied with the changes that are made to their source . Our prototype system will not alter any white space or indentation unless a piece of code is changed . This will make the look and feel of the program the same as before and thus a. Complex cases involving overloading are designed but not yet implemented . Table 1 Classes of supported changes Kind of Change Current status add and remove include files or change their names . implemented add , remove or rename function names . implemented move a function from an include file to another . designed , not implemented add , remove and reorder function parameters . implemented change default arguments to non default . implemented change the return type of a function . implemented change the type of a function parameter . implemented for common casesa change the meaning of an in-coming function parameter . implemented remove , add , rename and change a struct field . implemented remove , add , rename and change a global variable . implemented the application maintainers only need to focus on changes , if any , that adapt to the new interface . The action description determines how modified code appears in the updated application . 4.2 Limitations Our approach is based on interface changes that are stored in the interface specification files . There are , however , some classes of library updates that our current implementation can not handle . For example , we can not not handle changes that are dependent on two places of the source code . For example , if foo -LRB- -RRB- does something that bar -LRB- -RRB- doesn?t need to be called , then when we see bar -LRB- -RRB- in the source code , we can not tell if foo -LRB- -RRB- is already in used . A change dependency on multiple locations of the source code is not easy to handle but fortunately , this does not happen too often at all . When this happens , a conservative approach is to alert the application maintainers whenever one of the two functions is used and let the application maintainers decide what to do . A specific example of this problem occurs when a change is made to an output parameter of a function . In this case , the declaration of the variable into which the output parameter will be written generally has to be changed , too . But we can not yet handle these two coordinated but physically separate changes . This specific case is more promising than the general case , since we could apply knowledge about type-casting or the library maintainer could provide additional type conversion routines to aid in the application update . In addition , there are a number of language specific features that our implementation has not been able to handled . The common problem among these language features is aliasing . For example , the alias of a variable to another variable when change is based on or a function pointer that may point to any real functions and some of which may have some change specification . Also , the introduction of inheritance class hierarchy and virtual member functions make some C++ changes hard to handle . These are interesting issues in future work . However , even in these cases , the application maintainers are still no worse than , if not better than before . Because of the employment of various tool for change propagation and transformation , a small amount of disk space -LRB- ~ 10 MB -RRB- may need to be reserved by each library client for upgrading their source . However , the same tool can be used for source code upgrade of other software applications using other languages and interfaces , with the other grammar and transformation specifications . 5 Related work One of the activities that is often done before making semantic changes to a program is to restructure it first . Restructuring is often necessary due to the natural degradation of software structure -LSB- Lehman 80 -RSB- after a series of modification . The restructuring approach -LSB- Griswold & Notkin 93 -RSB- focuses on the tedious task of maintaining the meaning of a program while its structure is being altered by the maintainer . There are two major differences between this approach and our work however . First , the entire program is presumably visible and changeable by the restructuring tool while parts of the program are either not visible or not changeable in my proposal . Second , some structural changes in the restructuring approach need not be dealt with by our change adaptation tool because they do not result in interface changes . In fact , there are a number of researchers -LSB- Johnson & Opdyke 1993 -RSB- , -LSB- Casais 1992 -RSB- , -LSB- Bergstein 1991 -RSB- and -LSB- Lieberherr & Xiao 1993 -RSB- working along the same line as -LSB- Griswold & Notkin 1993 -RSB- i.e. , maintaining changes in various different ways , not merely interface changes , within a program . However , in this kind of closed system , it is indeed required that all source code is accessible and modifiable . Typically , the programmer and the maintainer are the same person in a closed system . In the industry , however , some sort of a script is sometimes provided for people that deal with interface changes , e.g. Borland?s ObjectWindows Library converter -LSB- Borland 1993b -RSB- and Microsoft?s migrate -LSB- Microsoft 1994 -RSB- . In general , they are based on lexical analysis and they also make more assumptions about the source and thus make themselves very restrictive and will work only in a narrow domain . In fact , these transformation scripts can be generated by a more general mechanism such as our implementation . 6 Discussion 6.1 Engineering decisions In our actual implementation , both the syntax tree constructor and the syntax tree transformer can be used to change the program . This flexibility allows us to experiment with various ways to do program transformation . For example , we can use the syntax tree constructor to mark certain tree nodes -LRB- derived from tokens -RRB- to make the identification of a tree pattern easier in the later stage . However , in this case , there will be an added overhead of the regeneration of the parser in each transformation . A balance between these two concerns will be studied in detail in the future . 6.2 Other potential uses Our approach is not only useful for library interface changes , it can also be used whenever the detection of usage needs to be done at the client site and suggestions or corrections will be made at that time . Thus , naturally , it can be used to adapt a program to use a competitor?s library interface to make the conversion of programs easier to use a newer and perhaps more efficient library . 6.3 On keeping old interfaces Some organizations advocate the maintenance of all interfaces . They may introduce new interfaces that are more general but they will never throw away old interfaces . However , the cost of keeping the old interface , which may be discouraged , is the size of the ? . h ? files which at a minimal is definitely distraction to new users , and it also subjects them to misuse of the old interface . Keeping the old interface also means keeping bigger object code for the old interface and new interface together . This results in longer link time . Also it is more likely to have link time conflicts with other libraries . Even in the case that old interfaces are kept , and more generic interfaces are introduced , our prototype system can still be used to give warnings to the client users when the use of the old interface is detected . In some sense our model is similar to Eiffel -LSB- Meyer 1992 -RSB- . The Eiffel keyword ? obsolete ? can be used to indicate something is obsolete . However , the Eiffel language itself does not support transformation of client code based on this keyword . 7 Summary In our prototype system , the library maintainer needs to pay the one time cost of providing the grammar and the transformation specification . And then for each interface change , the change specification must be provided . In this way , the major cost of upgrading source code for library interface changes are shifted from the burden of thousands if not millions of application maintainers to the library maintainers . In fact , this is the biggest strength of our approach and implementation , to make the thousands of application maintainers happier when the library interface is indeed changed . Another added advantage of this requirement for the library maintainers to specify the changes is to force them to think seriously before making interface changes . Our implementation assumes the existence of interface files that contain the interface specification . This realistic assumption allows us to build a prototype toolset to demonstration our idea nicely and practically . Also , by using comments , rather than new language features , to introduce library change specifications , we can more easily adapt our approach elsewhere . When a library interface is indeed changed , the library users need to be notified of those changes . The changes and suggested way to adapt the source code to those changes are usually written in a human language as part of a printed document , the README file associated with the new library or e-mail announcements . However , it is not clear whether this kind of information can actually reach the clients . Furthermore , it is not clear if the clients are always very keen to read README files , not to mention that some README files are not easily understandable by most library users . Even if they do , the updating activity is still manual in addition to the requirement that the clients need to understand the sometimes highly cryptic suggestions in some README files . In addition , README files sometimes do not tell the whole truth . Indeed , the README file itself can be out of date , because there is no other formal process to verify the content of the README files . The principle of the semi-automatic update of application in response to library changes is to enable the library maintainers to propagate necessary interface changes to the users ? code . The small extra work done by the library maintainers is a very small price to pay for the thousands or millions of library users . In this paper , we tackle the real life problem of unstable library interfaces directly . We identify the requirements to reduce the cost of updating source code that is affected by interface changes . We propose the model of our approach and give a reasonable implementation that works with real life examples . Within the area of library interface changes , we have done a study on the pattern of library changes -LSB- Chow 1996 -RSB- to gain confidence in the usefulness of our tool . Future work will be required to evaluate the effectiveness of our model and implementation . For example , some of the process may not require a complete syntax parsing of the program . Light weight lexical approaches -LSB- Murphy & Notkin 1995 -RSB- can be applied when appropriate , for example . Also , the syntax of the change specification may need to be more friendly and versatile . As discussed earlier , future work should also include handling certain language features that make automatic change propagation difficult . A classification of these problems and general guidelines to library maintainers in terms of writing change specification would be useful . In summary , we regard adapting source code to library interface changes as one of the biggest activity in asynchronous software evolution -LSB- Chow 1995 -RSB- . In future , we will look at other areas of asynchronous software evolution -LSB- Chow & Notkin 1996 -RSB- . References -LSB- Bergstein 1991 -RSB- Paul L. Bergstein , ? Object-preserving Class Transformations ? Proceedings of OOPSLA ' 91 , pp. 299-313 -LRB- 1991 -RRB- . -LSB- Borland 1993a -RSB- Borland?s README file for release 4.0 . -LSB- Borland 1993b -RSB- Borland ObjectWindows for C++ Programmer ? s Guide 2.0 . 1993 . -LSB- Casais 1992 -RSB- Eduardo Casais , ? An Incremental Class Reorganization Approach ? Proceedings of ECOOP ' 92 , pp. 114-132 -LRB- June 1992 -RRB- . -LSB- Chow 1995 -RSB- Kingsum Chow , ? Program Transformation for Asynchronous Software Maintenance ? , Proceedings of ICSE-17 Workshop on Program Transformation for Software Evolution , William Griswold , editor , The 17th International Conference on Software Engineering , April 24-28 , 1995 , Seattle , Washington , USA . Also published as Technical Report Number CS95-418 , Computer Science and Engineering , University of California , San Diego . -LSB- Chow 1996 -RSB- Kingsum Chow , Ph.D. dissertation in preparation , Department of Computer Science and Engineering , University of Washington , Seattle , Washington , USA -LRB- 1996 -RRB- . -LSB- Chow & Notkin 1986 -RSB- Kingsum Chow and David Notkin , ? Asynchronous Software Evolution ? AsiaPacific Workshop on Software Engineering Research , March 21 , 1996 , Hong Kong . -LSB- Collofello & Buck 1987 -RSB- Collofello , J. S. , and Buck , J. J , ? Software quality assurance for maintenance ? IEEE Computer . -LRB- Sept. 1987 -RRB- , 46-51 . -LSB- Griswold & Notkin 1993 -RSB- William G. Griswold and David Notkin , ? Automated Assistance for Program Restructuring ? ACM Transactions on Software Engineering and Methodology . 2 -LRB- 3 -RRB- pp. 228-269 -LRB- July 1993 -RRB- . -LSB- Johnson 1975 -RSB- S. C. Johnson , ? Yacc - Yet Another Compiler-Compiler ? Computer Science Technical Report 32 , AT&T Bell Labs , Murray Hill , NJ , USA -LRB- 1975 -RRB- . -LSB- Johnson & Opdyke 1993 -RSB- Ralph E. Johnson and William F. Opdyke . ? Refactoring and Aggregation ? Proceedings of the First JSSST International Symposium on Object Technologies for Advanced Software , S. Nishio and A. Yonezawa -LRB- editors -RRB- , pp. 264-278 -LRB- November 1993 -RRB- . -LSB- Lampson 1984 -RSB- Butler W. Lampson , ? Hints for Computer System Design ? IEEE Software pp. 11-28 -LRB- January 1984 -RRB- . -LSB- Lehman 1980 -RSB- M. M. Lehman , ? On understanding laws , evolution and conservation in the large-program life cycle ? J. Syst . Softw . 1 , 3 -LRB- 1980 -RRB- . -LSB- Lesk & Schmidt 1975 -RSB- M. E. Lesk and E. Schmidt , ? Lex - A Lexical Analyser Generator ? Computer Science Technical Report 39 , AT&T Bell Labs , Murray Hill , NJ , USA -LRB- 1975 -RRB- . -LSB- Lieberherr & Xiao 1993 -RSB- Karl J. Lieberherr and Cun Xiao , ? Object-oriented Software Evolution ? IEEE Transactions on Software Engineering 19 , 4 pp. 313-343 -LRB- April 1993 -RRB- . -LSB- Meyer 1992 -RSB- Meyer , Bertrand . Eiffel : the language . Prentice Hall -LRB- 1992 -RRB- . -LSB- Microsoft 1994 -RSB- MFC Migration Guide . 1994 . -LSB- Microsoft 1994 -RSB- Microsoft Foundation Classes 3.0 : C++ Application Framework for Microsoft Windows -LRB- Technical White Paper -RRB- , July 1994 . -LSB- Murphy & Notkin 1995 -RSB- Gail C. Murphy and David Notkin , ? Lightweight Source Model Extraction ? In Proceedings of the Third ACM Symposium on the Foundations of Software Engineering -LRB- FSE ? 95 -RRB- . -LSB- Opdyke 1992 -RSB- William F. Opdyke , ? Refactoring Object-Oriented Frameworks ? Ph.D. . Thesis . University of Illinois at Urbana-Champaign -LRB- 1992 -RRB- . -LSB- Pancake 1995 -RSB- Cherri M. Pancake , ? The Promise and the Cost of Object Technology : A Five-Year Forecast ? Communications of the ACM 38 , 10 pp . 33-49 -LRB- October 1995 -RRB- . -LSB- Parnas 1972 -RSB- D. L. Parnas , ? On the Criteria To Be Used in Decomposing System into Modules ? Communications of the ACM pp. 1053-1058 -LRB- December 1972 -RRB- . -LSB- Parnas 1979 -RSB- David L. Parnas , ? Designing Software for Ease of Extension and Contraction ? IEEE Transactions on Software Engineering . 5 -LRB- 2 -RRB- pp. 128-138 -LRB- March 1979 -RRB- . -LSB- Parr 1994 -RSB- Terence J. Parr , ? An Overview of SORCERER : A Simple Tree-Parser Generator ? International Conference on Compiler Construction -LRB- April 1994 -RRB- . -LSB- Parr 1995 -RSB- Terence J. Parr , Language Translation Using PCCTS and C++ -LRB- A Reference Guide -RRB- . -LSB- Stroustrup 1991 -RSB- Bjarne Stroustrup , ? The C++ Programming Language ? 2/ed . Addison-Wesley Publishing Company . -LRB- 1991 -RRB- . -LSB- USDoD 1980 -RSB- United States Department of Defense , ? Ada Programming Language ? MIL-STD-1815 . -LSB- Wall & Schwartz 1990 -RSB- Larry Wall and Randal L. Schwartz . Programming perl . O?Reilly & Associates -LRB- 1990 -RRB- .

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O

asynchronous software evolution
asynchronous software maintenance
program restructuring
software evolution
software libraries
software maintenance