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

Dan Petrisko petrisko at cs.washington.edu
Thu Jul 11 22:14:59 BST 2019


>
> Or can they all be independent - e.g. support for Q but not D or F etc.?


Chapter 12: D

> The D extension depends on the base single-precision instruction subset F.
>
Chapter 13: Q

> The quad-precision binary floating-point instruction-set extension is
> named “Q”; it depends on the double-precision floating- point extension D.
>

So no, Q requires D requires F.

On Thu, Jul 11, 2019 at 5: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/CAC2bXD7Na%2B41LSzp_dLSeXKPcfT%2BXWTukCit0ab4gfzeipBbQA%40mail.gmail.com
> <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAC2bXD7Na%2B41LSzp_dLSeXKPcfT%2BXWTukCit0ab4gfzeipBbQA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>


More information about the libre-riscv-dev mailing list