[libre-riscv-dev] [Bug 44] IEEE754 FPU inverse-sqrt

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=44

--- Comment #33 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #32)
> (In reply to Jacob Lifshay from comment #31)
> > If no one else is working on it, I'll start working on implementing the
> > div/mod/fdiv/fsqrt/frsqrt pipeline.
> 
> keep it short, keep in touch continously (every few days), and use .pyi
> files,
> do *not* put type information into the .py files, and for FP, follow the
> format of the pipeline code rather than create an entirely new pipeline
> design
> (use FPMUL and FPADD as cookie-cut templates).  otherwise we waste time
> and money reworking two sets of completely disparate code.
I was planning on creating an arithmetic pipeline similar to the multiplier in
that operations just travel in a simple manner from start to finish and we can
add on all the pipeline control circuitry externally (since we still haven't
fully resolved how pipeline control will work).

> also keep the integer and FP pipelines *separate* for now: the FPU code
> is seriously complicated already, and in actual usage, int would hold up FP
> and FP would hold up int.
Actually, the fpdiv uses an integer div+mod internally, so having separate fp
and integer pipelines here actually makes it more complicated. The only int
operation supported is div+mod.

> i'm looking to put in another funding application to cover a "comprehensive"
> version of the isqrt/fsqrt/fdiv code, including formal verification, for
> which programmer-mathematicians could be attracted to help out.
I'm planning on implementing the algorithms such that they create an exact
result at all times, the binary result and a remainder (or the equivalent for
sqrt/rsqrt). those can then be converted to the mantissa and guard/round/sticky
bits and relatively simply proven to be correct for all inputs.
> 
> that means keeping the timescales on FPDIV/ISQRT/SQRT *real* short.
Since the algorithms are relatively simple, I'm expecting the fixed-point core
to be done in 1-2 days and then the FP
unpacking/normalization/special-case-handling can be added on the front and
back.

-- 
You are receiving this mail because:
You are on the CC list for the bug.