From: lkcl Date: Wed, 21 Sep 2022 13:05:26 +0000 (+0100) Subject: (no commit message) X-Git-Tag: opf_rfc_ls005_v1~345 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=267dba0c0fc85e93aa21921290cb8897a0dea7d4;p=libreriscv.git --- diff --git a/openpower/sv.mdwn b/openpower/sv.mdwn index 680760a45..3babea8c5 100644 --- a/openpower/sv.mdwn +++ b/openpower/sv.mdwn @@ -199,12 +199,14 @@ different results on different hardware depending on a "Silicon Partner" hardware choice. This choice catastrophically and irrevocably causes binary non-interoperability *despite being a "feature"*. Explained in +it is the exact same binary-incompatibility issue faced by Power ISA +on its 32- to 64-bit transition: 32-bit hardware was **unable** to +trap-and-emulate 64-bit binarues because the opcodes were (are) the same. It is therefore *guaranteed* that extensions to the register file width and quantity in Simple-V shall only be made in future by explicit means, ensuring binary compatibility. - # Optional Scalar instructions **Additional Instructions for specific purposes (not SVP64)** @@ -275,7 +277,35 @@ To protect SVP64 from damage, a "Hard Rule" has to be set: must correspondingly be added in the Scalar space with the exact same 32-bit "Defined Word" or not at all. - +Some explanation of the above is needed. Firstly, "Defined Word" is a term +used in Section 1.6.3 of the Power ISA v3 1 Book I: it means, in short, +"a 32 bit instruction", which can then be Prefixed by EXT001 to extend it +to 64-bit. Prefixed-Prefixed (96-bit Variable-Length) encodings are +prohibited in v3.1 and they are just as prohibited in Simple-V: it's too +complex in hardware. + +Secondly, the term "Vectoriseable" was used. This refers to "instructions +which if SVP64-Prefixed are actually meaningful". `sc` is meaningless +to Vectorise, for example, as is `sync` and `mtmsr` (there is only ever +going to be one MSR). + +The problem comes if the rationale is applied, "Unvectoriseable opcodes +can be allocated to alternative instructions within the SVP64 Opcode space", +which unfortunately results in huge inadviseable complexity in HDL at the +Decode Phase, attempting to discern between the two. Worse than that, +if the alternate 64-bit instruction is Vectoriseable but the 32-bit Scalar +"Defined Word" is already allocated, how can there ever be a Scalar version +of the alternate instruction? It would have to be added as a **completely +different** 32-bit "Defined Word" and things go rapidly downhill in the +Decoder from there. + +Therefore to avoid risk: + +* *even Unvectoriseable* "Defined Words" (`mtmsr`) must have the + corresponding SVP64 Prefixed Space `RESERVED`, permanently requiring + Illegal Instruction to be raised. +* *Even instructions that may not be Scalar* ( although for various + practical reasons this is extremely rare if not impossible) # Other Scalable Vector ISAs