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

[Jacob Lifshay]

On Thu, Aug 8, 2019, 02:41 lkcl <luke.leighton at gmail.com> wrote:

>
>
> On Thursday, August 8, 2019 at 7:30:38 AM UTC+1, waterman wrote:
>
>>
>> ISA-level support for correctly rounded transcendentals is speciously
>> attractive, but its utility is not clearly evident and is possibly
>> negative.
>>
>
> wait... hang on: there are now *four* potential Platforms against which
> this statement has to be verified.  are you saying that for a *UNIX*
> platform that correctly-rounded transcendentals are potentially undesirable?
>

maybe a solution would be to add an extra field to the fp control csr (or
isamux?) to allow selecting one of several accurate or fast modes:
- machine-learning-mode: fast as possible
    -- maybe need additional requirements such as monotonicity for atanh?
- GPU-mode: accurate to within a few ULP
    -- see Vulkan, OpenGL, and OpenCL specs for accuracy guidelines
- almost-accurate-mode: accurate to <1 ULP
     (would 0.51 or some other value be better?)
- fully-accurate-mode: correctly rounded in all cases
- maybe more modes?

all modes are required to produce deterministic answers (no random outputs
for the same input) only depending on the input values, the mode, and the
fp control reg.

the unsupported modes would cause a trap to allow emulation where traps are
supported. emulation of unsupported modes would be required for unix
platforms.

there would be a mechanism for user mode code to detect which modes are
emulated (csr? syscall?) (if the supervisor decides to make the emulation
visible) that would allow user code to switch to faster software
implementations if it chooses to.

Jacob Lifshay