Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!cogen
From: cogen@XN.LL.MIT.EDU (David Cogen)
Newsgroups: comp.lang.lisp
Subject: Re: lisp to C translator
Message-ID: <665@xn.LL.MIT.EDU>
Date: Fri, 28-Aug-87 15:36:25 EDT
Article-I.D.: xn.665
Posted: Fri Aug 28 15:36:25 1987
Date-Received: Sun, 30-Aug-87 01:52:51 EDT
References: <2446@bnrmtv.UUCP>
Organization: MIT Lincoln Laboratory, Lexington, MA
Lines: 26
In-reply-to: wagner@bnrmtv.UUCP's message of 27 Aug 87 18:49:39 GMT

Posting-Front-End: GNU Emacs 18.46.1 of Fri Jun 12 1987 on xn (berkeley-unix)


In article <2446@bnrmtv.UUCP> wagner@bnrmtv.UUCP (Mark Wagner) writes:

>   If anyone knows of a common lisp to C translator I would
>   appreciate e-mail describing it.  I realize that this sort
>   of translation is fraught with problems but I believe that
>   some portion of the translation could be made.


KCL (Kyoto Common Lisp) uses C as the intermediate code output from its
compiler. The C output is ugly. For example, it is incorrectly indented, uses
goto and no structured constructs (for, while, etc), uses a lot of meaningless
variables (L1, L2, etc.), and requires a run-time Lisp system to use the
compiled output. 

However, the output is very efficient, assuming you make liberal use of type
declarations. For example, a convolution routine I wrote was within 15% of a
simple handcoded C routine, and within 50% of a highly optimized C routine.

One of the difficulties in a Lisp-to-anything_else translator is the very large
number of functions in Lisp. All these must be emulated by the run-time system.
There is nothing difficult, in principle, in providing your own run-time system
(instead of KCL) to interface with your C-translated Lisp routines. KCL (all
source available, cheap) is very good at interfacing Lisp and C.


(DAVID (am I balanced) COGEN)