[PATCH v4 07/15] ARC: hardware floating point support

[Joseph Myers]

On Fri, 27 Mar 2020, Vineet Gupta via Libc-alpha wrote:

> > The bits to enable exception traps look like dynamic control mode bits to 
> > me.  In general fegetmode should only need to mask off bits on 
> > architectures where the same register has both control and status bits, 
> > not on architectures where those are separate registers and fegetmode / 
> > fesetmode can work with the whole control register.
> 
> Yeah, looking back into my old dev branch, that is how I did it initially, but
> then switched to current implementation to "make get/set mode functions
> inter-operate with get/set round" - although there was no inter-calling between
> the two. We can go back to that implementation as it seems slightly better in
> generated code, but I'm curious if it is wrong too....

fegetmode / fesetmode deal with the complete set of dynamic control modes, 
not just rounding modes.  I don't think any masking or shifting is needed 
or appropriate in fegetmode / fesetmode.

> Is following pseudo-code correct for semantics ?
> 
> fesetenv(env)
> 
>    if FE_DFL_ENV
>       fpcr = _FPU_DEFAULT;
>       fpsr = _FPU_FPSR_DEFAULT;
>    else
>       fpcr = envp->__fpcr;
>       fpsr = envp->__fpsr;
> 
> feupdateenv(env)
> 
>    if FE_DFL_ENV
>       fpcr = _FPU_DEFAULT;
>       fpsr = _FPU_FPSR_DEFAULT;
>    else
>       fpcr = envp->__fpcr;
>       fpsr |= envp->__fpsr;   <-- this is different

feupdateenv has to preserve the previously raised exceptions even in the 
FE_DFL_ENV case.  It's equivalent to

exc = fetestexcept (FE_ALL_EXCEPT);
fesetenv (envp);
feraiseexcept (exc);

> In some places I have following:
> 
>   if (((fpcr >> __FPU_RND_SHIFT) & FE_DOWNWARD) != round)
> 
> So FE_DOWNWARD (0x3) is used as mask, is that OK or would you rather see
> 
>   #define __FPU_RND_MASK 0x3

I think it's cleanest to have a separate define for the mask.

-- 
Joseph S. Myers
joseph@codesourcery.com