As part of bug #952 - the NLnet 2022 OPF ISA WG Grant 2022-08-051 - it was established that PO9 is a candidate for use by SVP64 instead of shoe-horning into PO1. That now needs to be implemented along-side its knock-on implications in ISACaller, the insndb, and binutils. Additionally there are some instructions easy to implement (LD/ST-post-update) that are beneficial to performance, that again came out of the OPF RFC Feedback process. --- * removing use of PO1 and replacing with PO9 * creating EXT200-263 under PO9 * moving all LD/ST-post-update to EXT200-263, with their exact respective *pre-update* EXT000-063 encodings (example: lhz is EXT040, therefore lhzp *is* EXT240, no arguing, no question: it just *is*) * freeing up the LDST_IMM SVP64 "post-update" bit and allocating it instead to Vector-Immediate (with elwidths on VIs) * using the reserved Normal/Arithmetic mode also for VI * bug #1047 finishing LDST-EXTRA-322 involves: * specification writing and checking * insndb updating (two ways: PO9 itself *and* the new EXT2xx * a new PowerDecoder (for EXT2xx) * test_caller* unit tests * writing the LD/ST-post-update mdwn files (Nicholas, new member) * ISACaller updates * binutils updates (to SVP64 as well as a new EXT2xx area)
this is the table that needs to record what goes in the new EXT200-263, what goes in PO5, what in PO22 https://libre-soc.org/openpower/sv/draft_opcode_tables/
https://libre-soc.org/openpower/power_trans_ops_copy_from_PO59_table.py/