[libre-riscv-dev] [Bug 217] create a "ring" system which allows pad locations to be specified conveniently

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=217

--- Comment #41 from Jock Tanner <tanner.of.kha at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #40)
> (In reply to Jock Tanner from comment #39)
> looks great to me.  the docstring quality is excellent.

When I enter 3 quotes under a 'def', Pycharm creates a docstring template for
me. I only have to fill in the human-readable descriptions.

> 
> i did my usual "make myself go over the code by making
> whitespace cleanups" i find it's a good way to "review" by making my fingers
> "do" if you know what i mean.  you'll need to do a git pull, there.

I see. Your style is valid, but it eats up more space than mine (newline after
and before parentheses aka 'hanging indent'). I think hanging indent

- is better than smaller indent when it comes to cramping things up,

- has a consistent look in regard of other multiline expressions (split
strings, lists, list/dict comprehensions, et c.)

> so the next two things, i think:
> 
> 1. can you make a function which creates the BLOCKAGE "things"?
>    then call it from add() and sub().  defaults to 2,3,4 however allow
>    it to be parameterisable.

What about the existing 'get_layer()'?

> 2. add() and sub() are near-duplicates and to some extent so is alu16.
>    could you make a function which both add() and sub() call, and break
>    out pieces for alu16()?  for example, the "find and place" add and sub

I think it's doable. The code indeed is very repetitive.

I have two questions about our current setup.

1. Is it OK that we have separate adder and subtractor? I think most ALUs just
negate and add instead of subtract. I think this would use a bit less logic,
and negation in itself is also a useful operation.

2. Did we lost 'op' pin?

-- 
You are receiving this mail because:
You are on the CC list for the bug.