No abstract

Loop combination has been a traditional optimization technique employed in APL compilers, but may introduce dependencies into the combined loop. We propose an analysis method by which the compiler can keep track of the change of the parallelism when combining high-level primitives. The analysis is necessary when the compiler needs to decide a trade-off between more parallelism and a further combination. We also show how the space usage, as well as the performance, improves by using system calls with the aid of garbage collection to implement a dynamic memory allocation. A modification of the memory management scheme can also increase available parallelism. Our experimental results indicate that the performance and the space usage improve appreciably with the above enhancements.

The testing of the APL-to-C compiler, COMPC, developed at the IBM T.J. Watson Research Center consists of two components: a testing suite of 140 APL programs collected from various sources covering a variety of fields, and a unit-testing procedure which tests each primitive function on all possible subcases arising from different combinations of storage types and shapes. The second component, unit-testing, is an interesting example of the productivity APL can provide for software development. The unit-testing procedure is based on a workspace written in APL, and utilizes the □ FX feature of APL to dynamically create a test function from one of several templates. The running of both testing components is automated through the use of control programs written in the REXX procedures language under the VM/CMS operating system.

APL-style programs use high level primitives on arrays instead of DO-loops whenever possible. For such programs, the average size of a basic blocks is much large than those in their FORTRAN counterparts. Hence, it is sufficiently profitable and relative easy to concentrate on basic blocks when parallelizing APL-style programs.But such an approach must depend on an APL compiler. The APL/3 70 compiler we have been developing aims at implementing automatic parallelization of APL programs at basic block level.The compiler exploits functional parallelism on data independent sub-expressions and data parallelism of array primitives on array elements. The compiler front end does a local data dependency analysis and emits synchronization flags at function nodes. The back end does partitioning of (assembly code) array loops. A set of low-level synchronization primitives on MVS has also been developed. This will enable us to run compiled applications in parallel mode on IBM 3090 multi-processors to access the effectiveness of various scheduling methods on a shared memory model.

We have implemented sparse matrix technology tools in A PL. Such tools have been conspicuously scarce, because APL has not been the language of choice for solving boundary value problems governed by partial differential equations. But when carefully coded, APL is able to tackle problems governed by partial differential equations in a way that ads flexibility and, on account of its compactness, maintainability. The main criticism of APL in numerically intensive applications has been execution speed. APL compilation addresses Lhis drawback and shows factors of speed improvement of better than about three. Timings will be presented for some benchmark elliptical boundary value problems, both for interpretive and compiled APL. Examples are given of common tasks that are encountered in conjunction with the finite element method, such as determination of the symbolic form of the stiffness matrix, and the more universal task of solution of a sparse (symmetric) set of equations using the conjugate gradient method.