[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 #17 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #16)
> (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.

there's sorta precedent on other architectures: the x86 div and idiv
instructions that do 128 by 64-bit div/rem. also sparc has 64 by 32-bit divide
instructions.

>  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).

no, because that bigint by word division needs the high half of the numerator
to be scalar and the low half to be vector. having an implicit high half means
they have to be both scalar or both vector--unusable to do division with a
single sv.divrem2du.

> > 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+

two: divrem2du and divrem2d.

> 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 already explained that, for smaller bigints (around 8 words), big-integer
goldschmidt needs like 30x as many word operations as algorithm d. algorithm d
is necessary.

>  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.