ruby: slicc: remove nextLineHack from Type.py
[gem5.git] / src / mem / tport.hh
index 91706fbe9374b443bcd1ee0381e8be8f9308d8cb..166a23125b09a10d3eb0a3d0a94b19de4ec015b9 100644 (file)
 
 /**
  * The simple timing port uses a queued port to implement
- * recvFunctional and recvTiming through recvAtomic. It is always a
+ * recvFunctional and recvTimingReq through recvAtomic. It is always a
  * slave port.
  */
 class SimpleTimingPort : public QueuedSlavePort
 {
 
-  protected:
+  private:
 
-    /** The packet queue used to store outgoing responses. */
-    PacketQueue queue;
+    /**
+     * The packet queue used to store outgoing responses. Note that
+     * the queue is made private and that we avoid overloading the
+     * name used in the QueuedSlavePort. Access is provided through
+     * the queue reference in the base class.
+     */
+    RespPacketQueue queueImpl;
+
+  protected:
 
     /** Implemented using recvAtomic(). */
     void recvFunctional(PacketPtr pkt);
 
     /** Implemented using recvAtomic(). */
-    bool recvTiming(PacketPtr pkt);
+    bool recvTimingReq(PacketPtr pkt);
 
     virtual Tick recvAtomic(PacketPtr pkt) = 0;
 
+    /**
+     * @todo this is a temporary workaround until the 4-phase code is committed.
+     * upstream caches need this packet until true is returned, so hold it for
+     * deletion until a subsequent call
+     */
+    std::vector<PacketPtr> pendingDelete;
+
+
   public:
 
     /**
      * Create a new SimpleTimingPort that relies on a packet queue to
-     * hold responses, and implements recvTiming and recvFunctional
+     * hold responses, and implements recvTimingReq and recvFunctional
      * through calls to recvAtomic. Once a request arrives, it is
      * passed to recvAtomic, and in the case of a timing access any
      * response is scheduled to be sent after the delay of the atomic