[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