Re: [Qemu-devel] Re: [PATCH 01/12] TCG "sync" op

[Alexander Graf <agraf@suse.de>]

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.

Or am I totally wrong here?

Alex