From: <dan...@ya...> - 2002-04-16 21:24:52
|
--- Earnie Boyd <ear...@ya...> wrote: > Would it be possible/feasible to override _fpreset as a wrapper to > fsetenv(FE_DFL_ENV)? Anyway, I think it's worth defaulting to 64 bit > precision. > Yes that's possible. The documentation on _fpreset is rather vague. It just says it resets the fp environment to startup default. My info comes from trial and error and dumping the structure retrned by fegetenv after calling fpreset(). I've made a few changes yesterday to startup code, fesetenv and the fp environment macros in mingwex CVS to make it bit more flexible. Have a look. It would be easy to include a 64-bit mantissa version of _fpreset in the alternative CRT_fp10.o code so that this one gets linked in whenever the startup set 64-bit PC, but the native one gets linked in otherwise. Danny > Earnie. > > Danny Smith wrote: > > > > Hi. > > > > Currently mingw set the default floating point precision at startup to > 64 > > bit (53-bit mantissa). This mean that coprocessor does its > intermediate > > calculations in 53 bits rather than the Intel x87 default of 64 bit > > mantissa. Accoding to Intel docs this affects only the instructions > ADD, > > SUB, DIV, MUL, and SQRT. For other insns, either the precision is > > determined by the opcode or extended precision (64-bit mantissa) is > used. > > > > Do we want to continue this? > > > > One problem I see with changing to extended precision (or aleast > providing > > a simple option to set the default as extended) is that any time user > code > > calls the non-ANSI MSVCRT function _fpreset(), it will reset the > precision > > back to 53-bit. Using the alternative C99 function call > > fesetenv(FE_DFL_ENV), would reset the FP environemnt to Intel default > of > > 64-bit mantissa (at least the way I've written fesetenv.c in mingwex). > > > > Having the option of extended precision would allow a real long double > type > > (Currently, GCC defines long double as 80 bits padded to 96 bits. > However, > > the long double type has the same precision as a double because of the > call > > to _fpreset() at runtime startup ). It would *not* mean that we could > > printf or scanf long doubles, because mscvrt versions of thse functions > > expect 64 bit reals. Long double math fuctions however would be > possible > > as add-ons to runtime lib. > > > > Danny > > > > http://messenger.yahoo.com.au - Yahoo! Messenger > > - A great way to communicate long-distance for FREE! > > > > _______________________________________________ > > MinGW-users mailing list > > Min...@li... > > > > You may change your MinGW Account Options or unsubscribe at: > > https://lists.sourceforge.net/lists/listinfo/mingw-users > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users http://messenger.yahoo.com.au - Yahoo! Messenger - A great way to communicate long-distance for FREE! |