Hey Nilay, I just wanted to say another "good work" to you in tackling this issue. I am looking forward to seeing an updated patch here. After the the ISCA deadline, I'd like to lock in on this issue more and help where I can (It's at least pretty important to my future work).
I've admittedly lost some touch on the specifics of this thread, but I would agree with you on that it's probably the best path to get the simpler version to work (at the head of the store buffer) first since that would be a subset of the more complicated version anyway (cases where it's not at the head of the store buffer). Right? On Mon, Nov 14, 2011 at 5:27 PM, Nilay Vaish <[email protected]> wrote: > On Fri, 11 Nov 2011, Nilay Vaish wrote: > > I am thinking of implementing a modified version Brad's second proposal. >> Each store accesses the cache at most twice. Once, when the store is >> committed, following cases can happen -- >> * store is at the head of the store buffer, then issue write req to >> memory system >> * store is not at the head of the store buffer. If architecture has TSO >> as memory model, then issue a read exclusive request to the memory system. >> Else if a relaxed model is in place, a write request is sent to the memory >> system. >> >> Once the store reaches the head of the store buffer, the actual store is >> issued in case of TSO. Even if the store buffer receives an invalidation >> for some address to which a store exists in the buffer, the read ex request >> would not be issued again. >> >> > Before starting the implementation for this scheme, I had implemented the > scheme in which only the store at the head of the store queue is allowed to > be in flight. > > For past two-three days, I have been trying to write the code for the > scheme described above. As of now, it seems to me that I am writing this > code by trying to debug the error I observe when running the simulation. > Given the complexity of the code, adding this feature would only complicate > the code further. And given that we want TSO and Alpha's memory model to > co-exist, it seems to me that we will be making this code lot more complex > than it is today. > > My opinion is that we should go with the simple implementation, rather > than going for the aggressive approach and complicating the code further. > > > -- > Nilay > ______________________________**_________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mailman/listinfo/gem5-dev> > -- - Korey _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
