[Libre-soc-bugs] [Bug 782] add galois field bitmanip instructions

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Thu Mar 10 03:48:51 GMT 2022


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

--- Comment #63 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #61)
> (In reply to Luke Kenneth Casson Leighton from comment #60)
> > (In reply to Jacob Lifshay from comment #58)
> > > I added all the proposed ops to the wiki, I still need to add pseudo-code
> > > for several of them.
> > 
> > -# Galois Field 2^M
> > +# Instructions for Carry-less Operations aka. Polynomials with coefficients
> > in `GF(2)`
> > 
> > clmul(rh) were already added.
> > 
> > prime-polynomial ones there's not enough room unless moving ternary
> > to another major opcode (sigh), the ??madd ones take up vast amounts
> > of space.
> 
> we could change the madd ops to be 3-arg rather than 4:

i already explained clearly and non-negotiably the damaging
consequences and cost of that.

> if we did that, we'd want to have additional separate variants that allow
> you to overwrite the term input rather than a factor input (inspired by
> x86's fma ops).

which in turn would require a rewrite of SV REMAP to match it
and it took about 10 weeks to write.

i am puzzled that you do not remember this, it was only about 3
days ago.

matching the exact form (assembly, reg names) is an absolute
highest inviolate top priority over everything else.

except for the poly SPR which allows gf ops to match int arith


> I intentionally started new sections, because i think the grouping/ordering
> makes more sense. I didn't delete the old sections yet cuz I figured we
> wanted to keep whatever info was there for reference until the new sections
> explain everything.

makes sense, do mark them as such tho


> > yes drop pseudocode in, if it's missing.
> 
> I'm likely to also edit the existing/new pseudo-code to change naming and
> stuff to make it consistent with the instructions.

yep go for it. drop into gf.py to test them as well. gf.py should become
an easy to use/read reference, sandbox for other people,
and basis of tests (eventually)

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


More information about the libre-soc-bugs mailing list