Hi Brad, Yes, the new atomic support also requires the sequencer to have a pointer to the cache controller. The code that is in the repository now is a hack of the slicc protocol code generator. The code is inserted in the middle of the wakeup function in the cache controller. The new uncommited code instead specifies several functions for the cache controller, so that instead the Sequencer calls those functions upon encountering atomics. It is better this way because the Sequencer has much more useful information about the atomic and so it is easier for it to make a decision.
All in all, the Sequencer needs to call the controller because the atomic operations block access to a specific cache block for a specific cache controller. It is harder to block the access anywhere else other than the cache controller. Hope this helps. Polina On Tue, Dec 1, 2009 at 2:08 PM, Beckmann, Brad <brad.beckm...@amd.com>wrote: > Hi, > > > > This question is mostly for Derek, but I figured that others at Wisconsin > may be able to answer it as well. I notice that the current Ruby atomic > support requires the sequencer to have direct access to its associated L1 > cache controller, rather than just via the mandatory queue. Derek recently > told me that he has some changes to how atomics are supported in Ruby. Does > that new atomic support also require the sequencer to have a pointer to the > cache controller? > > > > The reason I ask is it impacts the new unified configuration support. We > can make it work as is, I just wanted to confirm that the effort was worth > it. > > > > Thanks, > > > > Brad > > > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > >
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
