From: lkcl Date: Sat, 17 Sep 2022 09:24:07 +0000 (+0100) Subject: (no commit message) X-Git-Tag: opf_rfc_ls005_v1~396 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=b74db399201f29af2eee957f80d2eda1c7bfbe41;p=libreriscv.git --- diff --git a/openpower/sv/rfc/ls001.mdwn b/openpower/sv/rfc/ls001.mdwn index b7067bbf8..e3def5e06 100644 --- a/openpower/sv/rfc/ls001.mdwn +++ b/openpower/sv/rfc/ls001.mdwn @@ -550,7 +550,9 @@ Setting a simple inviolate rule helps avoid this scenario but does need to be borne in mind when discussing potential allocation schemes, as well as when new Vectoriseable Opcodes are proposed for addition by future RFCs: the opcodes **must** be uniformly -added to Scalar **and** Vector spaces. +added to Scalar **and** Vector spaces, or added in one and reserved +in the other, or +not added at all in either.[^whoops] \newpage{} # Potential Opcode allocation solution @@ -1129,3 +1131,4 @@ operations. [^autovec]: Compiler auto-vectorisation for best exploitation of SIMD and Vector ISAs on Scalar programming languages (c, c++) is an Indusstry-wide known-hard decades-long problem. Cross-reference the number of hand-optimised assembler algorithms. [^hphint]: intended for use when the compiler has determined the extent of Memory or register aliases in loops: `a[i] += a[i+4]` would necessitate a Vertical-First hphint of 4 [^svshape]: although SVSHAPE0-3 should, realistically, be regarded as high a priority as SVSTATE, and given corresponding SVSRR and SVLR equivalents, it was felt that having to context-switch **five** SPRs on Interrupts and function calls was too much. +[^whoops]: two efforts were made to mix non-uniform encodings into Simple-V space: one deliberate to see how it would go, and one accidental. They both went extremely badly, the deliberate one costing two months to add then remove.