clarify comments on (key strategic) sv_insn_t::remap function

diff --git a/riscv/sv.cc b/riscv/sv.cc
index 0ec5ce73406e2d6d105c38e725c6626c936e8804..e665f69662441aa09c18bcc28a10fa8bb8065cff 100644 (file)
--- a/riscv/sv.cc
+++ b/riscv/sv.cc
@@ -29,10 +29,26 @@ bool sv_check_reg(bool intreg, uint64_t reg)
   return false;
 }
 
+/* this is the "remap" function.  note that registers can STILL BE REDIRECTED
+ * yet NOT BE MARKED AS A VECTOR.
+ *
+ * reg 5 -> active=false, regidx=XX, isvec=XX     -> returns 5
+ * reg 5 -> active=true , regidx=35, isvec=false  -> returns 35
+ * reg 5 -> active=true , regidx=35, isvec=true   -> returns 35 *PLUS LOOP*
+ *
+ * so it is possible for example to use the remap system for C  instructions
+ * to get access to the *full* range of registers x0..x63 (yes 63 because
+ * SV doubles both the int and fp regfile sizes), by setting
+ * "active=true, isvec=false" for any of x8..x15
+ *
+ * where "active=true, isvec=true" this is the "expected" behaviour
+ * of SV.  it's "supposed" to "just" be a vectorisation API. it isn't:
+ * it's quite a bit more.
+ */
 uint64_t sv_insn_t::remap(uint64_t reg, bool intreg)
 {
   // okaay so first determine which map to use.  intreg is passed
-  // in (ultimately) from the examination of the use of
+  // in (ultimately) from id_regs.py's examination of the use of
   // FRS1/RS1, WRITE_FRD/WRITE_RD, which in turn gets passed
   // in from sv_insn_t::fimap...
   sv_reg_entry *r;