[Ecls-list] Tighter c/c++ integration, toplevel inline c/c++ code ???

[Juan Jose Garcia-Ripoll]

On Mon, May 3, 2010 at 7:22 PM, Seth Burleigh <seth at tewebs.com> wrote:

> So, I guesssing that there isn't a simple parser which replaces the
> funcall of the non-obfuscated lisp name with the actual obfuscated
> function call? Instead literally the lisp 'funcall' is called? Some
> other mechanism i should look up since i need to be able to call the
> lisp functions.
>

I am a bit confused by the jump of requirements. But let me explain the
following: each lisp function gets compiled to a C function with one of
these signatures

cl_object f1(cl_narg narg, cl_object arg1, ...)

cl_object f2(cl_object arg1, cl_object arg2, ..., cl_object argn)

In the first case the "..." are actual optional arguments (this happens for
&key, &optional and &rest functions) and in the second case it is a lisp
function with N arguments.

In principle you could call these functions directly, but we obfuscate the
names on purpose so as to have  the functions not collide with each other
(in CL you may define the same function twice and you are happy, in C it is
not possible).

What Matthew showed was that it is possible to use FUNCALL + a pointer to
the symbol naming the function to call that function. In addition to this
there is a mechanism to actually *name* the function, that is specifying to
ECL what C name the function must have. In this case the function will be
exported and you can call it.


> then when we 'load' a fas we're actually loading a shared library, we
> call init_FAS_code and pass in a flag object, the flag object will then
> contain the compiler_cfuns array which contains the function pointers
> which can then be used to access the functions. Is this the way it
> happens?
>

More or less so. For each pointer the Common Lisp creates a CFUN object
(compiled-function in the Common Lisp type system) which keeps the pointer,
the name and the number of arguments it takes. This object is a Common Lisp
one and can be used by FUNCALL. It is then stored in the appropriate slot of
a symbol so that you can also use the symbol instead in FUNCALL.


> So, now conceptually my ideal .fas would also store an .h file which
> contains all the function definitions and structure, class defs, etc per
> package scope (lets not worry how we get those, im thinking of clang as
> it is a structured compiler with an api).
>

Well, getting CLang to do that is not simpler than embedding CLang in ECL
and using it as a compiler instead. Then you can forget about the rest of
your problems because all definitions will be available to you. Furthermore
by that price you would get ECL with an embedded compiler that can be
distributed anywhere.

So, again, if you turn ECL into a C compiler then you can do what you want,
but this is no little feat. Otherwise there are way simpler ways to live
with C -- and actually I do not see the point in creating an infrastructure
where your C code is so tightly packed with the Common Lisp world: it is not
reusable at all and by that price you might be working entirely in Common
Lisp using FFI.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://tream.dreamhosters.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20100503/ca67bfa2/attachment.html>