Execution Of Prolog Programs Research Articles

Algebraic computational models of OR-parallel execution of Prolog

A specification of the OR-parallel execution of Prolog programs, using CHOCS (calculus of higher order communicating systems) [24], is presented in the paper. A translation is defined from Prolog programs and goals to CHOCS processes: the execution of the CHOCS process corresponding to a goal mimics the OR-parallel execution of the original Prolog goal. In the translation, clauses and predicate definitions of a Prolog program correspond to processes. To model OR-parallelism, the processes \(P^1, \cdots , P^n\), corresponding to clauses \(C_1, \cdots , C_n\) (having the same head predicate \(p\)) start their execution concurrently, but, in order to respect the depth-first search rule, each \(P^i\) is guarded by the termination of the executions of processes \(P^j\)'s, \(j < i\). The computational model is proved correct with respect to the semantics of Prolog, as given in [4, 5]. Our model, because of its algebraic specification, can be easily used to prove properties of the parallel execution of Prolog programs. Moreover, the model exploits the maximum degree of parallelism, by giving the Prolog solutions in parallel, without any order among them. However, this model, being close to the Prolog semantics definition, contains sources of inefficiency which make it unpractical as a guide for the implementation. To overcome these problems, a new computational model is defined. This model is obtained by modifications of the basic one and thus its correctness can be easily proved. Finally, we show how to obtain models of different real implementations of OR-parallel Prolog by slight modification of the new model. The relations among all these models, in terms of parallelism degree, are studied by using the concepts of bisimulation and simulation, developed for concurrent calculi.

An Abstract Approach to Some Loop Detection Problems

The abstract approach proposed here encompasses both the detection of some periodic loops during the execution of Prolog programs and the detection of some periodic loops during recursive computations (an attempt to look at the loop detection problem for Prolog from an abstract point of view has been done previously in a paper by the same author published in 1993).

Design and Simulation of the Aquarius-II Multiprocessor

Aquarius-II is a cache coherent multiprocessor system designed for the parallel execution of Prolog programs. It contains two tiers of memory: synchronization memory and high bandwidth (HB) memory. The synchronization memory consists of snooping caches connected to a bus and is used to store rendezvous points, synchronization bits, synchronization variables such as locks and semaphores and most of the write shared data. The HB memory is used to store the bulk of the application program code and data. It contains caches and an inexpensive VLSI chip based crossbar interconnection network to memory. The caches connected to the crossbar do not have full snooping capability. The architecture is evaluated by a full simulation of parallel execution of Prolog programs on Aquarius-II. The design details of the components of the architecture and simulation results are presented. Simulation results indicate that the two tier memory system significantly reduces memory interference and speeds up synchronization when compared to a single bus multi. This shared memory multiprocesor architecture has the potential to support other parallel programming paradigms.

On the detection of some periodic loops during the execution of Prolog programs

On the detection of some periodic loops during the execution of Prolog programs

Extending CLOS towards logic programming

Prolog, because of its weakness in describing structured objects, has always benefited from a mixing with an OO paradigm maybe more than other languages. Logic programming seems to be complementary with OO programming. This paper presents a proposal of an extension of CLOS towards logic programming. We show how it has been possible to introduce in CLOS a set of new mechanisms which allow the execution of Prolog programs. The paper outlines how the CLOS approach resulted in a very useful and powerful framework to increase flexibility, expressivity and elegance in Prolog design.

Prolog on a RISC: Implementation and evaluation

This paper discusses about the compilation of Prolog on a RISC processor. This is part of the Symbion project, which aims at designing the basic processing element for modular parallel symbolic machines. The compiler is based on a variant of the WAM. First, some results are presented with respect to the emulation of the abstract machine. Then, we comment on the code generation on a RISC processor (the MIPS), and give some results obtained from the execution of Prolog programs on a MIPS emulator. The performances obtained on a 20 MHz clocked MIPS are close to the performances of WAM-based Prolog machines.

The occur-check problem revisited

A method is presented for executing PROLOG programs which avoids almost all unnecessary occur-checks. The method is based on a dynamic classification of the context in which logical variables occur. No static global analysis of the PROLOG program is required to detect the places where an occur-check has to be made. The presented method has also an important side benefit. It considerably cuts down on the number of memory references during the execution of PROLOG programs. Furthermore, in most cases it avoids “trailing” and “untrailing” of unbound variables altogether. Due to this fact the employed method actually speeds up PROLOG execution. The method is discussed in terms of an actual implementation based on the Warren abstract PROLOG instruction set. However, the method should be applicable to other implementation models as well. No assumptions are made with respect to particular hardware.