From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Date: Thu, 7 Jun 2018 22:42:24 +0000 (+0100)
Subject: element width conversion ok
X-Git-Tag: convert-csv-opcode-to-binary~5252
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=e01af18fedcdab46d4109f1e59a3752e7b5a125d;p=libreriscv.git

element width conversion ok
---

diff --git a/simple_v_extension.mdwn b/simple_v_extension.mdwn
index a5fa3d208..d77f43a6a 100644
--- a/simple_v_extension.mdwn
+++ b/simple_v_extension.mdwn
@@ -1917,6 +1917,23 @@ reply:
 > non-predicated vector-compare, followed by vector gather-scatter on the
 > result?
 
+## element width conversion: restrict or remove?
+
+summary: don't restrict / remove.  it's fine.
+
+> > it has virtually no cost/overhead as long as you specify
+> > that inputs can only upconvert, and operations are always done at the
+> > largest size, and downconversion only happens at the output.
+>
+> okaaay.  so that's a really good piece of implementation advice.
+> algorithms do require data size conversion, so at some point you need to
+> introduce the feature of upconverting and downconverting.
+>
+> > for int and uint, this is dead simple and fits well within the RVV pipeline
+> > without any critical path, pipeline depth, or area implications.
+
+<https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/g3feFnAoKIM>
+
 ## Implementation Paradigms <a name="implementation_paradigms"></a>
 
 TODO: assess various implementation paradigms.  These are listed roughly