From: lkcl Date: Wed, 12 Apr 2023 17:04:37 +0000 (+0100) Subject: (no commit message) X-Git-Tag: opf_rfc_ls010_v1~52 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=1e7791dd188efc45d5fc889071210b56790c7238;p=libreriscv.git --- diff --git a/openpower/sv/svp64_quirks.mdwn b/openpower/sv/svp64_quirks.mdwn index 26d966325..bff45dcd8 100644 --- a/openpower/sv/svp64_quirks.mdwn +++ b/openpower/sv/svp64_quirks.mdwn @@ -685,3 +685,29 @@ complexity in the Hazard Management when context-switching CR fields, as the entire batch of 128 CR Fields may be transferred to 8 GPRs with a VL of 16 and elwidth overriding of 32. Truncation is sufficent, dropping the top 32 bits of the Condition Register(s) which are always zero anywy. + +# Separate Scalar and Vector Condition Register files + +As explained in the introduction [[sv/svp64]] and [[sv/cr_ops]] +Scalar Power ISA lacks "Conditional Execution" present in ARM +Scalar ISA of several decades. When Vectorised the fact that +Rc=1 Vector results can immediately be used as a Predicate Mask +back into the following instruction can result in large latency +unless "Vector Chaining" is used in the Micro-Architecture. + +But that aside is not the main problem faced by the introduction +of Simple-V to the Power ISA: it's that the existing implementations +(IBM) don't have "Conditional Execution" and to add it to their +existing designs would be too disruptive a first step. + +A compromise is to wipe blank certain entries in the Register Dependency +Matrices by prohibiting some operations involving the two groups +of CR Fields: those that fall into the existing Scalar 32-bit CR +(fields CR0-CR7) and those that fall into the newly-introduced +CR Fields, CR8-CR127. + +This will drive compiler writers nuts, and give assembler writers headaches, +but it gives IBM the opportunity to implement SVP64 without massive +disruption. They can add an entirely new Vector CR register file, +new pipelines etc safe in the knowledge that existing Scalar HDL +needs no modification.