Clock: Add a Cycles wrapper class and use where applicable

This patch addresses the comments and feedback on the preceding patch
that reworks the clocks and now more clearly shows where cycles
(relative cycle counts) are used to express time.

Instead of bumping the existing patch I chose to make this a separate
patch, merely to try and focus the discussion around a smaller set of
changes. The two patches will be pushed together though.

This changes done as part of this patch are mostly following directly
from the introduction of the wrapper class, and change enough code to
make things compile and run again. There are definitely more places
where int/uint/Tick is still used to represent cycles, and it will
take some time to chase them all down. Similarly, a lot of parameters
should be changed from Param.Tick and Param.Unsigned to
Param.Cycles.

In addition, the use of curTick is questionable as there should not be
an absolute cycle. Potential solutions can be built on top of this
patch. There is a similar situation in the o3 CPU where
lastRunningCycle is currently counting in Cycles, and is still an
absolute time. More discussion to be had in other words.

An additional change that would be appropriate in the future is to
perform a similar wrapping of Tick and probably also introduce a
Ticks class along with suitable operators for all these classes.

1 files changed, 57 insertions, 0 deletions

diff --git a/src/base/types.hh b/src/base/types.hh
index ba6d53ad7..4caf92c97 100644
--- a/src/base/types.hh
+++ b/src/base/types.hh
@@ -39,6 +39,8 @@
 
 #include <inttypes.h>
 
+#include <cassert>
+
 /** uint64_t constant */
 #define ULL(N)          ((uint64_t)N##ULL)
 /** int64_t constant */
@@ -58,6 +60,61 @@ typedef uint64_t Tick;
 const Tick MaxTick = ULL(0xffffffffffffffff);
 
 /**
+ * Cycles is a wrapper class for representing cycle counts, i.e. a
+ * relative difference between two points in time, expressed in a
+ * number of clock cycles.
+ *
+ * The Cycles wrapper class is a type-safe alternative to a
+ * typedef, aiming to avoid unintentional mixing of cycles and ticks
+ * in the code base.
+ *
+ * Operators are defined inside an ifndef block to avoid swig touching
+ * them. Note that there is no overloading of the bool operator as the
+ * compiler is allowed to turn booleans into integers and this causes
+ * a whole range of issues in a handful locations. The solution to
+ * this problem would be to use the safe bool idiom, but for now we
+ * make do without the test and use the more elaborate comparison >
+ * Cycles(0).
+ */
+class Cycles
+{
+
+  private:
+
+    /** Member holding the actual value. */
+    uint64_t c;
+
+  public:
+
+    /** Explicit constructor assigning a value. */
+    explicit Cycles(uint64_t _c) : c(_c) { }
+
+#ifndef SWIG // keep the operators away from SWIG
+
+    /** Converting back to the value type. */
+    operator uint64_t() const { return c; }
+
+    /** Prefix increment operator. */
+    Cycles& operator++()
+    { ++c; return *this; }
+
+    /** Prefix decrement operator. Is only temporarily used in the O3 CPU. */
+    Cycles& operator--()
+    { assert(c != 0); --c; return *this; }
+
+    /** In-place addition of cycles. */
+    const Cycles& operator+=(const Cycles& cc)
+    { c += cc.c; return *this; }
+
+    /** Greater than comparison used for > Cycles(0). */
+    bool operator>(const Cycles& cc) const
+    { return c > cc.c; }
+
+#endif // SWIG not touching operators
+
+};
+
+/**
  * Address type
  * This will probably be moved somewhere else in the near future.
  * This should be at least as big as the biggest address width in use