The compiler I'm writing uses the LLVM API to generate LLVM-IR directly which is just-in-time compiled to executable code.
Using (setq XXX (COMPILE nil (lambda (x) (* 3 x)))) returns a compiled function that can be evaluated directly using (FUNCALL XXX 4) --> 12.
There are no intermediate compilers that need to be run to generate executable code.

I am guided by my own interest to learn/try my own Common Lisp --> LLVM implementation.



On Mar 16, 2013, at 9:39 AM, Anton Vodonosov <> wrote:

05.03.2013, 01:25, "Juan Jose Garcia-Ripoll" <>:
On Mon, Mar 4, 2013 at 5:30 PM, Christian Schafmeister <> wrote:
I've created a new implementation of Common Lisp that has a core written in C++ completely from scratch but hosts the ECL Common Lisp source code.
Sounds like a lot of work.
It hosts all of the ECL Common Lisp code in the ecl/src/lsp and ecl/src/clos directories of the ECL source tree.
I do not use any part of the ECL CL->C compiler or the byte code compiler.
I've implemented my own CL interpreter and CL->LLVM-IR->native code compiler.
I do not understand why you reimplemented the interpreter, but the LLVM thingy looks interesting.
As ECL can compiles List to C, a C compiler generating LLVM code may be used
(llvm-gcc or clang).
Juan Jose, Christian, how can you compare Lisp -> C -> LLVM with Lisp -> LLVM
solution to ECL?
My understantind (pure theoretical, I haven't tried any of that):
if ECL can generate LLVM directly, it is a simplification to user, less tools to chain.
But Lisp to LLVM required efforts to implement and will also take mainenance efforts.
Christian, have you compared these options, or you were just guided by interest
to learn/try your own Lisp -> LLVM implementation?
Best regards,
- Anton