2006-01-31 18:12:49 +01:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2002-2005 The Regents of The University of Michigan
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions are
|
|
|
|
* met: redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer;
|
|
|
|
* redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution;
|
|
|
|
* neither the name of the copyright holders nor the names of its
|
|
|
|
* contributors may be used to endorse or promote products derived from
|
|
|
|
* this software without specific prior written permission.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
|
|
|
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
|
|
|
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
|
|
|
|
* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
|
|
|
|
* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
|
|
|
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
|
|
|
|
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
|
|
|
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
|
|
|
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
|
|
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
|
|
|
|
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
2006-06-01 01:26:56 +02:00
|
|
|
*
|
|
|
|
* Authors: Ron Dreslinski
|
2006-01-31 18:12:49 +01:00
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @file
|
2006-08-15 01:25:07 +02:00
|
|
|
* Port Object Declaration. Ports are used to interface memory objects to
|
2006-01-31 18:12:49 +01:00
|
|
|
* each other. They will always come in pairs, and we refer to the other
|
|
|
|
* port object as the peer. These are used to make the design more
|
|
|
|
* modular so that a specific interface between every type of objcet doesn't
|
|
|
|
* have to be created.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef __MEM_PORT_HH__
|
|
|
|
#define __MEM_PORT_HH__
|
|
|
|
|
|
|
|
#include <list>
|
|
|
|
|
2006-03-11 01:11:27 +01:00
|
|
|
#include "base/misc.hh"
|
2006-01-31 18:12:49 +01:00
|
|
|
#include "base/range.hh"
|
2009-05-17 23:34:51 +02:00
|
|
|
#include "base/types.hh"
|
2006-01-31 18:12:49 +01:00
|
|
|
#include "mem/packet.hh"
|
|
|
|
#include "mem/request.hh"
|
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.
2008-10-09 13:58:23 +02:00
|
|
|
#include "sim/eventq.hh"
|
2006-01-31 18:12:49 +01:00
|
|
|
|
2006-02-21 18:32:45 +01:00
|
|
|
/** 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;
|
2006-04-06 06:51:46 +02:00
|
|
|
typedef std::list<Range<Addr> >::iterator AddrRangeIter;
|
2006-02-21 18:32:45 +01:00
|
|
|
|
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.
2008-10-09 13:58:23 +02:00
|
|
|
class EventQueue;
|
2006-10-31 19:59:30 +01:00
|
|
|
class MemObject;
|
|
|
|
|
2006-01-31 18:12:49 +01:00
|
|
|
/**
|
|
|
|
* Ports are used to interface memory objects to
|
|
|
|
* each other. They will always come in pairs, and we refer to the other
|
|
|
|
* port object as the peer. These are used to make the design more
|
|
|
|
* modular so that a specific interface between every type of objcet doesn't
|
|
|
|
* have to be created.
|
|
|
|
*
|
|
|
|
* Recv accesor functions are being called from the peer interface.
|
|
|
|
* Send accessor functions are being called from the device the port is
|
|
|
|
* associated with, and it will call the peer recv. accessor function.
|
|
|
|
*/
|
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.
2008-10-09 13:58:23 +02:00
|
|
|
class Port : public EventManager
|
2006-01-31 18:12:49 +01:00
|
|
|
{
|
2008-06-16 06:34:32 +02:00
|
|
|
protected:
|
2006-05-26 19:48:35 +02:00
|
|
|
/** Descriptive name (for DPRINTF output) */
|
2006-06-25 06:24:50 +02:00
|
|
|
mutable std::string portName;
|
2006-05-26 19:48:35 +02:00
|
|
|
|
2006-05-31 01:49:28 +02:00
|
|
|
/** A pointer to the peer port. Ports always come in pairs, that way they
|
|
|
|
can use a standardized interface to communicate between different
|
|
|
|
memory objects. */
|
|
|
|
Port *peer;
|
|
|
|
|
2006-10-31 19:59:30 +01:00
|
|
|
/** A pointer to the MemObject that owns this port. This may not be set. */
|
|
|
|
MemObject *owner;
|
|
|
|
|
2006-01-31 18:12:49 +01:00
|
|
|
public:
|
2006-05-26 19:48:35 +02:00
|
|
|
/**
|
|
|
|
* Constructor.
|
|
|
|
*
|
|
|
|
* @param _name Port name for DPRINTF output. Should include name
|
|
|
|
* of memory system object to which the port belongs.
|
2006-10-31 19:59:30 +01:00
|
|
|
* @param _owner Pointer to the MemObject that owns this port.
|
2008-06-28 19:19:38 +02:00
|
|
|
* Will not necessarily be set.
|
2006-05-26 19:48:35 +02:00
|
|
|
*/
|
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.
2008-10-09 13:58:23 +02:00
|
|
|
Port(const std::string &_name, MemObject *_owner);
|
2006-05-26 19:48:35 +02:00
|
|
|
|
|
|
|
/** Return port name (for DPRINTF). */
|
|
|
|
const std::string &name() const { return portName; }
|
|
|
|
|
2008-06-16 06:34:32 +02:00
|
|
|
virtual ~Port();
|
2006-05-26 19:48:35 +02:00
|
|
|
|
2006-01-31 18:12:49 +01:00
|
|
|
// mey be better to use subclasses & RTTI?
|
2006-05-31 00:57:42 +02:00
|
|
|
/** Holds the ports status. Currently just that a range recomputation needs
|
|
|
|
* to be done. */
|
2006-01-31 18:12:49 +01:00
|
|
|
enum Status {
|
2006-10-09 00:48:03 +02:00
|
|
|
RangeChange
|
2006-01-31 18:12:49 +01:00
|
|
|
};
|
|
|
|
|
2008-06-28 19:19:38 +02:00
|
|
|
void setName(const std::string &name)
|
|
|
|
{ portName = name; }
|
|
|
|
|
2006-10-31 19:59:30 +01:00
|
|
|
/** Function to set the pointer for the peer port. */
|
2007-03-09 16:06:09 +01:00
|
|
|
virtual void setPeer(Port *port);
|
2006-01-31 18:12:49 +01:00
|
|
|
|
2006-10-31 19:59:30 +01:00
|
|
|
/** Function to get the pointer to the peer port. */
|
2006-02-22 02:04:23 +01:00
|
|
|
Port *getPeer() { return peer; }
|
2006-02-21 19:39:01 +01:00
|
|
|
|
2008-06-28 19:19:38 +02:00
|
|
|
/** Function to set the owner of this port. */
|
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.
2008-10-09 13:58:23 +02:00
|
|
|
void setOwner(MemObject *_owner);
|
2008-06-28 19:19:38 +02:00
|
|
|
|
2006-10-31 19:59:30 +01:00
|
|
|
/** Function to return the owner of this port. */
|
|
|
|
MemObject *getOwner() { return owner; }
|
|
|
|
|
2008-06-28 19:19:38 +02:00
|
|
|
/** Inform the peer port to delete itself and notify it's owner about it's
|
|
|
|
* demise. */
|
|
|
|
void removeConn();
|
2007-03-09 00:57:15 +01:00
|
|
|
|
2008-06-16 06:34:32 +02:00
|
|
|
virtual bool isDefaultPort() const { return false; }
|
|
|
|
|
|
|
|
bool isConnected() { return peer && !peer->isDefaultPort(); }
|
2007-03-09 00:57:15 +01:00
|
|
|
|
2006-01-31 18:12:49 +01:00
|
|
|
protected:
|
|
|
|
|
2006-02-21 18:20:02 +01:00
|
|
|
/** These functions are protected because they should only be
|
|
|
|
* called by a peer port, never directly by any outside object. */
|
|
|
|
|
2006-01-31 18:12:49 +01:00
|
|
|
/** Called to recive a timing call from the peer port. */
|
2006-10-20 09:10:12 +02:00
|
|
|
virtual bool recvTiming(PacketPtr pkt) = 0;
|
2006-01-31 18:12:49 +01:00
|
|
|
|
|
|
|
/** Called to recive a atomic call from the peer port. */
|
2006-10-20 09:10:12 +02:00
|
|
|
virtual Tick recvAtomic(PacketPtr pkt) = 0;
|
2006-01-31 18:12:49 +01:00
|
|
|
|
|
|
|
/** Called to recive a functional call from the peer port. */
|
2006-10-20 09:10:12 +02:00
|
|
|
virtual void recvFunctional(PacketPtr pkt) = 0;
|
2006-01-31 18:12:49 +01:00
|
|
|
|
|
|
|
/** Called to recieve a status change from the peer port. */
|
|
|
|
virtual void recvStatusChange(Status status) = 0;
|
|
|
|
|
|
|
|
/** Called by a peer port if the send was unsuccesful, and had to
|
|
|
|
wait. This shouldn't be valid for response paths (IO Devices).
|
|
|
|
so it is set to panic if it isn't already defined.
|
|
|
|
*/
|
2006-05-31 00:57:42 +02:00
|
|
|
virtual void recvRetry() { panic("??"); }
|
2006-01-31 18:12:49 +01:00
|
|
|
|
|
|
|
/** Called by a peer port in order to determine the block size of the
|
|
|
|
device connected to this port. It sometimes doesn't make sense for
|
2007-05-07 20:42:03 +02:00
|
|
|
this function to be called, so it just returns 0. Anytthing that is
|
|
|
|
concerned with the size should just ignore that.
|
2006-01-31 18:12:49 +01:00
|
|
|
*/
|
2009-06-05 08:21:12 +02:00
|
|
|
virtual unsigned deviceBlockSize() const { return 0; }
|
2006-01-31 18:12:49 +01:00
|
|
|
|
|
|
|
/** The peer port is requesting us to reply with a list of the ranges we
|
|
|
|
are responsible for.
|
2006-04-06 06:51:46 +02:00
|
|
|
@param resp is a list of ranges responded to
|
|
|
|
@param snoop is a list of ranges snooped
|
2006-01-31 18:12:49 +01:00
|
|
|
*/
|
2006-04-06 06:51:46 +02:00
|
|
|
virtual void getDeviceAddressRanges(AddrRangeList &resp,
|
2007-05-22 08:36:09 +02:00
|
|
|
bool &snoop)
|
2006-02-21 18:32:45 +01:00
|
|
|
{ panic("??"); }
|
2006-01-31 18:12:49 +01:00
|
|
|
|
|
|
|
public:
|
|
|
|
|
|
|
|
/** Function called by associated memory device (cache, memory, iodevice)
|
|
|
|
in order to send a timing request to the port. Simply calls the peer
|
|
|
|
port receive function.
|
|
|
|
@return This function returns if the send was succesful in it's
|
|
|
|
recieve. If it was a failure, then the port will wait for a recvRetry
|
2006-05-31 00:57:42 +02:00
|
|
|
at which point it can possibly issue a successful sendTiming. This is used in
|
2006-01-31 18:12:49 +01:00
|
|
|
case a cache has a higher priority request come in while waiting for
|
|
|
|
the bus to arbitrate.
|
|
|
|
*/
|
2006-10-20 09:10:12 +02:00
|
|
|
bool sendTiming(PacketPtr pkt) { return peer->recvTiming(pkt); }
|
2006-01-31 18:12:49 +01:00
|
|
|
|
2006-05-31 04:30:42 +02:00
|
|
|
/** Function called by the associated device to send an atomic
|
|
|
|
* access, an access in which the data is moved and the state is
|
|
|
|
* updated in one cycle, without interleaving with other memory
|
|
|
|
* accesses. Returns estimated latency of access.
|
|
|
|
*/
|
2006-10-20 09:10:12 +02:00
|
|
|
Tick sendAtomic(PacketPtr pkt)
|
2006-01-31 18:12:49 +01:00
|
|
|
{ return peer->recvAtomic(pkt); }
|
|
|
|
|
|
|
|
/** Function called by the associated device to send a functional access,
|
|
|
|
an access in which the data is instantly updated everywhere in the
|
2006-03-31 01:06:00 +02:00
|
|
|
memory system, without affecting the current state of any block or
|
|
|
|
moving the block.
|
2006-01-31 18:12:49 +01:00
|
|
|
*/
|
2006-10-20 09:10:12 +02:00
|
|
|
void sendFunctional(PacketPtr pkt)
|
2006-01-31 18:12:49 +01:00
|
|
|
{ return peer->recvFunctional(pkt); }
|
|
|
|
|
|
|
|
/** Called by the associated device to send a status change to the device
|
|
|
|
connected to the peer interface.
|
|
|
|
*/
|
|
|
|
void sendStatusChange(Status status) {peer->recvStatusChange(status); }
|
|
|
|
|
|
|
|
/** When a timing access doesn't return a success, some time later the
|
|
|
|
Retry will be sent.
|
|
|
|
*/
|
2006-05-31 00:57:42 +02:00
|
|
|
void sendRetry() { return peer->recvRetry(); }
|
2006-01-31 18:12:49 +01:00
|
|
|
|
|
|
|
/** Called by the associated device if it wishes to find out the blocksize
|
|
|
|
of the device on attached to the peer port.
|
|
|
|
*/
|
2009-06-05 08:21:12 +02:00
|
|
|
unsigned peerBlockSize() const { return peer->deviceBlockSize(); }
|
2006-01-31 18:12:49 +01:00
|
|
|
|
|
|
|
/** Called by the associated device if it wishes to find out the address
|
|
|
|
ranges connected to the peer ports devices.
|
|
|
|
*/
|
2007-05-22 08:36:09 +02:00
|
|
|
void getPeerAddressRanges(AddrRangeList &resp, bool &snoop)
|
2006-04-06 06:51:46 +02:00
|
|
|
{ peer->getDeviceAddressRanges(resp, snoop); }
|
2006-01-31 18:12:49 +01:00
|
|
|
|
|
|
|
/** This function is a wrapper around sendFunctional()
|
|
|
|
that breaks a larger, arbitrarily aligned access into
|
|
|
|
appropriate chunks. The default implementation can use
|
|
|
|
getBlockSize() to determine the block size and go from there.
|
|
|
|
*/
|
2006-03-30 22:59:49 +02:00
|
|
|
virtual void readBlob(Addr addr, uint8_t *p, int size);
|
2006-01-31 18:12:49 +01:00
|
|
|
|
|
|
|
/** This function is a wrapper around sendFunctional()
|
|
|
|
that breaks a larger, arbitrarily aligned access into
|
|
|
|
appropriate chunks. The default implementation can use
|
|
|
|
getBlockSize() to determine the block size and go from there.
|
|
|
|
*/
|
2006-03-30 22:59:49 +02:00
|
|
|
virtual void writeBlob(Addr addr, uint8_t *p, int size);
|
2006-01-31 18:12:49 +01:00
|
|
|
|
|
|
|
/** Fill size bytes starting at addr with byte value val. This
|
|
|
|
should not need to be virtual, since it can be implemented in
|
2006-03-12 22:38:16 +01:00
|
|
|
terms of writeBlob(). However, it shouldn't be
|
2006-01-31 18:12:49 +01:00
|
|
|
performance-critical either, so it could be if we wanted to.
|
|
|
|
*/
|
2006-03-30 22:59:49 +02:00
|
|
|
virtual void memsetBlob(Addr addr, uint8_t val, int size);
|
2006-02-21 17:27:53 +01:00
|
|
|
|
2008-01-02 21:20:15 +01:00
|
|
|
/** Inject a PrintReq for the given address to print the state of
|
|
|
|
* that address throughout the memory system. For debugging.
|
|
|
|
*/
|
|
|
|
void printAddr(Addr a);
|
|
|
|
|
2006-02-21 17:27:53 +01:00
|
|
|
private:
|
|
|
|
|
|
|
|
/** Internal helper function for read/writeBlob().
|
|
|
|
*/
|
2007-02-07 19:53:37 +01:00
|
|
|
void blobHelper(Addr addr, uint8_t *p, int size, MemCmd cmd);
|
2006-01-31 18:12:49 +01:00
|
|
|
};
|
|
|
|
|
2006-03-31 01:06:00 +02:00
|
|
|
/** A simple functional port that is only meant for one way communication to
|
|
|
|
* physical memory. It is only meant to be used to load data into memory before
|
|
|
|
* the simulation begins.
|
|
|
|
*/
|
|
|
|
|
|
|
|
class FunctionalPort : public Port
|
|
|
|
{
|
|
|
|
public:
|
2006-10-31 19:59:30 +01:00
|
|
|
FunctionalPort(const std::string &_name, MemObject *_owner = NULL)
|
|
|
|
: Port(_name, _owner)
|
2006-05-26 19:48:35 +02:00
|
|
|
{}
|
|
|
|
|
2006-08-31 01:24:26 +02:00
|
|
|
protected:
|
2007-01-27 00:48:51 +01:00
|
|
|
virtual bool recvTiming(PacketPtr pkt) { panic("FuncPort is UniDir");
|
|
|
|
M5_DUMMY_RETURN }
|
|
|
|
virtual Tick recvAtomic(PacketPtr pkt) { panic("FuncPort is UniDir");
|
|
|
|
M5_DUMMY_RETURN }
|
2006-10-20 09:10:12 +02:00
|
|
|
virtual void recvFunctional(PacketPtr pkt) { panic("FuncPort is UniDir"); }
|
2006-04-29 23:37:25 +02:00
|
|
|
virtual void recvStatusChange(Status status) {}
|
2006-03-31 01:06:00 +02:00
|
|
|
|
2006-08-31 01:24:26 +02:00
|
|
|
public:
|
2006-06-09 01:03:58 +02:00
|
|
|
/** a write function that also does an endian conversion. */
|
|
|
|
template <typename T>
|
|
|
|
inline void writeHtoG(Addr addr, T d);
|
|
|
|
|
|
|
|
/** a read function that also does an endian conversion. */
|
|
|
|
template <typename T>
|
|
|
|
inline T readGtoH(Addr addr);
|
|
|
|
|
2006-04-06 06:51:46 +02:00
|
|
|
template <typename T>
|
|
|
|
inline void write(Addr addr, T d)
|
|
|
|
{
|
|
|
|
writeBlob(addr, (uint8_t*)&d, sizeof(T));
|
|
|
|
}
|
|
|
|
|
|
|
|
template <typename T>
|
|
|
|
inline T read(Addr addr)
|
|
|
|
{
|
|
|
|
T d;
|
|
|
|
readBlob(addr, (uint8_t*)&d, sizeof(T));
|
|
|
|
return d;
|
|
|
|
}
|
|
|
|
};
|
2006-03-31 01:06:00 +02:00
|
|
|
|
2006-01-31 18:12:49 +01:00
|
|
|
#endif //__MEM_PORT_HH__
|