From 320fe573d8714b0a98bf823fb73443f455d5b603 Mon Sep 17 00:00:00 2001 From: lkcl Date: Fri, 27 May 2022 12:46:28 +0100 Subject: [PATCH] --- openpower/sv/svp64_quirks.mdwn | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn index 72458c425..fb77529d6 100644 --- a/openpower/sv/svp64_quirks.mdwn +++ b/openpower/sv/svp64_quirks.mdwn @@ -1,5 +1,7 @@ # The Rules +[[!toc]] + SVP64 is designed around these fundamental and inviolate principles: 1. There are no actual Vector instructions: Scalar instructions @@ -89,4 +91,24 @@ overwrites LR. Well over 500 Vectorised branch instructions exist in SVP64 due to the number of options available: close integration and interaction with -the base Scalar Branch was unavoidable. +the base Scalar Branch was unavoidable in order to create Conditional +Branching suitable for parallel 3D / CUDA GPU workloads. + +# Saturation + +The application of Saturation as a retro-fit to a Scalar ISA is challenging. +It does help that within the SFFS Compliancy subset there are no Saturated +operations at all: only in VSX. + +Saturation does not inherently change the instruction itself: it does however +come with some fundamental implications, when applied. For example: +a Floating-Point operation that would normally raise an exception will +no longer do so, instead setting the CR1.SO Flag. Another quirky +example: signed operations which produce a negative result will be +truncated to zero if Unsigned Saturation is requested. + +One very important aspect for implementors is that the operation in +effect has to be considered to be performed at infinite precision, +followed by saturation detection. In practice this does not actually +require infinite precision hardware! Two 8-bit integers being +added can only ever overflow into a 9-bit result. -- 2.30.2