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. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net