This report surveys the major developments in sequential Prolog implementation during the period 1983--1993. In this decade, implementation technology has matured to such a degree that Prolog has left the university and become useful in industry. The survey is divided into four parts. The first part gives an overview of the important technical developments starting with the Warren Abstract Machine (WAM). The second part presents the history and the contributions of the major software and hardware systems. The third part charts the evolution of Prolog performance since Warren's DEC-10 compiler. The fourth part extrapolates current trends regarding the evolution of sequential logic languages, their implementation, and their role in the marketplace.

This dissertation presents the thesis that good and usable instruction sets can be automatically derived for a specified data path and benchmark set. This is achieved by a multistep process: generating execution traces for the benchmark programs, sampling these traces to form a large set of small code segments, optimally recompiling these segments using exhaustive search, and finding the cover of the new instructions generated that optimizes the performance metric. The complete process is illustrated by generating an instruction set for a processor optimized for executing compiled Prolog programs. The generated instruction set is compared with the hand-designed VLSI-BAM instruction set. The automatically designed instruction set is smaller and has only a few percent less performance on th...

Most Prolog machines have been based on specialized architectures. Our goal is to start with a general purpose architecture and determine a minimal set of extensions for high performance Prolog execution. We have developed both the architecture and optimizing compiler simultaneously, drawing on results of previous implementations. We find that most Prolog specific operations can be done satisfactorily in software; however, there is a crucial set of features that the architecture must support to achieve the best Prolog performance. The emphasis of this paper is on our architecture and instruction set. The costs and benefits of the special architectural features and instructions are analyzed. Simulated performance results are presented and indicate a peak compiled Prolog performance of 3.68 million logical inferences per second. 1 Introduction Logic programming in general and Prolog [22] in particular have become popular for rapid software prototyping, natural language translation, and ...

The execution of a compiled Prolog program can spend a significant amount of time in the unification of compound terms. We show that in the Warren Abstract Machine [7], the approach to compile this unification may be unnecessarily inefficient. When we analyse what are the redundant operations that the WAM executes, we can see that the inefficiency is mainly caused by the breadth-first approach to traverse the structures during the unification. We present here a method to compile the unification of compound terms which is based on a depth-first approach and show that it is both more general and more efficient than that of the original WAM. Furthermore we present a more efficient approach to compile compound terms in the body and also describe several possible optimizations. Our method was used in the implementation of the SEPIA system [4] developed at ECRC. III 1 Introduction The execution of Prolog programs consists mainly of procedure invocation and unification. The unification its...

Abstract. Functional logic languages amalgamate functional and logic programming paradigms. They can be efficiently implemented by extending techniques known from logic programming. Such implementations can be largely improved if information about the run-time behavior, in particular the modes of function calls, is available at compile time. In this paper we present a framework to derive such global information. The concrete operational semantics considered in this paper is normalizing innermost narrowing, which combines the deterministic reduction principle of functional languages with the nondeterministic search principle of logic languages. Due to the normalization process between narrowing steps, standard analysis frameworks for logic programming cannot be applied. Therefore we develop new techniques to correctly approximate the effect of the intermediate normalization process. 1 Introduction A lot of proposals have been made to amalgamate functional and logic programming languages (see [15] for a recent survey). Functional logic languages with a sound and complete operational semantics are based on narrowing (e.g., [9, 11, 25, 27]), a combination of the reduction principle of functional languages and the resolution principle of logic languages. Narrowing solves equations by finding appropriate values for variables occurring in goal equations. This is done by unifying an input term with the left-hand side of some rule and then replacing the instantiated input term by the instantiated right-hand side of the rule. Example 1. The following rules define the addition of two natural numbers which are represented by terms built from 0 and s:

. Functional logic languages amalgamate functional and logic programming paradigms. They can be efficiently implemented by extending techniques known from logic programming. In this paper we show how global information about the call modes of functions can be used to optimize the compilation of functional logic programs. Since mode information has been successfully used to improve the implementation of pure logic programs and these techniques can be applied to implementations of functional logic programs as well, we concentrate on optimizations which are unique to the operational semantics of functional logic programs. We define a suitable notion of modes for functional logic programs and present compile-time techniques to optimize the normalization process during the execution of functional logic programs. 1 Introduction In recent years, a lot of proposals have been made to amalgamate functional and logic programming languages [7, 17]. Functional logic languages with a so...

Machine (WAM) [36]. Their instruction sets were derived from the WAM to support execution of Prolog programs. These processors are special purpose, microcoded engines that depend on parallel execution of operations within each relatively coarsegrained instruction for high performance. Initial designs implemented only the instructions that supported the WAM and depended on a host processor for nonWAM computations. To support Prolog built-ins (primitive Prolog operations provided by the system) and system I/O, newer designs incorporate general purpose instructions to minimize dependence on a host. Alternatively, the use of a simple, non-WAM instruction set better supports compiler optimization. Several such special purpose reduced instruction set architectures have been proposed for logic programming [11, 18, 19, 24]. These architectures include primitives that support the use of tagged data, pointer dereference, and multi-waybranches. Our hypothesis is that providing support for both co...

Machine 18 4.1 Memory Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.1.1 WAM Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2 WAM Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2.1 Choice point Management Instructions . . . . . . . . . . . . . . . . . . . . . . 21 4.2.2 Environment Creation Instructions . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2.3 Unification Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.2.4 Unification Failure and Backtracking . . . . . . . . . . . . . . . . . . . . . . . 25 4.2.5 Clause Body Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.3 A Complete WAM Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.4 Basic WAM Optimizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.4.1 Environment Trimming . . . . . . . . . . . ...