openrisc.lists.librecores.org archive mirror
 help / color / mirror / Atom feed
From: Stafford Horne <shorne@gmail.com>
To: Richard Henderson <richard.henderson@linaro.org>
Cc: QEMU Development <qemu-devel@nongnu.org>,
	Linux OpenRISC <linux-openrisc@vger.kernel.org>
Subject: Re: [PATCH 3/3] target/openrisc: Setup FPU for detecting tininess before rounding
Date: Wed, 3 May 2023 17:31:05 +0100	[thread overview]
Message-ID: <ZFKMSfkJupFHXtrl@antec> (raw)
In-Reply-To: <e3fabb1d-7bf6-f251-9649-5a813b409200@linaro.org>

On Wed, May 03, 2023 at 10:41:42AM +0100, Richard Henderson wrote:
> On 5/3/23 10:14, Stafford Horne wrote:
> > > > +    set_default_nan_mode(1, &cpu->env.fp_status);
> > > > +    set_float_detect_tininess(float_tininess_before_rounding,
> > > > +                              &cpu->env.fp_status);
> > > 
> > > You don't mention the nan change in the commit message.
> > 
> > Right, and I am not sure I need it.  Let me remove it and run tests again.  I
> > was just adding it as a few other architectures did who set
> > float_tininess_before_rounding.
> 
> What that does is *not* propagate NaN payloads from (some) input to the
> output.  This is certainly true of RISC-V, which specifies this in their
> architecture manual.  OpenRISC does not specify any NaN behaviour at all.

Thanks, that is what I also gathered from reading up on it.

> It's not a bad choice, really, and it almost certainly simplifies the design
> of the FPU, as you can do NaN propagation and silencing in one step.

Right, it makes sense to optimize.  It doesn't look like any of our FPU
implementation do that at the moment.

I will check with bandvig who implemented the FPU to understand his thought on
this.  It at least deserves to be discussed how nan payload is to be handled in
the architecture spec.

-Stafford

      reply	other threads:[~2023-05-03 16:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-02 18:57 [PATCH 0/3] OpenRISC updates for user space FPU Stafford Horne
2023-05-02 18:57 ` [PATCH 1/3] target/openrisc: Allow fpcsr access in user mode Stafford Horne
2023-05-03  6:29   ` Stafford Horne
2023-05-02 18:57 ` [PATCH 2/3] target/openrisc: Set PC to cpu state on FPU exception Stafford Horne
2023-05-03  7:36   ` Richard Henderson
2023-05-03  9:12     ` Stafford Horne
2023-05-02 18:57 ` [PATCH 3/3] target/openrisc: Setup FPU for detecting tininess before rounding Stafford Horne
2023-05-03  7:37   ` Richard Henderson
2023-05-03  9:14     ` Stafford Horne
2023-05-03  9:41       ` Richard Henderson
2023-05-03 16:31         ` Stafford Horne [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZFKMSfkJupFHXtrl@antec \
    --to=shorne@gmail.com \
    --cc=linux-openrisc@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).