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

[MitchAlsup]

On Sunday, September 15, 2019 at 7:35:56 PM UTC-5, lkcl wrote:
>
> On Monday, September 16, 2019 at 5:51:20 AM UTC+8, Jacob Lifshay wrote:
>
> > 
> > 
> > All of the above isn't really necessary for GPU applications, since they 
> never tried to achieve correct-rounding in the first place, however it is 
> definitely needed on Unix platforms, since those generally try for 
> correctly-rounded operations and users often assume the operations are 
> reproducible.
>
> This really is the key differentiator between the current GPU world and 
> what we are doing here with the Libre RISCV SoC: sitting squarely in *both* 
> worlds and being performance, power and price competitive *in* both worlds.
>
> I like the idea that you suggested, Mitch, and if we were doing a pure GPU 
> only, I would go for it 100%.
>
> The problem with changing the accuracy on a per op basis (which would be 
> fine on a GPU) is as Jacob points out: it would not meet IEEE754.
>

There is one way around this that I did invent::
Consider a set of instructions that for a "very vast majority" of input 
operands deliver results completely compatible with IEEE 754-2008.
For those results that are not, we are at most off by a rounding (otherwise 
the very vast majority could not have been correct.)
Since these are only different by a rounding (conforming to the word 
"Faithful" rounding), we can detect those pre-rounded results that could 
potentially be misrounded, and instead of delivering an incorrect IEEE 
754-2008 but a faithfully rounded result, instead we raise an UNCERTAIN 
exception (that is an exception not currently in anyone's exception list) , 
and let a long winded, known to be correct, hunk of SW produce the IEEE 
754-2008 compliant result.
 

> That in turn would relegate this initiative to being a perfect candidate 
> for a CUSTOM extension, and the conversation on isa-dev ends there.
>
> We are not proposing a custom extension.
>
> We are proposing a transcendental extension for use in *all* of HPC, 
> Embedded, 3D Hybrid *and* 3D Embedded worlds (all without *any* 
> Vectorisation being a mandatory prerequisite for any of the same) where 
> full integration into GNU libm, python-numpy, GNU gcc and LLVM is not only 
> desirable it is welcomed and encouraged to br upstream right across the 
> board for the benefit of the *entire* RISCV Community.
>
> And, in turn, I anticipate that hardware vendors come forward and begin to 
> help with that effort for their own commercial benefit and financial gain, 
> such that no one single vendor including ourselves has to shoulder the cost 
> of that development and ongoing maintenance.
>
> As a *custom* extension none of those benefits which exist through 
> collaboration on such a shared goal would be available to either ourselves 
> or to anyone else.
>
> The key words there being "shared goal".
>
> Thus we *define* the requirements strictly to meet the potential *to* 
> share, and thus by direct implication:
>
> * being a custom extension is not an option and is never going to be an 
> option
> * meeting IEEE754 is mandatory AND
> * meeting OpenCL and Vulkan minimum requirements is mandatory AND
> * having the runtime option to choose between the two is clearly necessary 
> AND
> * having separate opcodes for deaccurified versions is an option but puts 
> pressure on the opcode space hence Zfpacc as an alternative (neat) solution.
>
> L.
>
>
>