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 _______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
