Re: [Tinycc-devel] tcc as jit-compiler

[Pete]

I've done this with tcc a couple of times.

On 2014年10月20日 13:15, Basile Starynkevitch wrote:
> I know nothing about windows, not much about TCC (which I sometimes use, but
> not much since it seems unable to compile GCC on Linux/x86-64 these days),

Well, gcc uses C++ internally nowadays, doesn't it?  I'm not entirely
sure of how much C++ lives inside the compiler, but it wouldn't be a
surprise if a C compiler couldn't compile a C++ program. ;)

> main developer of MELT http://gcc-melt.org/ which
> is a domain specific language to extend & customize the GCC compiler. MELT code 
> is
> translated to C (actually a bit of C++ today) at runtime then dlopen-ed.

Why the dlopen call instead of compiling to memory?  Just a pragmatic
thing?  I tried using the dlopen approach for dynamic compilation, but
it can get a bit unwieldy.

> I am not sure that you right in wanting to use tinycc for JIT-ing purposes.
> The point is that generating C code is probably not easier than
> using some JIT library like LibJit http://www.gnu.org/software/libjit/,
> GNU lightning, or LLVM.

I ended up abandoning Lightning for JIT.  I like it a lot, but
generating C is much more convenient than the other approaches if, for
example, you want to take advantage of compiler macros without writing
them twice.

For example, in one of my projects, there are a few macros for checking
stack depth, and rewriting them in Lightning was a bit more tedious and
error-prone than just generating C that called the pre-existing macros.

On top of that, though, when using JIT to build an FFI, you can use
compile-time macros that the library itself defines.  For example, after
simple "Hello, World!" case where I called puts(), I used SDL for the
next test of the FFI, and this is a pain to do without SDL's internal
macros.  I'm sure there are a number of libraries that abstract things
away by means of #define.

> My point is : if you wish to emit JIT machine code, just use some JIT library.
> If you want to generate C code, there are cases where you want it to be compiled
> with strong optimizations, and then TinyCC is not the right compiler.

Well, for something like an FFI, or dynamically compiling a large number
of small functions independently, a fast compiler that compiles to
memory can make the program run more quickly than a compiler that
produces highly optimized code.

Because of that I wouldn't dismiss using tcc, especially since this is a
case where your mileage may vary a great deal, although I think that
this emacs Paolo was talking about might do better with a bytecode VM
(mawk *is* very fast).  Barring a bytecode interpreter, I think tcc
actually is a really good fit here.

Pete