From 1a6f664b7a4a8232739d30b13b0e99b88083ae60 Mon Sep 17 00:00:00 2001 From: lkcl Date: Mon, 29 May 2023 15:48:24 +0100 Subject: [PATCH] --- openpower/sv/svp64.mdwn | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) 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 -- 2.30.2