[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: [PATCH 01/12] TCG "sync" op
From: |
Alexander Graf |
Subject: |
Re: [Qemu-devel] Re: [PATCH 01/12] TCG "sync" op |
Date: |
Wed, 18 Nov 2009 16:21:42 +0100 |
User-agent: |
Thunderbird 2.0.0.23 (X11/20090817) |
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