From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Date: Wed, 26 Sep 2018 10:14:24 +0000 (+0100)
Subject: clarify comments on (key strategic) sv_insn_t::remap function
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=ad4329be9ba00d13a992d98a6a89f5ca24977094;p=riscv-isa-sim.git

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

diff --git a/riscv/sv.cc b/riscv/sv.cc
index 0ec5ce7..e665f69 100644
--- 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;