Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!mcsun!unido!ecrcvax!micha From: micha@ecrcvax.UUCP (Micha Meier) Newsgroups: comp.lang.prolog Subject: Re: logic programs -> procedural lang? Message-ID: <780@ecrcvax.UUCP> Date: 27 Sep 89 10:25:52 GMT References: <27335@shemp.CS.UCLA.EDU> Reply-To: {pyramid,mcvax!unido}!ecrcvax!micha (Micha Meier) Organization: ECRC, Munich 81, West Germany Lines: 46 In article <27335@shemp.CS.UCLA.EDU> arman@oahu.cs.ucla.edu (Arman Bostani) writes: > >I am looking references to any work done in the area of "compiling" >logic programming languages (i.e. Prolog, CLP(R), etc.) into a >procedural/deterministic language such as C. There is an article "A Piggy-back Compiler For Prolog" by J.L.Weiner and S.Ramakrishnan in SIGPLAN'88 about a Prolog compiler that compiles into C. The authors claim that they got reasonable performance and portability. Since I've done similar work with ECRC-Prolog, I can say that a Prolog compiler that generates C is extremely user-unfriendly and can never achieve the speed of a good WAM emulator without serious portability flaws. There has been another note about a Prolog compiler into C, Proteus Prolog from MCC, where a very high speed was obtained with some slight modifications in the C compiler. Our experience with generating C was interesting in that it showed us that it is not the way to go, although it has some advantages. Shortly, the main problems vere space and time :-). The compiler either generates huge amounts of C code (if every WAM instruction is expanded) or it uses some sort of threaded code or subroutine calls which both need some code in assembler or modifications in the C compiler if they have to be efficient. This actually loses the portability leaving no other major advantage. Compilation time was the other main problem; if the compiler is written in Prolog, it is slow enough, but it is still nothing compared to the speed of the C compilation. The point is that there is much unnecessary work done in the C compiler, because the Prolog compiler generates only a very small subset of C, the same holds for the assembly code generated by the C compiler. The 'normal' approach, i.e. Prolog compiler generating abstract WAM code and possibly a native code back-end generator achieve much better (orders of magnitude) compilation speed. For example, with our current system, SEPIA, we can compile programs about 1000 times faster than with ECRC-Prolog and the speed of the generated code is better in SEPIA. If the aim is just to compile a Prolog program into an equivalent (and readable) C program, it is a different matter which, I think, can be theoretically achieved. The main task is to implement the backtracking which can be done in the Poplog way, or using continuations in the WAM way, (i.e. either return on success or return on failure), however such a program cannot achieve performances comparable with the up-to-date Prolog systems. --Micha