| 0-5 | 6 | 7 | 8-31 | 32-3 | Description |
|-----|---|---|-------|------|---------------------------|
-| PO9?| 1 | 0 | 0000 | xx | `RESERVED1` or EXT300-363 |
-| PO9?| 0 | x | xxxx | 0b00 | `RESERVED2` or EXT200-216 |
-| PO9?| 0 | x | xxxx | 0b01 | `RESERVED2` or EXT216-231 |
-| PO9?| 0 | x | xxxx | 0b10 | `RESERVED2` or EXT232-247 |
-
-Where:
+| PO9?| 1 | 0 | 0000 | xx | `RESERVED1` or EXT300-363 (32-bit) |
+| PO9?| 0 | x | xxxx | 0b00 | `RESERVED2` or EXT200-216 (55-bit) |
+| PO9?| 0 | x | xxxx | 0b01 | `RESERVED2` or EXT216-231 (55-bit) |
+| PO9?| 0 | x | xxxx | 0b10 | `RESERVED2` or EXT232-247 (55-bit) |
* SVP64Single (`RESERVED3/4`) is *planned* for a future RFC
(but needs reserving as part of this RFC)
* QTY 3of 55-bit spaces also exist for future use (longer by 3 bits
than opcodes allocated in EXT001)
* Simple-V EXT2nn is restricted to range EXT248-263
-* non-Simple-V EXT2nn (if ever allocated by a future RFC) is restricted to range EXT200-247
+* non-Simple-V (non-Vectoriseable) EXT2nn (if ever requested in any future RFC) is restricted to range EXT200-247
* Simple-V EXT0nn takes up 50% of PO9 for this and future Simple-V RFCs
+**This however potentially puts SVP64 under pressure (in 5-10 years).**
+Ideas being discussed already include adding LD/ST-with-Shift and variant
+Shift-Immediate operations that require large quantity of Primary Opcodes.
+To ensure that there is room in future,
+it may be better to allocate 25% to `RESERVED`:
+
+| 0-5 | 6 | 7 | 8-31 | 32 | Description |
+|-----|---|---|-------|-----|---------------------------|
+| PO9?| 1 | 0 | 0000 | x | EXT300-363 or `RESERVED1` (32-bit) |
+| PO9?| 0 | x | xxxx | 0b0 | EXT200-232 or `RESERVED2` (56-bit) |
+| PO9?| 0 | x | xxxx | 0b1 | EXT232-263 and SVP64(/V/S) |
+
The clear separation between Simple-V and non-Simple-V stops
conflict in future RFCs, both of which get plenty of space.
EXT000-063 pressure is reduced in both Vectoriseable and