Re: [Qemu-devel] TCG flow vs dyngen

[Blue Swirl <blauwirbel@gmail.com>]

On Fri, Dec 10, 2010 at 9:26 PM, Stefano Bonifazi
<stefboombastic@gmail.com> wrote:
> Hi all!
>  From the technical documentation
> (http://www.usenix.org/publications/library/proceedings/usenix05/tech/freenix/bellard.html)
> I read:
>
> The first step is to split each target CPU instruction into fewer simpler
> instructions called micro operations. Each micro operation is implemented by
> a small piece of C code. This small C source code is compiled by GCC to an
> object file. The micro operations are chosen so that their number is much
> smaller (typically a few hundreds) than all the combinations of instructions
> and operands of the target CPU. The translation from target CPU instructions
> to micro operations is done entirely with hand coded code.
>
> A compile time tool called dyngen uses the object file containing the micro
> operations as input to generate a dynamic code generator. This dynamic code
> generator is invoked at runtime to generate a complete host function which
> concatenates several micro operations.
>
> instead from wikipedia(http://en.wikipedia.org/wiki/QEMU) and other sources
> I read:
>
> The Tiny Code Generator (TCG) aims to remove the shortcoming of relying on a
> particular version of GCC or any compiler, instead incorporating the
> compiler (code generator) into other tasks performed by QEMU in run-time.
> The whole translation task thus consists of two parts: blocks of target code
> (TBs) being rewritten in TCG ops - a kind of machine-independent
> intermediate notation, and subsequently this notation being compiled for the
> host's architecture by TCG. Optional optimisation passes are performed
> between them.
>
> - So, I think that the technical documentation is now obsolete, isn't it?

At least we shouldn't link to that paper anymore. There's also
documentation generated from qemu-tech.texi that should be up to date.

> - The "old way" used much offline (compile time) work compiling the micro
> operations into host machine code, while if I understand well, TCG does
> everything in run-time(please correct me if I am wrong!).. so I wonder, how
> can it be as fast as the previous method (or even faster)?

The dyngen way was to extract machine instructions for each micro-op
from an object file (op.o) compiled by GCC during QEMU build. TCG
instead generates the instructions directly. Since the whole host
register set is available for the micro-ops (in contrast to fixed
T0/T1/T2 used by dyngen), TCG should outperform dyngen in some cases.
In other cases, GCC may have used some optimization when generating
the op which would be too complex to implement by the TCG generator so
the dyngen op may have been more optimal.

The old way was not portable to GCC 4.x series. Now it might be even
possible to replace GCC extensions with something else and use other
compilers.

> - If I understand well, TGC runtime flow is the following:
>     - TCG takes the target binary, and splits it into target blocks
>     - if the TB is not cached, TGC translates it (or better the target
> instructions it is composed by) into TCG micro ops,

The above is not the job of TCG (which is host specific), but the
target specific translators (target-*/translate.c).

>     - TGC compiles TGC uops into host object code,

OK.

>     - TGC caches the TB,
>     - TGC tries to chain the block with others,

The above is part of the CPU execution loop (cpu-exec.c), TCG is not
involved anymore.

>     - TGC copies the TB into the execution buffer

There is no copying.

>     - TGC runs it
> Am I right? Please correct me, whether I am wrong, as I wanna use that flow
> scheme for trying to understand the code..

Otherwise right.