[Libre-soc-dev] planning next OPF ISA WG RFC: ls003, biginteger?

[Jacob Lifshay]

On Mon, Oct 10, 2022 at 2:31 PM lkcl via Libre-soc-dev
<libre-soc-dev at lists.libre-soc.org> wrote:
>
> https://libre-soc.org/openpower/sv/biginteger/
>
> whilst ls002 questions and revisions are underway, my thoughts as
> to the next candidate RFC would be divmod, mulx, shfl/r. sound
> reasonable?

I'd like to *not* submit double-wide shift instructions just yet, as
part of writing the toom-cook algorithm generator I'm realizing that
as currently defined the shift instructions are quite difficult to use
as currently defined and they need some more thought/proposals. Feel
free to submit divmod2du/maddeu, though I'd like to review the RFC
before you submit it since iirc the wiki may be a bit inconsistent.

maddeu in particular may need more justification (specifically
mentioning SVP64) for why the maddhdu/maddld pair aren't sufficient.

for divmod2du, writing a scalar divmod(bigint, word) loop and
demonstrating using 1/3 as many instructions should be sufficient
justification, though they're likely to also ask why not have a pair
of instructions that don't write two outputs...

I also just realized that sv.divmod2du used for divmod(bigint, word)
can use a similar ultra-wide 320/64->256-bit divide trick (with 64-bit
remainder) as sv.maddeu does for bigint*word mul where the SIMD
backend can do a 256*64+64->320-bit mul add.

> (int fp mv needs amalgamation, i am not in any way going to
> hit the OPF ISA WG at this early stage with a whopping 20 page
> RFC with 32 instructions)

imho it's waay simpler than you're thinking and trying to mush it all
into less mnemonics just moves the inherently required complexity
somewhere else (an immediate), making it possibly harder to understand
but likely requiring the exact same amount of opcode space...that
said, I'm fine with not submitting it just yet.

Jacob