On 9/24/19 8:35 AM, Mark Cave-Ayland wrote:
> The existing functions (now incorrectly) assume that the MSB and LSB of DFP
> numbers are stored as consecutive 64-bit words in memory. Instead of accessing
> the DFP numbers directly, introduce set_dfp{64,128}() helper functions to ease
> the switch to the correct representation.
>
> Signed-off-by: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk>
> ---
> target/ppc/dfp_helper.c | 90 ++++++++++++++++++++++-------------------
> 1 file changed, 48 insertions(+), 42 deletions(-)
>
> diff --git a/target/ppc/dfp_helper.c b/target/ppc/dfp_helper.c
> index 354a4aa877..cb98780d20 100644
> --- a/target/ppc/dfp_helper.c
> +++ b/target/ppc/dfp_helper.c
> @@ -47,6 +47,17 @@ static void get_dfp128(uint64_t *dst, uint64_t *dfp)
> dst[1] = dfp[LO_IDX];
> }
>
> +static void set_dfp64(uint64_t *dfp, uint64_t *src)
> +{
> + dfp[0] = src[0];
> +}
> +
> +static void set_dfp128(uint64_t *dfp, uint64_t *src)
> +{
> + dfp[0] = src[HI_IDX];
> + dfp[1] = src[LO_IDX];
> +}
...
> decimal##size##FromNumber((decimal##size *)dfp.t64, &dfp.t,
> &dfp.context);\
> postprocs(&dfp); \
> if (size == 64) { \
> - t[0] = dfp.t64[0]; \
> + set_dfp64(t, dfp.t64); \
> } else if (size == 128) { \
> - t[0] = dfp.t64[HI_IDX]; \
> - t[1] = dfp.t64[LO_IDX]; \
> + set_dfp128(t, dfp.t64); \
> }
This is perhaps a bit harder to see than the get case, because POSTPROCS is in
the way.
However, we can guess, because postprocs has not been passed GETPC(), that it
cannot longjmp out, and therefore not interfere with writing back of the result
to the register file. And, as it turns out from inspection, the set of
postprocs also does not modify dfp->t64; only looks at dfp->context.status.
Therefore, as a first step we can move postprocs down, then as a second step
combine the conversion from decNumber (dfp->t) to decimal128, and then into the
register file (t).
r~
