(no commit message)

diff --git a/simple_v_extension/specification/sv.setvl.mdwn b/simple_v_extension/specification/sv.setvl.mdwn
index fb4f6752d32a1317a99b3d1502bf71c01f513354..6b0472708225343e86ba9d81a0e73f67e9f53128 100644 (file)
--- 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.
 
+<https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/7lt9YNCR_bI/8Hh2-UY6AAAJ>
+
+    (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?