themselves) which instructions should be submitted over the next 18
months.
+*It is expected that readers visit and interact with the Libre-SOC resources
+in order to do due-diligence on the prioritisation evaluation*.
+
Worth bearing in mind during evaluation that every "Defined
Word" may or may not be Vectoriseable, but that every "Defined Word"
should have merits on its own not just when Vectorised. An example
* 15 - Transcendentals (1-arg) [[openpower/transcendentals]]
* 25 - Transcendentals (2-arg) [[openpower/transcendentals]]
+Summary tables are created below by different sort categories. Additional
+columns as necessary can be requested to be added as part of update revisions
+to this RFC.
+
+# Target Area summaries
+
+## Transcendentals
+
+Found at [[openpower/transcendentals]] these subdivide into high priority for
+accelerating general-purpose and High-Performance Compute, specialist 3D GPU
+operations suited to 3D visualisation, and low-priority less common instructions
+where IEEE754 full bit-accuracy is paramount. In 3D GPU scenarios for example
+even 12-bit accuracy can be overkill, but for HPC Scientific scenarios 12-bit
+would be disastrous.
+
+## Audio/Video
+
+Found at [[sv/av_opcodes]] these do not require Saturated variants because Saturation
+is added via [[sv/svp64]] (Vector Prefixing) and via [[sv/svp64_single]] Scalar
+Prefixing. This is important to note for Opcode Allocation because placing these
+operations in the UnVectoriseble areas would irrediemably damage their value.
+Unlike PackedSIMD ISAs the actual number of AV Opcodes is remarkably small once
+the usual cascading-option-multipliers (SIMD width, bitwidth, saturation, HI/LO)
+are abstracted out to RISC-paradigm Prefixing, leaving just absolute-diff-accumulate,
+min-max, average-add etc. as "basic primitives".
+
+
[[!inline pages="openpower/sv/rfc/ls012/areas.mdwn" raw=yes ]]
[[!tag opf_rfc]]