From 58f12c9f665abb7b64a1b48188fc4388a12cf542 Mon Sep 17 00:00:00 2001 From: Luke Kenneth Casson Leighton Date: Fri, 6 Apr 2018 16:11:26 +0100 Subject: [PATCH] partial update --- simple_v_extension.mdwn | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/simple_v_extension.mdwn b/simple_v_extension.mdwn index 0c3a9c9f2..17d97b4d6 100644 --- a/simple_v_extension.mdwn +++ b/simple_v_extension.mdwn @@ -1,5 +1,31 @@ # 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. +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 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*. + +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 +would provide even more flexibility. + +In David Patterson and Andrew Waterman's analysis of SIMD and Vector +ISAs, the analysis comes out clearly in favour of + +* SIMD considered harmful * Link to first proposal * Recommendation by Jacob Bachmeyer to make zero-overhead loop an "implicit program-counter" -- 2.30.2