Improve the compilation of PROLOG to C (No. 5-1)-unfinished

Http://clip.dia.fi.upm.es/papers/morales03:p-to-c-ciclops.pdf

Improve the compilation of PROLOG to C-use type and deterministic details: Preliminary Results

J. moralesy *
Jfran@clip.dia.fi.upm.es

M. carroy *
Mcarro@fi.upm.es

M. hermenegildoy *#
Herme@fi.upm.es

Summary

We describe the current situation and provide the preliminary performance test results for the prolog to C compiler. The compiler is novel when it is designed to accept different types of high-level information (usually expressed in standardized deterministic languages through initial PROLOG program analysis ), and use this information to optimize the generated C code, and then further process the ready-made C compiler. In the basic translation process, the corresponding bytecode Of The PROLOG program is used to simulate a C-encoded bytecode simulator. Then optimize the application. This is the bytecode instruction and their lower-level component that promotes the more exile design. This method can reuse a considerable number of mechanical bytecode simulators: With C code, data definition, memory management routines and regions, etc, and the native compilation code of the mixed bytecode simulation and relatively simple method. We report program performance compiled by the current system version, with or without analysis information.

1. Introduction
Since the original interpreter developed by colmerauer and Roussel [col93], a number of technologies have been designed to implement Prolog, many of which aim to achieve higher speeds. 1. In [van94], you can find an excellent survey on the important part of this job. The following is a rough classification of PROLOG (in fact, it also applies to many other languages ):

× Translator (such as C-Prolog [per87] and others), lightweight preprocessing or translation may be completed before the program is executed, but a lot of work is done by the translation at runtime.

× Bytecode compilers and their translators (often called simulators ). The compiler uses a special-purpose language to produce relatively low-level code. This low-level code translator is still needed. Currently, most simulators are based on Warren abstraction machine (WAM) [war83, ak91], but other suggestions are available: [91, kb95].

× A low-level language compiler, usually (local) machine code. In this case, output execution requires little or no additional support. One solution is to generate machine code directly for the compiler. In this example, the Aquarius system [vd92], the sicsus Prolog version [swe99], some systems, the bim-Prolog Compiler [mar93] And the GNU Prolog Compiler [DC01]. Another method is to generate a (low-level) language, such as C-[jrr99] or C. One of the machine code compilers is readily available, the latter is the method [CD95] adopted by wamcc.

Each method has advantages and disadvantages:

Enforceability can be compared with the size and compilation speed of executable files:Compiling lower-level code can achieve faster programs, eliminate the overhead of interpretation and perform low-level optimization. In general, you can work as much as possible during compilation to avoid runtime overhead. Using more resources in the compilation phase results in faster execution speed, and may generate larger executable files. In general, the compiler is more complex and takes longer time to preprocess the program than the translator. As part of the compilation process, the complex forms of code analysis are becoming increasingly different. This may affect the development time, although complex analysis can be disabled during the development process and only provided when the code is generated. On the contrary, the translator may have lower load/compilation time. When the speed is not a priority, it is often a good solution because of its simplicity. The simulator is at the center of complexity and cost. Highly optimized Simulators
[Qui86, scdra00, dn00, swe99, bcc + 02] provides excellent performance and reduces program size (because single-byte commands correspond to multiple machine code commands) this may be a key issue for very large programs and symbolic datasets.

--------------------------------------------------------------------------------

Note: This work is partially supported by Spain's mcyt project tic 2002-0055 cubico, eu ist project 2001-42517amos and IST-2001-38059 ASAP, with support from Prince Asturias, University of New Mexico Information Technology College. The European Social Fund co-funding mcyt also supports J. Morales.

* Madrid University of Technology, boadilla Del Monte, E-28660
# Computer science, electronics, and Computer Engineering, University of New Mexico