<br><br>On Friday, February 1, 2019, Jacob Lifshay <<a href="mailto:programmerjake@gmail.com">programmerjake@gmail.com</a>> wrote:<div><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>Neat! I did not know that about the V extension. So this sounds as though the V extension would like support for <VL x <4 x float>>-style vectors as well.</div><div><br></div><div>We are currently thinking of defining the extension in terms of a 16-bit prefix that changes standard 32-bit instructions into vectorized 48-bit instructions,</div><div><br></div></div></div></div></blockquote><div><br></div><div>(and Compressed 16-bit ones into vectorised 32-bit, unmodified)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> allowing most future or current standard/non-standard extensions to be vectorized, rather than having to wait for additional extensions to have vector versions added to the V extension (one reason we are not using the V extension instead), such as the B extension. </div></div></div></div></blockquote><div><br></div><div>(and there isn't enough free RISCV 32 bit opcode space to add vectorised versions of xBitManip, nor any future custom or standard ops. So the simplest most powerful way to move forward quickly and without disruption is a prefix)</div><div><br></div><div>L.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div><br><br>-- <br>---<br>crowd-funded eco-conscious hardware: <a href="https://www.crowdsupply.com/eoma68" target="_blank">https://www.crowdsupply.com/eoma68</a><br><br>