> Well, if changing fpscr and fpscr_values at the same time was your
> only concern, you could just call __set_fpscr. That puts the burden
> of preserving the SZ / PR bit in fpscr on the caller, though.
> (i.e. read the current value of fpscr, modify the bits you want changed,
> place that change
In http://gcc.gnu.org/ml/gcc/2006-05/msg00047.html, you wrote:
Ok, I'll bite. Why are there two of them?!
Well, this is the real reason why we need an API and not just a simple
builtin. GCC uses that table of values to quickly switch the FPU
modes between single and double precision. How
> > __fpscr_values[0] &= off;
> > __fpscr_values[0] |= on;
> > __fpscr_values[1] &= off;
> > __fpscr_values[1] |= on;
>
> Ok, I'll bite. Why are there two of them?!
Well, this is the real reason why we need an API and not just a simple
builtin. GCC uses that table of values to quickl
On 01 May 2006 20:55, DJ Delorie wrote:
> At this point, I would like some feedback about the API and how to
> cleanly (namespace-wise) add it to libgcc.a.
Um, I know it's a bit bikeshedcolour, and sorry about that, but wouldn't a
target-dependent builtin be a better fit to this kind of problem
I'd like to extend the FPSCR support functions in SH's libgcc.a to
include a way for applications to change the bits that GCC doesn't
care about (exception handling, denormals, etc). I've come up with
this routine and (after much head-banging) managed to test it on real
hardware. The idea is tha
