[Openmcl-devel] Executing CCL from within C/C++

[Gary Byers]

On 07/25/2016 05:23 PM, R. Matthew Emerson wrote:
>
>> On Jul 25, 2016, at 6:36 PM, Josh Hamell <jhamell at sift.net> wrote:
>>
>> We have had great experiences using CCL on a number of different
>> projects in different capacities, and are now looking at a very niche
>> use case.
>>
>> Within Linux, is it possible to compile a C/C++ program against
>> lisp-kernel headers, link against the binary (lx86cl64), and execute
>> arbitrary Lisp code as input char* s-expressions?  Naively, I can peruse
>> the exposed functions using objdump, and would like to believe in a
>> simple way to start the interpreter, load an existing heap image, and
>> run, all through simple C.  This is sort of a "reverse CFFI" - our issue
>> is that the C code needs to be the application entry point, without
>> resorting to separate processes.
>
> I'm afraid that as currently written, CCL doesn't support this.  That is, you can't use CCL as a linkable library as you describe.


I don't know what a "char * s-expression" is ...

there has been (intermittently( an Android Arm port of CCL, which tends 
to go through cycles where it sort of works for a while before bitrot 
sets in,

the last time that it worked (sorta kinda), the application was a sort 
of minimal ELF executable image which opened the lisp kernel as an ELF 
library.  Doing so mapped a heap image into memory and transferred 
control to it.

A couple of points that people seem to be confused about:

- most of the code in the lisp kernel is written in C; you can
C the code with objdump and similar tools, and easily call it from C
code. Most of that code is not liso code and not very interesting in and
of itself.  you can call lisp code from C: see defcallback in the mabual
or use the cffi wraooer around defcallback if you prefer,

- when people note potential issues with signal handling in this 
environment, they are likely more concerned with signals like SIGILL and 
SIGSEGV than they are with things like SIGVTALARM.  SIGILL and SIGSEGV
are generated by hardware in response to things that happen in a 
specific thread and which generate machine exceptions, and handlers for 
those signals run in the execution context of the machine exception and
on the thread on which the exception occurred.

It is possible that a C progran needs to handle SIGILL et al, but most C 
prograns don't,

- when the CCL kernel maps the heap image into the address space, it tries
to map each part of it at the same address it was saved from.  the code 
that deals with this can usually do some kinds of relocation, though the
need to do this is less common in the 64-bit world than it had once 
been. an exception to this is that NIL pretty much has to be at a fixed 
address (#x1300b), and it is  likely not practical to change this,

I think that the code in question is likely in the ccl svn trunk; look
in ccl:compiler;androidarm; and ccl:compiler;lisp-kernel;androidarm; 
especially,

I can't say with total certainty that you can embed CCL in any C 
progran, but it is probably easier to enbed it in many C programs than I 
once thought it was.  If you are not sure of how to do this and it
is important to your organuzation, Clozure has been known to take money 
to do this sort of thing
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> https://lists.clozure.com/mailman/listinfo/openmcl-devel
>