qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 09/21] target/xtensa: add DFP option, registers and opcodes


From: Max Filippov
Subject: Re: [PATCH 09/21] target/xtensa: add DFP option, registers and opcodes
Date: Wed, 8 Jul 2020 22:14:52 -0700

On Wed, Jul 8, 2020 at 5:19 PM Richard Henderson
<richard.henderson@linaro.org> wrote:
> Do I read that right,
[...]
> means that if DFP is present, float64 has use_first_nan, but float32 does 
> not?!?

That's correct. And float64 madd.d/msub.d again don't have it.

> What in the world is going on?

My thoughts exactly. What I've found out is that at least
it wasn't meant to be like that. But also it is not specified
in any official documentation, and that I guess is one of
the reasons why it's like that. There are also no plans to
change it.

> >> E.g. the translator could remember the previous setting within the TB, only
> >> changing when necessary.  E.g. if env->config->use_first_nan, then set it
> >> during reset and never change it again.  Similarly if DFP is not enabled.
> >
> > This thought crossed my mind too, but then set_use_first_nan only
> > sets one variable in the float_status and gets inlined.
> > Is it worth the trouble?
>
> You have a point that the operation I'm trying to avoid is trivial, and
> probably not worth much.  But I had hoped that a given cpu would stick with 
> one
> method and not change it.

CPU with only a single precision FPU (either FPU2000 or DFPU)
could do it, but apparently not one with a full DFPU.
We could give full DFPU its own implementations of single precision
helpers and choose appropriate helper at translation time.
I just felt that it would neither simplify the code nor have any
performance impact.

-- 
Thanks.
-- Max



reply via email to

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