# SIMD / Simple-V Extension Proposal
This proposal exists so as to be able to satisfy several disparate
-requirements: area-conscious designs and performance-conscious designs.
+requirements: power-conscious, area-conscious, and performance-conscious
+designs all pull an ISA and its implementation in different conflicting
+directions, as do the specific intended uses for any given implementation.
+
Also, the existing P (SIMD) proposal and the V (Vector) proposals,
whilst each extremely powerful in their own right and clearly desirable,
are also:
* Clearly independent in their origins (Cray and AndeStar v3 respectively)
-* Both contain duplication of pre-existing RISC-V instructions
+* Both contain partial duplication of pre-existing RISC-V instructions
+ (an undesirable characteristic)
* Both have independent and disparate methods for introducing parallelism
at the instruction level.
* Both require that their respective parallelism paradigm be implemented
along-side their respective functionality *or not at all*.
-* Both independently have methods for introducing parallelism that could,
- if separated, benefit *other areas of RISC-V not just DSP and Floating-point*.
+* Both independently have methods for introducing parallelism that
+ could, if separated, benefit
+ *other areas of RISC-V not just DSP or Floating-point respectively*.
Therefore it makes a huge amount of sense to have a means and method
of introducing instruction parallelism in a flexible way that provides
implementors with the option to choose exactly where they wish to offer
performance improvements and where they wish to optimise for power
-and area. If that can be offered even on a per-operation basis that
+and/or area. If that can be offered even on a per-operation basis that
would provide even more flexibility.
# Analysis and discussion of Vector vs SIMD