From 56adf721e61eaf60d6646ca8d5239497a4b9875d Mon Sep 17 00:00:00 2001 From: Luke Kenneth Casson Leighton Date: Fri, 6 Apr 2018 18:46:13 +0100 Subject: [PATCH] partial update --- simple_v_extension.mdwn | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/simple_v_extension.mdwn b/simple_v_extension.mdwn index 3ace324b5..aebeed0d2 100644 --- a/simple_v_extension.mdwn +++ b/simple_v_extension.mdwn @@ -27,6 +27,23 @@ performance improvements and where they wish to optimise for power and/or area. If that can be offered even on a per-operation basis that would provide even more flexibility. +**TODO**: reword this to better suit this document: + +Having looked at both P and V as they stand, they're _both_ very much +"separate engines" that, despite both their respective merits and +extremely powerful features, don't really cleanly fit into the RV design +ethos (or the flexible extensibility) and, as such, are both in danger +of not being widely adopted. I'm inclined towards recommending: + +* splitting out the DSP aspects of P-SIMD to create a single-issue DSP +* splitting out the polymorphism, esoteric data types (GF, complex + numbers) and unusual operations of V to create a single-issue "Esoteric + Floating-Point" extension +* splitting out the loop-aspects, vector aspects and data-width aspects + of both P and V to a *new* "P-SIMD / Simple-V" and requiring that they + apply across *all* Extensions, whether those be DSP, M, Base, V, P - + everything. + # Analysis and discussion of Vector vs SIMD There are four combined areas between the two proposals that help with -- 2.30.2