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

[Luke Kenneth Casson Leighton]

On Saturday, July 27, 2019, Jacob Lifshay <programmerjake at gmail.com> wrote:

> On Fri, Jul 26, 2019, 13:44 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> wrote:
>
> > On Friday, July 26, 2019, Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> > wrote:
> >
> > > fantastic.  btw fp16 sqrt and fsqrt can do the full coverage trick.
> >
> >
> >
> >
> > http://git.libre-riscv.org/?p=ieee754fpu.git;a=blob;f=src/
> ieee754/fpdiv/div2.py;h=f8d98f4eeed92277b90526a4b6eb53
> 81d391aeef;hb=refs/heads/messy-div-pipe-works#l112
> >
> > Yes. In fact the whole lot should be conditional, including in div core.
> >
> i think it adds unnecessary gates here since it would have to mux in zero
> or something since it's not at a register -- it should be done right at the
> pipeline registers, not here.


SIMD.  If there are several values being processed in parallel that need to
be kept together....

If however each value has its own "muxid" bit and that muxid bit is unary,
then early out (or stage bypassing) is ok and out_do_z can go.


> >
> > Without it, the stages will wiggle intermediary gates unnecessarily.
> >
> > I'd like to try actually doing a "return m" to simplify the code and get
> > rid of one indent level.
> >
> > I did originally think that out_do_z would go entirely and be replaced by
> > early out however for SIMD that might not be a good idea. It might work
> > (SIMD elements being able to early out then wait for others to catch up).
> >
> remember that early out increases complexity (maybe additional reg file
> write ports -- not sure).



No it doesn't increase regfile ports, yes the complexity goes up, however
unary muxid (down to the element level) ensures uniqueness so it's ok. No
conflict will ever occur therefore ORing can be done on all pipe merge
paths, whether at the end or in the middle.

Likewise, the "recycling" you mentioned, 64 bit div, can also be protected
by unary muxid.

The target ALU layout after all the different features are to be added,
it's going to be a handful. Aka "A Monster".

It will need careful planning and doing in stages.

Oh, also we need zero and sign extension.

And flags for FP. Darn.

Btw do you want to tackle FCLASS? Should be real simple.
http://bugs.libre-riscv.org/show_bug.cgi?id=117 cut/paste fcvt, should be
doable in a single cycle.


> >
> > Have to see.
> >
> > Suggestion for future, the moment the ide runs autopep8, do a commit
> > immediately.
> >
> i had already changed a bunch of code at that point


Whoops : )


>
> maybe I should just auto-format everything in a separate commit.


Really it should be in the top level Makefile and run regularly.

interestingly I do find it somewhat annoying that autopep8 wraps lines >=
> 80 chars instead of > 80.


I think the line length can be overridden.




-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68