From: Richard Henderson <rth@twiddle.net>
To: Chen Gang <chengang@emindsoft.com.cn>,
Peter Maydell <peter.maydell@linaro.org>,
Chris Metcalf <cmetcalf@ezchip.com>
Cc: chenwei@emindsoft.com.cn, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH v3 2/4] target-tilegx: Add single floating point implementation
Date: Thu, 10 Dec 2015 09:15:31 -0800 [thread overview]
Message-ID: <5669B333.1080405@twiddle.net> (raw)
In-Reply-To: <566988EA.109@emindsoft.com.cn>
On 12/10/2015 06:15 AM, Chen Gang wrote:
> +#define TILEGX_F_CALC_CVT 0 /* convert int to fsingle */
> +#define TILEGX_F_CALC_NCVT 1 /* Not convertion */
> +
> +static uint32_t get_f32_exp(float32 f)
> +{
> + return extract32(float32_val(f), 23, 8);
> +}
> +
> +static void set_f32_exp(float32 *f, uint32_t exp)
> +{
> + *f = make_float32(deposit32(float32_val(*f), 23, 8, exp));
> +}
Why take a pointer instead of returning the new value?
> +static inline uint32_t get_fsingle_sign(uint64_t n)
> +{
> + return test_bit(10, &n);
> +}
> +
> +static inline void set_fsingle_sign(uint64_t *n)
> +{
> + set_bit(10, n);
> +}
Why are you using test_bit and set_bit here, rather than continuing to use
deposit and extract?
> +static float32 sfmt_to_float32(uint64_t sfmt, float_status *fp_status)
> +{
> + float32 f;
> + uint32_t sign = get_fsingle_sign(sfmt);
> + uint32_t man = get_fsingle_man(sfmt);
> +
> + if (get_fsingle_calc(sfmt) == TILEGX_F_CALC_CVT) {
> + if (sign) {
> + return int32_to_float32(0 - man, fp_status);
> + } else {
> + return uint32_to_float32(man, fp_status);
> + }
> + } else {
> + f = float32_set_sign(float32_zero, sign);
> + f |= create_f32_man(man >> 8);
> + set_f32_exp(&f, get_fsingle_exp(sfmt));
> + }
I'm not especially keen on this calc bit. I'd much rather that we always pack
and round properly.
In particular, if gcc decided to optimize fractional fixed-point types, it
would do something very similar to the current floatsisf2 code sequence, except
that it wouldn't use 0x9e as the exponent; it would use something smaller, so
that some number of low bits of the mantessa would be below the radix point.
Therefore, I think that fsingle_pack2 should do the following: Take the
(sign,exp,man) tuple and slot them into a double -- recall that a single only
has 23 bits in its mantessa, and this temp format has 32 -- then convert the
double to a single. Pre-rounded single results from fsingle_* will be
unchanged, while integer data that gcc has constructed will be properly rounded.
E.g.
uint32_t sign = get_fsingle_sign(sfmt);
uint32_t exp = get_fsingle_exp(sfmt);
uint32_t man = get_fsingle_man(sfmt);
uint64_t d;
/* Adjust the exponent for double precision, preserving Inf/NaN. */
if (exp == 0xff) {
exp = 0x7ff;
} else {
exp += 1023 - 127;
}
d = (uint64_t)sign << 63;
d = deposit64(d, 53, 11, exp);
d = deposit64(d, 21, 32, man);
return float64_to_float32(d, fp_status);
Note that this does require float32_to_sfmt to store the mantissa
left-justified. That is, not in bits [54-32] as you're doing now, but in bits
[63-41].
> +static void ana_bits(float_status *fp_status,
> + float32 fsrca, float32 fsrcb, uint64_t *sfmt)
Is "ana" supposed to be short for "analyze"?
> +{
> + if (float32_eq(fsrca, fsrcb, fp_status)) {
> + *sfmt |= create_fsfd_flag_eq();
> + } else {
> + *sfmt |= create_fsfd_flag_ne();
> + }
> +
> + if (float32_lt(fsrca, fsrcb, fp_status)) {
> + *sfmt |= create_fsfd_flag_lt();
> + }
> + if (float32_le(fsrca, fsrcb, fp_status)) {
> + *sfmt |= create_fsfd_flag_le();
> + }
> +
> + if (float32_lt(fsrcb, fsrca, fp_status)) {
> + *sfmt |= create_fsfd_flag_gt();
> + }
> + if (float32_le(fsrcb, fsrca, fp_status)) {
> + *sfmt |= create_fsfd_flag_ge();
> + }
> +
> + if (float32_unordered(fsrca, fsrcb, fp_status)) {
> + *sfmt |= create_fsfd_flag_un();
> + }
> +}
Again, I think it's better to return the new sfmt value than modify a pointer.
r~
next prev parent reply other threads:[~2015-12-10 17:15 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <56698865.8050901@emindsoft.com.cn>
2015-12-10 14:13 ` [Qemu-devel] [PATCH v3 1/4] target-tilegx: Add floating point shared functions Chen Gang
2015-12-10 14:15 ` [Qemu-devel] [PATCH v3 2/4] target-tilegx: Add single floating point implementation Chen Gang
2015-12-10 17:15 ` Richard Henderson [this message]
2015-12-10 20:18 ` Richard Henderson
2015-12-10 22:15 ` Chen Gang
2015-12-22 22:29 ` Chen Gang
2015-12-10 22:14 ` Chen Gang
2015-12-20 15:30 ` Chen Gang
2015-12-21 15:01 ` Richard Henderson
2015-12-21 18:54 ` Chen Gang
2015-12-22 2:00 ` Richard Henderson
2015-12-10 14:15 ` [Qemu-devel] [PATCH v3 3/4] target-tilegx: Add double " Chen Gang
2015-12-10 21:17 ` Richard Henderson
2015-12-11 23:38 ` Chen Gang
2015-12-12 0:41 ` Richard Henderson
2015-12-12 2:45 ` Chen Gang
2015-12-10 14:16 ` [Qemu-devel] [PATCH v3 4/4] target-tilegx: Integrate floating pointer implementation Chen Gang
2015-12-10 21:37 ` Richard Henderson
2015-12-10 21:44 ` Chen Gang
2015-12-10 14:26 ` [Qemu-devel] [PATCH v3 0/4] target-tilegx: Implement floating point instructions Chen Gang
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=5669B333.1080405@twiddle.net \
--to=rth@twiddle.net \
--cc=chengang@emindsoft.com.cn \
--cc=chenwei@emindsoft.com.cn \
--cc=cmetcalf@ezchip.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@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).