[Libre-soc-bugs] [Bug 755] add grev instruction (OP_GREV)

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Fri Dec 17 12:47:35 GMT 2021


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

Luke Kenneth Casson Leighton <lkcl at lkcl.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|add grev                    |add grev instruction
                   |                            |(OP_GREV)

--- Comment #7 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
https://git.libre-soc.org/?p=nmutil.git;a=commitdiff;h=c63d1f2b483573fae75af6688c07409b84efa7e4

i did a style rewrite, and updated the comments.  it's definitely a
butterfly network - you can see by looking at the wikipedia page
and comparing against the xbitmanip draft.  it's definitely not
an ror, that's the function before in the RVV xbitmanip document
(the previous page contains a different diagram, for ror, not
butterfly)

https://en.wikipedia.org/wiki/Butterfly_network#/media/File:Butterfly_Network.jpg
https://ftp.libre-soc.org/2021-12-17_11-17.png

* i removed tee and pairwise: "adding yet more code" means "more things to
read"
  returned the code to the style that you replaced, which uses a list for
  an accumulator, inside elaborate.

  this is perfectly fine to do because the dut is instantiated (elaborate
  called) long before the unit test begins to refer to the actual contents

  this has the advantage of removing the intermediary signals from the
  constructor, such that when someone reads the constructor to find out
  what Signals they should be connecting up, they don't go "urrr what the
  heck should i do with these"

* module docstrings != class docstrings.  module docstrings describe the
  general concept, class docstrings typically tell you "how to use the class"

  the two are radically different

* saying "see this other stuff somewhere else" entirely defeats the object
  of the exercise of comments!

  comments are for "immediate thoughts necessary to understand, right now,
  what the hell is going on, right now".  referring *elsewhere* causes
  massive confusion, frustration, and irritation for the reader.

  for example: self._steps is not obvious at all that it's an accumulator
  of everything (input, intermediary, output)... *therefore say so*,
  then comment each addition and, oh look, "the last layer is also the
  output", okaaay, that's quite obvious.

  bottom line is that you should *not* assume - at all - that the reader
  is capable of understanding the HDL (the code).  AT ALL.
  someone who has NO UNDERSTANDING of python should be able to read
  the english language "words" and go, "hmmmm, y'know: i can just about
  understand this"

  also, any "tricks" - things that break standard conventions - DEFINITELY
  need to be commented.

* i replaced the "If" with an *actual* Mux, because it replaces 4 lines
  with 1.

* the FSFE provides guidance on how to do proper copyright notices.

  Copyright (C) year, year, year, year fullname contactinfo

  it is NOT ok to put yearstart-yearend, and you MUST NOT claim
  copyright in a year that you did not ACTUALLY make any additions.

  there are plenty of examples in the code to follow here.

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


More information about the libre-soc-bugs mailing list