From: lkcl Date: Tue, 3 Sep 2019 15:54:28 +0000 (+0100) Subject: (no commit message) X-Git-Tag: convert-csv-opcode-to-binary~4170 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=e48d207b01ab590c2128eb54dc04f01ed028e4c0;p=libreriscv.git --- diff --git a/simple_v_extension/vblock_format/discussion.mdwn b/simple_v_extension/vblock_format/discussion.mdwn index c9f94f9bd..257799fcf 100644 --- a/simple_v_extension/vblock_format/discussion.mdwn +++ b/simple_v_extension/vblock_format/discussion.mdwn @@ -82,24 +82,24 @@ Example (contrived): * The specification for the 3rd add is therefore "ADD scalar-x9, scalar-x4, scalar-x4" * The 4th instruction. **despite** using x7 as vector in instruction 2, x7 is **not** listed in the 1st instruction's operands. Likewise for x4. Therefore the "OR" rule applies to them. -* x5 on the other hand *is* in the 1st instruction's operands, and, given that x4 abd x7 have the "OR" rule applied, are also marked as "vector" *despite x4 being fornerly scalar in the 3rd instruction*. +* x5 on the other hand *is* in the 1st instruction's operands, and, given that x4 and x7 have the "OR" rule applied, are also marked as "vector" *despite x4 being fornerly scalar in the 3rd instruction*. * Therefore, the "full" specification for the 4th add is: "ADD vector-x7, vector-x5, vector-x4" Writing those out separately, for clarity: - ADD vector-x3, vector-x5, scalar-x12 # from vs1=1, vs2=0, vd=vs1|vs2 - ADD vector-x7, vector-x5, vector-x3 # x7: v-x5 | v-x3 - ADD scalar-x9, scalar-x4, scalar-x4 # x9, x4 not prefixed, therefore scalar - ADD vector-x7, vector-x5, vector-x4 # x4, x7, x5 vector + ADD vector-x3, vector-x5, scalar-x12 # from vs1=1, vs2=0, vd=vs1|vs2 + ADD vector-x7, vector-x5, vector-x3 # x7: v-x5 | v-x3 + ADD scalar-x9, scalar-x4, scalar-x4 # x9, x4 not prefixed, therefore scalar + ADD vector-x7, vector-x5, vector-x4 # x4, x7, x5 vector -Twin-SVP mode allows certain registers to be explicitly marked as "scalar", -where some of the rules might otherwise start to cascade through and cause +Twin-SVP mode allows even more registers to be explicitly marked, including some specifically as "scalar", +where the rules might otherwise start to cascade through and cause registers to be come undesirably marked as "vectors". -The reason why the OR rule cannot cascade onwards is because if a trap occurs and the context has to be reestablished, it may be reestablished purely with the VBLOCK header and by decoding the first (and second) instruction. +The reason why the OR rule cannot cascade onwards is because if a trap occurs and the context has to be reestablished on return, it may be reestablished purely with the VBLOCK header and by decoding the first (and second) instruction. -If the cascade of what was marked "vector" was allowed to continue, it would require re-reading of every opcode up to the point where execution of the VBLOCK left off, on order to reestablish the full cascade context. +If the cascade of what was marked "vector" was allowed to continue, it would require re-reading of every opcode up to the point where execution of the VBLOCK left off, in order to reestablish the full cascade context. # Discussion