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

[bugzilla-daemon at libre-soc.org]

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

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

> It's similar but not identical because wikipedia's example does grev from
> MSB to LSB (swap 4, swap 2, swap 1) but the code I wrote goes the other way
> (swap 1, swap 2, swap 4).

yes, a full butterfly isn't described on the wikipedia page: a full butterfly
you go 1 2 4 8 16 8 4 2 1 (or 16 8 4 2 1 2 4 8 16, bizarrely it doesn't
matter which) and ta-daa you have a full (100%) non-blocking routing network
as long as you have a permutation [no attempts to route 2 pieces of data
to the same destination]. this was my 3rd year project back in 1991.

i added an option to allow 1 2 4 8 rather than 8 4 2 1 because of that.

hmmm.... is that worth actually putting in as a bit-option into the
instruction? because the process of inverting just those few bits
(esp with SVP64) is going to be a pain in the ass.  looking at
the opcode list, though, it's already quite crushed for space
https://libre-soc.org/openpower/sv/bitmanip/

although, removing ternlog entirely (leaving ternlogv in) would
free up a heck of a lot of opcode space.

btw did you see grev-or (gorc)? that got me thinking that perhaps
an operator as an option to GRev would be cool.  and also mean that
GOrc is basically "import operator; GOrc = Grev(width, operator._or)"

i have no idea if a nor or nand version of Grev would even be useful
but i like the concept and can see it may have potential.

> I never said it's an ror, I said it's *similar* to an ror, which is true. it
> uses a very similar sequence of 2:1 muxes.

i got rather confused by the xbitmanip PDF which happens to have the
ROR diagram on the exact same page as the grev c-pseudocode, and thought
"errrr" for about half an hour

> > * i removed tee and pairwise: "adding yet more code" means "more things to
> > read"
> 
> I documented exactly what pairwise does...the exact same as python's
> standard library -- it returns successive pairs of the input items. imho
> it's waay easier to understand how I had written it.

mhrhhhm... well, that's what the code-comments are for: to explain "not quite
obvious" things [in english, not actual-code].

> no it's not, you *obviously* didn't run the test (cuz you broke it). 

yes, i'm catching up, i missed several messages (don't know how) and
didn't see that a unit test now existed.  sorted now.

> Also,
> having new members that show up only after calling something other than the
> constructor is poor style and quite confusing to use imho, hence why I
> replaced it.

vs the confusion / expectation when people look at the constructor and
go "oh, i must connect this array of Signals up, what the heck to, i have
no idea", and given that it's *only* for the unit test that those are
accessible, i'd say that the "public usage" wins over any kind of
"convenience" for us as writers of a public API.

elaborate() exists precisely because it was found to be problematic
to expect a class to construct everything-it-needs within its constructor,
so leveraging that is fine.

> then, simply, they just read the docstring for _steps and see that it says
> it's an internal signal only exposed for unit tests, and they then can
> easily ignore it. that should have been *also totally obvious* because its
> name starts with an underline anyway.

again: we can't assume that.  it's quite common to access member variables
with underscores, despite being an [unenforceable] convention that attempts
to dictate otherwise.  and inherited classes often *require* access to them.
in this case, it's definitely private.

> we had previously agreed just referring to Notices.txt was sufficient, cuz
> you can put the copyright notice in there and only have to update the
> copyright years in one place.

yyeah then i saw the FSFE's video at one of the NGI POINTER mini-conferences
and was reminded that that's insufficient.  also, from a legal perspective
it's technically incorrect.  changes to one file are required *only* to
add the current year: updating copyright years in a global file makes a
legally-dubious statement, "we claim *ALL* files were modified in this
year"

also, we are getting people taking our code and trying to claim both credit
and copyright, which they can do by cherry-picking and ignoring the bland
"see this other file" at the top.

a copyright notice and creditation in every single file makes it abundantly
clear, and if they remove those then that's a clear copyright violation.
(which is the whole purpose of the exercise of having them)

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