From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=57582 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PRQhL-0000VY-Vn for qemu-devel@nongnu.org; Sat, 11 Dec 2010 09:45:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PRQh7-0007EW-J1 for qemu-devel@nongnu.org; Sat, 11 Dec 2010 09:45:19 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:54789) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PRQh7-0007EG-Da for qemu-devel@nongnu.org; Sat, 11 Dec 2010 09:45:05 -0500 Received: by pwj6 with SMTP id 6so1027303pwj.4 for ; Sat, 11 Dec 2010 06:45:04 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <02a901cb9940$3437a610$9ca6f230$@gmail.com> References: <4D029B13.3050002@gmail.com> <4D036E9D.90401@gmail.com> <02a901cb9940$3437a610$9ca6f230$@gmail.com> From: Blue Swirl Date: Sat, 11 Dec 2010 14:44:44 +0000 Message-ID: Subject: Re: [Qemu-devel] TCG flow vs dyngen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefano Bonifazi Cc: qemu-devel@nongnu.org On Sat, Dec 11, 2010 at 2:32 PM, Stefano Bonifazi wrote: > -----Original Message----- > From: Blue Swirl [mailto:blauwirbel@gmail.com] > Sent: sabato 11 dicembre 2010 14:12 > To: Stefano Bonifazi > Cc: qemu-devel@nongnu.org > Subject: Re: [Qemu-devel] TCG flow vs dyngen > > >>There's a large buffer for generated code, allocated in exec.c. This is f= illed with host code by TCG, when full it is flushed. The CPU execution loo= p >generates new TBs when needed, otherwise the old code can be executed. > >>TCG also uses intermediate ops but those are used only once during transl= ation. > > So if I understand well the flow is the following: > > 1) the CPU execution loop at runtime takes a new TB from the target code > 2) I guess some hash function is computed on this TB for getting a key fo= r searching into the buffer of generated code that probably should store th= e binary as a map key-binary > 3) if the search is successful the binary is given to the translator(how?= You said no copy involved) and we return to point 1) otherwise: 1-3) Please see tb_find_fast() and its caller in cpu-exec.c. Only pointer passing is involved. > 4) the target specific translator generates TCG uops from the TB > 5) TCG uses uops for generating =C2=A0host binary code > 6) this new binary code is cached by TGC if there is enough storage place > > Is that all correct? 4-5) OK. 6) If there is no space, all previously generated code is thrown away. > > Where does the execution of host binary take place in the previous list o= f events? =C2=A0Between point 5) and 6) ? > After 6) ? In what QEMU source code file/function does the final executio= n of host binary take place? > > In the previous list of events, when does the translator try to chain the= current TB with previous ones? =C2=A0Before TCG generates the binary in or= der to feed it with "linked micro code"? All of this happens in cpu-exec.c:581 to 618.