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