Abstract. The implementation of abstract machines involves complex decisions regarding, e.g., data representation, opcodes, or instruction specialization levels, all of which affect the final performance of the emulator and the size of the bytecode programs in ways that are often difficult to foresee. Besides, studying alternatives by implementing abstract machine variants is a time-consuming and error-prone task because of the level of complexity and optimization of competitive implementations, which makes them generally difficult to understand, maintain, and modify. This also makes it hard to generate specific implementations for particular purposes. To ameliorate those problems, we propose a systematic approach to the automatic generation of implementations of abstract machines. Different parts of their definition (e.g., the instruction set or the internal data and bytecode representation) are kept separate and automatically assembled in the generation process. Alternative versions of the abstract machine are therefore easier to produce, and variants of their implementation can be created mechanically, with specific characteristics for a particular application if necessary. We illustrate the practicality of the approach by reporting on an implementation of a generator of production-quality WAMs which are specialized for executing a particular fixed (set of) program(s). The experimental results show that the approach is effective in reducing emulator size. 1

Almost all current Prolog systems are based on the Warren Abstract Machine (WAM), in which registers are used to pass procedure arguments and store temporary variables. In this paper, we present a stack machine for Prolog, named TOAM Jr., which departs from the TOAM adopted in early versions of B-Prolog in that it employs no registers for arguments or temporary variables, and offers variable-size instructions for encoding procedure calls. TOAM Jr. is suitable for fast bytecode interpretation: the use of coarse-grained instructions results in more compact code and execution of fewer instructions than the use of fine-grained instructions; and the omission of registers facilitates interpretation of tagged operands and instruction merging. TOAM Jr. has been employed in B-Prolog since Version 7.0. Benchmarking shows that TOAM Jr. significantly enhances the speed of B-Prolog.

One critical issue in the design of declarative languages is their memory performance, both in terms of total memory usage and locality in memory accesses. Early studies of Prolog programs have shown the language to have excellent characteristics in this regard. In this work we study the memory performance of two modern Prolog systems through detailed instruction-level simulation. Our work aims at addressing...

Progress in Prolog applications requires ever better performance and scalability from Prolog implementation technology. Most modern Prolog systems are emulator-based. Best performance thus requires both good emulator design and good memory performance. Indeed, Prolog applications can often spend hundreds of megabytes of data, but there is little work on understanding and quantifying the interactions between Prolog programs and the memory architecture of modern computers.

B-Prolog is a high-performance implementation of the standard Prolog language with several extensions including matching clauses, action rules for event handling, finite-domain constraint solving, arrays and hash tables, declarative loop constructs, and tabling. The B-Prolog system is based on the TOAM architecture which differs from the WAM mainly in that (1) arguments are passed old-fashionedly through the stack, (2) only one frame is used for each predicate call, and (3) instructions are provided for encoding matching trees. The most recent architecture, called TOAM Jr., departs further from the WAM in that it employs no registers for arguments or temporary variables, and provides variable-size instructions for encoding predicate calls. This paper gives an overview of the language features and a detailed description of the TOAM Jr. architecture, including architectural support for action rules and tabling.