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

[MitchAlsup]

On Thursday, August 8, 2019 at 1:19:38 PM UTC-5, Dan Petrisko wrote:
>
> 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:
>
>
> Preface: As Andrew points out, any ISA proposal must be associated with a 
> quantitative evaluation to consider tradeoffs.
>
> A natural place for a standard reduced accuracy extension "Zfpacc" would 
> be in the reserved bits of FCSR.  
>

In my patent application concerning double precision transcendentals, I 
invented another way.

The HW is in the position to KNOW if it is potentially making an incorrect 
rounding, 
and in the My 66000 architecture, there is a exception that can be enabled 
to transfer control when the HW is about to deliver a potentially 
improperly rounded result. Should the application enable said exception, a 
rounding not KNOWN to be correct will transfer control to some SW that can 
fix the problem.
The My 66000 ISA can deliver control to the trap handler in about a dozen 
cycles (complete with register file swapping) and back in about another 
dozen cycles.
If the trap rate is less than 1% and the trap overhead to deliver a correct 
result is on the order of 300 cycles, then the user will see a 5% penalty 
in wall clock time while never seeing an incorrectly rounded result. That 
5% penalty is 1 clock when transcendentals only take 20 cycles to complete.

HW skimps in precision, SW takes over when there is potential for error, 
and the overhead is essentially negligible.

But note:: this is root claim 4 in my patent application.

Note 2:: The slower the TRAP/RETT is the better the HW needs to be to have 
negligible overhead.