From: lkcl Date: Mon, 29 May 2023 14:48:24 +0000 (+0100) Subject: (no commit message) X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=1a6f664b7a4a8232739d30b13b0e99b88083ae60;p=libreriscv.git --- diff --git a/openpower/sv/svp64.mdwn b/openpower/sv/svp64.mdwn index 5c0b3d9ea..1942922f8 100644 --- a/openpower/sv/svp64.mdwn +++ b/openpower/sv/svp64.mdwn @@ -94,18 +94,18 @@ highly suited to High-Performance Computation (HPC), Supercomputing, and parallel GPU Workloads. *Architectural Resource Allocation note: at present it is possible to perform -partial parallel decode of the SVP64 24-bit Encoding at the same time +partial parallel decode of the SVP64 24-bit Encoding Area at the same time as decoding of the Suffix. Multi-Issue Implementations may even Decode multiple 32-bit words in parallel and follow up with a second -cycle of joining Prefix and Suffix "after-the-fact". +cycle of joining Prefix and Suffix "after-the-fact". Mixing and overlaying 64-bit Opcode Encodings into the {SVP64 24-bit Prefix}{Defined Word-instruction} space creates -a hard dependency that catastrophically damages Multi-Issue Decoding. +a hard dependency that catastrophically damages Multi-Issue Decoding by +greatly complexifying Parallel Instruction-Length Detection. Therefore it has to be prohibited to accept RFCs -which fundamentally violate this hard requirement. Under no circumstances -must the Suffix space have an alternate instruction encoding allocated - that is entirely different from the non-prefixed Defined -Word.* +which fundamentally violate the following hard requirement: **under no circumstances** +must the use of SVP64 24-bit Suffixes **also** imply a different Opcode space +from **any** non-prefixed Word, even RESERVED or Illegal Words.* Subset implementations in hardware are permitted, as long as certain rules are followed, allowing for full soft-emulation including future