|EXT001| 0 | 1 | nnnn | load/store suffix=defined-word |
|EXT001| 1 | 1 | nnnn | reg-to-reg suffix=defined-word |
+and so when bit 6=0 there is space to create an entirely
+new suite of encodings including new 32-bit instructions.
this "doubling" is already public and part of EXT001, the idea
here is to mirror that (bit 6), but unlike EXT001, use bit 7
| PO | 0 | 1 | nnnn | new, vector (SVP64) |
| PO | 1 | 1 | nnnn | old, vector (SVP64) |
+there are some special-cases here, involving bits 8-31 but
+they are degenerate. let us set `Scalar Identity Behaviour`:
+
+| 0-5 | 6 | 7 | 8-31 | Description |
+|-----|---|---|------|---------------------------|
+| PO | 0 | 0 | 0000 | new, scalar (SVP64Single) |
+| PO | 1 | 0 | 0000 | old, scalar (SVP64Single) |
+| PO | 0 | 1 | 0000 | new, vector (SVP64) |
+| PO | 1 | 1 | 0000 | old, vector (SVP64) |
+
+there is *one* set of encodings here which are redundant:
+
+* bit 6=1
+* bit 7=10
+* bits 8-31=0000
+
+this is a duplication of the **existing** v3.0B 32-bit
+Scalar operations. is it worth special-casing for
+"Reserved" honestly i do not know if it's worth it.
+it would be:
+
+| 0-5 | 6 | 7 | 8-31 | Description |
+|-----|---|---|------|---------------------------|
+| PO | 0 | 0 | nnnn | new, scalar (SVP64Single) |
+| PO | 1 | 0 | 0000 | `RESERVED` |
+| PO | 1 | 0 | !zero | old, scalar (SVP64Single) |
+| PO | 0 | 1 | nnnn | new, vector (SVP64) |
+| PO | 1 | 1 | nnnn | old, vector (SVP64) |