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

Luke Kenneth Casson Leighton lkcl at lkcl.net
Wed Jul 3 07:58:30 BST 2019


On Wed, Jul 3, 2019 at 7:14 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> On Tue, Jul 2, 2019 at 10:54 PM Luke Kenneth Casson Leighton
> <lkcl at lkcl.net> wrote:
> >
> > On Wed, Jul 3, 2019 at 5:52 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
> >
> > > I implemented FixedSqrt and FixedRSqrt and they pass all tests.
> >
> >  great.  btw, do try to avoid using functions with the word "test" in
> > them unless they're an actual unit test (shorten to tst or something)
> > - nosetests3 .../test_xxx.py throws several errors.
> Pushed a fix.
>
> I would consider it a bug in nosetests3, since python's built-in
> unittest module only uses functions that match the regex "^test.*" (or
> so I would assume from it's behavior).
>
> > >  I
> > > think I'll create a combined class that can compute all of
> > > div/rem/fixed-sqrt/fixed-rsqrt before converting to nmigen since
> > > python is easier to read/write than nmigen.
> >
> >  sigh indeed.  not sure if there's much that can be done about that,
> > although i have started doing this at the top of functions:
> >  comb = m.d.comb
> >  sync = m.d.sync
> >
> >  it reduces indentation by 4 and allows things to fit onto one line in
> > many cases.
> For me, I've mostly given up on fitting things on one line, and am
> using bigger names that don't need to be unabbreviated extensively
> before it's understandable.

 be careful with that: a 200 or 400-line function that results from
necessary vertical alignment is a "no" because it requires constant
page-up, page-down, page-up, page-down, page-up, page-down every
second just to read all of it.

 particularly when it comes to adding in explanatory comments as well.

 if you can split the code into sub-functions that would help keep
"relevant sections" onto a single page (where practical).

 the functions can return nmigen-fragments, that's not a problem: they
don't have to be made local (or class) variables.

> For the final algorithm, I'm trying to
> make it relatively easy to see how it matches up with the
> next-less-complex version, even if it's too complex to readily
> understand without the next-less-complex version as a reference.

 :)



More information about the libre-riscv-dev mailing list