From 2d9a42674c81d364334f4e033f881d5b742d4e7b Mon Sep 17 00:00:00 2001 From: lkcl Date: Thu, 29 Aug 2019 09:58:51 +0100 Subject: [PATCH] --- simple_v_extension/specification/sv.setvl.mdwn | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/simple_v_extension/specification/sv.setvl.mdwn b/simple_v_extension/specification/sv.setvl.mdwn index fb4f6752d..6b0472708 100644 --- a/simple_v_extension/specification/sv.setvl.mdwn +++ b/simple_v_extension/specification/sv.setvl.mdwn @@ -120,6 +120,17 @@ GETVL add1 SETVL is a pain. 3 operations because VL is a CSR it is not possible What about actually marking one of the registers *as* VL? this would save a *lot* of instructions. + + + (2) as it is the only one, VL may be hardware-cached, i.e. the fact that it points to a scalar register, well, that's only 5 bits: that's not very much to pass round and through pipelines. + + (3) if it's not very much to pass around, then the possibility exists to *rewrite* a CSRR VL instruction to become a MV operation, *at execution time*! + + yes, really: at instruction *decode* time, with there being only the 5 bits to check "if VL-cache-register is non-zero and CSR register == VL", it's really not that much extra logic to *directly* substitute the CSRR instruction with "MV rd, VL-where-VL-is-actually-the-contents-of-the-VL-cache" + + that would then allow the substituted-instruction to go directly into dependency-tracking *on the scalar register*, nipping in the bud the need for special CSR-related dependency logic, and no longer requiring the sub-par "stall" solution, either. + + ---- Setting VL from an immed without altering MVL is not possible in the above pseudocode. It is covered by VLtyp and the VL block in VBLOCK, however is that enough? -- 2.30.2