From 2c59a34348447ed751e2be9fd7dbcf868a204dcc Mon Sep 17 00:00:00 2001 From: lkcl Date: Sun, 23 Jun 2019 19:35:02 +0100 Subject: [PATCH] --- simple_v_extension/specification.mdwn | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/simple_v_extension/specification.mdwn b/simple_v_extension/specification.mdwn index c24340946..6ad8f0a8f 100644 --- a/simple_v_extension/specification.mdwn +++ b/simple_v_extension/specification.mdwn @@ -2330,8 +2330,10 @@ Notes: number of bits is 80 + 16 times IL. Standard RV32, RVC and also SVPrefix (P48/64-\*-Type) instructions fit into this space, after the (optional) VL / RegCam / PredCam entries -* Anything - any registers - within the VLIW-prefixed format *MUST* have the - RegCam and PredCam entries applied to it. +* In any RVC or 32 Bit opcode, any registers within the VLIW-prefixed format *MUST* have the + RegCam and PredCam entries applied to the operation + (and the Vectorisation loop activated) +* P48 and P64 opcodes do **not** take their Register or predication context from the VLIW Block tables: they do however have VL or SUBVL applied (unless VLtyp or svlen are set). * At the end of the VLIW Group, the RegCam and PredCam entries *no longer apply*. VL, MAXVL and SUBVL on the other hand remain at the values set by the last instruction (whether a CSRRW or the VL @@ -2363,6 +2365,8 @@ needed, more space is saved by using the 8 bit formats. In this light, embedding the VL/MAXVL, PredCam and RegCam CSR entries into a VLIW format makes a lot of sense. +Bear in mind the warning in an earlier section that use of VLtyp or svlen in a P48 or P64 opcode within a VLIW Group will result in corruption (use) of the STATE CSR, as the STATE CSR is shared with SVPrefix. To avoid this situation, the STATE CSR may be copied into a temp register and restored afterwards. + Open Questions: * Is it necessary to stick to the RISC-V 1.5 format? Why not go with -- 2.30.2