From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=46575 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PiA5a-0007G1-GT for qemu-devel@nongnu.org; Wed, 26 Jan 2011 13:27:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PiA5Z-0000dm-GU for qemu-devel@nongnu.org; Wed, 26 Jan 2011 13:27:30 -0500 Received: from cantor2.suse.de ([195.135.220.15]:40951 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PiA5Z-0000dM-8a for qemu-devel@nongnu.org; Wed, 26 Jan 2011 13:27:29 -0500 Message-ID: <4D40678F.8030504@suse.de> Date: Wed, 26 Jan 2011 19:27:27 +0100 From: Alexander Graf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 5/7] tcg-i386: Implement deposit operation. References: <1294716228-9299-1-git-send-email-rth@twiddle.net> <1294716228-9299-6-git-send-email-rth@twiddle.net> <20110125122749.GA19736@edde.se.axis.com> <4D3EF6C1.3080502@twiddle.net> <20110125164816.GA23569@laped.lan> <4D3F4993.4010109@twiddle.net> <20110126085338.GA26088@laped.lan> <4D4042B4.4020805@twiddle.net> <4D404533.3060708@suse.de> <4D404E66.4020109@twiddle.net> <4D4050E3.9010207@suse.de> <4D40660F.9070004@twiddle.net> In-Reply-To: <4D40660F.9070004@twiddle.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: "Edgar E.Iglesias" , qemu-devel@nongnu.org, aurelien@aurel32.net Richard Henderson wrote: > On 01/26/2011 08:50 AM, Alexander Graf wrote: > >> Oh, you mean basically to have the following: >> >> TCGv_i32 regs32[16]; >> TCGv_i64 regs[16]; >> >> Then declare both as globals with offset and just switch between the >> access type using a disas struct variable. Once the TB ends, I'd >> obviously have to sync back to 64 bit again. >> > > Maybe? I don't think that regs32 can overlap with regs in the real > cpu structure. Otherwise you have the same sort of sync problems as > was originally rejected. > > I had been picturing regs32 as a member of DisasContext, and it would > hold tcg_temp_new_i32 variables as-needed. Something like > That would mean that during a TB the reg32 parts would be in temporaries, right? So they'd end up being somewhere in a register. What do I do on a page fault now? I could rerun the translator to find out which registers would be stuck in a temporary, but I have no way to actually read the temporary's value, as all register state is thrown away on a page fault IIUC. So the only alternative to this would be that I'd keep both 32 bit and 64 bit register states around in env, declare both as global, and sync them manually on access. I guess. Alex