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
prev parent 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).