[Libre-soc-bugs] [Bug 745] OP_TERNARY instruction

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=745

--- Comment #8 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #7)

> the benefit of using x86's name is someone who has seen the x86 instruction
> before will know exactly what it does, without having to look it up. The
> other names are worse cuz they don't indicate that the operation is
> bitwise... the log in ternlog indicates bitwise logic.

yep, like it.  ternlog (and ternlogi) it is


> there's actually 2^56 possible input values cuz 3 * 16-bit inputs + 8-bit
> lut. I decided that was too many to test all of, 

hell yes.

> so I rely on the formal proof for complete coverage 

which is what they're for.

> and just pick 100 pseudorandom cases (using
> sha256 for reproducibility) to test in the unit test.

good idea.


> > also, what is the Repl() for?
> well, the way I implemented it is by building a binary tree of output-width
> wide BitwiseMux selecting based on the inputs, where each Signal in the tree
> is output-width wide

if pmux did not exist, or was not covered in nmigen by Array(),
or if there was some massive inefficiency expected by yosys to
completely fail to create an optimal binary-fan-out mux-tree,
then it would be a good idea.

> -- the Repl is to splat each lut bit into an
> output-width wide value so the BitwiseMux tree has all the right input bits.

that can be covered by specifying a fixed width as an integer argument
for both input and output.

that results in the number of lines of code required literally reducing
down to four (4)

if someone wants Repl() externally they can do that... with another Module
or in the Module.

forcing the API to deal with a case that may - or may not - be even needed
introduces API and design complexity.

needs to go.  4 lines of code.  that's all.

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