> Could you sketch out what the code would look like to do this?
Something like this:
struct InfoMessage
{
virtual ~InfoMessage() {}
};
class Port
{
bool sendInfoMessage(InfoMessage *ir) { return peer->recvInfoMessage(ir); }
virtual bool recvInfoMessage(InfoMessage *ir) = 0;
};
struct BlockSizeRequest : public InfoMessage
{
int blockSize;
};
struct AddressRangesRequest : public InfoMessage
{
AddrRangeList ranges;
bool snoop;
};
class MyPort : public Port
{
bool
recvInfoMessage(InfoMessage *ir)
{
BlockSizeRequest *bsr = dynamic_cast<BlockSizeRequest *>(ir);
if (bsr) {
bsr->blockSize = blockSize;
return true;
}
AddressRangeRequest *arr = dynamic_cast<AddressRangesRequest *>(ir);
if (arr) {
arr->ranges = foo;
arr->snoop = false;
return true;
}
return false;
}
};
>> It seems to me that the printAddr mechanism that Steve did could also
>> be folded into this mechanism as well (instead of hijacking
>> sendFunctional). Maybe this one is going too far, but for the other
>> ones, I don't see a good reason not to do this.
>
> Seems like that might be too far.
>
>> One thing that is interesting no matter what we choose is what to do
>> when an object doesn't know about an information request type. Should
>> we just pass the request through the object (and broadcast it in the
>> case of networks/busses), or should we error out?
>
> I would imagine it should pass it on, maybe printing a warning?
>
> Ali
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
