From cda0fe09f657337d3d2dfe62ecab32d569212442 Mon Sep 17 00:00:00 2001 From: Luke Kenneth Casson Leighton Date: Thu, 22 Dec 2022 17:45:09 +0000 Subject: [PATCH] clarify about FP32/16/BF16 etc in ls005 --- openpower/sv/rfc/ls005.mdwn | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/openpower/sv/rfc/ls005.mdwn b/openpower/sv/rfc/ls005.mdwn index 22888b94c..fd6635cd6 100644 --- a/openpower/sv/rfc/ls005.mdwn +++ b/openpower/sv/rfc/ls005.mdwn @@ -7,7 +7,6 @@ **URLs**: * -* * * * @@ -76,7 +75,6 @@ In this way, the limitations of what would otherwise restrict the usefulness of a severely-targetted application-specific processor may be overcome in order to make it still possible to (at reduced performance) still run general-purpose applications. - AI application-specific processing or other Processing-In-Memory or other specialist design therefore may for example focus a balance of raw computing power heavily onto 8-bit or 16-bit computation, but still @@ -101,6 +99,18 @@ Definitions of the Register File(s) for GPR and FPR are then changed to be "XLEN" wide. However, for Embedded purposes (XLEN=32/16/8), an SPR controls whether (and how many) sequentially-grouped registers are taken together to create 16-bit, 32-bit and 64-bit addresses (depending on application need). +GPR is obvious, FPR is quirky. SVP64 redefines FP ops (those not ending in "s") +to be "full width" and all ops ending in "s" to be "half of +the FP width". + +* XLEN=64 keeps FPR "full width" exactly as presently defined, and + "half width" exactly as presently defined. +* XLEN=32 overrides FPR "full width" operations to + full FP32, and "half width" to be "FP16 stored in an FP32" +* XLEN=16 redefines FPR "full width" operations to full BFP16 and leaves + "half width" UNDEFINED (there is no FP8). +* XLEN=8 redefines FPR "full width" operations to BF16 and leaves + "half width" UNDEFINED (there is no BF8). ---------------- -- 2.30.2