**URLs**:
* <https://libre-soc.org/openpower/sv/rfc/ls005/>
-* <https://bugs.libre-soc.org/show_bug.cgi?id=671>
* <https://bugs.libre-soc.org/show_bug.cgi?id=663>
* <https://git.libre-soc.org/?p=openpower-isa.git;a=tree;f=openpower/isa;hb=HEAD>
* <https://git.openpower.foundation/isa/PowerISA/issues/104>
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
"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).
----------------