From owner-freebsd-alpha Mon Mar 6 13:34:26 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from alcanet.com.au (mail.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id BD87A37BA93; Mon, 6 Mar 2000 13:34:21 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <115210>; Tue, 7 Mar 2000 08:35:08 +1100 Content-return: prohibited From: Peter Jeremy Subject: Re: alpha/17032: strtod(3) floating exception In-reply-to: <38C3791F.A2616790@inpharmatica.co.uk>; from m.seaman@inpharmatica.co.uk on Mon, Mar 06, 2000 at 08:25:45PM +1100 To: Matthew Seaman Cc: gnats-admin@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Message-Id: <00Mar7.083508est.115210@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii References: <20000306154855R.nobu@rd.isac.co.jp> <38C3791F.A2616790@inpharmatica.co.uk> Date: Tue, 7 Mar 2000 08:35:08 +1100 Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 2000-Mar-06 20:25:45 +1100, Matthew Seaman wrote: > It does this by directly twiddling with the bits in the floating >point representation of the number. On the i386 (and judging by the >NetBSD code, most other CPU's) this is fine. On the alpha it works >most of the time... Unlike every other modern CPU that I'm aware of, the Alpha does not implement IEEE754 in hardware. It implements some of it, and relies on software support (in both the compiler and the kernel) for the rest - including denormalised numbers. This is fairly messy since the Alpha architecture allows out-of-order and speculative execution as well as imprecise exceptions (meaning that there's no relationship between the address reported by the trap and the instruction causing the trap) - I don't know of any other common CPUs that do this either. It is possible that the seminumerical bit-twiddling is revealing a bug in either the hardware trap handling, or (more likely) in either the compiler or kernel FP exception handler. >I did have a go at writing a strtod(3) function from scratch without any >adjustments like that. I'd strongly recommend reading Willian D. Clinger's paper, "How to Read Floating-Point Numbers Accurately", Proceedings of the ACM SIGPLAN'90 Conference on Programming Language Design and Implementation, ftp://ftp.ccs.neu.edu/pub/people/will/howtoread.ps. (This is the paper referenced from /usr/src/lib/libc/stdlib/strtod.c). Based on a quick comparison between the NetBSD and FreeBSD strtod()'s, there _are_ some real fixes (not just whitespace changes) that NetBSD has done. It might be worthwhile going through their changes and merging some or all of them in. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message