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@xxxxxxxxxxxxxxxx _______________________________________________ linux-snps-arc mailing list linux-snps-arc@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-snps-arc
