[libre-riscv-dev] div/mod algorithm written in python

[Jacob Lifshay]

On Thu, Jul 25, 2019, 07:45 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Thu, Jul 25, 2019 at 2:13 PM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
> >
> > I got everything working!
>
>  faantastic!
>
> > I disabled the frsqrt test for fp64 since we
> > don't have a proper reference implementation yet.
>
> well with the others working, how about a test that at least gets within 2
> bits?
>
> > fp32 and fp16 seem
> > to work well enough for now by emulating using fp64 arithmetic, but
> > it's NOT GUARANTEED TO WORK.
>
>  yehyeh, i got it - i thought about doing that, and how if there was
> fp128 it could be used for all of them.  hmm...
>
I built about half of a quadratic numbers (numbers of form (a+sqrt(b))/c
where a,b,c are integers) implementation in Rust, decided full general
algebraic numbers are too complicated to implement now. once that's done,
since it represents the results of add/sub/mul/div/sqrt/rsqrt exactly, we
can use it to implement all those fp ops with all the rounding modes pretty
trivially. will be building rust to python bindings for the quadratic
numbers lib.

>
> > it was a single giant messy commit, so I pushed to the
> > messy-div-pipe-works branch instead of master.
> > I'll split it up properly tomorrow.
>
>  awesome.
>
>              # create (in each pipe) a StageChain n_comb_stages in length
>              pipechain.append(kls(self.pspec, n_comb_stages, stage_idx))
> -            stage_idx += n_comb_stages  # increment so that each CalcStage
> -            # gets a (correct) unique index
> +            stage_idx += n_comb_stages # increment so that each CalcStage
> +                                       # gets a (correct) unique index
>
> you ran autopep8, didn't you? :)  i like lining up comments, however
> it's not pep8-compliant.
>
i did -- it's on by default for the ide i'm using.

>
> couple of spaces have been added (on the end of lines), like the
> addition of the names (pain in the neck having z$0 z$1 z$2),
>
> > Would you consider this good enough to declare the frsqrt, fsqrt, and
> > fdiv bugs resolved for now?
>
>  once the unit tests have been re-run (minimum 20,000 random runs,
> increase n_vals=1000 on the "coverage" tests), yes.  i can run some of
> them, if you do others.
>
i'll set it up to run them while I sleep, probably 100k. one of the tests
failed due to a bad import path when using pytest.

the coverage tests need to be split up into separate top-level test
functions since that's the level that the tests are parallelised by
pytest-xdist (see test_core.py for examples). they run several times as
long as the others and only use a few of my 12 hw threads to do that.

>
>
> > I still want to build in SIMD capabilities
>
>  absolutely counting on that - as separate bugreports.
> http://bugs.libre-riscv.org/show_bug.cgi?id=115
>
> > like the multiplier and
> > support fp64 operations by running them through the pipeline twice.
>
>  yehyeh that'd be really good - have to think how it can be done in a
> way that does *not* require 2 separate micro-ops.  a hardware
> feedback-er.  that way the ReservationStation stays "reserved".
>
>  http://bugs.libre-riscv.org/show_bug.cgi?id=114
>
> > Also, integer division is not implemented yet.
>
>  (to go under http://bugs.libre-riscv.org/show_bug.cgi?id=116)
>
>  yes.  this one will be fun - being able to set the op to FP or INT
> and bypass the FP normalisation and post-processing.  that's this one:
> http://bugs.libre-riscv.org/show_bug.cgi?id=106
>
> l.
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>