[libre-riscv-dev] [isa-dev] Re: FP transcendentals (trigonometry, root/exp/log) proposal

[lkcl]

On Thursday, August 8, 2019 at 7:47:38 PM UTC+8, Jacob Lifshay wrote:

> are you suggesting that implementors be permitted to *dynamically* alter the accuracy of the results that their hardware produces, in order to comply with *more than one* of the [four so far] proposed Platform Specs, *at runtime*?
> yes.

Ok. I like it.  It's kinda only sonething that hybrid CPU/GPU combinations would want, however the level of interest that Pixilica got at SIGGRAPH 2019 in their hybrid CPU/GPU concept says to me that this is on the right track.

Also a dynamic switch stops any fighting over whether one Platform Spec should get priority preference to the exclusion of others.

Will update the page shortly.

> 
> also, having explicit mode bits allows emulating more accurate operations when the HW doesn't actually implement the extra gates needed.

Oh, yes, good point, however it would only be mandatory for UNIX* Platforms to provide such traps.

> This allows greater software portability (allows converting a libm call into a single instruction without requiring hw that implements the required accuracy).

and associated performance penalties of doing so (extra conditional tests) if the trap isn't there. The conditional tests which substitute for a lack of a trap adversely impact performance for *both* modes.

> 
> I do think that there should be an exact-rounding mode even if the UNIX platform doesn't require that much accuracy, otherwise, HPC implementations (or others who need exact rounding) will run into the same dilemma of needing more instruction encodings again.

Hmm hmm.... well, you know what? If it's behind a CSR Mode flag, and traps activate on unsupported modes, I see no reason why there should not be an extra accuracy mode.

L.