[Top][All Lists]

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

Re: [Tinycc-devel] Using TCC as a backbone for our compiler

Subject: Re: [Tinycc-devel] Using TCC as a backbone for our compiler
Date: Sat, 13 Jun 2009 16:21:47 +0200
User-agent: Mozilla-Thunderbird (X11/20090103)

On Sat, Jun 13, 2009 at 5:37 AM, Basile
STARYNKEVITCH<address@hidden> wrote:
Jerome St-Louis wrote:
Hi all...

We are contemplating using TCC as the backbone engine to generate
object code for an eC language Just-In-Time compiler system.
Did you consider using something more appropriate for that purpose, like
LLVM or perhaps LibJit?
Jerome St-Louis wrote:
Hi, thanks for the reply.

Of course we're considering all options, and I'll admit we're not very
familiar with any of them yet.

I was particularly fond of TCC however, and maybe the thing that
naturally brought us to TCC is the fact that we currently output
intermediate C code and uses GCC, and TCC is a lighter and smaller

I am not an expert on TCC. I am a GCC contributor (but I won't claim to be a GCC expert yet. FWIW, my main GCC work is the MELT branch, which also generates C code -inside a GCC plugin; so I clearly understand what generating C code means in practice.).

Of course, if your compiler already generate C code, switching to TCC should be easy. However, the generated code performance is not good (w.r.t. GCC). The main strength of TCC is that it compiles C code very quickly, to a slow executable.

I am not sure to understand your goals. And I do not understand what you are currently doing: is your language a C dialect, very similar to C (enough so that representing all the abstract syntax tree is not done inside your compiler) or not. You really should explain alot more what is already done. Is your language http://www.ecere.com/ ?

First, you should try (temporarily, as an experiment) to replace gcc in your program by tcc. That should be really trivial (just fork a tcc process, not a gcc one; basically change the "gcc" string inside your compiler into "tcc"). That should give you a feeling of what tcc would give you (or not). In particular, you'll measure that tcc generate really awful machine code - but the generation time is very very fast! You could also temporarily experiment replacing "gcc" with "lvm-gcc" or even "nwcc" ; all this are very easy experiments!

If that suits your expectations, then you may take some time to use tcc as a library. But you probably won't win a lot. That brings you the libtcc.h API & library; *mostly the following function.
/* compile a string containing a C source. Return non zero if
  error. */
  LIBTCCAPI int tcc_compile_string(TCCState *s, const char *buf);

There is also another point you should care about: generating good machine code from any kind of source language is a hard task (because there is an increasing impedance mismatch between C, and even more higher level languages like Ocaml, and current processors). You should define what you really care about. Is the execution time of the generated code an important point to you? In practice, in your current use of gcc, do you invoke it usually with -O1 or -O2? If you do, that means that you care about the performance of the generated code. Tcc generates machine code roughly in the same quality as gcc -O0!

You might also consider generating CIL or JVM bytecode, or C# or Java source code. Or even Ocaml.

You might also consider using other metaprogramming languages, in particular Common Lisp, Clojure, ...

Again, I don't really understand your goals, your needs, the things you really care about.

In addition of libjit & LLVM, you might also consider GNU lightning (which share with tcc the facet of generating quickly code which does not perform well).

Also, do you have an important code base? Do you have a lot of users for Ecere? Will they complain of incompatible changes?

And of course, you could make a front-end from Ecere for GCC (ie for its GIMPLE internal representation). This is not as hard as you believe: you just have to adapt your parser to build GIMPLE internal representation. If you did that, you'll get all the code generation power of GCC.

What part of compiler science are you familiar with (compilation is no more a parsing problem: the hard work happens on internal intermediate representations, and it is really hard work!!).


And please explain in one paragraph what is the interest of Ecere. The http://www.ecere.com/action.html page suggest that most of it is a graphical library, not really a new programming language (would it make sense to code in Ecere any non-graphical application, eg a formal theorem demonstrator?). See also Vala http://live.gnome.org/Vala/


PS. It could happen that the discussion becomes off topic on a tinycc list.

Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

reply via email to

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