From 1a5e3a527d1c1579f851fde53a1e2a067f5dbe9f Mon Sep 17 00:00:00 2001 From: lkcl Date: Sat, 8 Apr 2023 16:19:07 +0100 Subject: [PATCH] --- openpower/sv/rfc/ls012.mdwn | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/openpower/sv/rfc/ls012.mdwn b/openpower/sv/rfc/ls012.mdwn index ea254a1ee..a7b75ddff 100644 --- a/openpower/sv/rfc/ls012.mdwn +++ b/openpower/sv/rfc/ls012.mdwn @@ -88,10 +88,14 @@ to this RFC. These without question have to go in EXT0xx. Future extended variants, bringing even more powerful capabilities, can be followed up later with EXT1xx prefixed -variants. Examples include adding psvshape in order to support both Inner and +variants, which is not possible if placed in EXT2xx. +*Only `svstep` is actually Vectoriseable*, all other Management instructions +are UnVectoriseane. PO1-Prefixed examples include adding psvshape in order to +support both Inner and Outer Product Matrix Schedules, by providing the option to directly reverse the order of the triple loops. Outer is used for standard Matrix Multiply, but Inner -is required for Warshall Transitive Closure. +is required for Warshall Transitive Closure (on top of a cumulatively-applied +max instruction). The Management Instructions themselves are all Scalar Operations, so PO1-Prefixing is perfecly reasonable. SVP64 Management instructions of which there are only -- 2.30.2