Comments below:

> > I have a couple questions:
> > - Why do you modify the msg.sm files?  It seems unecessary.
> 
> Each class that inherits from the Message/NetworkMessage class can
> potentially hold the <address, datablock> that needs to be accessed
> functionally. The question here is what assumptions do we want to make on
> these classes. I am trying to strive for a solution where we do not have any
> restrictions. For example, can we assume that each of these classes will have
> exactly one data block?

Yes, this is a tradeoff of flexibility vs. elegance.  Certainly Ruby/Slicc has 
precedence to favor the former.  I'm not excited to have to modify all msg.sm 
files to support functional accesses, but maybe I/we were fooling ourselves 
earlier that support functional accesses could be relatively invisible to the 
slicc programmer.  This change puts that hope to rest.  Oh well.  I don't want 
to sacrifice flexibility.


> 
> 
> > - How do you handle functional writes to message buffers no part of the
> network?
> 
> I am assuming that only other buffers are the ones in the
> cache/directory/dma/ controllers. A separate call is made to functionally
> access these buffers.
> 
> >
> > As you already know, I'm in favor of just creating a list of message
> > buffers by modifying the MessageBuffer constructor.  After seeing the
> > number of files you had to change with this existing patch, I'm further
> > convinced that is the better approach.  This current patch seems quite
> > hackish, and adding this support to Garnet is only going to be uglier.
> > What can I do to convince you that the MessageBuffer approach is better?
> > Or in other words, can you explain exactly what you don't like about the
> > MessageBuffer approach?
> >
> 
> I think that going via network is better. Firstly, the list that would
> need to be created for accessing the buffers in the memory system, already
> exists as part of the network hierarchy we have. Secondly, it seems to
> that it would easier to debug if traverse the network in a structured
> manner rather than traversing a flat list.
> 

How is traversing the network plus calling all controllers to update their 
message buffers easier than just creating a flat list?  Precedence in the 
simulator is that creating a flat list is better.  For example, to drain the 
system, the flat list of SimObjects is traversed, not the configuration graph.  

Brad

_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to