On Sun, Aug 2, 2009 at 1:17 PM, nathan binkert<[email protected]> wrote: >> Also, I think with this flag in place we ought to be able to get rid >> of the tlb_mode setting; the TLB can just look and see whether >> isInstFetch() is true to decide how to handle the request... does >> anyone agree or disagree? > > Well, mode is read/write/execute. You're proposing figuring just > execute, or all of it?
I had only noticed that it was used for selecting between the ITB and DTB in the inorder code, so that's all I was thinking of. I agree that it only makes sense to make the change if we get rid of it entirely, which should be feasible. > I'm for the change if it's all of it, but the > funny thing is that the command is only in the packet object, so you > don't know by looking at a request object if it is a read or write. > (Which actually seems pretty odd.) That does seem strange on the face of it; the intuition behind that is that it's the "common" fields that don't vary from packet to packet, and read vs write can vary if you have a writeback cache where a write coming in can turn into a read-exclusive request going out. That's still conceptually a write though, so you could flag the request as a write, but then it's redundant wrt the packet command field, and I'm not sure that redundancy buys us anything other than avoiding having this conversation every once in a while. > Also, is it always unambiguous how > to map a command to read or write? (My guess is probably, but i'm > just checking.) Calling pkt->isWrite() should do it. (Note that RMW ops return true for both isRead() and isWrite(), so you'd definitely need to use the latter.) > Finally, any ideas how Ruby will deal with any of > this? Not really... you're more on top of the Ruby interface details than I am. Assuming that our TLBs still get used even when Ruby is providing the memory system, I can't see how it would matter, since the end result is still the same and I don't believe the tlb mode that we're getting rid of gets passed to Ruby. Steve _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
