From 174cba568cd9ff3863b7257de598304717bded65 Mon Sep 17 00:00:00 2001 From: lkcl Date: Fri, 7 Apr 2023 15:04:19 +0100 Subject: [PATCH] --- openpower/sv/fcvt.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openpower/sv/fcvt.mdwn b/openpower/sv/fcvt.mdwn index 27de2900e..7a57e1baa 100644 --- a/openpower/sv/fcvt.mdwn +++ b/openpower/sv/fcvt.mdwn @@ -8,7 +8,7 @@ Whilst this is fantastic in that it provides opportunities for speeding up FP64 To solve this, the FP values need to be compacted or expanded such that Vector operations do not waste space. The current thinking is that it nay be reasonable to overload `fmv` at different element widths (srcwid != destwid) to perform the necessary conversion, as opposed to just simply doing a straight bitcopy with truncation. -The result of this has some interesting side-effects when considering what "single precision FP operations" means when elwidth=32. A reasonable interpretation is: the operation is to be performed at FP16 precision yet the result placed in FP32 format, just as how for FP64 single-precision is xarried out at FP32 and placed in FP64. +The result of this has some interesting side-effects when considering what "single precision FP operations" means when elwidth=32. A reasonable interpretation is: the operation is to be performed at FP16 precision yet the result placed in FP32 format, just as how for FP64 single-precision is carried out at FP32 and placed in FP64. see for discussion. -- 2.30.2