summaryrefslogtreecommitdiff
path: root/src/mem/port.hh
diff options
context:
space:
mode:
authorNathan Binkert <nate@binkert.org>2008-10-09 04:58:23 -0700
committerNathan Binkert <nate@binkert.org>2008-10-09 04:58:23 -0700
commit8291d9db0a0bdeecb2a13f28962893ed3659230e (patch)
treeccd4df59a41cd3d8e4ac35adc591315f44425479 /src/mem/port.hh
parent68c75c589b2e006292f623bd6428754d7d590f01 (diff)
downloadgem5-8291d9db0a0bdeecb2a13f28962893ed3659230e.tar.xz
eventq: Major API change for the Event and EventQueue structures.
Since the early days of M5, an event needed to know which event queue it was on, and that data was required at the time of construction of the event object. In the future parallelized M5, this sort of requirement does not work well since the proper event queue will not always be known at the time of construction of an event. Now, events are created, and the EventQueue itself has the schedule function, e.g. eventq->schedule(event, when). To simplify the syntax, I created a class called EventManager which holds a pointer to an EventQueue and provides the schedule interface that is a proxy for the EventQueue. The intent is that objects that frequently schedule events can be derived from EventManager and then they have the schedule interface. SimObject and Port are examples of objects that will become EventManagers. The end result is that any SimObject can just call schedule(event, when) and it will just call that SimObject's eventq->schedule function. Of course, some objects may have more than one EventQueue, so this interface might not be perfect for those, but they should be relatively few.
Diffstat (limited to 'src/mem/port.hh')
-rw-r--r--src/mem/port.hh11
1 files changed, 5 insertions, 6 deletions
diff --git a/src/mem/port.hh b/src/mem/port.hh
index 15fda2164..1d9135ae6 100644
--- a/src/mem/port.hh
+++ b/src/mem/port.hh
@@ -47,6 +47,7 @@
#include "base/range.hh"
#include "mem/packet.hh"
#include "mem/request.hh"
+#include "sim/eventq.hh"
/** This typedef is used to clean up the parameter list of
* getDeviceAddressRanges() and getPeerAddressRanges(). It's declared
@@ -58,6 +59,7 @@
typedef std::list<Range<Addr> > AddrRangeList;
typedef std::list<Range<Addr> >::iterator AddrRangeIter;
+class EventQueue;
class MemObject;
/**
@@ -71,7 +73,7 @@ class MemObject;
* Send accessor functions are being called from the device the port is
* associated with, and it will call the peer recv. accessor function.
*/
-class Port
+class Port : public EventManager
{
protected:
/** Descriptive name (for DPRINTF output) */
@@ -86,9 +88,6 @@ class Port
MemObject *owner;
public:
-
- Port();
-
/**
* Constructor.
*
@@ -97,7 +96,7 @@ class Port
* @param _owner Pointer to the MemObject that owns this port.
* Will not necessarily be set.
*/
- Port(const std::string &_name, MemObject *_owner = NULL);
+ Port(const std::string &_name, MemObject *_owner);
/** Return port name (for DPRINTF). */
const std::string &name() const { return portName; }
@@ -121,7 +120,7 @@ class Port
Port *getPeer() { return peer; }
/** Function to set the owner of this port. */
- void setOwner(MemObject *_owner) { owner = _owner; }
+ void setOwner(MemObject *_owner);
/** Function to return the owner of this port. */
MemObject *getOwner() { return owner; }