[libre-riscv-dev] [isa-dev] Re: FP transcendentals (trigonometry, root/exp/log) proposal
lkcl
luke.leighton at gmail.com
Thu Aug 8 13:56:43 BST 2019
On Thursday, August 8, 2019 at 8:42:57 PM UTC+8, Jacob Lifshay wrote:
> On Thu, Aug 8, 2019, 05:37 lkcl <luke.l... at gmail.com> wrote:
> On Thursday, August 8, 2019 at 7:56:15 PM UTC+8, Jacob Lifshay wrote:
>
>
>
> >
>
> > One more part: hw can implement a less accurate mode as if a more accurate mode was selected, so, for example, hw can implement all modes using hw that produces correctly-rounded results (which will be the most accurate mode defined) and just ignore the mode field since correct-rounding is not less accurate than any of the defined modes.
>
>
>
> Hmm don't know. Hendrik pointed out that Ahmdahl / IBM370 mainframe problem that extra accuracy caused.
>
> if portable results are desired, correct rounding produces the same results on all (even non-risc-v) hw, for all implementation algorithms.
>
>
> less accurate modes produce results that depend on the exact algorithm chosen, which is a choice that should be left for implementers.
Hendrik's example was that Ahmdahl hardware had correct (accurate) FP, where the IBM 370 did not.
Applications writers ran into problems when running on *more accurate* hardware. Ahmdahl had to patch the OS, with associated performance penalty, to *downgrade* the FP accuracy and to emulate IBM's *inaccurate* hardware, precisely.
What I do not know is whether there was something unique about the 370 mainframe and applications being written for it, or, if now in 2019, this is sufficiently well understood such that all FP applications writers have properly taken *better* accuracy (not worse accuracy: *better* accuracy) into consideration in the design of their programs.
Not knowing the answer to that question - not knowing if it is a risky proposition or not - tends to suggest to me that erring on the side of caution and *not* letting implementors provide more accuracy than the FP Accuracy CSR requests is the "safer" albeit more hardware-burdensome option.
Hence why I said I have no clue what the best answer is, here.
L.
More information about the libre-riscv-dev
mailing list