footnote no space
authorLuke Kenneth Casson Leighton <lkcl@lkcl.net>
Sun, 11 Sep 2022 20:05:29 +0000 (21:05 +0100)
committerLuke Kenneth Casson Leighton <lkcl@lkcl.net>
Sun, 11 Sep 2022 20:53:22 +0000 (21:53 +0100)
openpower/sv/rfc/ls001.mdwn

index b222975dd149d1f4931b201cae7ca46382d55bae..086b147b4ca7a2d28867bcd6201cdba489f3405a 100644 (file)
@@ -129,7 +129,7 @@ such large numbers of registers, even for Multi-Issue microarchitectures.
   version may extend to 256 or beyond[^extend] or also extend VSX[^futurevsx]
 * 24-bits are needed within the main SVP64 Prefix (equivalent to a 2-bit XO)
 * Another 24-bit (a second 2-bit XO) is needed for a planned future encoding,
-  currently named "SVP64-Single" [^likeext001]
+  currently named "SVP64-Single"[^likeext001]
 * A third 24-bits (third 2-bit XO) is strongly recommended to be `RESERVED`
   such that future unforeseen capability is needed (although this may be
   alternatively achieved with a mandatory PCR or MSR bit)
@@ -184,7 +184,7 @@ The primary options are:
 
 * element-width overrides, which dynamically redefine each SFFS or SFS
   Scalar prefixed instruction to be 8-bit, 16-bit, 32-bit or 64-bit
-  operands **without requiring new 8/16/32 instructions** [^pseudorewrite]
+  operands **without requiring new 8/16/32 instructions**[^pseudorewrite]
 * predication.  this is an absolutely essential feature for a 3D GPU VPU ISA.
   CR Fields are available as Predicate Masks hence the reason for their
   extension to 128.
@@ -317,7 +317,7 @@ it risks jeapordising the Power ISA. These requirements are:
 There exists a potential scheme which meets (exceeds) the above criteria,
 providing plenty of room for both Scalar (and Vectorised) operations,
 *and* provides SVP64-Single with room to grow.  It
-is based loosely around Public v3.1 EXT001 Encoding. [^ext001]
+is based loosely around Public v3.1 EXT001 Encoding.[^ext001]
 
 | 0-5 | 6 | 7 | 8-31  | Description               |
 |-----|---|---|-------|---------------------------|