Date: Wed, 30 Oct 2002 23:49:59 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: bde@zeta.org.au, rittle@labs.mot.com, rittle@latour.rsch.comm.mot.com, current@FreeBSD.ORG, dschultz@uclink.Berkeley.EDU Subject: Re: Lack of real long double support Message-ID: <3DC0E0A7.290A57CA@mindspring.com> References: <3DC06CE4.57CF2F96@mindspring.com> <20021030.170154.35505346.imp@bsdimp.com> <3DC0D732.C29B956C@mindspring.com> <20021031.001532.99559440.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"M. Warner Losh" wrote: > : > This > : > example shows that we don't support it in printf, since the above > : > example does ***NOT*** give +Inf, but rather whatever 2*DBL_MAX is. [ ... ] > Terry you are wrong. This has to do with the RANGE not the PRECISION > of the floating point number. It is ***NOT*** +Inf. I await an explanation of how you can fit 2*DBL_MAX into a double, which has a range of DBL_MIN..DBL_MAX. > You are wrong. You are confusing the precision of the mantissa with > the range of the exponent. I'm talking about the range of the double itself. When you round it, you don't jsut truncate the bits off the mantissa, you also increase the exponent. > Printf should *NOT* truncate to double before converting to print. > That's a bug too. I agree with the printf statement, but I don't see where printf is coing into the discussion. > Yes. > > : The main issue that I think is outstanding is that you can't get > : both exception behaviour and non-exception behaviour, and it is > : going to have to be the compiler's job to force the issue, because > : it can't dictate implementaiton to the host OS. > > I don't follow. I think that a number that's a 64 bit mantissa reaised to an exponent N takes a larger N if you have only 53 bits of mantissa, if you want to represent the same value. > : One problem is the initialization of the hardware (there was already > : a flags change for an initialization difference from what the compiler > : expects suggested in this thread -- to my mind, it's a workaround for > : the gcc generating header files, instead of taking the system's word > : for it). > > I don't follow. The obvious example in the FreeBSD case is the default value of the expression (fpgetprec() == FP_PE). The compiler is not permitted to assume, one way or the other; it has to do runtime testing, at the time you compile the compiler, to comply with a completely strict interpretation of C99 (IMO). It would have been nice if C99 provided a way to list the host defaults for use in compiling the compiler, since the host and the compiler have to cooperate, but there's no way to do this at run time because the standard failed to assign responsibility totally to the compiler vendor or totally to host OS. The closest possible approach will be for the compilation of the compiler to make some runtime tests to find out about the host environment. Really, it comes down to whether the host, or the compiler, owns math.h and float.h. According to my reading of C99, ownership is split between them. This kind of implies that the compiler gets to generate them however it wants, but that the host gets to dictate operation to the compiler, based on runtime tests the compiler is required to run to get the information. Since gcc supplies the crt0, it could always call fpsetprec(FP_PE); before starting to force the hardware into the compiler's preferred state. That's one answer, which makes it really hard to have a gcc and a TenDRA compiler that give the same results, if they happen to pick different defaults. The FP-using code would have to take all this into account, and be prepared to deal with all the possible allowed values. One workaround to this really ugly situation would be to define a host specific header file that's included by a host independent math.h and float.h to control its behaviour on a per-host basis, and then expect the host OS vendor to provide it, or the compiler to dig it out itself. It's better for the vendor to provide it, if the vendor wants any say in the matter at all (i.e. if the crt0 is going to call fpsetprec() to force the initial state, then why would the OS define an initial state that wasn't what the compiler wanted, so it could skip the set call?, etc.). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DC0E0A7.290A57CA>