Re: RFC [libstdc++v3] target-specific cpu_limits.h

[Danny Smith <danny_r_smith_2001 at yahoo dot co dot nz>]

 --- Phil Edwards <phil@jaj.com> wrote: > On Sat, Mar 09, 2002 at
01:25:52PM +1100, Danny Smith wrote:
> > I note that files cpu-limits.h in various
> libstdc++-v3/config/cpu/*/bits/
> > dirs don't have much to say about fp environment, other than size of
> long
> > double. 
> > 
> > In local build tree I have added following file in cpu subdir as
> > libstdc++-v3/config/cpu/i386/mingw32/bits/cpu-limits.h and modified
> > configure.target accordingly. The file defines constants based on the
> > default behavior of native C-runtime (default i387 fpu mode is set at
> CRT
> > startup).   
> > 
> > My question: Is this the place to add these defines?  Can I put
> something
> > like this (after more testing and discussion with other mingw
> developers)
> > in FSF tree?
> > 
> > Here is the file:
> [snip]
> 
> 
> This looks like the right way to go about specializing these FP parts.
> The limits header is set up to pay attention to cpu-specific overrides.
> No other port currently does this, so you're breaking new ground.
> (Gaby? Sanity check?)
> 
> The filename you suggest looks wrong; are these specific to mingw or are
> the specific to the i386?

Thanks, for your feedback. 

I don't think the constants are i386-generic, but would depend on how
implementation initialises i387 unit (or emulator) at startup.  mingw calls
msvcrt.dll function _fpreset() which does much the same thing that asm
"fninit" would do (initializes the control register to 0x37f, the status
register to zero and the tag word to 0xFFFF).  By default, msvcrt sets
internal fpu precision to 64 bit (53-bit mantissa).   That is _not_ a
generic i386 behaviour.    

Representation of sNaN, qNaN, Inf constants is also implementation
dependent, as is denorm_min.  I was intending to (and have done in my local
sandpit) put these global constants and access functions in mingw C-runtime
and extract from there. If every one  could just say {return nan("sNaN");},
it  would make it easier.
 
I would not like to impose mingw fp wobblies on the rest of the i386 world,
hence my reason for putting in subdir.  I'm not even sure that other mingw
developers would agree that mimicking msvc++ behaviour on mingw is the
right thing.  

Danny

http://movies.yahoo.com.au - Yahoo! Movies
- Vote for your nominees in our online Oscars pool.