[Ecls-list] New compiler

[Juan Jose Garcia Ripoll]

Hi,

this weekend I intended to work on the missing FFI:DEFENTRY (If you remember 
from previous e-mails, DEFENTRY allows one to declare a C function in a lisp 
file; it appears in the documentation, but it is missing from ECL!).

In doing so, I realized that everything would be much easier if we had a new 
special form with syntax

(C-INLINE (arg1 ... argn) (c-type-1 ... c-type-n) output-c-type
        "C code with arguments as #[number] and lisp objects as @[lispobject"
        :side-effects {t | n}
        :one-liner {t | n})

This form can appear anywhere in the code, and it defines a piece of C code 
that takes lisp values as arguments and outputs some C value (which is 
automatically converted to lisp, of course).

With such a special form, DEFENTRY, DEFCBODY, etc, become macros, and not part 
of the compiler itself. Everything much easier for me! :-)

This weekend I have worked out an implementation for C-INLINE, and in doing so 
I have made huge changes in the way the ECL compiler understands types. Now, 
for each form there are two types, a lisp type and a representation type. 
Thus, 125 belongs to (SIGNED-BYTE 8), but it can be represented internally 
(that is, in compiled code), as a :object (Lisp representation!), :long, 
:int, :unsigned-int, :unsigned-byte, :byte, etc. Type names follow the 
conventions in UFFI.

The current implementation is slow, and it has already revealed some problems 
in the previous version of the compiler (For instance, the optimizer for CASE 
and ECASE, which have been now removed from the code). On the other hand, I 
expect better optimizations to be possible.

The status of CVS is, right now:
+ The trunk of the tree has been tagged ECL_0_9, and keeps the stable version.
+ A branch has been created, with name NEW_COMPILER, which contains the latest 
developments. It is unstable in the sense of being rather untested, but it 
passes all regression tests.

The NEW_COMPILER branch contains the changes to the compiler type-inference 
scheme, variable creation and management, and the C-INLINE routine. DEFENTRY 
has to be rewritten, as well as DEFCBODY and similar ones. Expect this to 
happen in a couple of days.

Besides, preliminary support for run-time foreign data creation and 
manipulation "a la" UFFI has been included. But this still is a long way far 
from completion (i.e. there is support for foreign-data in the garbage 
collector, but the library does not yet allow data to be retrieved out of or 
inserted into these foreign-data areas).

I would really like people to test this and provide feedback. It is now to 
suggest improvements, complain about current syntax, etc.

Juanjo