qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Richard Henderson <richard.henderson@linaro.org>
To: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
	qemu-devel@nongnu.org, qemu-ppc@nongnu.org, pc@us.ibm.com,
	david@gibson.dropbear.id.au
Subject: Re: [PATCH 1/7] target/ppc: introduce get_dfp{64,128}() helper functions
Date: Tue, 24 Sep 2019 12:21:23 -0700	[thread overview]
Message-ID: <e4e2220b-d23b-aa54-2c46-c937bd0efe86@linaro.org> (raw)
In-Reply-To: <20190924153556.27575-2-mark.cave-ayland@ilande.co.uk>

On 9/24/19 8:35 AM, Mark Cave-Ayland wrote:
> +static void get_dfp64(uint64_t *dst, uint64_t *dfp)
> +{
> +    dst[0] = dfp[0];
> +}
> +
> +static void get_dfp128(uint64_t *dst, uint64_t *dfp)
> +{
> +    dst[0] = dfp[HI_IDX];
> +    dst[1] = dfp[LO_IDX];
> +}

I'm not keen on this.  I would prefer some type difference that prevents you
from getting the arguments the wrong way around.

I'm thinking that a combination helper like

static void get_dfp64(decNumber *out, uint64_t *in)
{
    union {
       uint64_t i;
       decimal64 d;
    } u;

    u.i = *in;
    decimal64ToNumber(&u.d, out);
}

> @@ -129,7 +140,7 @@ static void dfp_prepare_decimal64(struct PPC_DFP *dfp, uint64_t *a,
>      dfp->env = env;
>  
>      if (a) {
> -        dfp->a64[0] = *a;
> +        get_dfp64(dfp->a64, a);
>          decimal64ToNumber((decimal64 *)dfp->a64, &dfp->a);
>      } else {
>          dfp->a64[0] = 0;

becomes

    get_dfp64(&dfp->a, a);

and that might clean up a lot of the code.

> @@ -617,10 +626,12 @@ uint32_t helper_##op(CPUPPCState *env, uint64_t *a, uint64_t *b)         \
>  {                                                                        \
>      struct PPC_DFP dfp;                                                  \
>      unsigned k;                                                          \
> +    uint64_t a64;                                                        \
>                                                                           \
>      dfp_prepare_decimal##size(&dfp, 0, b, env);                          \
>                                                                           \
> -    k = *a & 0x3F;                                                       \
> +    get_dfp64(&a64, a);                                                  \
> +    k = a64 & 0x3F;                                                      \
>                                                                           \
>      if (unlikely(decNumberIsSpecial(&dfp.b))) {                          \
>          dfp.crbf = 1;                                                    \

Whereas cases like this, where a scalar is being passed in, I don't think that
re-using the same helper is appropriate.  Ideally, they would be passed in by
value, and not by reference at all.  That, of course, requires changes to the
translator beyond the scope of this patch.

>  void helper_dctqpq(CPUPPCState *env, uint64_t *t, uint64_t *b)
>  {
>      struct PPC_DFP dfp;
> +    uint64_t b64;
>      dfp_prepare_decimal128(&dfp, 0, 0, env);
> -    decimal64ToNumber((decimal64 *)b, &dfp.t);
> +    get_dfp64(&b64, b);
> +    decimal64ToNumber((decimal64 *)&b64, &dfp.t);

This would become

    get_dfp64(&dfp.t, b);

with no intermediate b64 temp.


r~


  reply	other threads:[~2019-09-24 19:23 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-24 15:35 [PATCH 0/7] target/ppc: DFP fixes and improvements Mark Cave-Ayland
2019-09-24 15:35 ` [PATCH 1/7] target/ppc: introduce get_dfp{64,128}() helper functions Mark Cave-Ayland
2019-09-24 19:21   ` Richard Henderson [this message]
2019-09-24 21:05     ` Mark Cave-Ayland
2019-09-24 21:29       ` Richard Henderson
2019-09-24 15:35 ` [PATCH 2/7] target/ppc: introduce set_dfp{64,128}() " Mark Cave-Ayland
2019-09-24 21:27   ` Richard Henderson
2019-09-24 15:35 ` [PATCH 3/7] target/ppc: update {get, set}_dfp{64, 128}() helper functions to read/write DFP numbers correctly Mark Cave-Ayland
2019-09-24 21:33   ` Richard Henderson
2019-09-24 15:35 ` [PATCH 4/7] target/ppc: introduce dfp_finalize_decimal{64, 128}() helper functions Mark Cave-Ayland
2019-09-24 21:47   ` Richard Henderson
2019-09-24 15:35 ` [PATCH 5/7] target/ppc: change struct PPC_DFP decimal storage from uint64[2] to ppc_vsr_t Mark Cave-Ayland
2019-09-24 21:41   ` Richard Henderson
2019-09-24 21:46   ` Richard Henderson
2019-09-24 15:35 ` [PATCH 6/7] target/ppc: use existing VsrD() macro to eliminate HI_IDX and LO_IDX from dfp_helper.c Mark Cave-Ayland
2019-09-24 21:44   ` Mark Cave-Ayland
2019-09-24 21:46   ` Richard Henderson
2019-09-25 20:37     ` Mark Cave-Ayland
2019-09-26 17:28       ` Richard Henderson
2019-09-24 15:35 ` [PATCH 7/7] target/ppc: remove unnecessary if() around calls to set_dfp{64, 128}() in DFP macros Mark Cave-Ayland
2019-09-24 21:47   ` Richard Henderson
2019-09-24 16:30 ` [PATCH 0/7] target/ppc: DFP fixes and improvements Paul Clarke
2019-09-24 16:37   ` Mark Cave-Ayland

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=e4e2220b-d23b-aa54-2c46-c937bd0efe86@linaro.org \
    --to=richard.henderson@linaro.org \
    --cc=david@gibson.dropbear.id.au \
    --cc=mark.cave-ayland@ilande.co.uk \
    --cc=pc@us.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.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).