[Libre-soc-dev] force pushing to nmutil.git and libreriscv.git -- everyone's write permissions temporarily removed

[Luke Kenneth Casson Leighton]

On Sun, Mar 27, 2022 at 11:30 AM Jacob Lifshay <programmerjake at gmail.com>
wrote:

>
> pushed the missing commits.


brilliant.

I'll fix CLMulAdd's test once
> https://bugs.libre-soc.org/show_bug.cgi?id=787 is fixed so we can move the
> cl* gf[bp]* reference code to nmutil rather than staying in the wiki.
>

need to think that through properly.

nmutil is intended to be a "general-purpose library for anything and
anyone",
containing useful tid-bits and small recipes that everyone would find useful
day-to-day, and stand a high probability that they'd have to reinvent them.

as such it's critically important that it not be viewed as "becoming special
purpose or tied to either libre-soc or OpenPOWER ISA".

i'm not entiiirrely sure that galois-field qualifies as "something that
engineers
would use routinely", where the pipeline code definiteiy is, and things like
the Priority-Picker and the "dynamic byte-reversing" function definitely
are.

the last thing we need - and this is why i backed out the additions - is
for the build and distribution dependencies to become inextricably
and permanently linked when they are completely inappropriate
(or, worse, recursive).

bottom line here is that the sole exclusive dependency of nmutil *has*
to be "nmigen" and absolutely nothing else.  it should be possible for
us to ask Sebastien, the nmigen Trademark Holder, to consider adding
nmutil as a top-level repo peer of nmigen and nmigen-boards etc.
and for there to be no barriers (at all) for that to happen.

if we were just adding gf2 (carry-less mul) i'd say "yes absolutely
add them" because i can see that clmul is clearly something
common (CRC).

however *as a group* my feeling is that they qualify for "new repo" status.
they're all sufficiently general that others may wish to use them.
soc is not appropriate.  ieee754fpu is not appropriate.  nmutil isn't
appropriate.

l.