From: Chen Gang <chengang@emindsoft.com.cn>
To: Richard Henderson <rth@twiddle.net>,
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: Fri, 11 Dec 2015 06:14:35 +0800 [thread overview]
Message-ID: <5669F94B.8060209@emindsoft.com.cn> (raw)
In-Reply-To: <5669B333.1080405@twiddle.net>
On 12/11/15 01:15, Richard Henderson wrote:
> 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?
>
I referenced set_* functions' declarations in "include/fpu/softfloat.h",
originally.
>> +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?
>
It is really only for one bit test and set, so test_bit/set_bit are
simpler and clearer than deposit/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.
>
OK.
> 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.
>
Oh, really.
> 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].
>
For me, it is a good idea! :-)
>> +static void ana_bits(float_status *fp_status,
>> + float32 fsrca, float32 fsrcb, uint64_t *sfmt)
>
> Is "ana" supposed to be short for "analyze"?
>
Yes.
>> +{
>> + 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.
>
Oh, I guess, we can inline ana_bits() to main_calc(), for they are both
simple short functions, and ana_bits() is only called by main_calc().
Thanks.
--
Chen Gang (陈刚)
Open, share, and attitude like air, water, and life which God blessed
next prev parent reply other threads:[~2015-12-10 22:11 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
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 [this message]
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=5669F94B.8060209@emindsoft.com.cn \
--to=chengang@emindsoft.com.cn \
--cc=chenwei@emindsoft.com.cn \
--cc=cmetcalf@ezchip.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.