[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:18:08 GMT 2022
https://bugs.libre-soc.org/show_bug.cgi?id=782
--- Comment #61 from Jacob Lifshay <programmerjake at gmail.com> ---
(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:
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).
# was gfpmsub
gfpmsubf RT, RA, RB # overwrites factor
(RT) = int_to_gfp((RT) * (RA) - (RB), GFPRIME)
gfpmsubt RT, RA, RB # overwrites term
(RT) = int_to_gfp((RA) * (RB) - (RT), GFPRIME)
# was gfpmsubr
gfpmsubrf RT, RA, RB # overwrites factor
(RT) = int_to_gfp((RB) - (RT) * (RA), GFPRIME)
gfpmsubrt RT, RA, RB # overwrites term
(RT) = int_to_gfp((RT) - (RA) * (RB), GFPRIME)
>
> another option, the entirety of gf* and cl* moves to its own major opcode.
>
> (In reply to Jacob Lifshay from comment #59)
>
> > The encodings still need to be decided, should I let you (lkcl) figure that
> > out, or should I figure them out myself?
>
> best let me do it (tomorrow) because i know the "rules" i applied to them
> and have the working-set in my head
>
> yes go for it on the pseudocode, do move the clmul(rh) ones to the
> (existing) carryless section,
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.
> 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.
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-soc-bugs
mailing list