From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47175) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aAg1G-0000lA-Le for qemu-devel@nongnu.org; Sun, 20 Dec 2015 10:35:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aAg1C-0000Ur-LR for qemu-devel@nongnu.org; Sun, 20 Dec 2015 10:35:34 -0500 Received: from mail113-250.mail.alibaba.com ([205.204.113.250]:38487 helo=us-alimail-mta1.hst.scl.en.alidc.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aAg1B-0000UK-Vi for qemu-devel@nongnu.org; Sun, 20 Dec 2015 10:35:30 -0500 Message-ID: <5676C98C.4040101@emindsoft.com.cn> Date: Sun, 20 Dec 2015 23:30:20 +0800 From: Chen Gang MIME-Version: 1.0 References: <56698865.8050901@emindsoft.com.cn> <566988EA.109@emindsoft.com.cn> <5669B333.1080405@twiddle.net> <5669F94B.8060209@emindsoft.com.cn> In-Reply-To: <5669F94B.8060209@emindsoft.com.cn> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v3 2/4] target-tilegx: Add single floating point implementation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson , Peter Maydell , Chris Metcalf Cc: chenwei@emindsoft.com.cn, qemu-devel After tried, I guess, this way below is incorrect: float64_to_float32() assumes the input 'd' is already a standard (packed) float64 variable. But in fact, it is not (e.g. the input from floatsisf2). And we have to still check TILEGX_F_CALC_CVT, for they are really two different format: TILEGX_F_CALC_CVT has no HBIT, but TILEGX_F_CALC_NCVT has HBIT (which we need process it specially). For me, the way like helper_fdouble_pack2 (the double implementation) is OK to TILEGX_F_CALC_NCVT format, too. - Shift left to get HBIT, and change the related vexp (use vexp instead of exp to process overflow cases -- like double implementation does). - Use (u)int32_to_float32 for the mantissa. - Then process exp again. Thanks. On 12/11/15 06:14, Chen Gang wrote: >> 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! :-) > > -- Chen Gang (陈刚) Open, share, and attitude like air, water, and life which God blessed