Re: [Qemu-arm] [Qemu-devel] [PATCH 1/2] softfloat: Enable run-time-configurable meaning of signaling NaN bit

[Eduardo Habkost]

On Mon, Apr 04, 2016 at 08:46:17PM +0100, Peter Maydell wrote:
> On 4 April 2016 at 20:42, Eduardo Habkost <address@hidden> wrote:
> > On Mon, Apr 04, 2016 at 08:38:54PM +0100, Peter Maydell wrote:
> >> On 4 April 2016 at 20:37, Eduardo Habkost <address@hidden> wrote:
> >> > On Mon, Apr 04, 2016 at 02:31:47PM +0100, Peter Maydell wrote:
> >> >> On 4 April 2016 at 14:21, Aleksandar Markovic
> >> >> <address@hidden> wrote:
> >> >> > B. arm - explicitely sets other fields of float_status,
> >> >> >       explicit invocation of set_snan_bit_is_one(0) added
> >> >>
> >> >> We zero the float_status structs on reset, because they are earlier
> >> >> in the CPUARMState structure than the 'features' field (and so the
> >> >> memset() in arm_cpu_reset() will clear them). So you don't
> >> >> need to explicitly zero a field like this. I expect the other
> >> >> architectures are the same.
> >> >
> >> > Even if it is not zeroed on reset, it is zeroed on object_new().
> >> > Isn't that enough?
> >>
> >> It must be zeroed on reset, otherwise we won't get the right
> >> behaviour if you reset the CPU after running it for a bit.
> >> object_new() zeroing is not sufficient.
> >
> > The only calls to set_snan_bit_is_one() with non-zero arguments I
> > see on this patch are during CPU init or reset. How exactly would
> > the snan_bit_is_one field change to non-zero during runtime, to
> > require zeroing it again on reset?
> 
> I meant in general for these float_status flags, not anything
> specific to this particular flag.

Sorry, I misunderstood you.

I was talking about snan_bit_is_one, specifically. My point is
that all the set_snan_bit_is_one(0, ...) calls on this patch are
not necessary because object_new() already zeroed the field.

-- 
Eduardo