|--------|---|---|-------|--------|---------|
| PO (9)?| 1 | 1 | nnnn | PO2 | SVP64:{EXT000-063} |
+# Potential Opcode allocation solution (2)
+
+One of the risks of the bit 6/7 scheme above is that there is no
+room to share PO9 (EXT009) with other potential uses. A workaround for
+that is as follows:
+
+* EXT009, like EXT001 of Public v3.1, is **defined** as a 64-bit
+ encoding
+* bits 32-33 if 0b11 are indefinitely allocated to SVP64 Format
+ *regardless of what that is*
+* other combinations of bits 32-33 are `RESERVED` for other purposes
+
+
+There are unfortunately some inviolate requirements that directly place
+pressure on the EXT000-EXT063 (32-bit) opcode space to such a degree that
+it risks jeapordising the Power ISA. These requirements are:
+
+* all of the scalar operations must be Vectoriseable
+* all of the scalar operations intended for Vectorisation
+ must be in a 32-bit encoding (not prefixed-prefixed to 96-bit)
+* bringing Scalar Power ISA up-to-date from the past 12 years
+ needs 75% of two Major opcodes all on its own
+
+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]
+
+| 0-5 | 6 | 7 | 8-31 | Description |
+|-----|---|---|-------|---------------------------|
+| PO | 0 | 0 | 0000 | new-suffix `RESERVED1` |
+| PO | 0 | 0 | !zero | new-suffix, scalar (SVP64Single), or `RESERVED3` |
+| PO | 1 | 0 | 0000 | new scalar-only word, or `RESERVED2` |
+| PO | 1 | 0 | !zero | old-suffix, scalar (SVP64Single), or `RESERVED4` |
+| PO | 0 | 1 | nnnn | new-suffix, vector (SVP64) |
+| PO | 1 | 1 | nnnn | old-suffix, vector (SVP64) |
+
# Example Legal Encodings and RESERVED spaces
This section illustrates what is legal encoding, what is not, and