Re: [Qemu-devel] TCG flow vs dyngen

[Stefano Bonifazi <stefboombastic@gmail.com>]

Thank you very very much! I'd take months for understanding everything 
myself from the source code! :)

On 12/11/2010 12:02 PM, Blue Swirl wrote:
> On Fri, Dec 10, 2010 at 9:26 PM, Stefano Bonifazi
> <stefboombastic@gmail.com>  wrote:
>> [..]
>>
>> - 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.
Do you mean this:
http://www.weilnetz.de/qemu-tech.html
?

>> - If I understand well, TCG runtime flow is the following:
>>      - TCG takes the target binary, and splits it into target blocks
>>      - if the TB is not cached, TCG 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).
Ok, then considering QEMU flow instead of simply TCG, do those steps 
take place in the order I considered?

>>      - TCG caches the TB,
>>      - TCG tries to chain the block with others,
> The above is part of the CPU execution loop (cpu-exec.c), TCG is not
> involved anymore.
Ok! Thank you, now I have a clearer idea of where different operations 
are implemented.. but again considering the whole QEMU flow, are the 
steps I reported executed in the order I put them?
>>      - TCG copies the TB into the execution buffer
> There is no copying.
Does that mean TCG produces the host object code directly into the 
emulator's memory for it to fetch? Or does TCG make the emulator even 
execute that object code as soon as it is produced?
But, if the object code is consumed on the fly, it means there is no 
cashing of it, is it there?
What is actually cached? Only target blocks? Their translation into TCG 
uops? Host binary code generated by TCG?

Again many many thanks!!!
Stefano B.