[libre-riscv-dev] div/mod algorithm written in python
programmerjake at gmail.com
Thu Jul 25 16:09:59 BST 2019
On Thu, Jul 25, 2019, 07:45 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> On Thu, Jul 25, 2019 at 2:13 PM Jacob Lifshay <programmerjake at gmail.com>
> > I got everything working!
> > 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
> > 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
> > 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.
> # 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.
> > 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".
> > 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:
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
More information about the libre-riscv-dev