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

[Seth Burleigh]

> Be careful because Seth stated that he does not want to call the C
> functions that are used for lisp. He wants to call functions that take
> as arguments ordinary C types (structures, pointers, integers, etc)
> and which automatically convert the arguments of these functions to
> lisp, that acting as proxy for the real lisp functions. That is the
> definition of a callback.
> 
> 

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.


--------------------------

Looking at the code generated, I gather/speculate that this is the way
that the functions are 'used' by ecl:


The header file defines an array which contains function pointers
(cl_objectfn cast?)

static const struct ecl_cfun compiler_cfuns[] = {
 /*t,m,narg,padding,name,block,entry*/
{0,0,0,0,MAKE_FIXNUM(2),MAKE_FIXNUM(0),(cl_objectfn)L1test,Cnil,MAKE_FIXNUM(326)},
{0,0,0,0,MAKE_FIXNUM(3),MAKE_FIXNUM(1),(cl_objectfn)L2test2,Cnil,MAKE_FIXNUM(437)},
};

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?

---------------------------------------------------------------------------------------
#ifdef __cplusplus
extern "C"
#endif
ECL_DLLEXPORT void init_fas_CODE(cl_object flag)
{ VT1 VLEX1 CLSR1 STCK1
	const cl_env_ptr cl_env_copy = ecl_process_env();
	cl_object value0;
	cl_object *VVtemp;
	if (!FIXNUMP(flag)){
	Cblock=flag;
	#ifndef ECL_DYNAMIC_VV
	flag->cblock.data = VV;
	#endif
	flag->cblock.data_size = VM;
	flag->cblock.temp_data_size = VMtemp;
	flag->cblock.data_text = compiler_data_text;
	flag->cblock.data_text_size = compiler_data_text_size;
	flag->cblock.cfuns_size = compiler_cfuns_size;
	flag->cblock.cfuns = compiler_cfuns;
	flag->cblock.source =
make_constant_base_string("/home/seth/install/test.lisp");
	return;}
	#ifdef ECL_DYNAMIC_VV
	VV = Cblock->cblock.data;
	#endif
	Cblock->cblock.data_text = "@EcLtAg:init_fas_CODE@";
	VVtemp = Cblock->cblock.temp_data;
	(void)si_select_package(_ecl_static_0)    /*  SELECT-PACKAGE  */;
	ecl_cmp_defun(VV[2]);
	ecl_cmp_defun(VV[3]);
}


---------------------------------------------------------------------------------------

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).

So, lets now say that when we use a package we can also specify c
functions which have been defined in that package to 'import' into a new
package. When imported, an h file would be imported also consisting of
pieces of the .h file which correspond to what we requested. Than, any
compile-file in that package would piece together all those .h files and
use them, plus also link to the corresponding .fas files.

So, basically if this is conceptually sound what would be needed from
the ecl compiler is a bunch of compiler hooks and loading hooks.

Would this work or am i missing something?


In this way, we could treat c functions, c classes, etc as regular
imports (would be interesting) and everything would be pretty seamlessly
integrated.