[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 5/7] target/ppc: change struct PPC_DFP decimal storage from u
From: |
Richard Henderson |
Subject: |
Re: [PATCH 5/7] target/ppc: change struct PPC_DFP decimal storage from uint64[2] to ppc_vsr_t |
Date: |
Tue, 24 Sep 2019 14:41:12 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 |
On 9/24/19 8:35 AM, Mark Cave-Ayland wrote:
> struct PPC_DFP {
> CPUPPCState *env;
> - uint64_t t64[2], a64[2], b64[2];
> + ppc_vsr_t vt, va, vb;
This I don't think is a good idea. It's not a vsr_t.
I think this step would be clearer with
union {
decimal64 d;
uint64_t i;
} u;
union {
decimal128 d;
uint64_t i[2];
} u;
in the separate dfp_prepare_decimal{64,128} functions. Which is basically what
we have before, only smooshing the a64 and b64 scratch-pads together, and using
a nice union instead of an ugly cast.
r~
- [PATCH 3/7] target/ppc: update {get, set}_dfp{64, 128}() helper functions to read/write DFP numbers correctly, (continued)
- [PATCH 4/7] target/ppc: introduce dfp_finalize_decimal{64, 128}() helper functions, Mark Cave-Ayland, 2019/09/24
- [PATCH 5/7] target/ppc: change struct PPC_DFP decimal storage from uint64[2] to ppc_vsr_t, Mark Cave-Ayland, 2019/09/24
- [PATCH 7/7] target/ppc: remove unnecessary if() around calls to set_dfp{64, 128}() in DFP macros, Mark Cave-Ayland, 2019/09/24
- Re: [PATCH 0/7] target/ppc: DFP fixes and improvements, Paul Clarke, 2019/09/24