From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1HTQWS-0007RX-TQ
	for qemu-devel@nongnu.org; Mon, 19 Mar 2007 18:40:12 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1HTQWR-0007QF-Jd
	for qemu-devel@nongnu.org; Mon, 19 Mar 2007 18:40:12 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1HTQWR-0007QC-9i
	for qemu-devel@nongnu.org; Mon, 19 Mar 2007 17:40:11 -0500
Received: from bangui.magic.fr ([195.154.194.245])
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <l_indien@magic.fr>) id 1HTQUv-0001J1-T5
	for qemu-devel@nongnu.org; Mon, 19 Mar 2007 18:38:38 -0400
Received: from [192.168.0.2] (ppp-36.net-723.magic.fr [80.118.184.36])
	by bangui.magic.fr (8.13.1/8.13.1) with ESMTP id l2JMcVma009311
	for <qemu-devel@nongnu.org>; Mon, 19 Mar 2007 23:38:31 +0100
Subject: [Fwd: Re: [Qemu-devel] [PATCH] softfloat missing functions]
From: "J. Mayer" <l_indien@magic.fr>
Content-Type: text/plain
Date: Mon, 19 Mar 2007 23:38:36 +0100
Message-Id: <1174343916.24702.26.camel@rapid>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Repost: looks like this message never reached the list....

-------- Forwarded Message --------
> From: J. Mayer <l_indien@magic.fr>
> To: Julian Seward <jseward@acm.org>
> Cc: qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] [PATCH] softfloat missing functions
> Date: Mon, 19 Mar 2007 22:10:14 +0100
> 
> On Mon, 2007-03-19 at 20:37 +0000, Julian Seward wrote:
> > > Note that float64_to_uint64 functions are not correct, as they won't
> > > return results between INT64_MAX and UINT64_MAX. Hope someone may know
> > > the proper solution for this.
> > 
> > How about this?
> 
> Yes, it seems to be the correct way, but thinking more about the
> problem, it appeared to me that the implementation could be even easier
> than yours. It seems to me that this may be sufficient:
> uint64_t float64_to_uint64 (float64 a STATUS_PARAM)
> {
>     int64_t v;
> 
>     v = llrint(a + (float64)INT64_MIN);
> 
>     return v - INT64_MIN;
> }
> uint64_t float64_to_uint64_round_to_zero (float64 a STATUS_PARAM)
> {
>     int64_t v;
> 
>     v = (int64_t)(a + (float64)INT64_MIN);
> 
>     return v - INT64_MIN;
> }
> 
> For "not-native" softfloat, this gives:
> uint64_t float64_to_uint64 (float64 a STATUS_PARAM)
> {
>     int64_t v;
> 
>     v = int64_to_float64(INT64_MIN STATUS_VAR);
>     v = float64_to_int64((a + v) STATUS_VAR);
> 
>     return v - INT64_MIN;
> }
> 
> uint64_t float64_to_uint64_round_to_zero (float64 a STATUS_PARAM)
> {
>     int64_t v;
> 
>     v = int64_to_float64(INT64_MIN STATUS_VAR);
>     v = float64_to_int64_round_to_zero((a + v) STATUS_VAR);
> 
>     return v - INT64_MIN;
> }
> 
> This should also give the correct result for NaN and overflows, if we
> rely to the fact float64_to_int64 is correct. Please tell me if I'm
> wrong !
> 
-- 
J. Mayer <l_indien@magic.fr>
Never organized