tcc module

["Ag. D.E Chatzimanikas" <aga.chatzimanikas@xxxxxxxxx>]

Hi John,

I took it of to mailing list, as others might want to chime in.

On Tue, Mar 27, at 08:41 John E. Davis wrote:
> Hi Αγαθοκλή,
> 
> Sorry for the delay.  I am very busy with job related stuff.  However,
> I did manage to get the test script run with the debian tcc package.
> I had to make a few changes though.  I have appended the diffs below.

Thanks. Could you show me the following command output?

  ls -l /lib/i386-linux-gnu /usr/lib/i386-linux-gnu

I'm mostly interest if they are symbolic links.

Does also Debian set any of the following environment variables?

LD_LIBRARY_PATH and C_INCLUDE_PATH

or any other relative?

> On Wed, 7 Mar 2018 "Ag. D.E Chatzimanikas" <aga.chatzimanikas@xxxxxxxxx> said:
> > But the question is how to integrate?
> > If you give me some thoughts then it might give me a direction to
> > concentrate.  Don't have to be explicit.
> 
> For me the most important thing is that the use of the jit tcc
> compiler is that it should not cause the interpreter to crash.  I have
> users that use the interpreter in long running interactive
> environments sessions analysing scientific data.  Many times, some
> task could benefit from a jit compiled language, e.g., indexing an
> array that does not parallelize.
> 
> I know that one can embed inline assembly code within a C program
> using, e.g., an "asm" keyword, e.g.,
> 
>  __asm__ ("movl %eax, %ebx\n\t"
>           "movl $56, %esi\n\t"
> 	  "movl %ecx, $label(%edx,%ebx,$4)\n\t"
> 	  "movb %ah, (%ebx)");
> 
> For slang, it might look like:
> 
>    __tcc__ ("C code here that interacts with interpreter variables");
> 
> However, I have no idea how to go about doing this in a way that would
> guaranteee that the interpreter does not crash.

First, the tcc api gives the freedom to call a callback function when
encounters an error, with the following signature:

  void __tcc_error_handler (void *opaque, const char *msg)

For now, the default handler in the tcc-module looks first for a slang
defined function "tcc_error_handler".
If it is defined, it pushes the message string and calls that function.

But we can do better, but I don't know the way. I guess the opaque
pointer argument should be the current state of tcc, which doesn't help
much since the tcc state is an opaque object anyway and we don't have
any access to its fields. Or am i missing something? Ideally, we would
like, this argument to be our own TCC_Type. We can of course declaring
a global variable when running any code through tcc, but this wouldn't
make it, how they call it in programming: not thread safe?

Ideally again, we could give to any job e.g., a specific id, which we
could store a reference of the type in a table in C side or in slang
side.
But this needs cooperation from tcc, to add one more field to its state
to store this id and the ability to manipulate it (something like a user
defined field, could be enough).

Perhaps I have to take it this on the tcc mailing list.

FYI, there is already a thread in that same mailing list dedicated to
the slang and tcc collaboration:

http://lists.nongnu.org/archive/html/tinycc-devel/2018-03/msg00023.html

perhaps you might want to help me there to teach them slang :).

> Thanks,
> --John

Me too,
  Αγαθοκλής