[Libre-soc-isa] [Bug 817] Big Integer Math (sv.adde, sv.subfe, sv.madded, 128 by 64-bit -> 64-bit div/rem, maybe more...)

[bugzilla-daemon at libre-soc.org]

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

--- Comment #16 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #14)
> Replying to:
> https://lists.libre-soc.org/pipermail/libre-soc-dev/2022-April/004772.html
> > a new 128/64 scalar divide instruction would be
> >
> >    dividend[0:(XLEN*2)-1] <- (RA) || (RS)
> >
> > where RS=RA+1 just like lq and stq.
> 
> no...it should instead be:
> divrem2du rt, ra, rb, rc

that's a no on any more VA-Form 4-operand math operations, and a hard-no
because there's no precedent to follow.  madd* etc. set the precedent
already so just barely justifies one additional instruction.

following lq/stq is sort-of-fine [i may have got the dividend the wrong
way round, (RS) || (RA) rather than (RA) || (RS).

> we'd probably also want a divrem2d for signed div/rem since that's also
> needed for faster 128-bit arithmetic (which is likely way more common than
> bigints)

again: hard no.

there does not exist a divrem scalar instruction therefore justifying
the addition of four+ instructions when the space in EXT04 is so precious
is not something i am comfortable - at all - putting in front of the
OPF ISA WG.

when there is opcode pressure like this we simply cannot just blithely
and arbitrarily propose instructions.

especially when the other options - big-integer goldschmidt - have not
been explored.  i made a start here:

https://git.libre-soc.org/?p=libreriscv.git;a=blob;f=openpower/sv/biginteger/divgnu64.c;hb=HEAD

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