Rename Port address range functions... like the block size

functions, the send/recv*Query naming seems awkward.
Also create a typedef for AddrRangeList.

--HG--
extra : convert_revision : dd0ff3fad06ec329c82c199700d0a6264f1271d3
This commit is contained in:
Steve Reinhardt 2006-02-21 12:32:45 -05:00
parent 00264ff1b8
commit 944646124e
3 changed files with 18 additions and 13 deletions

View file

@ -50,8 +50,7 @@ class PioPort : public Port
virtual void recvFunctional(Packet &pkt) virtual void recvFunctional(Packet &pkt)
{ device->recvAtomic(pkt) }; { device->recvAtomic(pkt) };
virtual void recvAddressRangeQuery(std::list<Range<Addr> > &range_list, virtual void getDeviceAddressRanges(AddrRangeList &range_list, bool &owner)
bool &owner)
{ device->addressRanges(range_list, owner); } { device->addressRanges(range_list, owner); }
void sendTiming(Packet &pkt, Tick time) void sendTiming(Packet &pkt, Tick time)
@ -101,8 +100,7 @@ class DmaPort : public Port
virtual Packet *recvRetry() virtual Packet *recvRetry()
{ return transmitList.pop_front(); } { return transmitList.pop_front(); }
virtual void recvAddressRangeQuery(std::list<Range<Addr> > &range_list, virtual void getDeviceAddressRanges(AddrRangeList &range_list, bool &owner)
bool &owner)
{ range_list.clear(); owner = true; } { range_list.clear(); owner = true; }
void dmaAction(Memory::Command cmd, DmaPort port, Addr addr, int size, void dmaAction(Memory::Command cmd, DmaPort port, Addr addr, int size,
@ -146,8 +144,7 @@ class PioDevice : public SimObject
PioPort *pioPort; PioPort *pioPort;
virtual void addressRanges(std::list<Range<Addr> > &range_list, virtual void addressRanges(AddrRangeList &range_list, bool &owner) = 0;
bool &owner) = 0;
virtual read(Packet &pkt) = 0; virtual read(Packet &pkt) = 0;

View file

@ -103,8 +103,7 @@ class Bus : public MemObject
// downstream from this bus, yes? That is, the union of all // downstream from this bus, yes? That is, the union of all
// the 'owned' address ranges of all the other interfaces on // the 'owned' address ranges of all the other interfaces on
// this bus... // this bus...
virtual void addressRanges(std::list<Range<Addr> > &range_list, virtual void addressRanges(AddrRangeList &range_list, bool &owner);
bool &owner);
}; };
/** A count of the number of interfaces connected to this bus. */ /** A count of the number of interfaces connected to this bus. */

View file

@ -46,6 +46,15 @@
#include "mem/packet.hh" #include "mem/packet.hh"
#include "mem/request.hh" #include "mem/request.hh"
/** This typedef is used to clean up the parameter list of
* getDeviceAddressRanges() and getPeerAddressRanges(). It's declared
* outside the Port object since it's also used by some mem objects.
* Eventually we should move this typedef to wherever Addr is
* defined.
*/
typedef std::list<Range<Addr> > AddrRangeList;
/** /**
* Ports are used to interface memory objects to * Ports are used to interface memory objects to
* each other. They will always come in pairs, and we refer to the other * each other. They will always come in pairs, and we refer to the other
@ -123,8 +132,9 @@ class Port
an object wants to own some ranges and snoop on others, it will an object wants to own some ranges and snoop on others, it will
need to use two different ports. need to use two different ports.
*/ */
virtual void recvAddressRangesQuery(std::list<Range<Addr> > &range_list, virtual void getDeviceAddressRanges(AddrRangeList &range_list,
bool &owner) { panic("??"); } bool &owner)
{ panic("??"); }
public: public:
@ -172,9 +182,8 @@ class Port
/** Called by the associated device if it wishes to find out the address /** Called by the associated device if it wishes to find out the address
ranges connected to the peer ports devices. ranges connected to the peer ports devices.
*/ */
void sendAddressRangesQuery(std::list<Range<Addr> > &range_list, void getPeerAddressRanges(AddrRangeList &range_list, bool &owner)
bool &owner) { peer->getDeviceAddressRanges(range_list, owner); }
{ peer->recvAddressRangesQuery(range_list, owner); }
// Do we need similar wrappers for sendAtomic()? If not, should // Do we need similar wrappers for sendAtomic()? If not, should
// we drop the "Functional" from the names? // we drop the "Functional" from the names?