Luke Kenneth Casson Leighton
lkcl at lkcl.net
Mon Apr 22 22:08:34 BST 2019
i found another piece of code that could be removed... :)
@@ -95,7 +96,7 @@ class LFSR(LFSRPolynomial):
# if enabled, shift-and-feedback
# shift up lower bits by Cat'ing in a new bit zero (feedback)
- newstate = Cat(feedback, self.state[0:self.max_exponent - 1])
+ newstate = Cat(feedback, self.state[:-1])
m.d.sync += self.state.eq(newstate)
this one: instead of having to keep a variable around, where you
measure to the end of the object: well... the object knows its length
*already*.... so just measure from the end with a negative number.
yes, slices from the *first* parameter as a negative number also work:
range(5)[-3:-1] is [2,3], where the original list was [0,1,2,3,4]
so... count *backwards* to the 3rd *from the right* for the start
and the end-of-slice is also negative, so count *backwards* from the
end to find the end as well.
this confused the crap out of me when i first saw it, that both start
*and* end could be positive *or* negative, independently. oh - and
the step (slice actually takes up to 3 arguments) can be non-zero
positive or negative as well :)
btw i also removed the width parameter, after making LFSR inherit from
LFSRPolynomial (removing more code including doing for e in self
rather than for e in self.polynomial), as it became basically an
assignment of a variable to a variable (yes, one of them's a
so i gave a hint in the docstring about that, so that people don't go
"moo? what's the width of self.state? why is it based on
yes, of course, making such a dramatic API change - *removal* of
properties - would be extremely dangerous, and in a type-safe language
would cause an entire application to fail to build.
python's rule: *run the damn test suite before committing*!
no test suite: write one!
we really need to tidy up the unit tests and add a Makefile to each
project. enough code to start initiating that, now, really.
More information about the libre-riscv-dev