Re: [Tinycc-devel] Using TinyCC with GPL

[Yann Renard]

Ivo wrote:
> AFAIK Fabrice's libtcc is LGPL, so linking it to a non-(L)GPL'd application 
> should not be a problem as long as you publish any modifications you make 
> to libtcc, etc... (comply with the LGPL for the library).
>
> If you use Rob Landley's fork, your application must be GPL as Rob switched 
> to the GPL for all of tinycc.

Ok, I thank you for this precision

Ivo wrote:
> Keep in mind though that tcc is basically a non-optimising compiler. The 
> compiled code is even slower than gcc -O0. If you do not really need the 
> scripting facility, you might have a look at dlopen() for plugins and 
> compile those with your favourite optimising compiler (gcc, icc, 
> suncc, ...) instead.

My application already has a plugin loading system based on dlopen and 
LoadLibrary. In the past, we developed a plugin to apply a basic 
arithmetic operation on a list of value. It included all the basic 
<math.h> functions and created an evaluation tree with function 
pointers. It works pretty well but I guess any non optimized C compiler 
would make something faster, and open doors for more complexe processing.

F.B. wrote:
> C and try/catch? Now that's a good one.

:) I'm not an expert at using C in C++. My experience is much bigger on 
using C. However, I suppose and maybe I'm wrong, that I can catch any 
error for the C code part into the C++ calling application. Isn't it ?

F.B. wrote:
> Do yourself a favour and look into Lua, it'll save you some headaches.

I heard of Lua some years ago and forgot about it. I will go back on 
this piece of code so to have an idea of how better it could be.

Basile wrote:
> I agree with F.B. who suggest Lua. You might also look into Ocaml. Its bytecode 
> VM is quite fast!
> If your machine is x86 (= i686 = ia32 = 32 bits only, not the 64 bits variant = 
> AMD64 = x86-64) then the LuaJit implementation should be even faster. And 
> Tinycc does not run for x86-64!

Ok, this is a point I missed

Basile wrote:
> If speed is your main concern, it is somehow antagonistic with scripting 
> language. But usually script language are used in performance application to 
> drive lower-level, resource consuming, routines.

Developper have the option of writing native plugins if they want. The 
idea behing this scripting option is to fast protoype something. 
However, the code should run realtime (we basically do signal processing 
on brain activity to provide feedback). So having too low performances 
will make the protoype unusable. I want the scripting functionnality to be :
- as fast to tun as possible
- as fast to develop as possible

At the end, when tuning is done, a developper will most probably and in 
writing a native plugin.

Basile wrote:
> Again, scripting in a non-safe language is really a nightmare. What is your 
> user supposed to do on a core dump?

Same behavior as for native plugins : deactivate the functionnality 
until the scenario is reseted and restarted.

Basile wrote:
> However, you might consider also:
>  * generating C code, compiling it (either with tinycc, or with another 
> compiler like gcc, using -fPIC -shared on Linux) and dynamically loading it 
> with dlopen(3).
>  * using some JIT-ed scripting implementation (LuaJit, Parrotcode, ...)
>  * using some machine code generator library, like libjit (use the CVS 
> version), LLVM, GNU lightning
>  * generating some other langage source code (C++, D, C-- Pascal ...) and 
> compiling it and dynamically loading it.
>  * restricting yourself to ordinary plugins
>  * using some language implementation which dynamically compile to machine code: many Lisp-s (e.g SBCL), several Java JVM, next version of Ocaml, some Haskells, .. 

Ok guys, thank you very much for all your advices. Seems like I'm a 
crazy man wanting to use tinycc in my context. I will compare this 
option to LUA, both on safety aspect and performances.

Thanks again,
Best regards,
Yann Renard