From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NAmLv-0002w0-Ns for qemu-devel@nongnu.org; Wed, 18 Nov 2009 10:21:51 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NAmLq-0002tn-Lw for qemu-devel@nongnu.org; Wed, 18 Nov 2009 10:21:50 -0500 Received: from [199.232.76.173] (port=45129 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NAmLq-0002tf-AZ for qemu-devel@nongnu.org; Wed, 18 Nov 2009 10:21:46 -0500 Received: from cantor2.suse.de ([195.135.220.15]:34725 helo=mx2.suse.de) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NAmLo-0007fI-Kz for qemu-devel@nongnu.org; Wed, 18 Nov 2009 10:21:45 -0500 Message-ID: <4B041106.6090201@suse.de> Date: Wed, 18 Nov 2009 16:21:42 +0100 From: Alexander Graf MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 01/12] TCG "sync" op References: <1256133153-3121-1-git-send-email-uli@suse.de> <1256133153-3121-2-git-send-email-uli@suse.de> <20091022210317.GO1883@hall.aurel32.net> <200911110056.48147.paul@codesourcery.com> <20091117234050.GB9052@hall.aurel32.net> <8F9ADC5C-1A42-4EEF-94D5-98D466F459C6@suse.de> <20091118151258.GD9052@hall.aurel32.net> In-Reply-To: <20091118151258.GD9052@hall.aurel32.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Aurelien Jarno Cc: Paul Brook , qemu-devel@nongnu.org Aurelien Jarno wrote: > On Wed, Nov 18, 2009 at 01:01:13AM +0100, Alexander Graf wrote: > >> On 18.11.2009, at 00:40, Aurelien Jarno wrote: >> >> >>> On Wed, Nov 11, 2009 at 12:56:47AM +0000, Paul Brook wrote: >>> >>>> On Thursday 22 October 2009, Aurelien Jarno wrote: >>>> >>>>> On Wed, Oct 21, 2009 at 03:52:22PM +0200, Ulrich Hecht wrote: >>>>> >>>>>> sync allows concurrent accesses to locations in memory through >>>>>> different >>>>>> TCG variables. This comes in handy when you are emulating CPU >>>>>> registers >>>>>> that can be used as either 32 or 64 bit, as TCG doesn't know >>>>>> anything >>>>>> about aliases. See the s390x target for an example. >>>>>> >>>>>> Fixed sync_i64 build failure on 32-bit targets. >>>>>> >>>>> Looking more in details to the use case of this patch, I think it >>>>> can be >>>>> useful in QEMU. However I don't feel very comfortable in merging it >>>>> without having the opinion of more persons. Paul, Malc Blue Swirl or >>>>> others, any opinion? >>>>> >>>> I don't think this is the right solution. >>>> >>>> IIUC the basic problem is that we have a register file where >>>> adjacent pairs of >>>> 32-bit registers are also accessed as a 64-bit value. This is >>>> something many >>>> other targets need to do (at least ARM, PPC, MIPS and SPARC). >>>> >>>> While sync appears attractive as a quick hack to achieve this, I >>>> think it is >>>> liable to be abused, and cause us serious pain long-term. If you >>>> need an easy >>>> solution then use ld/st (as with ARM VFP registers). If you want a >>>> good >>>> solution then fix whichever bit of TCG makes accessing a pair of >>>> registers >>>> horribly slow. We already have some support for this >>>> (concat_i32_i64). >>>> >>>> >>> What is probably needed here are merge_low and merge_high ops, merging >>> a >>> 32-bit value into the low or high part of a 64-bit value, leaving the >>> other part unchanged. Not sure we can really optimize that on x86/ >>> x86_64 >>> compared to standard TCG code though. >>> >> Maybe I got the whole point wrong but isn't this about having 2 virtual >> register sets for the same target registers? So you'd have: >> >> TCGvar my_reg_32; >> TCGvar my_reg_64; >> >> and whenever you work with either of them you want to have the correct >> value present in both (cut off for 32bit, extended for 64 bit). >> >> So what's really necessary is some internal coupling and dirty log of >> variables within TCG so it knows that an access to the 64 bit of a >> coupled variable means it needs to sync the 32 bit value over and vice >> versa. Then magically everything would just work as expected. >> >> > > That's an option, basically keeping the list (or only one ?) of aliased > TCG variables for each of them, and freeing the others before using one. > Yeah, only one. I don't think this should be getting overengineered (and thus slow) :-). Doesn't really sound hard, does it? Any TCG magicians around? :) Alex