[libre-riscv-dev] [isa-dev] Re: FP transcendentals (trigonometry, root/exp/log) proposal
MitchAlsup at aol.com
Thu Aug 8 21:15:32 BST 2019
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
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
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
More information about the libre-riscv-dev