[Top][All Lists]

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

Re: [Tinycc-devel] Optimizing code for expressions

From: Fabrice Bellard
Subject: Re: [Tinycc-devel] Optimizing code for expressions
Date: Tue, 08 Jul 2003 22:15:16 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408

>>>>>> "Fabrice" == Fabrice Bellard <address@hidden>
>>>>>> writes:
> Fabrice> Mauro Persano wrote:
>>> Hi,
>>> I'm wondering if there would be any interest in a modification for
>>> tcc [...]
>>> I realize that tcc is (highly) optimized for compiler size and fast
>>> compile times, so a modification like this could be viewed as an
>>> attempt to steer it away from its original goals. I'm willing to
>>> try it, though. Any thoughts?
> Fabrice> I would prefer a modification in which the program is Fabrice>
> transformed in an intermediate RISC like machine Fabrice> language.
> A first step would be to add a new target for Fabrice> TCC to
> generate this RISC like language, and then to Fabrice> write the
> converter to x86 code.
> Two small remarks (which I might have already made here a few months
> ago)
> First, as a RISC like intermediate langauge, you might consider C--;
> see http://www.cminusminus.org for more. However, generating any
> kind on language would IMHO make the compiler much slower (so
> against tcc goals). I think that tinycc speed is essentially because
> it generate directly binary code.
> Second, for dynamicly generating small piece of code, the GNU lightning
> library might be more useful. You can get it from
> http://www.gnu.org/software/lightning/lightning.html (current
> version is 1.1).
> Lightning could also be used inside tinycc to offer portability to some
> more architectures such as Sparc (perhaps at the expanse of performance
> of the generated code).

I would prefer writing the code generator from scratch, at least to learn, as I never wrote a register allocator.

An interesting project would be to use the same code generator in both TinyCC and QEMU. In both projects speed is critical, and both projects must generate code for several CPUs. Currently QEMU is more mature on that side as it generates code for many CPUs, but both projects generate very poorly optimised code. The main difference I see in the two projects is that TinyCC must generate function calls while QEMU only needs basic blocks.


reply via email to

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