[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