qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 02/21] target-s390x: split FPU ops


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH 02/21] target-s390x: split FPU ops
Date: Tue, 4 Sep 2012 23:46:59 -0400

On 04.09.2012, at 18:03, Richard Henderson wrote:

> On 09/04/2012 12:40 PM, Blue Swirl wrote:
>> On Tue, Sep 4, 2012 at 6:42 PM, Richard Henderson <address@hidden> wrote:
>>> On 09/02/2012 10:33 AM, Blue Swirl wrote:
>>>> +/* fpu_helper.c */
>>>> +uint32_t set_cc_f32(float32 v1, float32 v2);
>>>> +uint32_t set_cc_f64(float64 v1, float64 v2);
>>>> +uint32_t set_cc_nz_f32(float32 v);
>>>> +uint32_t set_cc_nz_f64(float64 v);
>>>> +
>>> 
>>> I think that the CC handling should stay together, regardless of FPU-ness.
>>> These functions are quite small and can be usefully inlined by the compiler.
>>> 
>>> OTOH, this is much easier to do with my translate.c rewrite, so maybe I'll
>>> just take responsibility for moving them back...
>> 
>> The problem is that these are used by some FPU ops as well as
>> condition code ops. Maybe it's better to move them to cpu.h as inline
>> functions?
> 
> Maybe...
> 
>> It could be also possible to upgrade condition code functions to full
>> helpers, that could help implementing lazy condition code evaluation.
> 
> Done and ...
> 
>> I noticed that the helpers don't use TCGv registers for register
>> access but instead the helpers access env->regs[] and env->fregs[]
>> directly, this probably would need to be changed too.
> 
> done, in my rewrite.

So that means your rewrite is based on this series and just fixes it up? Does 
that mean if I apply this patch, you will be all happy?


Alex




reply via email to

[Prev in Thread] Current Thread [Next in Thread]