From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44996) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUp9H-00042W-W3 for qemu-devel@nongnu.org; Sun, 27 Nov 2011 19:32:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RUp9G-0006Ck-LG for qemu-devel@nongnu.org; Sun, 27 Nov 2011 19:32:43 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:43453) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUp9G-0006Ce-I3 for qemu-devel@nongnu.org; Sun, 27 Nov 2011 19:32:42 -0500 Received: by iakk32 with SMTP id k32so9199615iak.4 for ; Sun, 27 Nov 2011 16:32:41 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <4ED24545.1060902@suse.de> <4ED24EF7.4050704@suse.de> Date: Sun, 27 Nov 2011 19:32:41 -0500 Message-ID: From: Xin Tong Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] cpu_regs in target-i386 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: =?ISO-8859-1?Q?Andreas_F=E4rber?= , qemu-devel Thank you very much. This is very helpful. Xin On Sun, Nov 27, 2011 at 6:33 PM, Peter Maydell w= rote: > On 27 November 2011 23:07, Xin Tong wrote: >> can you please show me where the (120) is used. we pushed a global >> TCGV to the gen_opparam_ptr. lets say the backend is i386 and the >> operation is an add. > > So, you can find it like this: > > (1) starting from tcg_global_mem_new_i64 we follow where that > offset went, and we see that tcg_global_mem_new_internal stores > it in the mem_offset field of a TCGTemp structure. > (2) So we grep for uses of mem_offset, and we find that tcg.c > uses it in the register allocator; basically there are a lot > of places where we say "if this is a TEMP_VAL_MEM then either > load or store the value". We do that load or store by calling > tcg_out_ld() or tcg_out_st(), passing the mem_offset value > (plus some other stuff like the base register and whatever > temporary register the allocator wants to use for it). > (3) grepping for tcg_out_ld() we find it's implemented in the > backends. Specifically, tcg/i386/tcg-target.c has the x86 > version which writes out x86 code to do a load/store from > [reg+offset]. > > So we can deduce that TCG doesn't try to be particularly > clever about these values -- we just load them when we need > them and store them again when they are updated. (We don't > try to support issuing add instructions with memory operands > even if the host CPU architecture has them.) > > I didn't particularly know this in advance -- I'm just looking > through the code and searching for uses of things and implementations > of functions. QEMU's code generation is not particularly > exotic: > =A0* guest-specific front end decodes instructions and writes > =A0 intermediate representation > =A0* optimisation pass that works on IR > =A0* liveness analysis (ie work out when data values are no > =A0 longer needed, so we can reuse the registers they're in) > =A0* turn IR into generated code by making calls to a handful > =A0 of host-specific backend functions > > (about the only slightly unexpected thing is that we do the > register allocation as we go along generating the final > code, rather than doing it as a separate pass.) > So if you can get a grasp of the general structure then > following through it to answer specific questions like this > should be straightforward. > > -- PMM >