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

[Evan Langlois]

On 10/20/2014 08:15 AM, Basile Starynkevitch wrote:
> bit of C++ today) at runtime then dlopen-ed. 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. Of course, generating C code has its advantages too: it can be 
> well compiled by complex C compilers (like GCC or Clang), which Tinycc 
> is not. 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. Cheers. -- Basile Starynkevitch

I'm also looking into TCC for the same purpose.  I know C.  From what 
I've seen libjit is going to be a lot harder to deal with than just 
translating to C.

While I think there could be advantages to using LLVM (although it won't 
be a fast JIT), TCC has some interesting benefits as well. First, its 
small and I would imagine that you could write a new "front end" that 
bypassed the C parser if you really wanted to get every last ounce of 
speed out of it, but it parses C so fast as it is, that you can save 
bypassing the C parser for a rainy day.   If you ever want to allow 
someone to simply type in a C function directly, then tcc wins.  Add 
"ability to write functions in C" as a language feature.  Done.  It 
links with GCC libs, so any functions that need to be super-fast can 
simply be created in C and compiled with GCC or LLVM.  If you are 
already set up to output C code to feed into TCC (via libtcc), then you 
can output to any compiler without much more difficulty.  Let some 
future background profiler routine determine which bits need to be sent 
to an industrial compiler (or maybe you can have those generated as an 
OpenCL kernel?)

If your language is mainly calling a library of C routines, the internal 
C is highly optimized with nothing but the linkage as JIT code, and that 
wouldn't require heavy optimization.  The traditional down-falls of 
interpretted code are things like simple math, where you end up with a 
long function call for every operation, and that will get a significant 
speed-up when using TCC to generate the code.  If you are outputting C 
anyway to feed into libtcc, you could feed it to gcc -O3 in the 
background and dl-open it when it completes. Then you know you have the 
most optimized version of the code.   You can link tcc into your code 
without adding much to the program's size.

There is no guarantee of the quality of optimization for libjit or 
lightning.  The former mentions support to re-compile functions with 
greater optimization, which tells me that the default may not be that 
good, or that optimization might be slow.  Lightning is just a 
translation layer and it doesn't look like its going to optimize at 
all.  Its just a way to write portable assembler.  And how small will 
these libs be if they can optimize as good as GCC or LLVM?   If it can 
optimize that well and still be as fast as TCC, then we need to just 
write a C compiler based on libJIT! The point is, we don't know how good 
the code is.  We know what TCC can do.

Personally, my plan is to allow the execution back-end to be pluggable.  
It generates a language specific intermediate code which can then be 
executed like a virtual machine or you swap out the virtual machine for 
a function that feeds the intermediate code to a JIT implementation - 
different backends can use different JITs ... but the first will be just 
outputting C as its mostly function calls anyway.  The run-time will 
know what functions are intermediate/VM code and which are compiled to 
native.