qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 01/10] target-arm: Make Neon helper routines use


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH 01/10] target-arm: Make Neon helper routines use correct FP status
Date: Sun, 3 Apr 2011 12:41:58 +0300

On Sat, Apr 2, 2011 at 1:33 AM, Peter Maydell <address@hidden> wrote:
> On 1 April 2011 19:29, Blue Swirl <address@hidden> wrote:
>> On Fri, Apr 1, 2011 at 5:30 PM, Peter Maydell <address@hidden> wrote:
>>> Make the Neon helper routines use the correct FP status from
>>> the CPUEnv rather than using a dummy static one. This means
>>> they will correctly handle denormals and NaNs and will set
>>> FPSCR exception bits properly.
>
>> I didn't check, but if neon_helper.c is compiled like op_helper.c,
>> passing env should not be needed.
>
> It isn't; see the comments when this patch was first posted.
>
>> If that is not the case, the
>> functions could be moved to op_helper.c.
>
> Nobody seemed to have a coherent rule about when functions
> should be in op_helper.c and use the global 'env' variable
> and when they should be in some other file and have 'env'
> passed as a parameter (or indeed why only op_helper.c
> should be special in this way). Currently the ARM target has
> both kinds of helper function. So I took the straightforward
> approach of not moving code around wholesale, and just
> passed in the env pointer, consistent with the way we already
> handle most functions that talk to softfloat.

In general, helpers for the translated code belong to op_helper.c.
They can and should access global env directly for speed. If a helper
is used for both translated code and outside of it, a wrapper should
be added to do global env shuffling (or for example a copy without
shuffling added).



reply via email to

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