[libre-riscv-dev] TLB

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
         with m.If(self.enable):
             # 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
property).

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
max_exponent??"

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.

l.



More information about the libre-riscv-dev mailing list