[libre-riscv-dev] [isa-dev] FP reciprocal sqrt extension proposal

[Dan Petrisko]

>
> Dan, I'm not talking about the original sqrt, i'm talking about rsqrt
> (reciprocal).
>

Yes, I understand.  My assumption was that there would be similar
motivations for have a single operand since the instructions are similar.

However, if it is treated as separate
> sqrt followed by divide, you can get a/sqrt(b) without doing the extra
> 1/sqrt(a) lookup table.
>

This is interesting, though. I'm not solid on FPU implementations, so
forgive my ignorance for the following:

1/sqrt(a) has been done as single-operand because it's an easy,
> independent table-lookup operation, followed by iteration to get the
> desired precision. it converges nicely.


Is this a hardware implementation you're describing or an FP software
emulation library? If it's the former, then it doesn't sound like a/sqrt(b)
is easily implementable.  If it ends up being a LUT * a in hardware anyway,
we haven't saved much.

Best,
Dan Petrisko


On Thu, Jul 11, 2019 at 5:20 PM Guy Lemieux <glemieux at vectorblox.com> wrote:

> Just because "that's the way it's always been done" is not a good
> reason to justify its continuance.
>
> 1/sqrt(a) has been done as single-operand because it's an easy,
> independent table-lookup operation, followed by iteration to get the
> desired precision. it converges nicely.
>
> however, in real software, the function 1/sqrt(a) almost never stands
> alone. it is used for normalization, so it is almost always followed
> by a multiplication, ie a/sqrt(b), or preceeded by an addition, ie
> 1/sqrt(a+b).
>
> saying it is "subjected to rounding twice" isn't really fair. if done
> as separate operations, it is subjected to rounding twice.  when done
> as an atomic operation, you can arrange extended precision and round
> only once.
>
> sorry, i'm not trying to overly advocate for this, just trying to
> encourage that we keep an open mind.
>
> guy
>
>
> On Thu, Jul 11, 2019 at 2:12 PM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
> >
> > On Thu, Jul 11, 2019, 13:42 Guy Lemieux <glemieux at vectorblox.com> wrote:
> >>
> >> 1/sqrt(a) is a single-operand instruction.
> >>
> >> might there be more performance value in making it dual-operand to make
> better use of available read ports, eg:
> >>
> >> a/sqrt(b)
> >>   or
> >> 1/sqrt(a+b)
> >>
> >> both are common forms of usage. i suppose these could be formed by
> chaining, but if that’s the case there’s little need for rsqrt if you have
> both div and sqrt.
> >
> > the reason for not just chaining two instructions is that sqrt followed
> by div gives different results due to rounding twice. div followed by sqrt
> gives different results due to rounding twice, returning NaN instead of
> -Inf for -0 inputs, and very small inputs overflow to +Inf where rsqrt
> won't ever overflow or underflow.
> >
> > 1/sqrt(a+b) additionally gives different results for special cases,
> assuming the addition is defined the same as fadd, since the sign of the
> result is different for different rounding modes when adding +0 and -0,
> whereas (if I recall correctly) IEEE 754-2008 defines rsqrt(+0) to give
> +Inf and rsqrt(-0) to give -Inf for all rounding modes.
> >
> > I think having a frsqrt instruction that doesn't need an additional
> input will be useful since the compiler doesn't have to load the constant 1
> (for a/sqrt(b)) or +0 or -0 (for 1/sqrt(a+b)).
> >
> > Additionally, frsqrt is a commonly implemented operation, so already
> working and verified single-input frsqrt HW is readily available, whereas
> the modified versions that have 2 inputs aren't as likely to be available,
> and it would quite complex to implement and verify a new FP unit, greatly
> restricting who can implement the Zfrsqrt extension.
> >
> > I have no problems modifying the encoding to permit 2-input frsqrt, I
> just think that should be an additional extension on top of Zfrsqrt.
> >
> >
> > Jacob
>
> --
> You received this message because you are subscribed to the Google Groups
> "RISC-V ISA Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to isa-dev+unsubscribe at groups.riscv.org.
> To view this discussion on the web visit
> https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CALo5CZxWfPS-z8XgogJuKTG_fVCfOgJLb2vPQS2-ukxajmFHcQ%40mail.gmail.com
> .
>