qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paul Clarke <pc@us.ibm.com>
To: Richard Henderson <richard.henderson@linaro.org>, qemu-devel@nongnu.org
Cc: qemu-ppc@nongnu.org, david@gibson.dropbear.id.au
Subject: Re: [Qemu-devel] [PATCH v2 1/2] ppc: Add support for 'mffscrn', 'mffscrni' instructions
Date: Tue, 17 Sep 2019 16:49:52 -0500	[thread overview]
Message-ID: <2d8e94cc-71c9-c888-3816-728149539a77@us.ibm.com> (raw)
In-Reply-To: <a561c80e-68b0-bd56-2718-6c3325d27716@linaro.org>

On 9/17/19 3:45 PM, Richard Henderson wrote:
> On 9/16/19 1:02 PM, Paul A. Clarke wrote:
>> +#define FP_DRN2         (1ull << FPSCR_DRN2)
>> +#define FP_DRN1         (1ull << FPSCR_DRN1)
>> +#define FP_DRN0         (1ull << FPSCR_DRN0)
>> +#define FP_DRN          (FP_DRN2 | FP_DRN1 | FP_DRN0)
> 
> Why not just 7ull << FPSCR_DRN?
> Are the individual DRN bits separately useful?
> They don't appear to be...

I was just following what was done with RN:
#define FPSCR_RN1    1
#define FPSCR_RN0    0  /* Floating-point rounding control                   */
...
#define FP_RN1          (1ull << FPSCR_RN1)
#define FP_RN0          (1ull << FPSCR_RN0)
#define FP_RN           (FP_RN1 | FP_RN0)

>> -#define FP_MODE         FP_RN
>> +#define FP_MODE         (FP_DRN | FP_RN)
> 
> This, I think, isn't helpful.
> 
>> +static void gen_helper_mffscrn(DisasContext *ctx, TCGv_i64 t1)
>> +{
>> +    TCGv_i64 t0 = tcg_temp_new_i64();
>> +    TCGv_i32 mask = tcg_const_i32(0x0001);
>> +
>> +    gen_reset_fpstatus();
>> +    tcg_gen_extu_tl_i64(t0, cpu_fpscr);
>> +    tcg_gen_andi_i64(t0, t0, FP_MODE | FP_ENABLES);
>> +    set_fpr(rD(ctx->opcode), t0);
>> +
>> +    /* Mask FPSCR value to clear RN.  */
>> +    tcg_gen_andi_i64(t0, t0, ~FP_MODE);
> 
> Because here,
> 
>> +static void gen_mffscrn(DisasContext *ctx)
>> +{
>> +    TCGv_i64 t1;
>> +
>> +    if (unlikely(!(ctx->insns_flags2 & PPC2_ISA300))) {
>> +        return gen_mffs(ctx);
>> +    }
>> +
>> +    if (unlikely(!ctx->fpu_enabled)) {
>> +        gen_exception(ctx, POWERPC_EXCP_FPU);
>> +        return;
>> +    }
>> +
>> +    t1 = tcg_temp_new_i64();
>> +    get_fpr(t1, rB(ctx->opcode));
>> +    /* Mask FRB to get just RN.  */
>> +    tcg_gen_andi_i64(t1, t1, FP_MODE);
> 
> and here, we're only interested in RN, not DRN.

Oh, you're right, of course.

> Possibly FP_MODE should itself be removed.  It's used
> exactly once, in mffsl, which could just as easily
> reference FP_RN | FP_DRN.

I will do, and then send an updated version.

PC


      reply	other threads:[~2019-09-17 21:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-16 17:02 [Qemu-devel] [PATCH v2 1/2] ppc: Add support for 'mffscrn', 'mffscrni' instructions Paul A. Clarke
2019-09-17 20:45 ` Richard Henderson
2019-09-17 21:49   ` Paul Clarke [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=2d8e94cc-71c9-c888-3816-728149539a77@us.ibm.com \
    --to=pc@us.ibm.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@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).