[Top][All Lists]

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

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

From: Evan Langlois
Subject: Re: [Tinycc-devel] tcc as jit-compiler
Date: Mon, 20 Oct 2014 13:05:06 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

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.

reply via email to

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