-Operations work on variable-length vectors of sub-vectors, where each sub-vector
-has a length *svlen*, and an element type *etype*. When the vectors are stored
-in registers, all elements are packed so that there is no padding in-between
-elements of the same vector. The number of bytes in a sub-vector, *svsz*, is the
-product of *svlen* and the element size in bytes.
+* Bits are numbered starting from 0 at the LSB, so bit 3 is 1 in the integer 8.
+* Bit ranges are inclusive on both ends, so 5:3 means bits 5, 4, and 3.
+* Operations work on variable-length vectors of sub-vectors up to *VL*
+ in length, where each sub-vector has a length *svlen*, and *svlen*
+ elements of type *etype*.
+* The actual total number of elements is therefore *svlen* times *VL*.
+* When the vectors are stored in registers, all elements are packed so
+ that there is no padding in-between elements of the same vector.
+* The register file itself is thus best viewed as a byte-level SRAM that
+ is typecast to an array of *etypes*
+* The number of bytes in a sub-vector, *svsz*, is the product of *svlen*
+ and the element size in bytes.
+
+Options
+=======
+
+The following partial / full implementation options are possible:
+
+* SVPrefix augments the main Specification_
+* SVPrefix operates independently, without the main spec VL (and MVL)
+ CSRs (in any priv level)
+* SVPrefix operates independently, without the main spec SUBVL CSRs
+ (in any priv level)
+* SVPrefix has no support for VL (or MVL) overrides in the 64 bit
+ instruction format (VLtyp=0 as the only legal permitted value)
+* SVPrefix has no support for svlen overrides in either the 48 or 64
+ bit instruction format either (svlen=0 as the only legal permitted value).
+
+All permutations of the above options are permitted, and the UNIX
+platform must raise illegal instruction exceptions on implementations
+that do not support each option. For example, an implementation that
+has no support for VLtyp that sees an opcode with a nonzero VLtyp must
+raise an illegal instruction exception.
+
+Note that SVPrefix (VLtyp and svlen) has its own STATE CSR, SVPSTATE. This allows Prefixed operations to be re-entrant on traps, and to not affect VBLOCK use of VL or SUBVL.
+
+If the main Specification_ CSRs and features are to be supported (VBLOCK), then when VLtyp or svlen are "default" they utilise the main Specification_ VBLOCK VL and/or SUBVL, and, correspondingly, the main VBLOCK STATE CSR will be updated and used to track hardware loops.
+
+If however VLtyp is set to nondefault, then the SVPSTATE src and destoffs fields are used instead to create the hardware loops, and likewise if svlen is set to nondefault, SVPSTATE's svoffs field is used.