tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Using TinyCC with GPL


From: Yann Renard
Subject: Re: [Tinycc-devel] Using TinyCC with GPL
Date: Mon, 09 Jun 2008 11:20:51 +0200
User-agent: Thunderbird 2.0.0.14 (X11/20080502)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]